<!-- CVS revision of original english document "1.6" -->
<!-- original version: 1.6 -->
<!-- last translator: philipe@debian-ba.org -->
<!-- last revision: carlinha@debian-ba.org -->
<!-- logging - ? -->


<!-- <chapt>Antes do incidente -->
<chapt>Antes do comprometimento do sistema

<sect id="keep-up-to-date">Atualizando continuamente o sistema

<p>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 <url
id="http://www.cs.umd.edu/~waa/vulnerability.html" name="paper by
Bill Arbaugh"> (apresentando no IEEE Symposium on Security and
Privacy em 2001) explica. Atualizações estão descritas em <ref
id="security-update">.

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

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

<p>Se você configurou o seu sistema como descrito em 
<ref id="security-update"> você só precisa fazer:

<example>
# apt-get update
# apt-get upgrade -s
</example>

<!--The first line will download the list of packages available from your
configured package sources.-->

<p>O primeiro comando baixa a lista de pacotes disponíveis nos
sources de pacotes configurados. A opção <tt>-s</tt> faz somente uma simulação,
isto é, <em>não</em> 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:
<example>
# 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)
</example>
<p>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 <em>woody</em>. Se quiser entender porque estes pacotes são
necessários, vá em 
<url id="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
<url id="http://www.debian.org/security/2003/dsa-233" name="DSA-233"> (para cvs)
e
<url id="http://www.debian.org/security/2003/dsa-232" name="DSA-232"> (para cupsys).

<sect1 id="cron-apt">Verificando automaticamente por atualizações com o cron-apt

<p>Um outro método para atualização de segurança automática é uso do 
<package>cron-apt</package>. 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.

<p>Note que você pode querer verificar a versão da 
distribuição, como descrito em <ref id="check-releases">,
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.

<sect1>Usando o Tiger para verificar automaticamente atualizações de segurança

<p> Se você está procurando por uma ferramenta que rapidamente 
verifique e relate vulnerabilidades de segurança do sistema, tente 
o pacote <package>tiger</package>. 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 <file>README.Debian</file> e a página de manual 
<manref section="8" name="tiger"> para mais informações.

<p>Uma dessas melhorias é o script <tt>deb_checkadvisories</tt>.
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 <tt>check_signatures</tt> 
implementado pelo Tiger, pois este é capaz de verificar MD5sums de
programas vulneráveis conhecidos.

<p>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 <em>check-against-DSA</em> é 
usada. Ambas as soluções DSA e MD5sums sofrem do problema de que as 
assinaturas devem ser atualizadas regularmente.

<p>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 <url id="http://security.debian.org"> (o servidor
web).

<p>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 <prgn>deb_checkadvisories</prgn> para confirmar vulnerabilidades seria 
bem-vindo. Envie-o como um relatório de bug para o pacote <package>tiger</package>.

<p>Uma vez instalado, a verificação mencionada é definida pela configuração
padrão do programa (veja <file>/etc/tiger/cronrc</file>):

<example>
# Check for Debian security measures every day at 1 AM
#
1 * *   deb_checkmd5sums deb_nopackfiles deb_checkadvisories
#
</example>

<p>Existe uma verificação adicional que você pode querer acrescentar apesar
de ainda não fazer parte dos scripts padrões do <prgn>cron</prgn>. O script
<tt>check_patches</tt> funciona da seguinte maneira:

<list>

<item>execute <tt>apt-get update</tt>

<item>verifique se há novos pacotes disponíveis

</list>

<p>Se você estiver rodando o Debian estável e adicionar a linha de fonte
<prgn>apt</prgn> security.debian.org em <file>/etc/apt/sources.list</file> (como
descrito em <ref id="security-update">), 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.

    <!-- REVISAR: Since the only packages
changing in this setup are security updates, then you have just what
you wanted. -->

<p>Claro que isso não funcionará se você estiver rodando a versão
<em>testing</em> ou <em>sid/unstable</em>, já que atualmente, os
novos pacote provavelmente têm mais funcionalidades que as atualização
de segurança.

<p> Você pode adicionar este script para realizar as verificações em um 
<prgn>cron</prgn> job (no arquivo de configuração) e no <prgn>tigercron</prgn>
poderá enviar um email (para o endereço especificado na diretiva
<tt>Tiger_Mail_RCPT</tt> em <file>/etc/tiger/tigerrc</file>) com os novos
pacotes:

<example>
# Check for Debian security measures every day at 1 am
#
1 * *   deb_checkmd5sums deb_nopackfiles check_patches
#
</example>

