[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]
Você deve fazer as atualizações de segurança frequentemente. A grande maioria
de exploits existentes é resultado de vulnerabilidades conhecidas que não foram
corrigidas a tempo, como este paper by Bill
Arbaugh
(apresentando no IEEE Symposium on Security and Privacy em
2001) explica. Atualizações estão descritas em Executar uma atualização de segurança,
Seção 4.2.
O Debian oferece uma ferramenta específica para verificar se o sistema precisa de atualização (veja o programa Tiger abaixo), mas muitos usuários preferem verificar manualmente se as atualizações de segurança estão disponíveis.
Se você configurou o seu sistema como descrito em Executar uma atualização de segurança, Seção 4.2 você só precisa fazer:
# apt-get update # apt-get upgrade -s
O primeiro comando baixa a lista de pacotes disponíveis nos sources de pacotes configurados. A opção -s faz somente uma simulação, isto é, não baixa ou instala os pacotes e sim diz quais devem ser baixados/instalados. Você poderá saber que pacotes foram consertados pelo Debian e estão disponíveis para atualização. Por exemplo:
# apt-get upgrade -s Reading Package Lists... Done Building Dependency Tree... Done 2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Inst cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable) Inst libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable) Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable) Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
Neste exemplo, você pode observar que precisa atualizar os pacotes cvs e
cupsys, os quais estão sendo retornados do arquivo de atualização de segurança
do woody. Se quiser entender porque estes pacotes são necessários, vá
em http://security.debian.org
e
verifique quais Alertas de Segurança do Debian foram publicados e estão
relacionados com esses pacotes. Neste caso, os alertas relacionados são
DSA-233
(para cvs) e DSA-232
(para
cupsys).
Um outro método para atualização de segurança automática é uso do
cron-apt
. Este pacote fornece uma ferramente para atualizar o
sistema em intervalos regulares (usando um job do cron). Ele faz a atualização
da lista de pacotes e baixa os pacotes novos por padrão. Ele também pode ser
configurado para enviar mails para o administrador do sistema.
Note que você pode querer verificar a versão da distribuição, como descrito em Checando releases das distribuições, Seção 7.4.2, se você pretende atualizar automaticamente o seu sistema (mesmo somente baixando pacotes). Caso contrário você não terá certeza que os pacotes baixados realmente são de origem confiável.
Se você está procurando por uma ferramenta que rapidamente verifique e relate
vulnerabilidades de segurança do sistema, tente o pacote tiger
.
Este pacote fornece um conjunto de scripts shell, programas em C e arquivos de
dados usados para realizar auditorias de segurança. O pacote do Debian
GNU/Linux tem melhorias adicionais voltadas para a distribuição Debian,
provendo mais funcionalidade do que os scripts Tiger fornecidos por TAMU (ou
até TARA, uma versão do tiger distribuida por ARSC). Veja o arquivo
README.Debian
e a página de manual tiger(8)
para mais
informações.
Uma dessas melhorias é o script deb_checkadvisories. Este script recebe uma lista de DSA's (Alertas de Segurança do Debian) e verifica com a base de pacote instalada, informando quaisquer pacotes que estão vulneráveis conforme o Time de Segurança do Debian. Ele é um pouco mais genérico do que o script check_signatures implementado pelo Tiger, pois este é capaz de verificar MD5sums de programas vulneráveis conhecidos.
Já que o Debian atualmente não distribui uma lista de MD5sums de programas vulneráveis conhecidos (utilizado por algum outro sistema operacional como Sun Solaris), a solução check-against-DSA é usada. Ambas as soluções DSA e MD5sums sofrem do problema de que as assinaturas devem ser atualizadas regularmente.
Atualmente esse problema é resolvido fazendo novas versões do pacote Tiger, mas
o mantenedor do pacote nem sempre pode fazer uma nova versão toda vez que um
DSA é anunciado. Uma melhoria interessante, que ainda não está implementada,
poderia fazer este trabalho pró-ativamente. Isto é, fazer o download dos DSAs
da web, construir a lista de DSAs e então rodar a verificação. Os DSAs são
atualmente atualizados pelo mantenador do CVS local das fontes WML utilizadas
para desenvolver http://security.debian.org
(o
servidor web).
Um programa para analisar sintaticamente os DSAs publicados, receber através de
e-mail ou disponibilizar no security.debian.org, e então gerar o arquivo usado
pelo deb_checkadvisories
para confirmar vulnerabilidades seria
bem-vindo. Envie-o como um relatório de bug para o pacote tiger
.
Uma vez instalado, a verificação mencionada é definida pela configuração padrão
do programa (veja /etc/tiger/cronrc
):
# Check for Debian security measures every day at 1 AM # 1 * * deb_checkmd5sums deb_nopackfiles deb_checkadvisories #
Existe uma verificação adicional que você pode querer acrescentar apesar de
ainda não fazer parte dos scripts padrões do cron
. O script
check_patches funciona da seguinte maneira:
execute apt-get update
verifique se há novos pacotes disponíveis
Se você estiver rodando o Debian estável e adicionar a linha de fonte
apt
security.debian.org em /etc/apt/sources.list
(como descrito em Executar uma
atualização de segurança, Seção 4.2), este script será capaz de informar se
existem pacotes novos que devem ser instalados. Desde que somente os pacotes
com configurações modificadas são atualizações de segurança, então você tem
apenas tudo o que queria.
Claro que isso não funcionará se você estiver rodando a versão testing ou sid/unstable, já que atualmente, os novos pacote provavelmente têm mais funcionalidades que as atualização de segurança.
Você pode adicionar este script para realizar as verificações em um
cron
job (no arquivo de configuração) e no tigercron
poderá enviar um email (para o endereço especificado na diretiva
Tiger_Mail_RCPT em /etc/tiger/tigerrc
) com os novos
pacotes:
# Check for Debian security measures every day at 1 am # 1 * * deb_checkmd5sums deb_nopackfiles check_patches #
Você também pode dar uma olhada em secpack
que é um
programa não-oficial escrito por Fruhwirth Clemens e usado para fazer
atualizações de segurança a partir do site security.debian.org com suporte a
verificação de assinaturas.
Ao menos que você tenha tempo para aplicar patches de segurança toda vez que uma vulnerabilidade é descoberta, você não deve usar a versão instável do Debian para sistemas em produção. A principal razão para isto é que não há atualizações de segurança para a versão unstable (veja Como a segurança é tratada na testing e unstable?, Seção 11.3.7).
O fato é que algumas questões relacionadas à segurança podem surgir na distribuição instável e não na stable. Isto porque novas funcionalidades são constantemente adicionadas às aplicações, assim como novas aplicações são incluídas sem serem totalmente testadas.
Para se fazer atualizações de segurança na versão unstable, você pode fazer uma atualização completa para nova versão (que atualiza muito mais do que somente os pacotes afetados). Embora existam algumas exceções, patches de segurança geralmente só são portadas para a versão stable. A idéia principal é que entre as atualizações, nenhum código novo deve ser adicionado, somente consertos para questões importantes.
Se você estiver utilizando uma versão em testing, existem algumas questões relacionadas à disponibilidade das atualizações de segurança que devem ser levadas em conta:
Quando um conserto de segurança é preparado, o Time de Segurança lança o patch para a versão stable (desde que a estável é geralmente algumas versões menor ou maior atrás). Os mantenedores de pacotes são responsáveis por preparar o patch para a versão unstable, geralmente baseado nos novos lançamentos. Algumas vezes as alterações acontecem quase ao mesmo tempo e em outras um dos lançamentos disponibiliza o conserto de segurança antes. Os pacotes para a distribuição stable são testados bem mais a fundo do que para a unstable, já que esta irá fornecer na maioria dos casos a última versão do lançamento (que pode incluir novos e desconhecidos bugs)
Atualizações de segurança estão disponíveis para a versão unstable geralmente quando os mantenedores fazem um novo pacote e para a versão stable quando o Time de Segurança publica um DSA e faz um novo upload. Observe que nada disso altera a versão em testing.
Se nenhum (novo) bug é detectado na versão unstable do pacote, ele passa para a versão em testing depois de algum tempo. Este tempo geralmente é de dez dias, embora dependa de algumas coisas como a prioridade de upload e se o pacote está ou não bloqueado para entrar em teste por causa de dependências. Note que se o pacote estiver bloqueado, a prioridade de upload não afetará o tempo que ele leva para entrar na versão em teste.
Esse comportamento pode ser alterado conforme o estado de lançamento da distribuição. Quando uma distribuição está perto de ser lançada, o Time de Segurança ou os mantenedores dos pacotes devem fornecer atualizações de segurança diretamente para a versão em teste.
Primeiro de tudo, atualizações automáticas não são recomendadas, já que o administrador deve revisar os DSAs (alertas de segurança do Debian) e entender o impacto causado pela atualização de segurança no sistema.
Para atualizar o seu sistema automaticamente você deve:
Configurar o apt
para que os pacotes que você não queria atualizar
continuem na mesma versão, usando o recurso de pinning do
apt
ou marcando-os como hold no dpkg
ou
dselect
.
Para fixar os pacotes em uma determinada versão, você deve editar o arquivo
/etc/apt/preferences
(veja apt_preferences(5)
) e
adicionar:
Package: * Pin: release a=stable Pin-Priority: 100
FIXME: verifcar se a configuração está OK.
Você também pode usar o cron-apt como descrito em Verificando automaticamente por atualizações com o cron-apt,
Seção 9.1.2. Ative-o para instalar os pacotes baixados ou adicione uma
entrada no cron
para que a atualização seja feita diariamente, por
exemplo:
apt-get update && apt-get -y upgrade
A opção -y faz com que o apt
assuma 'sim' para todos
os prompts que aparecerão durante a atualização. Em alguns casos, é melhor
você usar a opção --trivial-only em vez de
--assume-yes (equivalente a -y). [39]
Configure o cron
para que o debconf
não faça nenhuma
pergunta durante as atualizações, funcionando de forma não-interativa. [40]
Verifique os resultados da execução do cron
, que enviará um mail
para o superusuário (ao menos que a variável de ambiente MAILTO
seja alterada no script).
Uma alternativa mais segura seria usar a opção -d (ou
--download-only), que irá fazer o download dos pacotes necessários
mas não os instalará. Então se a execução do cron
mostrar que o
sistema precisa ser atualizado, esta atualização pode ser feita manualmente.
E para finalizar estas tarefas, o sistema deve ser configurado apropriadamente para fazer o download das atualizações de segurança como discutido no Executar uma atualização de segurança, Seção 4.2.
Entretanto, isto não é recomendado para a versão unstable sem que haja uma análise cuidadosa, uma vez que pode tornar o seu sistema inutilizável se algum pacote importante que estiver com um bug sério for instalado. A testing é um pouco mais segura com relação a isto, já que os bugs sérios podem ser detectados antes do pacote ser movido para a versão em teste (embora, você não tenha atualizações de segurança disponíveis para todos).
Se você tem uma distribuição mista, isto é, uma instalação stable com
alguns pacotes atualizados para a versão em testing ou
unstable, você pode utilizar o recurso de pinning assim como
a opção --target-release do apt
para atualizar
somente aqueles pacotes que devem ser atualizados. [41]
A verificação de integridade é feita baseada na informação completa do sistema gerada depois da instalação (ex. o snapshot descrito em Fazendo um snapshot do sistema, Seção 4.18) e deve ser feita de tempos em tempos. Com a verificação de integridade é possível detectar modificações no sistema de arquivos feitas por um intruso ou por algum erro do administrador do sistema.
As verificações de integridade devem ser, se possível, feitas offline [42] . Isto é, utilizar outro sistema operacional para fazer a verificação, evitando assim um falso senso de segurança (ex. falsos negativos) produzido por, por exemplo, rootkits instalados. A base de dados de integridade verificada pelo sistema também deve ser usada em uma mídia somente leitura.
Você deve considerar fazer a verificação online utilizando qualquer ferramenta de verificação de integridade do sistema de arquivos disponíveis (descrito em Verificando a integridade do sistema de arquivos, Seção 4.16.3), se você não puder deixar o sistema fora do ar. Entretanto, algumas precauções devem ser levadas em conta como a utilização de uma base de dados da integridade somente para leitura e assegurar que a ferramenta de verificação de integridade (e o kernel do sistema operacional) não esteja sendo usada.
Algumas das ferramentas citadas nesta seção, como aide
,
integrit
ou samhain
já estão preparadas para fazer
revisões periódicas (através do crontab nas duas primeiras e através de um
daemon standalone na samhain
) e pode avisar o administrador por
diferentes canais (geralmente e-mail, mas samhain
também pode
enviar pages, traps SNMP ou alertas do syslog) quando ocorrem alterações no
sistema de arquivos.
Claro que se você for executar uma atualização do sistema, deve ser tirado novamente um snapshot para acomodar as alterações sofridas durante a atualização de segurança.
O Debian GNU/Linux inclue ferramentas para detecção de intrusão, que é nada mais do que a prática de detectar atividades impróprias ou maliciosas no seu sistema local, ou outros sistemas que estejam na sua rede privada. Este tipo de defesa é importante se o sistema for altamente crítico ou você for realmente paranóico. Os tipos mais comuns de detecção de intrusão são detecção estatística de anomalias e detecção baseada em algum padrão.
Sempre tenha em mente que para melhorar a segurança do sistema com a instalação de uma dessas ferramentas, você deve ter um mecanismo de alertas e respostas elaborado. Detecção de intrusão é perda de tempo se você não for alertar ninguém.
Quando um ataque em particular for detectado, a maioria das ferramentas de
detecção de intrusão irá tanto gerar um log do evento com o
syslogd
enviar um e-mail para o super-usuário (o destinatário
geralmente é configurável). Um administrador precisa configurar propriamente
as ferramentas para que falsos positivos não gerem alertas. Alertas também
devem informar um ataque que pode estar acontecendo e ele não será útil,
digamos, um dia depois que ocorrer. Então tenha certeza que existe uma
política apropriada para tratar os alertas e que os mecanimos técnicos para
implementar essa política sejam viáveis.
Uma fonte interessante de informaçòes é CERT's
Intrusion Detection Checklist
As ferramentas de detecção de intrusão baseada em rede monitoram o tráfego em um segmento de rede e utilizam essas informações como fonte dos dados para serem analisados. Especificamente, os pacotes da rede são examinados, e eles são verificados para ver se existe uma certa assinatura de pacotes maliciosos.
O Snort
é um sniffer de pacotes bastante flexível ou logger que
detecta os ataques utilizando um dicionário de assinatura de ataques. Ele
detecta uma variedade de ataques e probes, como estouro de buffer, varredores
de portas stealth, ataques CGI, probes SMB e muito mais. O Snort
também tem a capacidade de gerar alertas em tempo real. Você pode usar o
snort
tanto para uma série de máquinas na sua rede quanto para o
seu próprio servidor. Ele é uma ferramenta que deve ser instalada em todos os
roteadores para manter os olhos na rede. Para instalá-lo basta usar o
apt-get install snort, seguir as perguntas, e verificar o log.
Para um arcabouço de segurança um pouco mais amplo, veja Prelude
.
O pacote snort
do Debian tem diversas configurações de segurança
ativadas por padrão. Entretanto, você deve customizar o programa tendo em
mente os serviços particulares que você roda no seu sistema. Também seria
interessante procurar algumas verificações específicas para estes serviços.
Nota: Os pacotes do snort disponíveis no woody não estão tão
atualizados e podem até estar bugados
,
você pode obter um backport (e assinatura) do Snort fornecido pelo mantenedor
do pacote em http://people.debian.org/~ssmeenk/snort-stable-i386/
.
Existem outras ferramentas mais simples que podem ser utilizadas para detectar
ataques em rede. O portsentry
é um pacote interessante que pode
ajudar a descobrir varreduras contra seus hosts. Outras ferramentas como
ippl
ou iplogger
também podem detectar alguns ataques
IP (TCP e ICMP), mesmo que eles não forneçam os tipos de técnicas que o
snort
fornece.
Você pode testar qualquer uma dessas ferramentas com o pacote do Debian
idswakeup
, um script em shell que gera alarmes falsos e inclue
muitas assinaturas de ataques comuns.
A detecção de intrusão baseada em host envolve o carregamento de um software no sistema a ser monitorado e que utiliza arquivos de log e/ou os programas de auditoria de sistema como uma fonte de dados. Ele procura por processos suspeitos, monitora acesso ao host e pode até monitorar alterações em arquivos críticos do sistema.
O tiger
é uma antiga ferramenta de detecção de intrusão que foi
portado para o Debian desde a versão do Woddy. Ele fornece verificações de
casos comuns relacionados a furo de segurança, como uso de força bruta nas
senhas, problemas no sistema de arquivo, comunicação de processos e outras
formas de comprometer o superusuário. Este pacote também inclue verificações
de segurança específicas para o Debian como: verificações de MD5sums de
arquivos instalados, localização de arquivos que não pertencem a nenhum pacote
e análise de processos locais que estão em estado de escuta. A instalação
padrão configura o tiger
para rodar diariamente, gerando um
relatório que é enviado para o superusuário sobre possíveis comprometimentos no
sistema.
Ferramentas de análise de log, como logcheck
também podem ser
usadas para detectar tentativas de intrusão. Veja Usando e personalizando o
logcheck
, Seção 4.12.1.
Em adição, pacotes que monitoram a integridade do sistema de arquivo (veja Verificando a integridade do sistema de arquivos, Seção 4.16.3) podem ser perfeitamente úteis na detecção de anomalias em um ambiente seguro. É muito provável que uma intrusão efetiva irá modificar alguns arquivos no sistema de arquivo local para driblar a política de segurança local, instalar Trojans, ou criar usuários. Tais eventos podem ser detectados com os programas para verificação de integridade do arquivo.
Loadable kernel modules são arquivos contendo componentes carregados dinamicamente no kernel e são usados para expandir a funcionalidade do mesmo. O benefício principal de se usar módulos é a habilidade de adicionar dispositivos adicionas, como uma placa de rede Ethernet ou uma placa de som, sem ter que aplicar um patch no código-fonte e recompilar todo o kernel. Entretanto, os crackers vêm usando os LKMs para criar rootkits (knark e adore), abrindo backdoors nos sistemas GNU/Linux.
Os backdoors LKM estão cada vez mais sofisticados e mais difíceis de serem
detectados que os rootkits tradicionais. Eles podem esconder processos,
arquivos, diretórios e até mesmo conexões sem precisar modificar o código fonte
dos binários. Por exemplo, um LKM malicioso pode forçar o kernel a esconder
processos específicos do procfs
, então mesmo uma cópia original do
binário ps
pode não listar informações precisas sobre os processos
que estão rodando no sistema.
Existem duas estratégias para defender seu sistema de rootkits LKM, a defesa pró-ativa e a reativa. O trabalho de detecção pode ser simples e fácil, ou difícil e cansativo, dependendo da estratégia escolhida.
A vantagem para este tipo defesa é que ela previne qualquer dano ao sistema
logo de início. Uma estratégia para esse tipo de defesa é conhecida como
pegar eles primeiro, que é carregar na memória um módulo LKM designado
para proteger o sistema de outros LKMs maliciosos. A segunda estratégia é
remover algumas funcionalidades do próprio kernel. Por exemplo, você pode
desabilitar a opção de carrergar módulos no kernel. Entretanto, note que
existem rootkits que podem funcionar até mesmo neste caso. Alguns deles podem
mexer com o /dev/kmem
(memória do kernel) diretamente para
torná-los indetectáveis.
O Debian GNU/Linux tem poucos pacotes que podem ser usados para montar uma defesa pró-ativa:
kernel-patch-2.4-lsm
- LSM é o arcabouço para os Módulos de
Segurança do Linux.
lcap
- Uma interface amigável para remover as
funcionalidades (controle de acesso) do kernel, fazendo o sistema mais
seguro. Por exemplo, executando lcap CAP_SYS_MODULE [43] irá remove a funcionalidade
de carregar módulos (mesmo para o super-usuário). [44] Para mais informações sobre
as funcionalidades do kernel você deve verificar a seção Kernel development
de
Jon Corbet na LWN (Dezembro 1999)
Se você realmente não precisa de muitos recursos do kernel no seu sistema
GNU/Linux, você pode desabilitar o suporte aos módulos carregáveis durante a
configuração do kernel. Para desabilitar este suporte, somente altere o
CONFIG_MODULES=n durante o estágio de configuração da construção do seu kernel,
ou no arquivo .config
. Isto irá prevenir os rootkits LKM, mas
você irá perder esta funcionalidade poderosa no kernel do Linux. Desabilitar a
opção para carregar módulos no kernel pode muitas vezes sobrecarregar o kernel.
Neste caso, é melhor deixar o kernel com o suporte.
A vantagem da defesa reativa é que ela não consome os recursos do sistema. Ela
trabalha comparando a tabela de chamadas ao sistema com uma cópia autêntica
conhecida, o arquivo em disco System.map
. Claro que a defesa
reativa somente notificará ao administrador do sistema depois que o sistema já
estiver sido comprometido.
A detecção de alguns root-kits no Debian pode ser efetuada com o pacote
chkrootkit
. O programa Chkrootkit
verifica por sinais de
diversos rootkits conhecidos no sistema alvo, mas isto não deve ser um teste
final.
Uma outra ferramenta auxiliar é o KSTAT
(Kernel Security
Therapy Anti Trolls) feita pelo grupo S0ftproject. O KSTAT busca na área de
memória do kernel (/dev/kmem
) informações sobre o host alvo para
ajudar o administrador do sistema a encontrar e remover LKMs maliciosos.
Esta é provavelmente a mais instável e divertida seção, apenas espero que algumas das ideias "duh, isso parece loucura" possam ser realizadas. A seguir algumas idéias para melhorar a segurança — talvez geniais, paranóicas, loucas ou até inspiradas dependendo do seu ponto de vista.
Brincando com o PAM. Como citado no artigo Phrack 56 PAM, a coisa legal do PAM é que "Você é limitado somente pelo o que pode imaginar". É verdade. Imagine efetuar login de root somente através de impressão digital ou verificação de retina ou cartão de criptografia (por que usei a conjunção OU em vez de E?).
Gravação fascista de logs. Eu prefiro me referir à toda discussão anterior acima como um "esquema leve de logs". Se você quiser fazer um esquema real de logs, pegue uma impressora com papel de formulário contínuo, e envie todos os logs para ela. Parece engraçado, mas é realmente confiável e as informações não podem ser sobrescritas ou apagadas.
Distribuição de CD. Essa idéia é muito simples de se realizar e oferece uma boa segurança. Crie uma distribuição Debian segura, com as regras de firewall apropriadas. Coloque ela em uma imagem ISO inicializável e grave em um CDROM. Agora você tem uma distribuição somente leitura, com mais ou menos 600 MB de espaço para os serviços. Tenha certeza de que todos os dados que devem ser escritos sejam feitos pela rede. É impossível para um intruso ter acesso de leitura/escrita no sistema, e qualquer alteração feita pelo intruso pode ser desfeita em uma reinicilização do sistema.
Desabilite a capacidade de carregar módulos. Como discutido anteriormente, quando você desabilita o uso de módulos em tempo de compilação do kernel, muitos backdoors baseados em kernel ficam impossíveis de serem implementados, pois a maioria deles é baseada na instalação de módulos do kernel modificados.
Grave os logs por um cabo serial. (contribuido por Gaby Schilders) Já que os servidores ainda têm portas serial, imagine ter um sistema de gravação de logs para um série de servidores. O sistema de logs é desconectado da rede, e conectado aos servidores via um multiplexador de porta serial (Cyclades ou algo do tipo). Agora faça com que todos os seus servidores gravem o log através da porta serial. A máquina de log vai somente aceitar o texto plano como entrada nas portas serial e escrever em um arquivo de log. Conecte um gravador de CD/DVD e grave o arquivo de log quando atingir a capacidade máxima da mídia.
Altere as atribuições do arquivo usando chattr
. (dica tirada do
Tips-HOWTO, escrito por Jim Dennis). Depois de uma instalação limpa e
configuração inicial, use o programa chattr
com o atributo
+i para que os arquivos não sejam modificados (o arquivo não pode
ser apagado, renomeado, criado link ou escrito algo nele). Defina este
atributo em todos os arquivos que estão em /bin
,
/sbin/
, /usr/bin
, /usr/sbin
,
/usr/lib
e também nos arquivos do kernel no root. Você também
pode fazer uma cópia de todos os arquivos do /etc/
, usando o
tar
ou algo do tipo e marcar o arquivo comprimido como imutável.
Esta estratégia irá ajudar a limitar o estrago que você poderá causar estando
logado como root. Você não poderá sobrescrever arquivos por engano, nem deixar
o sistema inoperante digitando por engano um espaço no comando rm
-fr
(você pode ainda fazer um monte de estragos no seus dados —
mas suas bibliotecas e seus binários estarão seguros.)
Esta estratégia também faz com que uma variedade de exploits de segurança e de negação de serviços (DoS) sejam difíceis ou impossíveis de serem realizados (já que a maioria deles conta com a permissão de sobrescrever um arquivo através de algum programa SETUID que a princípio não esteja fornecendo um comando shell arbitrário).
Uma inconveniência desse tipo de estratégia aparece durante a compilação e
instalação de alguns binários do sistema. Por outro lado, isso previne que um
comando make install
sobrescreva os arquivos. Quando você se
esquece de ler o Makefile e executa um chattr -i
nos arquivos a
serem sobrescritos, (também nos diretórios nos quais serão adicionados os
arquivos) - o comando make falha. Então você deve usar o comando
chattr
para desativar a flag de imutável e rodar o make novamente.
Você também pode optar por mover os binários e as bibliotecas antigas para
dentro de um diretório .old/ ou para um arquivo tar por exemplo.
Note que esta estratégia também impede que você atualize seu próprio sistema de
pacotes, já que os arquivos que os pacotes a serem atualizados fornecem não
podem ser sobrescritos. Você pode fazer um script ou usar outro mecanismo
parecido para desativar a permissão de imutável em todos os binários antes de
fazer um apt-get update
.
Você pode brincar um pouco com o cabeamento UTP cortando 2 ou 4 fios, tornando um cabo de tráfego unidirecional. Então use pacotes UDP para enviar informação para uma máquina de destino que atuaria como um servidor de log seguro ou até mesmo um sistema de armazenamento de cartões de crédito.
FIXME: É preciso de conteúdo mais específico para o Debian
Um honeypot é um sistema feito para auxiliar os administradores de sistemas a descobrir como os crackers sondam a máquina em busca de exploits. O sistema é configurado com a expectativa e objetivo de ser sondado, atacado e potencialmente invadido. Aprendendo as ferramentas e os métodos empregados pelo cracker, um administrador de sistema pode saber como melhor proteger seus sistemas e a rede.
Um sistema Debian GNU/Linux pode ser facilmente configurado como um honeypot, se você dedicar tempo para implementar e monitorá-lo. Simplesmente configure o servidor falso com um firewall e algumas ferramentas de detecção de intrusão de rede, coloque ele na Internet, e espere. Tome o cuidado de que se o sistema for invadido você seja imediatamente alertado (veja A importância dos logs e alertas, Seção 4.12), desta forma você poderá tomar providências necessárias e paralizar a invasão quando tiver informações suficientes. Abaixo estão alguns dos pacotes e questões importantes quando estiver configurando seu honeypot:
A tecnologia de firewall que irá usar (fornecidade pelo kernel do Linux).
syslog-ng
, útil para enviar logs do honeypot para um servidor
syslog remoto.
snort
, para configurar a captura de todo o tráfego de rede de
entrada para o honeypot e detectar os ataques.
osh
, um SETUID root, segurança aprimorada, shell restrita com
sistema de log (veja o artigo de Lance Spitzner abaixo).
Claro que todos os daemons serão usados por seu servidor honeypot falso (então não assegurar o honeypot).
The Deception Toolkit, que utiliza um sistema de indução ao erro para reagir
aos ataques. Homepage: Deception
Toolkit
Verificadores de integridade (veja Verificando a integridade do sistema de
arquivos, Seção 4.16.3) e o Toolkit do Coroner (tct
) para
fazer auditorias pós-ataque.
Você pode ler mais sobre como construir honeypots no excelente artigo de Lanze
Spitzner To
Build a Honeypot
(das séries "Know your Enemy"), ou de
David Raikow Building
your own honeypot
. O Projeto Honeynet
também fornece
informações valiosas relacionadas à construção de honeypots e auditoria dos
ataques feitos nelas.
[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]
Securing Debian Manual
v3.1,mailto:jfs@debian.org