Conceitos para Perícia Forense Computacional

Prévia do material em texto

1
Conceitos para perícia forense computacional
Adriano Mauro Cansian
UNESP – Universidade Estadual Paulista
Depto. de Ciências da Computação e Estatística
Laboratório ACME! de Pesquisa em Segurança1
Campus de São José do Rio Preto
R. Cristóvão Colombo, 2265
15055-000, São José do Rio Preto, SP, Brasil
adriano@ieee.org
Abstract
This work presents basic concepts about forensics analysis on computers and networks that have been
involved in some security incident. Two main strings of action are developed. Initially are presented
concepts that allow to understand the current panorama of problems related with attacks to networks and
computers systems. In this direction, a presentation on behavior and methodology of the attacker is made,
following a philosophy that is necessary to know the enemy, to be able to analyze and combat it. Basic
concepts on the collection of auditorship data, and the importance of these logs on network devices are
argued. Also, fundaments related with organization’s security policies are focused. In one second part, the
concepts of forensic skill and collection of evidences for security events analysis are indexed. Aspects on
data capture and freezing are dealt, as well as the reconstruction of last and past events. This methodology
is adopted based on the importance of evidences collection for a standardization, which allows to analyze
and to prove the occurred events.
Resumo
Este trabalho apresenta uma discussão a respeito de conceitos fundamentais para a realização de perícia
forense em computadores e redes que tenham experimentado algum incidente de segurança. São abordadas
duas linhas principais de ação. Inicialmente são apresentados conceitos que permitem entender o panorama
atual dos problemas relacionados com os ataques às redes e sistemas de computadores. Neste sentido, é
feita uma apresentação sobre o comportamento e a metodologia do atacante, dentro de uma filosofia de que
é necessário conhecer o inimigo, para poder analisa-lo e combate-lo. São discutidos conceitos básicos sobre
a coleta de dados de auditoria, e a importância destes registros nos equipamentos de uma rede. Também são
enfocados conceitos relacionados com políticas de segurança da organização. Numa segunda parte, são
discutidos os conceitos de perícia forense e coleta de evidências para análise de eventos de segurança. São
tratados aspectos sobre captura e congelamento dos dados, bem como a reconstrução de eventos passados.
Adota-se uma metodologia de trabalho baseada na importância da coleta de evidências dentro de um padrão
sistematizado, o qual permita analisar e comprovar os eventos ocorridos.
1 http://www.acme-ids.org
2
I. INTRODUÇÃO
Apesar de analistas internacionais considerarem que os crimes em redes de computador representam
perdas de milhões de dólares, é muito difícil estimar qual o real montante de prejuízos envolvidos
anualmente, principalmente porque, na grande maioria das vezes, os ataques não são relatados em função
da perda de prestígio e credibilidade que eles podem representar [1] . Sabe-se também que o risco tende a
aumentar pois, com o passar dos anos e com a disseminação de informações (notadamente através da
Internet), houve um significativo avanço no entendimento de como os sistemas operam. Isso fez com que
intrusos se tornassem verdadeiros especialistas em determinar e explorar vulnerabilidades a fim de obterem
acessos privilegiados. Estes mesmos intrusos também passaram a se utilizar de técnicas de ataque de difícil
rastreamento e identificação. Freqüentemente usam diversos níveis de ocultação e dissimulação, antes de
realizar um ataque. Procuram despistar o alvo, e raramente são surpreendidos, realizando ataques massivos,
que evidenciem facilmente uma atividade suspeita ou anormal. Além disso costumam cobrir seus rastros,
de forma que as atividades realizadas no sistema penetrado não são facilmente descobertas [2]. De uma
forma abrangente, Garfinkel e Spafford [3] definem um sistema computacional seguro como sendo aquele
que se comporta da maneira esperada. A observação do comportamento esperado, em comparação com o
comportamento apresentado, pode ser entendido como o nível de confiança do sistema, e indica o quanto
podemos confiar no seu funcionamento. O comportamento esperado é formalizado dentro da política de
segurança do sistema, e regula as metas que este deve cumprir. Dessa forma, um evento de segurança
normalmente está relacionado a uma violação de normas ou procedimentos, que dependem do sistema
computacional em uso.
Uma definição mais rígida de segurança de computadores baseia-se na confidencialidade, na integridade e
na disponibilidade dos recursos do sistema [4]. Confidencialidade requer que a informação seja acessível
somente àquelas pessoas autorizados para tal; integridade requer que a informação permaneça intacta e
inalterada por acidentes ou ataques, e disponibilidade requer que o sistema computacional funcione
adequadamente, sem degradação de acesso, fornecendo recursos aos usuários autorizados, quando eles
assim necessitarem. A confidencialidade pode ser importante para o sucesso comercial ou até mesmo
sobrevivência de uma empresa; integridade pode ser importante para um hospital que mantém históricos
médicos de seus pacientes e os utiliza para tomadas de decisões em situações críticas. A disponibilidade de
um recurso pode ser fator determinante no controle de um sistema de tráfego aéreo ou possibilidade de
3
retaliar um ataque militar. Nesta definição, um sistema computacional que não forneça todos os recursos
necessários no devido momento, é tratado como não-confiável, uma vez que o conjunto representa os
requisitos de segurança e, isolados ou em conjunto, podem representar um risco em potencial.
O que se pretende discutir aqui é que, apesar de possuir muitos pontos comuns, a definição de segurança
em sistemas de computadores é extremamente flexível e dependente de uma série de fatores e
características. É preciso entender a segurança de um sistema computacional não como sendo um item
particular, um produto ou uma determinada medida ou ação. A segurança deve ser interpretada como um
processo, o qual envolve elementos tecnológicos complexos ou não, mas que deve considerar também
aspectos humanos. Um sistema seguro deve conter um conjunto de ações que permitam proteger seus
dados, e seus recursos, de acesso não-autorizado, de intromissão ou de bloqueio de uso. Sabe-se que
segurança é obtida a custo da conveniência e facilidade de uso dos sistemas. Pode-se afirmar também que a
facilidade de conectividade de computadores é inversamente proporcional à segurança.
Controle de acesso e modelos de proteção não são muito úteis contra atacantes internos ou contra o
comprometimento dos módulos de autenticação de acesso a um sistema computacional [5]. Se uma senha
de acesso a uma conta do sistema é fraca, e foi comprometida, as medidas de controle de acesso não têm
como prevenir a perda ou corrupção dos dados aos quais aquela conta tem acesso. Em geral, métodos
estáticos de proteção podem simplesmente ser insuficientes, ou podem tornar o sistema extremamente
restritivo aos seus próprios usuários. Por exemplo, considere que uma determinada técnica de segurança
não seja capaz de prevenir ou detectar violação de política de segurança resultante de buscas generalizadas
em arquivos de dados; e se por essa razão o acesso a todos os arquivos tenha que ser controlado
rigorosamente, o sistema pode se tornar ineficiente para o uso proposto.
Um outro aspecto a se considerar é que a dificuldade em se produzir softwares complexos, funcionais e
isentos de erros ainda é uma questão a ser resolvida. Diversas falhas em sistemas freqüentemente se
manifestam como vulnerabilidades na segurança. Há que se considerar também, que os ciclos de vida útil
dos softwaresestão se tornando cada vez mais curtos devido à competitividade do mercado. Isso
geralmente tem como efeito colateral uma programação pobre e inadequada, ou então leva a testes e
validações insuficientes ou mal planejados, fatos estes que só vem a agravar o problema. Desse modo,
acredita-se que sistemas computacionais, e principalmente redes, continuarão potencialmente inseguros
ainda por muito tempo [6].
4
Dentro deste contexto, a análise e a perícia de computadores que tenham passado por algum tipo de
violação ou ataque, torna-se uma matéria importante no conjunto de ações de um processo de segurança. A
perícia tem diversos aspectos relevantes. Dois deles se destacam: primeiramente, ela é importante porque
permite que se entenda o que aconteceu, de forma a corrigir falhas que tenham sido cometidas no processo.
Em segundo lugar, ao olharmos para o passado, interpretando o que aconteceu, pode ser possível coletar
evidências necessárias a identificar o atacante, de tal forma que possam ser adotadas medidas legais ou
jurídicas pertinentes. Novamente, uma violação de segurança é fortemente dependente da política de
utilização do sistema, e deve ser entendida nesta particularidade. Este fato é muito importante e será
memorado insistentemente ao longo deste trabalho. A perícia de computadores é uma tarefa que envolve a
consideração de aspectos objetivos e subjetivos, por vezes associada a análise tecnológica, mas por outras
vezes fortemente dependente de questões comportamentais e de perfil, relativas ao atacante. Desta forma,
torna-se fundamental o conhecimento acerca de como pensam e agem os inimigos.
II. PANORAMA ATUAL
Os rumos da Segurança
A sofisticação dos ataques e ferramentas de intrusões e, por conseqüência, a eficiência dos intrusos está
aumentando. O conhecimento vem sendo passado aos intrusos menos hábeis pelos atacantes mais
experientes. Além disso, complexidade das redes cresce a passos largos, resultando sempre em novas
oportunidades de violações de segurança, tanto em nível local, como provenientes do mundo exterior,
principalmente através da Internet [7]. Em função destes aspectos, atualmente, o número de intrusões e
ataques a redes de computadores vem sofrendo taxas de crescimento significativas. A infra-estrutura de
informação tem muitos problemas de segurança fundamentais, os quais não podem ser resolvidos
rapidamente. O número de pessoas com conhecimento em segurança está aumentando, mas a uma taxa
significativamente menor que o aumento no número de usuários. O número de ferramentas de segurança
disponíveis está aumentando, mas não necessariamente tão rápido quanto a complexidade de softwares,
sistemas e redes. O número de equipes de resposta a incidentes tem crescido, entretanto a relação entre
pessoal de resposta a incidentes e usuários de Internet, e de redes em geral, está diminuindo [1]. Por razões
econômicas e mercadológicas, o ciclo de desenvolvimento e testes de produtos está sendo reduzido cada
vez mais, fazendo com que, novamente, apareçam outras possibilidades de exploração de vulnerabilidades.
5
Assim, empresas continuam produzindo softwares com vulnerabilidades, incluindo tipos onde a prevenção
já é bem compreendida, como por exemplo, problemas envolvendo falhas de buffer overflow [3].
Conhecendo o atacante
O perfil dos atacantes pode ser dividido genericamente em dois padrões: os atacantes provenientes do
meio interno, oriundos da própria organização, empresa ou instituição, e os atacantes externos,
normalmente provenientes da Internet [8]. É comum acreditar-se, erroneamente, que os ataques mais sérios,
e que causam mais prejuízos, são provenientes da Internet. Esta crença comum geralmente é compartilhada
em virtude da cobertura da mídia, que destaca, muitas vezes de forma sensacionalista, determinados casos
de hacking que ocorrem através da Internet. Entretanto, pesquisas recentes mostram que a maioria dos
ataques que envolvem perdas financeiras ocorrem, ou contam com a cooperação, de alguém de dentro das
próprias organizações atacadas [1].
Os atacantes oriundos do meio interno tem um comportamento mais complexo do que os atacantes
externos. As análises destes casos mostram que estes tipos de crimes eletrônicos, intrusões ou tentativas de
ataque ocorrem em virtude dos mesmos motivos pelos quais ocorrem a maioria dos crimes regulares. São
associados principalmente com cobiça, obtenção ilegal de dinheiro, lucro, riqueza ou acesso a recursos
adicionais ou restritos, ou ganho de vantagem competitiva, seja ela econômica, política ou pessoal.
Freqüentemente estão também ligados a revanches pessoais ou vinganças [9].
Em se tratando de violações de segurança provenientes do meio externo, o atacante tem sido sempre
alguém em busca de um alvo fácil, que não está em busca de algo específico. Entretanto, seu objetivo é
claro: ganhar acesso privilegiado, da maneira mais fácil possível, concentrando-se num número pequeno de
ferramentas e exploits, varrendo toda a Internet. Estes atacantes são denominados genericamente de script
kiddies [9]. Alguns são usuários avançados que desenvolvem suas próprias ferramentas, e deixam
backdoors sofisticados, ao passo que outros não têm a menor idéia do que estão fazendo.
Independentemente de suas habilidades, eles compartilham de uma estratégia comum: buscam
aleatoriamente por uma vulnerabilidade específica e, então, exploram aquela vulnerabilidade. Em algum
momento os atacantes encontrarão alguém vulnerável. A seleção aleatória de alvos é que torna o script
kiddie uma ameaça, pois ao não buscar alvos específicos, todos os sistemas estão potencialmente
ameaçados [10]. As ferramentas de busca de vulnerabilidades e ataques estão amplamente divulgadas, de
6
tal forma que qualquer pessoa pode obte-las e usa-las. Há um número crescente de atacantes fazendo uso
delas. Uma vez que a Internet, obviamente, não possui fronteiras, estas ameaças estão se espalhando
mundialmente. Os sistemas que os script kiddies estão procurando são aqueles não supervisionados, sem
registros de auditoria (“logs”), sem política de uso, desprotegidos, e fáceis de serem explorados. Ao
encontrarem algumas barreiras, eles geralmente mudam de alvo. Estes atacantes são motivados,
principalmente, por curiosidade, ganho de acesso a recursos computacionais restritos, distúrbios
comportamentais ligados a vandalismo e vontade de provocar danos, ou busca por atenção e projeção.
Padrões comportamentais ligados a revanche e vingança pessoal também são freqüentes. Obtenção de
vantagens financeiras aparecem em menor escala, mas também estão presentes, entretanto, com gravidade
inferior se comparados aos danos causados pelos atacantes internos. Entretanto, com o aumento gradativo
de operações comerciais ocorrendo por intermédio da Internet, é provável que esta característica venha a se
modificar.
Em resumo, há um senso comum de que os intrusos estão preparados e bem organizados. Os ataques,
provenientes da Internet ou internos, são fáceis, de baixo risco e muito difíceis de serem rastreados. As
ferramentas dos intrusos estão crescendo em sofisticação, são fáceis de usar, especialmente por novatos, e
são desenhadas para darem suporte a ataques em larga escala.
A metodologia dos atacantes
Tanto os ataques internos como os externos acontecem dentro de padrões bem definidos e de acordo com
uma seqüência de eventos que permitem estabelecer perfis ou padrões comportamentais. A metodologia
básica é simples: rastrear a rede, ou o computador alvo, buscando vulnerabilidades específicas,
estabelecendo uma base de dados de endereços IP que possam ser atacados. Assim que encontrar uma
vulnerabilidade, tentar explora-la, verificando se existe realmente a falha naquele equipamento [11]. Por
exemplo, atualmente muitos sistemas Linuxpossuem uma vulnerabilidade nativa no processo denominado
imapd . É feita uma busca por IPs válidos e ativos e desenvolve-se uma base de dados relacionando os
sistemas rodando Linux. Por intermédio de ferramentas específicas [12], verifica-se quais estão rodando
imapd vulnerável. A partir desta informação, os sistemas vulneráveis são explorados.
Um terreno fértil para a proliferação deste tipo de ataque é a ausência de monitoração e inspeção dos
computadores e redes. Muitas organizações não monitoram seus sistemas de forma alguma, e nunca
7
percebem que estão sendo atacados ou rastreados. São raros os sistemas com uma política clara e bem
definida e escrita sobre geração e inspeção regular de registros de auditoria (logs). Quando há logs, estes
não são sequer monitorados, nem automaticamente, nem por um humano. Os atacantes muitas vezes
buscam silenciosamente por um sistema que possam explorar e, ao ganharem acesso a este, encobrem seus
rastros eliminando registros de auditoria que eventualmente existam. Em seguida, utilizam o computador
comprometido como base de lançamento para outros ataques, ocultando sua posição real e colocando a
responsabilidade em outros administradores. A figura 1 mostra um esquema típico do desenvolvimento de
um ataque deste tipo.
Localizar
Sistema para
atacar
Obter acesso
privilegiado
( root )
Obter acesso
de nível de
usuário
Instalar
backdoors
Atacar outros
Roubar ou
alterar dados
Executar outras
atividades não
autorizadas
Encobrir os
rastros
Figura 1 – Comportamento típico da evolução de um ataque
Os resultados dos rastreamentos costumam ser armazenados, e são freqüentemente compartilhados com
outros atacantes. Quando uma nova vulnerabilidade aparece, os resultados de prospeções anteriores podem
ser usados como referência. Isso significa que, mesmo que um sistema não tenha sido rastreado
recentemente, ele não está isento de um ataque ou exploração de uma vulnerabilidade. Atacantes mais
sofisticados implementam e instalam programas que comprometem completamente os sistemas invadidos.
Estes programas maliciosos, conhecidos genericamente como trojans e backdoors, permitem acesso fácil e
oculto, de tal forma que os intrusos passam a usar o sistema sem serem notados. Os sistemas auditores,
indicadores de processos, ou mesmo filesystems, são freqüentemente comprometidos ou corrompidos e
tornam-se não confiáveis.
Quando se consideram ataques através da Internet, a questão temporal e os horário não são significativos.
8
Os ataques acontecem a qualquer hora e, muitas vezes, em larga escala. Existem ferramentas automáticas
de busca de vulnerabilidade, as quais operam 24 horas por dia, coletando dados. Além disso, há
abrangência mundial dos ataques, o que torna a questão de fuso horário pouco útil.
Ao contrário dos ataques que ocorriam no passado, as ferramentas de ataque, muitas das quais
disponíveis publicamente na Internet, são de fácil utilização e não exigem conhecimento específico em
redes ou em sistemas. Algumas são limitadas a um único propósito, com poucas opções, e outras são mais
versáteis, varrendo indiscriminadamente as redes ou os computadores alvo, a procura de vulnerabilidades.
Observando os atacantes
Informações importantes sobre as questões e eventos de segurança de um sistema podem ser obtidas por
intermédio dos registros de auditoria. Com alguns procedimentos simples é possível analisar questões
importantes, sem necessidade de investimentos ou recursos adicionais, além daqueles já regularmente
presentes na maioria dos sistemas. Através de informações básicas extraídas dos logs é possível determinar
se os sistemas foram examinados, o que os atacantes buscaram saber, que ferramentas ou técnicas foram
usadas e, eventualmente, se obtiveram sucesso. Informações significativamente úteis podem ser obtidas
através da simples análise e revisão de registros de auditoria. Entretanto, numa quantidade alarmante de
instalações, sequer existe qualquer sistema auditor, que registre as ocorrências e faça as contabilizações nos
sistemas. Também é importante ressaltar que sistemas de auditoria são freqüentemente os primeiros alvos
dos atacantes. Desta forma, é preciso proteger e garantir a integridade dos registros, caso contrário eles se
tornam inúteis. Há uma variedade de ferramentas que removem a presença dos atacantes dos registros, e
existem processos auditores (syslogd) corrompidos, os quais não registram as ações dos intrusos. O atacante
que tenha comprometido uma máquina pode estabelecer um ação automática que remova completamente
todos os registros, ou até mesmo uma partição inteira.
A importância dos logs
Em vista destas considerações, um dos principais aspectos que permite a execução de uma perícia bem
sucedida em um sistema, é a existência de registros de auditoria que estejam íntegros e confiáveis.
Independentemente de quão seguro é um computador ou uma rede, nunca será possível confiar totalmente
nos registros de um sistema que tenha sido comprometido. Isso dificulta, ou mesmo impossibilita, uma
9
perícia com sucesso. Desta forma, um dos principais conceitos a serem aplicados é o registro dos logs tanto
no sistema local, como num servidor de auditoria remoto.
Quando os registros de auditoria estão seguros num equipamento especial, existem maiores
possibilidades de sucesso ao se correlacionar e identificar padrões, ou rever rapidamente o que está
acontecendo em todas as máquinas da rede, usando só uma fonte de informação. Além disso, é possível
realizar comparações para determinar se os logs de origem foram modificados. Para alcançar estes
objetivos, uma recomendação é estabelecer um sistema de logs centralizado e dedicado, ou seja, que tenha
como função exclusiva a coleta de registros de auditoria, sem outros processos ou serviços. Uma opção
recomendável pode ser estabelecida, com baixo custo, por intermédio de uma máquina com sistema
operacional gratuito, como por exemplo Linux ou FreeBSD, agindo exclusivamente como coletora de logs
na rede local. Como exemplo da importância deste procedimento, podemos analisar o caso anteriormente
mencionado, onde a maioria dos Script Kiddies varre a rede em busca de uma única vulnerabilidade. Se os
logs indicam múltiplas conexões, do mesmo sistema remoto, na mesma porta, possivelmente trata-se de
uma varredura de alguma vulnerabilidade. A figura 2 apresenta um registro que permite correlacionar os
eventos de uma rede local. A figura 3 mostra a identificação de uma varredura genérica, e a figura 4 mostra
a identificação de um ataque de buffer overflow. A figura 5 mostra uma tentativa de exploração de uma
vulnerabilidade num servidor de http.
Servidor de logs - /var/adm/logs
Oct 09 22:13:48 wolverine in.ftpd[8723]: connect from 200.145.202.223
Oct 09 22:13:51 shadowcat in.ftpd[8723]: connect from 200.145.202.223
Oct 09 22:13:54 casper in.ftpd[8723]: connect from 200.145.202.223
Oct 09 22:13:57 fantasma in.ftpd[8723]: connect from 200.145.202.223
Oct 09 22:13:58 nimitz in.ftpd[8723]: connect from 200.145.202.223
Oct 09 22:14:02 bart in.ftpd[8723]: connect from 200.145.202.223
Figura 2 – Uma varredura ocorrida em servidores de ftp numa rede local, provenientes do computador
200.145.202.223
10
Servidor de logs - /var/log/secure
Oct 09 22:13:56 bart in.telnetd[22221]: connect from 200.145.202.223
Oct 09 22:13:56 bart imapd[22331]: connect from 200.145.202.223
Oct 09 22:13:56 bart in.fingerd[22249]: connect from 200.145.202.223
Oct 09 22:13:56 bart ipop3d[22322]: connect from 200.145.202.223
Oct 09 22:13:56 bart in.telnetd[22378]: connect from 200.145.202.223
Oct 09 22:13:56 bart in.ftpd[22541]: connect from 200.145.202.223
Oct 09 22:16:03 bart ipop3d[22542]: connect from 200.145.202.223
Oct 09 22:16:03 bart imapd[22543]: connect from 200.145.202.223Oct 09 22:16:04 bart in.fingerd[22546]: connect from 200.145.202.223
Oct 09 22:16:05 bart in.fingerd[22552]: connect from 200.145.202.223
Figura 3 – Uma varredura genérica na máquina “bart” da rede local, proveniente do computador
200.145.202.223, buscando por serviços disponíveis.
Servidor de logs - /var/log/secure
Oct 10 22:04:51 bart mountd[6688]: Unauthorized access by NFS client 200.145.202.223.
Oct 10 22:04:51 bart syslogd: Cannot glue message parts together
Oct 10 22:04:51 bart mountd[6688]: Blocked attempt of 200.145.202.223 to mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P3Û3À°^[Í~@3Ò3À~KÚ°^FÍ~@þÂuô1À°^BÍ~@~EÀubëb^V¬<ýt^FþÀt^Këõ°0þÈ~HFÿëì^°^B~
I^FþÈ~IF^D°^F~IF^H°f1ÛþÃ~IñÍ~@~I^F°^Bf~IF^L°*f~IF^N~MF^L~IF^D1À~IF^P°^P~IF^H°
fþÃÍ~@°^A~IF^D°f³^DÍ~@ë^DëLëR1À~IF^D~IF^H°fþÃÍ~@~Hð?1ÉÍ~@°?þÁÍ~@°?þÁÍ~@¸.bin@~
I^F¸.sh!@~IF^D1À~HF^G~Iv^H~IF^L°^K~Ió~MN^H~MV^LÍ~@1À°^A1ÛÍ~@èEÿÿÿÿýÿPrivet
ADMcrew~P(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(Oct 10 22:04:51
bart ^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^
E^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^ H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H(-^E
Figura 4 – Um ataque de buffer overflow, possivelmente com sucesso, proveniente de 200.145.2.223, tendo
como alvo a máquina “bart”.
11
Servidor de logs - /var/log/httpd/access_log
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/phf HTTP/1.0" 302 192
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/Count.cgi HTTP/1.0" 404 170
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/test-cgi HTTP/1.0" 404 169
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/php.cgi HTTP/1.0" 404 168
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/handler HTTP/1.0" 404 168
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/webgais HTTP/1.0" 404 168
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/websendmail HTTP/1.0" 404 172
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/webdist.cgi HTTP/1.0" 404 172
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/faxsurvey HTTP/1.0" 404 170
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/htmlscript HTTP/1.0" 404 171
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/pfdisplay.cgi HTTP/1.0" 404 174
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/perl.exe HTTP/1.0" 404 169
200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/wwwboard.pl HTTP/1.0" 404 172
200.145.202.223- - [10/Oct/2000:22:04:14 -0300] "GET /cgi-bin/ews/ews/architext_query.pl
HTTP/1.0" 404 187
200.145.202.223- - [10/Oct/2000:22:04:14 -0300] "GET /cgi-bin/jj HTTP/1.0" 404 163
Figura 5 – Uma tentativa de exploração de uma vulnerabilidade cgi-bin num servidor de http.
Conforme pode ser notado, a centralização dos logs assume um papel determinante na análise de
incidentes, e até mesmo na adoção de contra medidas. Entretanto, é importante mencionar que, obviamente,
se um serviço não está sendo auditorado ou registrado, não é possível determinar se o sistema foi rastreado
por aquela vulnerabilidade em particular. Além disso, outro aspecto importante que os peritos e analistas de
segurança devem considerar é o conhecimento acerca do que os registros de auditoria não podem fornecer.
Nem sempre os registros de auditoria resultam em informações úteis. Diversas ferramentas de ataque
possuem a opção de realizar varreduras com falsificação de endereços IP de origem (IP spoofing). Algumas
ferramentas automatizadas, como por exemplo o nmap [12], têm condições de falsificar a origem do ataque,
apresentando as varreduras como provenientes de 15 fontes diferentes, onde, entretanto, somente uma é a
real. Isso que torna bastante complexa a tarefa de determinar qual delas é a verdadeira. Também existem
técnicas de prospeção chamadas de “half-scan”. Esta é uma das técnicas de ocultação e dissimulação mais
freqüente. A varredura de half-scan usa só um pacote SYN do handshake de 3 vias do estabelecimento da
conexão TCP. Se o sistema remoto responde, a conexão é descartada com um pacote RST. Isso torna
bastante difícil a determinação da origem do ataque, apenas com a utilização dos registros de auditoria.
Neste caso, outras técnicas de análise precisam ser empregadas em conjunto. A figura 6 apresenta um
registro de auditoria de uma varredura de half-scan.
12
Servidor de logs - /var/adm/log
Oct 10 22:12:08 bart in.rshd[12717]: warning: can't get client address: Connection reset by peer
Oct 10 22:12:08 bart in.rshd[12717]: connect from unknown
Oct 10 22:12:09 bart in.timed[11718]: warning: can't get client address: Connection reset by peer
Oct 10 22:12:09 bart in.timed[12718]: connect from unknown
Oct 10 22:12:09 bart imapd[12719]: warning: can't get client address: Connection reset by peer
Oct 10 22:12:09 bart imapd[12719]: connect from unknown
Oct 10 22:12:09 bart ipop3d[12720]: warning: can't get client address: Connection reset by peer
Oct 10 22:12:09 bart ipop3d[12720]: connect from unknown
Oct 10 22:12:09 bart in.rlogind[12722]: warning: can't get client address: Connection reset by peer
Oct 10 22:12:09 bart in.rlogind[12722]: connect from unknown
Figura 6 – Um registro de auditoria de uma varredura de half-scan. Observe que a origem não pode ser
determinada
Como conclusão desta discussão, é importante ressaltar que os registros de auditoria tratam-se de uma
técnica simples que pode dizer muito sobre o atacante, desde que existam de fato, e estejam protegidos,
dentro de uma política bem definida. Uma vez que existem os registros, é possível identificar padrões e
correlações, permitindo até mesmo saber o que o intruso procura, ou (talvez) se ele teve ou não sucesso
[13].
III. FORENSICS
Uma introdução às técnicas de perícia forense em computadores e redes
Segundo Dan Farmer, a perícia computacional (forensics) “trata-se da captura e análise de evidências,
tanto quanto possível livres de estarem distorcidas ou tendenciosas, de tal forma a reconstruir determinados
dados ou o que aconteceu num sistema no passado”. Existem muitos desafios para a concussão destes
objetivos. Os sistemas são grandes e complexos, e mudam rapidamente, e os fatos e as evidências podem
estar ocultos em qualquer lugar, praticamente inexistindo softwares especializados disponíveis para tratar o
problema. Em função disso, exige-se muito conhecimento e experiência. É fácil coletar dados, mas a
análise é difícil. Além disso, esta análise exige muito tempo disponível. Associe-se a isto o problema de se
armazenar as grandes quantidades de dados resultantes de registros de auditoria e perícia.
Desta forma, um perito em análise de sistemas invadidos ou comprometidos necessita dispor de certas
características especiais, principalmente conhecimentos e habilidades relativas aos sistemas em questão, e
entendimento pleno acerca das implicações técnicas e legais de suas ações. Características concernentes a
espírito investigativo, suspeição e ética também são determinantes para o sucesso oufracasso das ações.
13
Ao se deparar com a condução de uma análise, o perito deve isolar e assegurar o perímetro, registrando a
“cena do crime” da melhor maneira possível, e conduzindo uma busca sistemática por evidências, coletando
e armazenando as que encontrar. A velocidade das ações é essencial, mas estas devem ser levadas em
consideração sem colocar em risco a coleta ou a veracidade das informações. O perito também deve ter em
mente que qualquer operação executada num sistema, causará alguma perturbação em seu estado. Além
disso, atacantes hábeis conhecem como as perícias são feitas e podem fornecer informações falsas em locais
específicos. Por esta razão, o perito nunca deve confiar plenamente no sistema em questão. Além deste fato,
outro aspecto importante diz respeito às leis vigentes na jurisdição, e as políticas da organização ou
instituição. Estas devem ser levadas em consideração, e respeitadas. Sem este procedimento, a coleta de
evidências pode ser inócua, ineficaz ou ilegítima.
Durante a busca por evidências, a preservação do estado do sistema é um fator determinante. Sem a
preservação do estado, pode acontecer de nunca se saber o passado. Desta forma, o perito sempre deve fazer
a coleta de dados de acordo com a ordem de volatilidade. Como ordem de volatilidade, deve-se considerar
coletar primeiramente os dados que forem mais efêmeros. A figura 7 apresenta a ordem de volatilidade dos
dados de perícia mais usados.
Registros de memória periférica, cache, etc...
Memória do kernel e física
Estado da rede, rotas, interfaces, etc...
Registros de memória periférica, cache, etc...
Processos em execução
Discos, filesystems, partições
Floppies, fitas e outros meios magnéticos
CD-ROMs, cópias impressas, etc...
Figura 7 – Ordem de volatilidade dos elementos de perícia mais utilizados. De cima para baixo, estão os
dados mais efêmeros, a serem coletados primeiramente.
Durante o tratamento de uma perícia em um sistema invadido ou atacado, alguns fatores muitas vezes
imperceptíveis são as maiores causas dos problemas e dificuldades. Não saber exatamente o que aconteceu,
e não conhecer contra quem, ou o que, se está lutando, são as maiores fontes dos problemas e dificuldades,
14
e por isso mesmo tornam-se os grandes desafios. Não saber em que dados confiar, dentre todos aqueles
disponíveis para a perícia, fazem com que problemas mais complexos requeiram uma preparação mais
elaborada, e um plano claro e bem definido para trata-los.
Se o analista de segurança ou o perito não conhece o sistema, a situação deve ser abordada ainda com
mais cautela. Deve-se conhecer e entender as limitações humanas, relativas a conhecimento técnico, para
abordagem do problema, da mesma forma como devem ser conhecidas as limitações técnicas do sistema, da
rede ou do equipamento sob análise. Esta abordagem deve ser adotada porque é muito fácil danificar,
corromper ou mascarar inadvertidamente as evidências da perícia. Mesmo uma análise simples num
sistema desconhecido pode ser arriscada, comprometendo definitivamente o trabalho a ser realizado, ou
mesmo a validade legal da análise. Desta forma, o analista de segurança deve trabalhar o menos possível
com os dados originais, ou seja, deve-se optar por providenciar uma imagem dos dados que serão usados e
deve-se operar sobre este conjunto, seguindo sempre a ordem de volatilidade discutida acima.
Dentro deste contexto, cumpre ressaltar novamente a importância de se aplicar sempre a política de
segurança da organização, da mesma forma que devem ser observadas a legislação da jurisdição em
questão. Com base nestes procedimentos, podem ser definidas metas claras de trabalho, de tal forma que a
perícia seja válida, tanto em termos institucionais como legais e jurídicos. Dentre os aspectos relativos à
política de segurança da organização, devem ser consideradas questões tais como: quem deve ser informado
dos eventos encontrados, o que deve ser registrado, o que fazer com as evidências, que seqüência de ações
devem ser seguidas, quais as prioridades, entre outros cuidados. Além disso, a maioria dos dados tem um
componente fortemente dependente do tempo e do horário. Em função disso, deve-se construir uma base de
tempo de referência, de tal forma que seja possível examinar uma certa janela de tempo, dentro daquela
linha, permitindo determinar os eventos que tenham acontecido durante aquele período
Congelamento de dados
Segundo a física quântica, o Princípio da Incerteza de Heisenberg define que é impossível determinar, ao
mesmo tempo, a velocidade e a posição de uma partícula, de tal forma que, ao se observar um deles, afeta-
se o estado do outro. Tratamento similar pode ser adotado em computadores e redes, ou seja, em
praticamente todos os casos, o ato de examinar ou coletar uma parte do sistema irá perturbar outros
componentes. É impossível capturar completamente o estado total do sistema, num dado momento do
15
tempo. Desta forma, o analista de segurança deve esforçar-se, ao máximo, para capturar uma representação
fiel do sistema, tão livre de distorções ou influências quanto possível. Esta é a essência da perícia, seja ela
em computadores, ou numa cena de crime convencional. O perito deve ter extremo cuidado para não tocar
em nada que possa perturbar a cena e, desta forma, comprometer a investigação.
Durante a análise também é importante considerar que o perito não poderá confiar nos dados que obtiver,
se não puder confiar nas suas ferramentas de trabalho. Portanto, é importante que o perito possua seu
próprio conjunto de ferramentas de software para inspeção, captura e análise dos dados. A composição do
conjunto de ferramentas irá depender sempre do tipo de sistema sob análise, e também do tipo de mídia
disponível para transporte e manipulação. Como exemplo, em se tratando de um sistema UNIX, algumas
ferramentas listadas a seguir podem ser consideradas indispensáveis. Opções semelhantes podem ser
adaptadas para outros sistemas:
• Ferramentas de coleta de dados tipo “statically linked”, tais como: dd, cp, du, cat, ls.
• Ferramentas de identificação de estado do sistema, tais como: netstat, route, arp, last, who, finger.
• FTP ou outro mecanismo para obter mais ferramentas ou extrair dados através da rede.
• Linguagem de scripts Perl
Este é um procedimento padrão, pois uma vez que um sistema foi comprometido, e dependendo do nível
de conhecimento do atacante, não se pode confiar nem mesmo nos recursos mais simples, como por
exemplo, listar os arquivos de um diretório (ls). Os recursos podem ter sido completamente modificados
para ocultar a presença das ações do atacante, ou mesmo apresentar apenas o que este deseja. O conjunto de
ferramentas deve sempre estar pronto antes de se precisar dele. Questões relativas ao Sistema Operacional
em uso, qual a versão ou distribuição, se existe rede ou equipamentos auxiliares disponíveis, se existe um
Notebook ou outras mídias, dentre outros, necessitam ser observadas na preparação das ações.
Durante a realização da captura de dados de perícia, além de seguir a ordem de volatilidade dos dados, já
discutida anteriormente, deve-se também levar em conta a “cadeia de confiança” do sistema. Esta cadeia de
confiança está associada com maneira na qual ocorre a execução de um binário dentro de um sistema
operacional. A cadeia de confiança apresenta a maneira como um sistema é perturbado durante a execução
de um comando ou programa. A figura 8 apresenta a execução da cadeia de confiança, com as ações de
execução de um binário.
16
Shell e variáveis de ambiente
Comando ou programa
Bibliotecas dinâmicas
Device drivers
Kernel
Controladoras
Hardware
Ordem de perturbação
ocorrida quando se
executa um binário
Figura 8 – A execução da cadeia de confiança,com as ações de execução e perturbação de um comando ou
programa
Uma das decisões que o analista de segurança deve tomar é com relação à manutenção da
operacionalidade do sistema, ou seja, se o sistema deve ser mantido no ar ou não. Esta é uma decisão
complexa, a qual deve, novamente, ser tomada com base na política de segurança e nas determinações
superiores da organização. Deve ser considerado se o fato de manter o sistema no ar permitirá obter mais
evidências ou, ao contrário, trará mais risco aos dados de perícia. Outro fato a ser considerado é com
relação a restrições de tempo, maiores ou menores, dependendo da necessidade de se restabelecer o sistema.
Por exemplo, em função da criticidade do sistema, pode ser necessário restabelece-lo imediatamente, o que
deixa menos tempo livre para coletar as evidências. Além disso a decisão de manter ou retirar do ar, podem
resultar em erros na replicação ou interpretação dos dados. Não existe uma regra geral para a tomada desta
decisão, e é preciso que a política de segurança da organização seja seguida à risca.
Reconstruindo eventos
Durante a realização de uma perícia será necessário realizar uma reconstrução de eventos passados. Neste
caso, o procedimento principal a ser adotado é a correlação de fatos. Ou seja, o analista deve estar apto a
associar e comparar informações de diferentes fontes, para tentar espelhar a situação encontrada no sistema,
com a maior fidelidade possível. Durante estes procedimentos será necessário observar cuidadosamente a
17
atividade de interesse, de tal forma a se determinar e reconstruir o que aconteceu no passado. Estas ações
deverão permitir entender, determinar e relatar os danos ocorridos, e os acontecimentos passados. Também
é preciso ter em mente que nenhum método ou técnica funciona sozinho. O perito deve combinar táticas
para obter as respostas que procura, de tal forma a associar o que aconteceu, operando dentro de um tempo
específico. Entre os métodos a serem aplicados na correlação de eventos, pode-se citar, em ordem de
importância, os seguintes procedimentos e técnicas, bem como algumas questões associadas a eles:
• Reconstrução do histórico dos usuários e suas operações.
! Quais usuários acessaram o sistema numa determinada hora ?
! Qual foi o padrão de uso de uma conta em particular ?
• Reconstrução do histórico dos processos executados, ou em execução.
! Qual o Username, terminal e hora de início da sessão de cada processo ?
! Qual a quantidade de uso de memória e CPU ?
! Quais as linhas de comando de chamada do processo ?
! Qual o estado do processo no momento (running, sleeping, suspended, dead, etc...) ?
! Quais os comandos executados por um processo específico ?
! Quais os comandos dentro de uma sessão específica ?
! Quais as sucessivas instâncias de um processo ?
! Quais as seqüências de comandos específicos de um usuário ?
! Quais os processos rodando durante uma determinada janela de tempo ?
! Quais os processos residentes que iniciaram após o tempo de reboot ?
• Reconstrução da situação das conexões de rede e roteamento.
! Qual a data, horário e destino da conexão ?
! Qual o nome do processo de rede e seu ID ?
! Qual o host cliente ?
! Opcional: Qual o usuário cliente ? (depende da existência de processo identd).
• Arquivos dos registros de auditoria (logs).
! Quais as conexões de, e para, um site específico ?
! Quais as conexões para um serviço específico (por exemplo, telnetd ou ftpd) ?
! Quais as seqüências sucessivas de conexão de um site (por ex. finger seguido de telnet) ?
! Quais as conexões ocorridas num intervalo de tempo ?
• Horários de acesso (ou modificação) de arquivos ou diretórios (M/A/C/times) [14].
! mtime = modification time
! atime = access time
! ctime = status change time
! dtime = deletion time (presente em alguns Linux)
! Estes tempos são associados a qualquer arquivo ou diretório no UNIX, no Windows NT e em
outros filesystems. Trazem uma quantidade significativa de informação.
! Existem cerca de 100.000 arquivos numa máquina Unix, representando 10 Mb de dados de
M/A/C/times.
! Se disponível, é um conjunto de evidências que deve ser seriamente considerado.
18
• Network Sniffing (se possível).
! É difícil de detectar.
! Pode capturar todo o tráfego de rede.
! Excelente para acompanhar o ataque em andamento ou o retorno do atacante.
! Útil para controle de danos, e inútil para recuperação de dados.
! Exige alta capacidade de armazenamento.
! Dados encriptados são um problema e impossibilitam a aplicação desta técnica.
! Pode violar a privacidade de outros usuários. É fortemente dependente da política da
organização e das leis vigentes.
IV. CONCLUSÕES
Dentro da discussão anteriormente apresentada, algumas conclusões podem ser obtidas para aplicação
antes e depois de um incidente envolvendo computadores e redes. A principal conclusão deve ser
centralizada na importância da existência de uma boa política de segurança. A política de segurança deve
ser bastante clara e concisa, permitindo que seja utilizada como um procedimento-padrão, no caso de
incidentes. Além disso, é importante que a política de segurança seja de amplo conhecimento dentro da
organização.
Também é muito importante conhecer os sistemas que estão em uso na organização. Uma vez que os
sistemas sejam bem conhecidos, devem ser ativados os processos de registros auditores, de tal forma que
seja possível inspecionar regularmente o ambiente. A inspeção e a auditoria devem ser uma prática
rotineira, da mesma forma que sejam também aplicados mecanismos que permitam sincronizar os relógios
dos diversos equipamentos. Sem a sincronização dos relógios, com uma base de tempo unificada, torna-se
muito difícil correlacionar os eventos dos diversos registros de auditoria. Deve-se considerar também
manter os sistemas atualizados, por intermédio de correções regulares (patches) dos softwares instalados.
Outro aspecto pouco abordado, mas de grande importância é a manutenção de uma educação continuada
dos usuários. Os usuários devem ser envolvidos como parte da solução do problema. É preciso entender que
um ambiente de segurança é tão forte quanto o elo mais fraco da cadeia de sistemas e usuários que o
formam. Isso significa que não adiantará manter um sistema controlado, se os usuários possuem
comportamentos de risco, como por exemplo, usando senhas fracas ou instalando de softwares de origem
duvidosa ou desconhecida. Os usuários devem ser envolvidos e estarem conscientes do seu poder
modificador e dos riscos envolvidos em suas ações. Portanto, é de fundamental importância uma educação
19
continuada dos recursos humanos da organização.
As emergências acontecem nos momentos menos esperados. A prevenção e a preparação devem fazer
parte das rotinas de procedimentos dos analistas de segurança. Neste sentido, é importante a simulação e o
treinamento dos procedimentos de emergência, de acordo com a política da organização. Os analistas de
segurança devem se manter atualizados, ou seja, devem estar informados sobre como os intrusos agem.
Além disso, devem estar preparados para, pelo menos, conhecer como capturar dados de perícia, ainda que
não saibam como analisa-los e interpreta-los. Este conhecimento é importante de forma a preservar as
evidências dentro de um ambiente comprometido, em função da volatilidade das informações, conforme
anteriormente discutido. Devem também estar preparados para contatar alguém no caso de uma emergência,
de tal forma que os dados e evidências possam ser interpretados por pessoal especializado.
Finalmente, os peritos e analistas de segurança devem estar muito atentos a aspectos éticos e legais,
dentro de suas jurisdições. Devem entender as implicações de suas ações quando inspecionam um sistema.
É importante o respeito à privacidade das pessoas. Deve-se ter em menteque este tipo de operação traz
responsabilidades muito importantes. A invasão de privacidade, a espionagem e a possibilidade de se
cometer abusos, ainda que inadvertidos, são possibilidades concretas. Além disso, o comportamento correto
ou incorreto do perito, ou do analista de segurança, terá efeitos profundos na validade legal das evidências.
Portanto, assim como em outros tipos de operações, nestas ações a ética e a clareza são fatores
preponderantes.
AGRADECIMENTOS
O Laboratório ACME! de pesquisa em segurança de redes agradece o suporte financeiro da FAPESP –
Fundação de Amparo à Pesquisa do Estado de São Paulo. O autor agradece a Sérgio A. Leugi Filho,
Thiago L. Charnet Ellero, Jarbas de Freitas Peixoto e Rodrigo Pace de Barros, pelas relevantes colaborações
e discussões pertinentes a este trabalho.
REFERÊNCIAS
[1] Computer Security Institute. “2001 Computer Crime and Security Survey”, San Franciso, CA, USA.12/03/2001 –
http://www.gocsi.com
[2] Computer Security Institute. “Current and Future Danger: A CSI Primer on Computer Crime and Information Warfare”. San
Franciso, CA, USA. 2001.
[3] Simson Garfinkel & Gene Spafford. Pratical Unix and Internet Security - 2nd Edition.O'Reilly and Associates, Sebastopol,
California, 1996.
[4] D. Russell & G. T. Gangemi Sr. Computer Security Basics. O'Reilly and Associates, Sebastopol, California, December, 1991.
20
[5] SANS - System Administration, Networking, and Security Institute. “How To Eliminate The Ten Most Critical Internet
Security Threats - The Experts’ Consensus”. Version 1.32 January 18, 2001 . http://www.sans.org/topten.htm (verif. 14/04/2001).
[6] Alan Paller and Stephen Northcutt (editors). “ Expert Predictions for Security Trends in 2001”.
SANS Institute . December/2000. http://www.sans.org/SANSSecAlert2_102000.pdf (verif. 14/04/2001).
[7] Yin Zhang. “Detecting Backdoors”. 9th USENIX Security Symposium Denver, Colorado, USA August 14-17, 2000.
[8] Hal Burch, and Bill Cheswick. “Tracing Anonymous Packets to Their Approximate Source”. 14th USENIX Systems
Administration Conference . New Orleans, Louisiana, USA. December 3-8, 2000
[9] Paul A. Taylor. Hackers – Crime in the Digital Sublime. Routledge Edit., London, 1999.
[10] Calvin Ko, Timothy Fraser, Lee Badger, and Douglas Kilpatrick. “Detecting and Countering System Intrusions Using
Software Wrappers”. 9th USENIX Security Symposium Denver, Colorado, USA August 14-17, 2000
[11] Dan Farmer and Wietse Venema. “Being Prepared for Intrusion” . Dr. Dobb's Journal , April 2001.
http://www.ddj.com/articles/2001/0104/0104f/0104f.htm (verif. 14/04/2001).
[12] NMAP . http://www.insecure.org/nmap/
[13] Soumyo D. Moitra and Suresh L. Konda. “A Simulation Model for Managing Survivability of Networked Information
Systems”. Carnegie Mellon University , Software Engineering Institute. CMU/SEI-2000-TR-020 Technical Report. December
2000. http://www.cert.org/research/00tr020.pdf (verif. 14/04/2001).
[14] Dan Farmer. “What Are MACtimes?”. Dr. Dobb's Journal , October 2000.
http://www.ddj.com/articles/2000/0010/0010f/0010f.htm (verif. 14/04/2001).