<sect1>Outros métodos para atualizações de segurança

<P>Você também pode dar uma olhada em 
<url id="http://therapy.endorphin.org/secpack/" name="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.

<sect1>Evite usar versões instáveis

<p>Ao menos que você tenha tempo para aplicar patches de segurança toda
vez que uma vulnerabilidade é descoberta, você <em>não</em> 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
<em>unstable</em> (veja <ref id="sec-unstable">).

<p>O fato é que algumas questões relacionadas à segurança podem surgir
na distribuição instável e <em>não</em> na <em>stable</em>. Isto porque
novas funcionalidades são constantemente adicionadas às aplicações,
assim como novas aplicações são incluídas sem serem totalmente 
testadas.

<p>Para se fazer atualizações de segurança na versão <em>unstable</em>,
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 <em>stable</em>. A idéia principal é que entre as atualizações,
<em>nenhum código novo</em> deve ser adicionado, somente consertos para
questões importantes.

<sect1>Evite usar versões em teste

<p>Se você estiver utilizando uma versão em <em>testing</em>, existem algumas
questões relacionadas à disponibilidade das atualizações de segurança que 
devem ser levadas em conta:

<list>

<item>Quando um conserto de segurança é preparado, o Time de Segurança 
lança o patch para a versão <em>stable</em> (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 <em>unstable</em>, 
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 <em>stable</em> são testados bem mais a fundo do que 
para a <em>unstable</em>, já que esta irá fornecer na maioria dos
casos a última versão do lançamento (que pode incluir novos e 
desconhecidos bugs)

<item>Atualizações de segurança estão disponíveis para a versão 
<em>unstable</em> geralmente quando os mantenedores fazem um 
novo pacote e para a versão <em>stable</em> quando o Time de 
Segurança publica um DSA e faz um novo upload. Observe que nada
disso altera a versão em <em>testing</em>.

<item>Se nenhum (novo) bug é detectado na versão <em>unstable</em> 
do pacote, ele passa para a versão em <em>testing</em> 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.

</list>

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

<sect1>Atualizações automáticas no sistema Debian GNU/Linux

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

<p>Para atualizar o seu sistema automaticamente você deve:

<list>

<item>Configurar o <prgn>apt</prgn> para que os pacotes que você não
queria atualizar continuem na mesma versão, usando o recurso de 
<em>pinning</em> do <prgn>apt</prgn> ou marcando-os como <em>hold</em>
no <prgn>dpkg</prgn> ou <prgn>dselect</prgn>.

<p>Para fixar os pacotes em uma determinada versão, você deve editar o arquivo
<file>/etc/apt/preferences</file> (veja <manref section="5"
name="apt_preferences">) e adicionar:

<example>
  Package: *
  Pin: release a=stable
  Pin-Priority: 100
</example>
<p>FIXME: verifcar se a configuração está OK.

<item>Você também pode usar o cron-apt como descrito em <ref id="cron-apt">.
Ative-o para instalar os pacotes baixados ou adicione uma entrada 
no <prgn>cron</prgn> para que a atualização seja feita diariamente, por exemplo:

<example>
  apt-get update && apt-get -y upgrade
</example>

<p>A opção <tt>-y</tt> faz com que o <prgn>apt</prgn> assuma 'sim' para 
todos os prompts que aparecerão durante a atualização. Em alguns casos, é
melhor você usar a opção <tt>--trivial-only</tt> em vez de 
<tt>--assume-yes</tt> (equivalente a <tt>-y</tt>).

<footnote>Você também pode optar por usar a opção <tt>--quiet</tt> (<tt>-q</tt>)
para diminuir a quantidade de informações de saída do <prgn>apt-get</prgn>. Caso 
nenhum pacote esteja sendo instalado, nenhuma informação é mostrada na tela.</footnote>

<item>Configure o <prgn>cron</prgn> para que o <prgn>debconf</prgn>
não faça nenhuma pergunta durante as atualizações, funcionando de forma 
não-interativa. <footnote>Note que alguns pacotes podem 
<em>não</em> usar o <prgn>debconf</prgn> e a atualizações irão parar 
para que o usuário entre com alguma configuração.</footnote>

<item>Verifique os resultados da execução do <prgn>cron</prgn>, que 
enviará um mail para o superusuário (ao menos que a variável de ambiente
<tt>MAILTO</tt> seja alterada no script).

</list>

<p>Uma alternativa mais segura seria usar a opção <tt>-d</tt> (ou
<tt>--download-only</tt>), que irá fazer o download dos pacotes 
necessários mas não os instalará. Então se a execução do <prgn>cron</prgn>
mostrar que o sistema precisa ser atualizado, esta atualização pode
ser feita manualmente.

<p>E para finalizar estas tarefas, o sistema deve ser configurado 
apropriadamente para fazer o download das atualizações de segurança 
como discutido no <ref id="security-update">.

<p>Entretanto, isto não é recomendado para a versão <em>unstable</em> 
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 <em>testing</em> é um pouco mais <em>segura</em> 
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ê <em>não</em> 
tenha atualizações de segurança disponíveis para todos).

