1

Conceitos para percia forense computacional

Adriano Mauro Cansian
UNESP Universidade Estadual Paulista
Depto. de Cincias da Computao e Estatstica
Laboratrio ACME! de Pesquisa em Segurana
1
Campus de So J os do Rio Preto
R. Cristvo Colombo, 2265
15055-000, So J os 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 organizations 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 discusso a respeito de conceitos fundamentais para a realizao de percia
forense em computadores e redes que tenham experimentado algum incidente de segurana. So abordadas
duas linhas principais de ao. Inicialmente so apresentados conceitos que permitem entender o panorama
atual dos problemas relacionados com os ataques s redes e sistemas de computadores. Neste sentido,
feita uma apresentao sobre o comportamento e a metodologia do atacante, dentro de uma filosofia de que
necessrio conhecer o inimigo, para poder analisa-lo e combate-lo. So discutidos conceitos bsicos sobre
a coleta de dados de auditoria, e a importncia destes registros nos equipamentos de uma rede. Tambm so
enfocados conceitos relacionados com polticas de segurana da organizao. Numa segunda parte, so
discutidos os conceitos de percia forense e coleta de evidncias para anlise de eventos de segurana. So
tratados aspectos sobre captura e congelamento dos dados, bem como a reconstruo de eventos passados.
Adota-se uma metodologia de trabalho baseada na importncia da coleta de evidncias dentro de um padro
sistematizado, o qual permita analisar e comprovar os eventos ocorridos.
1
http://www.acme-ids.org
2
I. INTRODUO
Apesar de analistas internacionais considerarem que os crimes em redes de computador representam
perdas de milhes de dlares, muito difcil estimar qual o real montante de prejuzos envolvidos
anualmente, principalmente porque, na grande maioria das vezes, os ataques no so relatados em funo
da perda de prestgio e credibilidade que eles podem representar [1] . Sabe-se tambm que o risco tende a
aumentar pois, com o passar dos anos e com a disseminao de informaes (notadamente atravs da
Internet), houve um significativo avano 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 tambm passaram a se utilizar de tcnicas de ataque de difcil
rastreamento e identificao. Freqentemente usam diversos nveis de ocultao e dissimulao, antes de
realizar um ataque. Procuram despistar o alvo, e raramente so surpreendidos, realizando ataques massivos,
que evidenciem facilmente uma atividade suspeita ou anormal. Alm disso costumam cobrir seus rastros,
de forma que as atividades realizadas no sistema penetrado no so 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 observao do comportamento esperado, em comparao com o
comportamento apresentado, pode ser entendido como o nvel de confiana do sistema, e indica o quanto
podemos confiar no seu funcionamento. O comportamento esperado formalizado dentro da poltica de
segurana do sistema, e regula as metas que este deve cumprir. Dessa forma, um evento de segurana
normalmente est relacionado a uma violao de normas ou procedimentos, que dependem do sistema
computacional em uso.
Uma definio mais rgida de segurana de computadores baseia-se na confidencialidade, na integridade e
na disponibilidade dos recursos do sistema [4]. Confidencialidade requer que a informao seja acessvel
somente quelas pessoas autorizados para tal; integridade requer que a informao permanea intacta e
inalterada por acidentes ou ataques, e disponibilidade requer que o sistema computacional funcione
adequadamente, sem degradao de acesso, fornecendo recursos aos usurios autorizados, quando eles
assim necessitarem. A confidencialidade pode ser importante para o sucesso comercial ou at mesmo
sobrevivncia de uma empresa; integridade pode ser importante para um hospital que mantm histricos
mdicos de seus pacientes e os utiliza para tomadas de decises em situaes crticas. A disponibilidade de
um recurso pode ser fator determinante no controle de um sistema de trfego areo ou possibilidade de
3
retaliar um ataque militar. Nesta definio, um sistema computacional que no fornea todos os recursos
necessrios no devido momento, tratado como no-confivel, uma vez que o conjunto representa os
requisitos de segurana 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 definio de segurana
em sistemas de computadores extremamente flexvel e dependente de uma srie de fatores e
caractersticas. preciso entender a segurana de um sistema computacional no como sendo um item
particular, um produto ou uma determinada medida ou ao. A segurana deve ser interpretada como um
processo, o qual envolve elementos tecnolgicos complexos ou no, mas que deve considerar tambm
aspectos humanos. Um sistema seguro deve conter um conjunto de aes que permitam proteger seus
dados, e seus recursos, de acesso no-autorizado, de intromisso ou de bloqueio de uso. Sabe-se que
segurana obtida a custo da convenincia e facilidade de uso dos sistemas. Pode-se afirmar tambm que a
facilidade de conectividade de computadores inversamente proporcional segurana.
Controle de acesso e modelos de proteo no so muito teis contra atacantes internos ou contra o
comprometimento dos mdulos de autenticao 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 no tm
como prevenir a perda ou corrupo dos dados aos quais aquela conta tem acesso. Em geral, mtodos
estticos de proteo podem simplesmente ser insuficientes, ou podem tornar o sistema extremamente
restritivo aos seus prprios usurios. Por exemplo, considere que uma determinada tcnica de segurana
no seja capaz de prevenir ou detectar violao de poltica de segurana resultante de buscas generalizadas
em arquivos de dados; e se por essa razo 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 questo a ser resolvida. Diversas falhas em sistemas freqentemente se
manifestam como vulnerabilidades na segurana. H que se considerar tambm, que os ciclos de vida til
dos softwares esto se tornando cada vez mais curtos devido competitividade do mercado. Isso
geralmente tem como efeito colateral uma programao pobre e inadequada, ou ento leva a testes e
validaes insuficientes ou mal planejados, fatos estes que s vem a agravar o problema. Desse modo,
acredita-se que sistemas computacionais, e principalmente redes, continuaro potencialmente inseguros
ainda por muito tempo [6].
4
Dentro deste contexto, a anlise e a percia de computadores que tenham passado por algum tipo de
violao ou ataque, torna-se uma matria importante no conjunto de aes de um processo de segurana. A
percia 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 possvel coletar
evidncias necessrias a identificar o atacante, de tal forma que possam ser adotadas medidas legais ou
jurdicas pertinentes. Novamente, uma violao de segurana fortemente dependente da poltica de
utilizao do sistema, e deve ser entendida nesta particularidade. Este fato muito importante e ser
memorado insistentemente ao longo deste trabalho. A percia de computadores uma tarefa que envolve a
considerao de aspectos objetivos e subjetivos, por vezes associada a anlise tecnolgica, mas por outras
vezes fortemente dependente de questes 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 Segurana
A sofisticao dos ataques e ferramentas de intruses e, por conseqncia, a eficincia dos intrusos est
aumentando. O conhecimento vem sendo passado aos intrusos menos hbeis pelos atacantes mais
experientes. Alm disso, complexidade das redes cresce a passos largos, resultando sempre em novas
oportunidades de violaes de segurana, tanto em nvel local, como provenientes do mundo exterior,
principalmente atravs da Internet [7]. Em funo destes aspectos, atualmente, o nmero de intruses e
ataques a redes de computadores vem sofrendo taxas de crescimento significativas. A infra-estrutura de
informao tem muitos problemas de segurana fundamentais, os quais no podem ser resolvidos
rapidamente. O nmero de pessoas com conhecimento em segurana est aumentando, mas a uma taxa
significativamente menor que o aumento no nmero de usurios. O nmero de ferramentas de segurana
disponveis est aumentando, mas no necessariamente to rpido quanto a complexidade de softwares,
sistemas e redes. O nmero de equipes de resposta a incidentes tem crescido, entretanto a relao entre
pessoal de resposta a incidentes e usurios de Internet, e de redes em geral, est diminuindo [1]. Por razes
econmicas e mercadolgicas, o ciclo de desenvolvimento e testes de produtos est sendo reduzido cada
vez mais, fazendo com que, novamente, apaream outras possibilidades de explorao de vulnerabilidades.
5
Assim, empresas continuam produzindo softwares com vulnerabilidades, incluindo tipos onde a preveno
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 padres: os atacantes provenientes do
meio interno, oriundos da prpria organizao, empresa ou instituio, e os atacantes externos,
normalmente provenientes da Internet [8]. comum acreditar-se, erroneamente, que os ataques mais srios,
e que causam mais prejuzos, so provenientes da Internet. Esta crena comum geralmente compartilhada
em virtude da cobertura da mdia, que destaca, muitas vezes de forma sensacionalista, determinados casos
de hacking que ocorrem atravs da Internet. Entretanto, pesquisas recentes mostram que a maioria dos
ataques que envolvem perdas financeiras ocorrem, ou contam com a cooperao, de algum de dentro das
prprias organizaes atacadas [1].
Os atacantes oriundos do meio interno tem um comportamento mais complexo do que os atacantes
externos. As anlises destes casos mostram que estes tipos de crimes eletrnicos, intruses ou tentativas de
ataque ocorrem em virtude dos mesmos motivos pelos quais ocorrem a maioria dos crimes regulares. So
associados principalmente com cobia, obteno ilegal de dinheiro, lucro, riqueza ou acesso a recursos
adicionais ou restritos, ou ganho de vantagem competitiva, seja ela econmica, poltica ou pessoal.
Freqentemente esto tambm ligados a revanches pessoais ou vinganas [9].
Em se tratando de violaes de segurana provenientes do meio externo, o atacante tem sido sempre
algum em busca de um alvo fcil, que no est em busca de algo especfico. Entretanto, seu objetivo
claro: ganhar acesso privilegiado, da maneira mais fcil possvel, concentrando-se num nmero pequeno de
ferramentas e exploits, varrendo toda a Internet. Estes atacantes so denominados genericamente de script
kiddies [9]. Alguns so usurios avanados que desenvolvem suas prprias ferramentas, e deixam
backdoors sofisticados, ao passo que outros no tm a menor idia do que esto fazendo.
Independentemente de suas habilidades, eles compartilham de uma estratgia comum: buscam
aleatoriamente por uma vulnerabilidade especfica e, ento, exploram aquela vulnerabilidade. Em algum
momento os atacantes encontraro algum vulnervel. A seleo aleatria de alvos que torna o script
kiddie uma ameaa, pois ao no buscar alvos especficos, todos os sistemas esto potencialmente
ameaados [10]. As ferramentas de busca de vulnerabilidades e ataques esto amplamente divulgadas, de
6
tal forma que qualquer pessoa pode obte-las e usa-las. H um nmero crescente de atacantes fazendo uso
delas. Uma vez que a Internet, obviamente, no possui fronteiras, estas ameaas esto se espalhando
mundialmente. Os sistemas que os script kiddies esto procurando so aqueles no supervisionados, sem
registros de auditoria (logs), sem poltica de uso, desprotegidos, e fceis de serem explorados. Ao
encontrarem algumas barreiras, eles geralmente mudam de alvo. Estes atacantes so motivados,
principalmente, por curiosidade, ganho de acesso a recursos computacionais restritos, distrbios
comportamentais ligados a vandalismo e vontade de provocar danos, ou busca por ateno e projeo.
Padres comportamentais ligados a revanche e vingana pessoal tambm so freqentes. Obteno de
vantagens financeiras aparecem em menor escala, mas tambm esto presentes, entretanto, com gravidade
inferior se comparados aos danos causados pelos atacantes internos. Entretanto, com o aumento gradativo
de operaes comerciais ocorrendo por intermdio da Internet, provvel que esta caracterstica venha a se
modificar.
Em resumo, h um senso comum de que os intrusos esto preparados e bem organizados. Os ataques,
provenientes da Internet ou internos, so fceis, de baixo risco e muito difceis de serem rastreados. As
ferramentas dos intrusos esto crescendo em sofisticao, so fceis de usar, especialmente por novatos, e
so desenhadas para darem suporte a ataques em larga escala.
A metodologia dos atacantes
Tanto os ataques internos como os externos acontecem dentro de padres bem definidos e de acordo com
uma seqncia de eventos que permitem estabelecer perfis ou padres comportamentais. A metodologia
bsica simples: rastrear a rede, ou o computador alvo, buscando vulnerabilidades especficas,
estabelecendo uma base de dados de endereos 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 Linux possuem uma vulnerabilidade nativa no processo denominado
imapd . feita uma busca por IPs vlidos e ativos e desenvolve-se uma base de dados relacionando os
sistemas rodando Linux. Por intermdio de ferramentas especficas [12], verifica-se quais esto rodando
imapd vulnervel. A partir desta informao, os sistemas vulnerveis so explorados.
Um terreno frtil para a proliferao deste tipo de ataque a ausncia de monitorao e inspeo dos
computadores e redes. Muitas organizaes no monitoram seus sistemas de forma alguma, e nunca
7
percebem que esto sendo atacados ou rastreados. So raros os sistemas com uma poltica clara e bem
definida e escrita sobre gerao e inspeo regular de registros de auditoria (logs). Quando h logs, estes
no so 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 lanamento para outros ataques, ocultando sua posio real e colocando a
responsabilidade em outros administradores. A figura 1 mostra um esquema tpico do desenvolvimento de
um ataque deste tipo.
Localizar
Sistema para
atacar
Obter acesso
privilegiado
( root )
Obter acesso
de nvel de
usurio
Instalar
backdoors
Atacar outros
Roubar ou
alterar dados
Executar outras
atividades no
autorizadas
Encobrir os
rastros
Figura 1 Comportamento tpico da evoluo de um ataque
Os resultados dos rastreamentos costumam ser armazenados, e so freqentemente compartilhados com
outros atacantes. Quando uma nova vulnerabilidade aparece, os resultados de prospees anteriores podem
ser usados como referncia. Isso significa que, mesmo que um sistema no tenha sido rastreado
recentemente, ele no est isento de um ataque ou explorao 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 fcil 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, so freqentemente comprometidos ou corrompidos e
tornam-se no confiveis.
Quando se consideram ataques atravs da Internet, a questo temporal e os horrio no so significativos.
8
Os ataques acontecem a qualquer hora e, muitas vezes, em larga escala. Existem ferramentas automticas
de busca de vulnerabilidade, as quais operam 24 horas por dia, coletando dados. Alm disso, h
abrangncia mundial dos ataques, o que torna a questo de fuso horrio pouco til.
Ao contrrio dos ataques que ocorriam no passado, as ferramentas de ataque, muitas das quais
disponveis publicamente na Internet, so de fcil utilizao e no exigem conhecimento especfico em
redes ou em sistemas. Algumas so limitadas a um nico propsito, com poucas opes, e outras so mais
versteis, varrendo indiscriminadamente as redes ou os computadores alvo, a procura de vulnerabilidades.
Observando os atacantes
Informaes importantes sobre as questes e eventos de segurana de um sistema podem ser obtidas por
intermdio dos registros de auditoria. Com alguns procedimentos simples possvel analisar questes
importantes, sem necessidade de investimentos ou recursos adicionais, alm daqueles j regularmente
presentes na maioria dos sistemas. Atravs de informaes bsicas extradas dos logs possvel determinar
se os sistemas foram examinados, o que os atacantes buscaram saber, que ferramentas ou tcnicas foram
usadas e, eventualmente, se obtiveram sucesso. Informaes significativamente teis podem ser obtidas
atravs da simples anlise e reviso de registros de auditoria. Entretanto, numa quantidade alarmante de
instalaes, sequer existe qualquer sistema auditor, que registre as ocorrncias e faa as contabilizaes nos
sistemas. Tambm importante ressaltar que sistemas de auditoria so freqentemente os primeiros alvos
dos atacantes. Desta forma, preciso proteger e garantir a integridade dos registros, caso contrrio eles se
tornam inteis. H uma variedade de ferramentas que removem a presena dos atacantes dos registros, e
existem processos auditores (syslogd) corrompidos, os quais no registram as aes dos intrusos. O atacante
que tenha comprometido uma mquina pode estabelecer um ao automtica que remova completamente
todos os registros, ou at mesmo uma partio inteira.
A importncia dos logs
Em vista destas consideraes, um dos principais aspectos que permite a execuo de uma percia bem
sucedida em um sistema, a existncia de registros de auditoria que estejam ntegros e confiveis.
Independentemente de quo seguro um computador ou uma rede, nunca ser possvel confiar totalmente
nos registros de um sistema que tenha sido comprometido. Isso dificulta, ou mesmo impossibilita, uma
9
percia 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 esto seguros num equipamento especial, existem maiores
possibilidades de sucesso ao se correlacionar e identificar padres, ou rever rapidamente o que est
acontecendo em todas as mquinas da rede, usando s uma fonte de informao. Alm disso, possvel
realizar comparaes para determinar se os logs de origem foram modificados. Para alcanar estes
objetivos, uma recomendao estabelecer um sistema de logs centralizado e dedicado, ou seja, que tenha
como funo exclusiva a coleta de registros de auditoria, sem outros processos ou servios. Uma opo
recomendvel pode ser estabelecida, com baixo custo, por intermdio de uma mquina com sistema
operacional gratuito, como por exemplo Linux ou FreeBSD, agindo exclusivamente como coletora de logs
na rede local. Como exemplo da importncia 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 mltiplas conexes, 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 identificao de uma varredura genrica, e a figura 4 mostra
a identificao de um ataque de buffer overflow. A figura 5 mostra uma tentativa de explorao 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.223
Oct 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 genrica na mquina bart da rede local, proveniente do computador
200.145.202.223, buscando por servios disponveis.
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~P33^[~@33~K^F~@u1^B~@~Eubb^V<t^Ft^K0~HF^^B~
I^F~IF^D^F~IF^Hf1~I~@~I^F^Bf~IF^L*f~IF^N~MF^L~IF^D1~IF^P^P~IF^H
f~@^A~IF^Df^D~@^DLR1~IF^D~IF^Hf~@~H?1~@?~@?~@.bin@~
I^F.sh!@~IF^D1~HF^G~Iv^H~IF^L^K~I~MN^H~MV^L~@1^A1~@EPrivet
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 mquina 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 explorao de uma vulnerabilidade cgi-bin num servidor de http.
Conforme pode ser notado, a centralizao dos logs assume um papel determinante na anlise de
incidentes, e at mesmo na adoo de contra medidas. Entretanto, importante mencionar que, obviamente,
se um servio no est sendo auditorado ou registrado, no possvel determinar se o sistema foi rastreado
por aquela vulnerabilidade em particular. Alm disso, outro aspecto importante que os peritos e analistas de
segurana devem considerar o conhecimento acerca do que os registros de auditoria no podem fornecer.
Nem sempre os registros de auditoria resultam em informaes teis. Diversas ferramentas de ataque
possuem a opo de realizar varreduras com falsificao de endereos IP de origem (IP spoofing). Algumas
ferramentas automatizadas, como por exemplo o nmap [12], tm condies 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. Tambm existem
tcnicas de prospeo chamadas de half-scan. Esta uma das tcnicas de ocultao e dissimulao mais
freqente. A varredura de half-scan usa s um pacote SYN do handshake de 3 vias do estabelecimento da
conexo TCP. Se o sistema remoto responde, a conexo descartada com um pacote RST. Isso torna
bastante difcil a determinao da origem do ataque, apenas com a utilizao dos registros de auditoria.
Neste caso, outras tcnicas de anlise 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 no pode ser
determinada
Como concluso desta discusso, importante ressaltar que os registros de auditoria tratam-se de uma
tcnica simples que pode dizer muito sobre o atacante, desde que existam de fato, e estejam protegidos,
dentro de uma poltica bem definida. Uma vez que existem os registros, possvel identificar padres e
correlaes, permitindo at mesmo saber o que o intruso procura, ou (talvez) se ele teve ou no sucesso
[13].
III. FORENSICS
Uma introduo s tcnicas de percia forense em computadores e redes
Segundo Dan Farmer, a percia computacional (forensics) trata-se da captura e anlise de evidncias,
tanto quanto possvel 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 concusso destes
objetivos. Os sistemas so grandes e complexos, e mudam rapidamente, e os fatos e as evidncias podem
estar ocultos em qualquer lugar, praticamente inexistindo softwares especializados disponveis para tratar o
problema. Em funo disso, exige-se muito conhecimento e experincia. fcil coletar dados, mas a
anlise difcil. Alm disso, esta anlise exige muito tempo disponvel. Associe-se a isto o problema de se
armazenar as grandes quantidades de dados resultantes de registros de auditoria e percia.
Desta forma, um perito em anlise de sistemas invadidos ou comprometidos necessita dispor de certas
caractersticas especiais, principalmente conhecimentos e habilidades relativas aos sistemas em questo, e
entendimento pleno acerca das implicaes tcnicas e legais de suas aes. Caractersticas concernentes a
esprito investigativo, suspeio e tica tambm so determinantes para o sucesso ou fracasso das aes.
13
Ao se deparar com a conduo de uma anlise, o perito deve isolar e assegurar o permetro, registrando a
cena do crime da melhor maneira possvel, e conduzindo uma busca sistemtica por evidncias, coletando
e armazenando as que encontrar. A velocidade das aes essencial, mas estas devem ser levadas em
considerao sem colocar em risco a coleta ou a veracidade das informaes. O perito tambm deve ter em
mente que qualquer operao executada num sistema, causar alguma perturbao em seu estado. Alm
disso, atacantes hbeis conhecem como as percias so feitas e podem fornecer informaes falsas em locais
especficos. Por esta razo, o perito nunca deve confiar plenamente no sistema em questo. Alm deste fato,
outro aspecto importante diz respeito s leis vigentes na jurisdio, e as polticas da organizao ou
instituio. Estas devem ser levadas em considerao, e respeitadas. Sem este procedimento, a coleta de
evidncias pode ser incua, ineficaz ou ilegtima.
Durante a busca por evidncias, a preservao do estado do sistema um fator determinante. Sem a
preservao 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 efmeros. A figura 7 apresenta a ordem de volatilidade dos
dados de percia mais usados.
Registros de memria perifrica, cache, etc...
Memria do kernel e fsica
Estado da rede, rotas, interfaces, etc...
Registros de memria perifrica, cache, etc...
Processos em execuo
Discos, filesystems, parties
Floppies, fitas e outros meios magnticos
CD-ROMs, cpias impressas, etc...
Figura 7 Ordem de volatilidade dos elementos de percia mais utilizados. De cima para baixo, esto os
dados mais efmeros, a serem coletados primeiramente.
Durante o tratamento de uma percia em um sistema invadido ou atacado, alguns fatores muitas vezes
imperceptveis so as maiores causas dos problemas e dificuldades. No saber exatamente o que aconteceu,
e no conhecer contra quem, ou o que, se est lutando, so as maiores fontes dos problemas e dificuldades,
14
e por isso mesmo tornam-se os grandes desafios. No saber em que dados confiar, dentre todos aqueles
disponveis para a percia, fazem com que problemas mais complexos requeiram uma preparao mais
elaborada, e um plano claro e bem definido para trata-los.
Se o analista de segurana ou o perito no conhece o sistema, a situao deve ser abordada ainda com
mais cautela. Deve-se conhecer e entender as limitaes humanas, relativas a conhecimento tcnico, para
abordagem do problema, da mesma forma como devem ser conhecidas as limitaes tcnicas do sistema, da
rede ou do equipamento sob anlise. Esta abordagem deve ser adotada porque muito fcil danificar,
corromper ou mascarar inadvertidamente as evidncias da percia. Mesmo uma anlise simples num
sistema desconhecido pode ser arriscada, comprometendo definitivamente o trabalho a ser realizado, ou
mesmo a validade legal da anlise. Desta forma, o analista de segurana deve trabalhar o menos possvel
com os dados originais, ou seja, deve-se optar por providenciar uma imagem dos dados que sero usados e
deve-se operar sobre este conjunto, seguindo sempre a ordem de volatilidade discutida acima.
Dentro deste contexto, cumpre ressaltar novamente a importncia de se aplicar sempre a poltica de
segurana da organizao, da mesma forma que devem ser observadas a legislao da jurisdio em
questo. Com base nestes procedimentos, podem ser definidas metas claras de trabalho, de tal forma que a
percia seja vlida, tanto em termos institucionais como legais e jurdicos. Dentre os aspectos relativos
poltica de segurana da organizao, devem ser consideradas questes tais como: quem deve ser informado
dos eventos encontrados, o que deve ser registrado, o que fazer com as evidncias, que seqncia de aes
devem ser seguidas, quais as prioridades, entre outros cuidados. Alm disso, a maioria dos dados tem um
componente fortemente dependente do tempo e do horrio. Em funo disso, deve-se construir uma base de
tempo de referncia, de tal forma que seja possvel examinar uma certa janela de tempo, dentro daquela
linha, permitindo determinar os eventos que tenham acontecido durante aquele perodo
Congelamento de dados
Segundo a fsica quntica, o Princpio da Incerteza de Heisenberg define que impossvel determinar, ao
mesmo tempo, a velocidade e a posio de uma partcula, 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. impossvel capturar completamente o estado total do sistema, num dado momento do
15
tempo. Desta forma, o analista de segurana deve esforar-se, ao mximo, para capturar uma representao
fiel do sistema, to livre de distores ou influncias quanto possvel. Esta a essncia da percia, seja ela
em computadores, ou numa cena de crime convencional. O perito deve ter extremo cuidado para no tocar
em nada que possa perturbar a cena e, desta forma, comprometer a investigao.
Durante a anlise tambm importante considerar que o perito no poder confiar nos dados que obtiver,
se no puder confiar nas suas ferramentas de trabalho. Portanto, importante que o perito possua seu
prprio conjunto de ferramentas de software para inspeo, captura e anlise dos dados. A composio do
conjunto de ferramentas ir depender sempre do tipo de sistema sob anlise, e tambm do tipo de mdia
disponvel para transporte e manipulao. Como exemplo, em se tratando de um sistema UNIX, algumas
ferramentas listadas a seguir podem ser consideradas indispensveis. Opes semelhantes podem ser
adaptadas para outros sistemas:
Ferramentas de coleta de dados tipo statically linked, tais como: dd, cp, du, cat, ls.
Ferramentas de identificao de estado do sistema, tais como: netstat, route, arp, last, who, finger.
FTP ou outro mecanismo para obter mais ferramentas ou extrair dados atravs da rede.
Linguagem de scripts Perl
Este um procedimento padro, pois uma vez que um sistema foi comprometido, e dependendo do nvel
de conhecimento do atacante, no se pode confiar nem mesmo nos recursos mais simples, como por
exemplo, listar os arquivos de um diretrio (ls). Os recursos podem ter sido completamente modificados
para ocultar a presena das aes do atacante, ou mesmo apresentar apenas o que este deseja. O conjunto de
ferramentas deve sempre estar pronto antes de se precisar dele. Questes relativas ao Sistema Operacional
em uso, qual a verso ou distribuio, se existe rede ou equipamentos auxiliares disponveis, se existe um
Notebook ou outras mdias, dentre outros, necessitam ser observadas na preparao das aes.
Durante a realizao da captura de dados de percia, alm de seguir a ordem de volatilidade dos dados, j
discutida anteriormente, deve-se tambm levar em conta a cadeia de confiana do sistema. Esta cadeia de
confiana est associada com maneira na qual ocorre a execuo de um binrio dentro de um sistema
operacional. A cadeia de confiana apresenta a maneira como um sistema perturbado durante a execuo
de um comando ou programa. A figura 8 apresenta a execuo da cadeia de confiana, com as aes de
execuo de um binrio.
16
Shell e variveis de ambiente
Comando ou programa
Bibliotecas dinmicas
Device drivers
Kernel
Controladoras
Hardware
Ordem de perturbao
ocorrida quando se
executa um binrio
Figura 8 A execuo da cadeia de confiana, com as aes de execuo e perturbao de um comando ou
programa
Uma das decises que o analista de segurana deve tomar com relao manuteno da
operacionalidade do sistema, ou seja, se o sistema deve ser mantido no ar ou no. Esta uma deciso
complexa, a qual deve, novamente, ser tomada com base na poltica de segurana e nas determinaes
superiores da organizao. Deve ser considerado se o fato de manter o sistema no ar permitir obter mais
evidncias ou, ao contrrio, trar mais risco aos dados de percia. Outro fato a ser considerado com
relao a restries de tempo, maiores ou menores, dependendo da necessidade de se restabelecer o sistema.
Por exemplo, em funo da criticidade do sistema, pode ser necessrio restabelece-lo imediatamente, o que
deixa menos tempo livre para coletar as evidncias. Alm disso a deciso de manter ou retirar do ar, podem
resultar em erros na replicao ou interpretao dos dados. No existe uma regra geral para a tomada desta
deciso, e preciso que a poltica de segurana da organizao seja seguida risca.
Reconstruindo eventos
Durante a realizao de uma percia ser necessrio realizar uma reconstruo de eventos passados. Neste
caso, o procedimento principal a ser adotado a correlao de fatos. Ou seja, o analista deve estar apto a
associar e comparar informaes de diferentes fontes, para tentar espelhar a situao encontrada no sistema,
com a maior fidelidade possvel. Durante estes procedimentos ser necessrio observar cuidadosamente a
17
atividade de interesse, de tal forma a se determinar e reconstruir o que aconteceu no passado. Estas aes
devero permitir entender, determinar e relatar os danos ocorridos, e os acontecimentos passados. Tambm
preciso ter em mente que nenhum mtodo ou tcnica funciona sozinho. O perito deve combinar tticas
para obter as respostas que procura, de tal forma a associar o que aconteceu, operando dentro de um tempo
especfico. Entre os mtodos a serem aplicados na correlao de eventos, pode-se citar, em ordem de
importncia, os seguintes procedimentos e tcnicas, bem como algumas questes associadas a eles:
Reconstruo do histrico dos usurios e suas operaes.
! Quais usurios acessaram o sistema numa determinada hora ?
! Qual foi o padro de uso de uma conta em particular ?
Reconstruo do histrico dos processos executados, ou em execuo.
! Qual o Username, terminal e hora de incio da sesso de cada processo ?
! Qual a quantidade de uso de memria 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 especfico ?
! Quais os comandos dentro de uma sesso especfica ?
! Quais as sucessivas instncias de um processo ?
! Quais as seqncias de comandos especficos de um usurio ?
! Quais os processos rodando durante uma determinada janela de tempo ?
! Quais os processos residentes que iniciaram aps o tempo de reboot ?
Reconstruo da situao das conexes de rede e roteamento.
! Qual a data, horrio e destino da conexo ?
! Qual o nome do processo de rede e seu ID ?
! Qual o host cliente ?
! Opcional: Qual o usurio cliente ? (depende da existncia de processo identd).
Arquivos dos registros de auditoria (logs).
! Quais as conexes de, e para, um site especfico ?
! Quais as conexes para um servio especfico (por exemplo, telnetd ou ftpd) ?
! Quais as seqncias sucessivas de conexo de um site (por ex. finger seguido de telnet) ?
! Quais as conexes ocorridas num intervalo de tempo ?
Horrios de acesso (ou modificao) de arquivos ou diretrios (M/A/C/times) [14].
! mtime =modification time
! atime =access time
! ctime =status change time
! dtime =deletion time (presente em alguns Linux)
! Estes tempos so associados a qualquer arquivo ou diretrio no UNIX, no Windows NT e em
outros filesystems. Trazem uma quantidade significativa de informao.
! Existem cerca de 100.000 arquivos numa mquina Unix, representando 10 Mb de dados de
M/A/C/times.
! Se disponvel, um conjunto de evidncias que deve ser seriamente considerado.
18
Network Sniffing (se possvel).
! difcil de detectar.
! Pode capturar todo o trfego de rede.
! Excelente para acompanhar o ataque em andamento ou o retorno do atacante.
! til para controle de danos, e intil para recuperao de dados.
! Exige alta capacidade de armazenamento.
! Dados encriptados so um problema e impossibilitam a aplicao desta tcnica.
! Pode violar a privacidade de outros usurios. fortemente dependente da poltica da
organizao e das leis vigentes.
IV. CONCLUSES
Dentro da discusso anteriormente apresentada, algumas concluses podem ser obtidas para aplicao
antes e depois de um incidente envolvendo computadores e redes. A principal concluso deve ser
centralizada na importncia da existncia de uma boa poltica de segurana. A poltica de segurana deve
ser bastante clara e concisa, permitindo que seja utilizada como um procedimento-padro, no caso de
incidentes. Alm disso, importante que a poltica de segurana seja de amplo conhecimento dentro da
organizao.
Tambm muito importante conhecer os sistemas que esto em uso na organizao. Uma vez que os
sistemas sejam bem conhecidos, devem ser ativados os processos de registros auditores, de tal forma que
seja possvel inspecionar regularmente o ambiente. A inspeo e a auditoria devem ser uma prtica
rotineira, da mesma forma que sejam tambm aplicados mecanismos que permitam sincronizar os relgios
dos diversos equipamentos. Sem a sincronizao dos relgios, com uma base de tempo unificada, torna-se
muito difcil correlacionar os eventos dos diversos registros de auditoria. Deve-se considerar tambm
manter os sistemas atualizados, por intermdio de correes regulares (patches) dos softwares instalados.
Outro aspecto pouco abordado, mas de grande importncia a manuteno de uma educao continuada
dos usurios. Os usurios devem ser envolvidos como parte da soluo do problema. preciso entender que
um ambiente de segurana to forte quanto o elo mais fraco da cadeia de sistemas e usurios que o
formam. Isso significa que no adiantar manter um sistema controlado, se os usurios possuem
comportamentos de risco, como por exemplo, usando senhas fracas ou instalando de softwares de origem
duvidosa ou desconhecida. Os usurios devem ser envolvidos e estarem conscientes do seu poder
modificador e dos riscos envolvidos em suas aes. Portanto, de fundamental importncia uma educao
19
continuada dos recursos humanos da organizao.
As emergncias acontecem nos momentos menos esperados. A preveno e a preparao devem fazer
parte das rotinas de procedimentos dos analistas de segurana. Neste sentido, importante a simulao e o
treinamento dos procedimentos de emergncia, de acordo com a poltica da organizao. Os analistas de
segurana devem se manter atualizados, ou seja, devem estar informados sobre como os intrusos agem.
Alm disso, devem estar preparados para, pelo menos, conhecer como capturar dados de percia, ainda que
no saibam como analisa-los e interpreta-los. Este conhecimento importante de forma a preservar as
evidncias dentro de um ambiente comprometido, em funo da volatilidade das informaes, conforme
anteriormente discutido. Devem tambm estar preparados para contatar algum no caso de uma emergncia,
de tal forma que os dados e evidncias possam ser interpretados por pessoal especializado.
Finalmente, os peritos e analistas de segurana devem estar muito atentos a aspectos ticos e legais,
dentro de suas jurisdies. Devem entender as implicaes de suas aes quando inspecionam um sistema.
importante o respeito privacidade das pessoas. Deve-se ter em mente que este tipo de operao traz
responsabilidades muito importantes. A invaso de privacidade, a espionagem e a possibilidade de se
cometer abusos, ainda que inadvertidos, so possibilidades concretas. Alm disso, o comportamento correto
ou incorreto do perito, ou do analista de segurana, ter efeitos profundos na validade legal das evidncias.
Portanto, assim como em outros tipos de operaes, nestas aes a tica e a clareza so fatores
preponderantes.
AGRADECIMENTOS
O Laboratrio ACME! de pesquisa em segurana de redes agradece o suporte financeiro da FAPESP
Fundao de Amparo Pesquisa do Estado de So Paulo. O autor agradece a Srgio A. Leugi Filho,
Thiago L. Charnet Ellero, J arbas de Freitas Peixoto e Rodrigo Pace de Barros, pelas relevantes colaboraes
e discusses pertinentes a este trabalho.
REFERNCIAS
[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 J anuary 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).