[ 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
Capítulo 9 - Antes do comprometimento do sistema


9.1 Atualizando continuamente o sistema

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.


9.1.1 Verificando manualmente quais atualizações de segurança estão disponíveis

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).


9.1.2 Verificando automaticamente por atualizações com o cron-apt

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.


9.1.3 Usando o Tiger para verificar automaticamente atualizações de segurança

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:

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
     #

9.1.4 Outros métodos para atualizações de segurança

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.


9.1.5 Evite usar versões instáveis

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.


9.1.6 Evite usar versões em teste

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:

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.


9.1.7 Atualizações automáticas no sistema Debian GNU/Linux

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:

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]


9.2 Faça verificações de integridade periódicas

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.


9.3 Configure um sistema de Detecção de Intrusão

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


9.3.1 Detecção de intrusão baseada em rede

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.


9.3.2 Detecção de intrusão baseada em host

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.


9.4 Evitando os rootkits


9.4.1 Loadable Kernel Modules (LKM)

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.


9.4.2 Detectando rootkits

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.


9.4.2.1 Defesa pró-ativa

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:

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.


9.4.2.2 Defesa reativa

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.


9.5 Idéias Geniais/Paranóicas — o que você pode fazer

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.


9.5.1 Construindo um honeypot

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:

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, Mon, 10 Feb 2014 17:06:00 +0000

Javier Fernández-Sanguino Peña jfs@debian.org
Autores, Seção 1.1