<p>Se você tem uma distribuição mista, isto é, uma instalação
<em>stable</em> com alguns pacotes atualizados para a versão em <em>testing</em> 
ou <em>unstable</em>, você pode utilizar o recurso de <em>pinning</em> 
assim como a opção <tt>--target-release</tt> do <prgn>apt</prgn> para
atualizar <em>somente</em> aqueles pacotes que devem ser atualizados. 
<footnote>Isso é uma prática comum, já que muitos usuários preferem manter
o sistema estável, podendo atualizar alguns pacotes para a versão 
<em>unstable</em> para obter novas funcionalidades. Esta necessidade surge devido
ao desenvolvimento de alguns projetos ser mais rápido que o tempo gasto 
entre os lançamentos da versão <em>stable</em> do Debian.</footnote>

<sect id="periodic-integrity">Faça verificações de integridade periódicas

<p>A verificação de integridade é feita baseada na informação completa do
sistema gerada depois da instalação 
(ex. o <em>snapshot</em> descrito em <ref id="snapshot">) 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.

<p>As verificações de integridade devem ser, se possível, feitas offline
<footnote>
Uma maneira fácil de fazer isso é utilizar um Live CD, tipo o 
<url id="http://www.knoppix-std.org/" name="Knoppix Std"> que inclue 
ambas as ferramentas de verificação de arquivos e a base de dados de integridade
do seu sistema.
</footnote>
. 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.

<p>Você deve considerar fazer a verificação online utilizando
qualquer ferramenta de verificação de integridade do sistema de 
arquivos disponíveis (descrito em <ref id="check-integ">), 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.

<P>Algumas das ferramentas citadas nesta seção, como
<prgn>aide</prgn>, <prgn>integrit</prgn> ou <prgn>samhain</prgn> 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
<prgn>samhain</prgn>) e pode avisar o administrador por diferentes
canais (geralmente e-mail, mas <prgn>samhain</prgn> também pode enviar
pages, traps SNMP ou alertas do syslog) quando ocorrem alterações no
sistema de arquivos.

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

</sect>
<sect id="intrusion-detect">Configure um sistema de Detecção de Intrusão

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

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

<p>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 <prgn>syslogd</prgn> 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.

<p>Uma fonte interessante de informaçòes é
<url id="http://www.cert.org/tech_tips/intruder_detection_checklist.html"
name="CERT's Intrusion Detection Checklist">

<sect1>Detecção de intrusão baseada em rede

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

<p>O <package>Snort</package> é 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 <prgn>Snort</prgn>
também tem a capacidade de gerar alertas em tempo real. Você pode usar o 
<prgn>snort</prgn> 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 
<tt>apt-get install snort</tt>, seguir as perguntas, e verificar o log. 
Para um arcabouço de segurança um pouco mais amplo, veja 
<url id="http://www.prelude-ids.org" name="Prelude">.

<p>O pacote <package>snort</package> 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.

<p><em>Nota</em>: Os pacotes do snort disponíveis no woody não estão tão 
atualizados e podem até estar <url
id="http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg02105.html"
name="bugados">, você pode obter um backport (e assinatura) do Snort
fornecido pelo mantenedor do pacote em
<url id="http://people.debian.org/~ssmeenk/snort-stable-i386/">.

<p>Existem outras ferramentas mais simples que podem ser utilizadas 
para detectar ataques em rede. O <package>portsentry</package> é um
pacote interessante que pode ajudar a descobrir varreduras contra 
seus hosts. Outras ferramentas como <package>ippl</package> ou
<package>iplogger</package> também podem detectar alguns ataques IP 
(TCP e ICMP), mesmo que eles não forneçam os tipos de técnicas que
o <prgn>snort</prgn> fornece.

<p>Você pode testar qualquer uma dessas ferramentas com o pacote do 
Debian <package>idswakeup</package>, um script em shell que gera 
alarmes falsos e inclue muitas assinaturas de ataques comuns.

<sect1>Detecção de intrusão baseada em host

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

<p>O <package>tiger</package> é 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 <prgn>tiger</prgn> para rodar diariamente, gerando 
um relatório que é enviado para o superusuário sobre possíveis 
comprometimentos no sistema.

<p>Ferramentas de análise de log, como <package>logcheck</package> 
também podem ser usadas para detectar tentativas de intrusão. Veja 
<ref id="custom-logcheck">.

<p>Em adição, pacotes que monitoram a integridade do sistema de arquivo 
(veja <ref id="check-integ">) 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.

<sect>Evitando os rootkits

<sect1 id="LKM">Loadable Kernel Modules (LKM)

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

<p>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 <file>procfs</file>, 
então mesmo uma cópia original do binário <prgn>ps</prgn> pode não
listar informações precisas sobre os processos que estão rodando no 
sistema.

<sect1>Detectando rootkits

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

<sect2 id="proactive">Defesa pró-ativa

<p>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 <em>pegar eles primeiro</em>, 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 <file>/dev/kmem</file> 
(memória do kernel) diretamente para torná-los indetectáveis.

<p>O Debian GNU/Linux tem poucos pacotes que podem ser usados para 
montar uma defesa pró-ativa:

<list>

<item><package>kernel-patch-2.4-lsm</package> - LSM é o arcabouço para 
os Módulos de Segurança do Linux.

<item><package>lcap</package> - Uma interface amigável para remover as
<em>funcionalidades</em> (controle de acesso) do kernel, fazendo o 
sistema mais seguro. Por exemplo, executando <tt>lcap
CAP_SYS_MODULE</tt>
<footnote>
Existem mais de 28 funcionalidades incluídas:
<tt>CAP_BSET</tt>,
<tt>CAP_CHOWN</tt>,
<tt>CAP_FOWNER</tt>,
<tt>CAP_FSETID</tt>,
<tt>CAP_FS_MASK</tt>,
<tt>CAP_FULL_SET</tt>,
<tt>CAP_INIT_EFF_SET</tt>,
<tt>CAP_INIT_INH_SET</tt>,
<tt>CAP_IPC_LOCK</tt>,
<tt>CAP_IPC_OWNER</tt>,
<tt>CAP_KILL</tt>,
<tt>CAP_LEASE</tt>,
<tt>CAP_LINUX_IMMUTABLE</tt>,
<tt>CAP_MKNOD</tt>,
<tt>CAP_NET_ADMIN</tt>,
<tt>CAP_NET_BIND_SERVICE</tt>,
<tt>CAP_NET_RAW</tt>,
<tt>CAP_SETGID</tt>, 
<tt>CAP_SETPCAP</tt>,
<tt>CAP_SETUID</tt>,
<tt>CAP_SYS_ADMIN</tt>,
<tt>CAP_SYS_BOOT</tt>,
<tt>CAP_SYS_CHROOT</tt>,
<tt>CAP_SYS_MODULE</tt>,
<tt>CAP_SYS_NICE</tt>,
<tt>CAP_SYS_PACCT</tt>,
<tt>CAP_SYS_PTRACE</tt>,
<tt>CAP_SYS_RAWIO</tt>,
<tt>CAP_SYS_RESOURCE</tt>,
<tt>CAP_SYS_TIME</tt>, and
<tt>CAP_SYS_TTY_CONFIG</tt>. Todas elas podem ser desativadas para
melhorar a segurança do seu kernel.
</footnote>
irá remove a funcionalidade de carregar módulos (mesmo para o
super-usuário).
<footnote>
Você não precisa instalar o <package>lcap</package> para fazer isto,
mas é melhor do que configurar o <file>/proc/sys/kernel/cap-bound</file> 
na mão.
</footnote>
Para mais informações sobre as funcionalidades do kernel você deve verificar
a seção <url id="http://lwn.net/1999/1202/kernel.php3" 
name="Kernel development"> de Jon Corbet na LWN (Dezembro 1999) 

</list>

<p>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
<file>.config</file>. 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.

<sect2>Defesa reativa

<p>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 
<file>System.map</file>. Claro que a defesa reativa somente notificará
ao administrador do sistema depois que o sistema já estiver sido 
comprometido.

<p>A detecção de alguns root-kits no Debian pode ser efetuada com o 
pacote <package>chkrootkit</package>. O programa <url name="Chkrootkit"
id="http://www.chkrootkit.org"> verifica por sinais de diversos 
rootkits conhecidos no sistema alvo, mas isto não deve ser um teste 
final.

<p>Uma outra ferramenta auxiliar é o <url name="KSTAT"
id="http://www.s0ftpj.org/en/site.html"> (Kernel Security Therapy Anti
Trolls) feita pelo grupo S0ftproject. O KSTAT busca na área de
memória do kernel (<file>/dev/kmem</file>) informações sobre o host 
alvo para ajudar o administrador do sistema a encontrar e remover 
LKMs maliciosos.

<sect>Idéias Geniais/Paranóicas &mdash; o que você pode fazer

<p>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 
 &mdash; talvez geniais, paranóicas, loucas ou até inspiradas 
 dependendo do seu ponto de vista.

<list>

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

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

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

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

<item>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. 
<!--(contributed by Gaby Schilders) As
long as servers still have serial ports, imagine having one dedicated
logging system for a number of servers. The logging system is
disconnected from the network, and connected to the servers via a
serial-port multiplexer (Cyclades or the like). Now have all your
servers log to their serial ports, write only. The log-machine only
accepts plain text as input on its serial ports and only writes to a
log file. Connect a CD/DVD-writer, and transfer the log file to it
when the log file reaches the capacity of the media. Now if only they
would make CD writers with auto-changers... Not as hard copy as direct
logging to a printer, but this method can handle larger volumes and
CDROMs use less storage space.-->

<item>Altere as atribuições do arquivo usando <prgn>chattr</prgn>.
(dica tirada do Tips-HOWTO, escrito por Jim Dennis). Depois de uma instalação 
limpa e configuração inicial, use o programa <prgn>chattr</prgn> com 
o atributo <tt>+i</tt> 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
<file>/bin</file>, <file>/sbin/</file>, <file>/usr/bin</file>, 
<file>/usr/sbin</file>, <file>/usr/lib</file> e também nos arquivos
do kernel no root. Você também pode fazer uma cópia de todos os arquivos 
do <file>/etc/</file>, usando o <prgn>tar</prgn> ou algo do tipo e
marcar o arquivo comprimido como imutável.

<p>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  <prgn>rm -fr</prgn> (você pode ainda fazer 
um monte de estragos no seus dados &mdash; mas suas bibliotecas e 
seus binários estarão seguros.)

<p>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 <em>não esteja fornecendo um comando shell arbitrário</em>).

<p>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 <prgn>make install</prgn> 
sobrescreva os arquivos. Quando você se esquece de ler o Makefile e 
executa um <prgn>chattr -i</prgn> nos arquivos a serem sobrescritos,
(também nos diretórios nos quais serão adicionados os arquivos) 
&dash; o comando make falha. Então você deve usar o comando <prgn>chattr</prgn> 
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.

<p>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
<prgn>apt-get update</prgn>.

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

</list>

<sect1>Construindo um honeypot

<p>FIXME: É preciso de conteúdo mais específico para o Debian

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

<p>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 <ref id="log-alerts">), 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:

<list>

<item>A tecnologia de firewall que irá usar (fornecidade pelo kernel
do Linux).

<item><package>syslog-ng</package>, útil para enviar logs do honeypot 
para um servidor syslog remoto.

<item><package>snort</package>, para configurar a captura de todo 
o tráfego de rede de entrada para o honeypot e detectar os ataques.

<item><package>osh</package>, um SETUID root, segurança aprimorada, 
shell restrita com sistema de log (veja o artigo de Lance Spitzner
abaixo).

<item>Claro que todos os daemons serão usados por seu servidor 
honeypot falso (então <em>não</em> assegurar o honeypot).

<item>The Deception Toolkit, que utiliza um sistema de indução ao erro para
reagir aos ataques.
Homepage: <url id="http://all.net/dtk/dtk.html" name="Deception Toolkit">

<item>Verificadores de integridade (veja <ref id="check-integ">) e o 
Toolkit do Coroner (<package>tct</package>) para fazer auditorias pós-ataque.

</list>

<p>Você pode ler mais sobre como construir honeypots no excelente artigo de
Lanze Spitzner <url
id="http://www.net-security.org/text/articles/spitzner/honeypot.shtml"
name="To Build a Honeypot"> (das séries "Know your Enemy"), ou de 
David Raikow <url
id="http://www.zdnetindia.com/techzone/resources/security/stories/7601.htm"
name="Building your own honeypot">. O <url
id="http://project.honeynet.org/" name="Projeto Honeynet"> também fornece
informações valiosas relacionadas à construção de honeypots e auditoria 
dos ataques feitos nelas.


