Agente de Aplicacao para IDS PDF

LEONARDO CAVALLARI MILITELLI
Proposta de um agente de aplicao para deteco,

preveno e conteno de ataques em ambientes
computacionais.
Dissertao de Mestrado apresentada

Escola Politcnica da Universidade de
So Paulo como parte dos requisitos
para obteno do ttulo de Mestre em
Engenharia Eltrica.
So Paulo
2006
LEONARDO CAVALLARI MILITELLI
Proposta de um agente de aplicao para deteco,

preveno e conteno de ataques em ambientes
computacionais.
Dissertao de Mestrado apresentada

Escola Politcnica da Universidade de
So Paulo como parte dos requisitos
para obteno do ttulo de Mestre em
Engenharia Eltrica.
rea de Concentrao:
Sistemas Eletrnicos
Orientador: Prof. Dr. Joo Antnio

Zuffo
So Paulo
2006
FICHA CATALOGRFICA
Militelli, Leonardo Cavallari

Proposta de um agente de aplicao para deteco, preven-
o e conteno de ataques em ambientes computacionais / L.
C. Militelli. --So Paulo, 2006.
p. 73
Dissertao (Mestrado) - Escola Politcnica da Universidade

de So Paulo. Departamento de Engenharia de Sistemas
Eletrnicos.
1.Segurana de redes 2.Segurana de computadores 3.Vrus

e antivrus de computador I.Universidade de So Paulo. Escola
Politcnica. Departamento de Engenharia de Sistemas
Eletrnicos II.t.
i
Agradecimentos
Em primeiro lugar, agradeo minha famlia, em especial minha me Luciana, por todo
carinho, apoio e incentivo ao longo dos anos.
Ao meu orientador Prof. Dr. Joo Antnio Zuffo e co-orientador Prof. Dr. Volnys Borges
Bernal pela oportunidade, orientao direcionada e por toda ajuda oferecida.
Aos meus amigos Artur, Gabrielle, Leandro, Milciades, Tamaris e Veronica que estiveram
junto ao longo do desenvolvimento do trabalho e contribuiram com uma parcela imensurvel
para a concretizao deste, mesmo sem terem tanta noo disto.
Aos grandes amigos Fbio, Murilo e Renato que acompanham e participam da mesma
trajetria desde a graduao, com os quais pretendo enfrentar novos desafios.
Aos integrantes e amigos do grupo NSRAV, em particular, Adlson, Fernando e Matteo, pelas
discusses tcnicas, cooperao e colaborao no trabalho.

ii
Resumo
Canais seguros, como os gerados pelos protocolos SSL e TLS, so cada vez mais utilizados
nos servios de rede para propiciar autenticao de parceiro, integridade e sigilo dos dados.
Porm, sua utilizao impede que um sistema de deteco de intruso de rede possa observar
o contedo dos pacotes, impossibilitando a anlise das mensagens.
Como alternativa de contorno deste problema proposta a arquitetura de um agente de

deteco, preveno e conteno de ataques baseado em aplicao, que possibilite interceptar
fluxos de mensagens diretamente na aplicao, inserido no contexto de uma arquitetura de
deteco distribuda e padronizada. O ADACA (Agente de Deteco, Anlise e Conteno de
Ataques) um agente IDS (Intrusion Detection System) hbrido capaz de operar tanto no
modo ativo quanto passivo. Dessa forma, permite realizar a anlise do contedo de mensagens
que estejam protegidos por protocolos seguros, como o SSL e TLS, e adotar uma medida pr-
definida antes que a aplicao alvo processe um contedo malicioso.
Alm disso, o padro de formato de mensagens de alertas IDMEF (Intrusion Detection

Message Exchange Format), proposto pelo IDWG, adotado para notificao de eventos do
agente ADACA a um IDS central.
Os resultados obtidos mostraram a viabilidade da utilizao de agentes de aplicao,

acoplados diretamente aplicao, como complemento aos sistemas IDS de rede.
iii
Abstract
Secure channel, as the one generated by protocols like SSL and TLS, has been used on
network services to provide partner authentication, integrity and confidentiality. However, its
utilization prevents a network intrusion detection system to observe and analyze packets
content.
As an alternative to circumvent this problem, the present work proposes an agent-based

intrusion detection, prevention and containment architecture capable to capture messages
flows directly at the host application and introduce it on a distributed intrusion detection
framework. The ADACA (Attack Detection, Analysis and Containment Agent) is a hybrid
agent that can operate on active and passive mode. In this context, it is able to detect attacks
where the application payload is encrypted by secure protocols, like SSL and TLS, and take
some predefined measure before the host application process a malicious content.
Further that, Intrusion Detection Message Exchange Format (IDMEF) standard proposed by
IDWG is considered to send alerts between agent ADACA and an IDS central.
The results shown that is practicable to use an application agent attached to an application as a
complement of network intrusion detection systems.
iv
Sumrio
Lista de Figuras .......................................................................................................................vi

Lista de Tabelas ......................................................................................................................vii
Lista de Abreviaturas............................................................................................................viii
Captulo 1. Introduo ......................................................................................................... 1
1.1 A problemtica da deteco de intrusos ..................................................................... 1
1.2 Motivao ................................................................................................................... 3
1.3 Objetivo ...................................................................................................................... 4
1.4 Organizao do Trabalho............................................................................................ 5
Captulo 2. Conceitos e padres da rea de deteco de intrusos .................................... 6
2.1 Agentes ....................................................................................................................... 7
2.1.1 Classificao de agentes em relao localizao ............................................. 7
2.1.2 Classificao dos agentes em relao atividade............................................... 9
2.2 Padronizao de sistema de deteco de intrusos..................................................... 11
2.2.1 CIDF ................................................................................................................. 12
2.2.2 Intrusion Detection Exchange Format Working Group (IDWG) ..................... 14
2.2.3 SCXP - Secure Components Exchange Protocol ............................................. 17
2.3 Situaes de mensagens fracionadas ........................................................................ 17
2.3.1 Evaso de IDS................................................................................................... 19
Captulo 3. Trabalhos relacionados .................................................................................. 22
3.1 IDREF....................................................................................................................... 22
3.2 ProtoMon .................................................................................................................. 25
3.3 AppArmor................................................................................................................. 27
3.4 Concluso ................................................................................................................. 28
Captulo 4. Proposta de arquitetura e seus componentes ............................................... 30
4.1 API ADACA............................................................................................................. 34
4.2 Mdulo central.......................................................................................................... 35
4.3 API Classifica ........................................................................................................... 36
4.4 API IDS Local .......................................................................................................... 37
4.5 Tabela de controle .................................................................................................... 38
4.6 Mdulo Comunica .................................................................................................... 39
4.7 API IDS Central........................................................................................................ 39
v
4.8 Mdulo Medidas....................................................................................................... 40

4.9 API Aciona ............................................................................................................... 41
4.10 IDS Central ............................................................................................................... 42
4.11 Operao................................................................................................................... 43
Captulo 5. Implementao e ambiente de testes ............................................................. 46
5.1 Escopo da implementao ........................................................................................ 46
5.1.1 Simplificaes .................................................................................................. 46
5.2 Definio da aplicao.............................................................................................. 47
5.3 Ambiente de desenvolvimento ................................................................................. 48
5.4 Implementao do agente ......................................................................................... 48
5.4.1 Integrao do ADACA aplicao .................................................................. 49
5.4.2 Modulo Comunica ............................................................................................ 49
5.4.3 IDS Local.......................................................................................................... 50
5.5 Ambiente de testes.................................................................................................... 50
5.6 Testes ........................................................................................................................ 51
Captulo 6. Anlise de resultados ...................................................................................... 53
6.1 Limitaes da implementao .................................................................................. 54
Captulo 7. Concluso ........................................................................................................ 55
7.1 Trabalhos futuros ...................................................................................................... 56
Referncias .............................................................................................................................. 58
vi
Lista de Figuras
Figura 1. Estatstica sobre a quantidade total de incidentes reportados ao CERT.br ................. 7

Figura 2. Arquitetura funcional CIDF ...................................................................................... 13
Figura 3. Canais de comunicao criados com diferentes perfis em uma nica sesso BEEP. 16
Figura 4. Captura de comando "dir" em conexo telnet ........................................................... 18
Figura 5. Evaso por sobreposio de fragmentos ................................................................... 21
Figura 6. Arquitetura IDS conforme definio do IDWG (SILVA, 2004)............................... 23
Figura 7. Arquitetura IDS adaptada ao IDREF (SILVA, 2004). .............................................. 23
Figura 8. Troca de estados de uma conexo SSL ..................................................................... 26
Figura 9. Arquitetura genrica do ProtoMon (Fonte: (JOGLEKAR; TATE, 2004)) ............... 27
Figura 10. Acesso somente leitura (r) aos recursos acessados pela pgina localtime.php ....... 28
Figura 11. Exemplo de arquitetura de deteco: aplicao com ADACA, sensores de rede e
central de gerncia e correlao................................................................................................ 30
Figura 12. Arquitetura do ADACA e suas interaes com outros componentes ..................... 34
Figura 13. Sintaxe da funo Analisa_Dados( ) da API ADACA............................................ 35
Figura 14. Ambiente estruturado para validao do agente...................................................... 51
vii
Lista de Tabelas
Tabela 1. Diferena entre os modos de operao de agentes.................................................... 11

Tabela 2. Caractersticas bsicas de IDS e IPS......................................................................... 11
Tabela 3. Tabela-exemplo utilizada para armazenamento das incidncias detectadas............. 36
Tabela 4. Exemplo de tabela de medidas. ................................................................................ 40
Tabela 5. Tabela de exemplo de execuo de medidas ............................................................ 41
viii
Lista de Abreviaturas
API Application Program Interface

BEEP Block Extensible Exchange Protocol
CAM Controle de Acesso Mandatrio
CERT.br Centro de Estudos, Resposta e Tratamento de Incidentes de Segurana no Brasil
CIDF Commom Intrusion Detection Framework
CISL Common Intrusion Specification Language
DoS Negao de Servio em ingls Denial of Service
DTD Document Type Definition
HIDS Sistema de Deteco de Intruso baseado em Mquina em ingls Host-based
Intrusion Detection System
HTTP Protocolo de Transferncia de HiperTexto em ingls HyperText Transfer Protocol
HTTPS Protocolo de Transferncia de HiperTexto Seguro em ingls HyperText Transfer
Protocol Secure
IAP Intrusion Alert Protocol
IDMEF Intrusion Detection Message Exchange Format
IDREF Intrusion Detection Response Exchange Format
IDP IDMEF Communication Protocol
IDS Sistema de Deteco de Intruso em ingls Intrusion Detection System
IDWG Intrusion Detection Exchange Format Working Group
IDXP Intrusion Detection Exchange Protocol
IESG Internet Engineering Steering Group
IETF Internet Engineering Task Force
IPS Sistema de Preveno de Intrusos em ingls Intrusion Prevention System
NIDS Sistema de Deteco de Intruso baseado em Rede em ingls Network-based
Intrusion Detection System
RFC Request for Comments
SCXP Secure Components Exchange Protocol
SQL Linguagem de consulta estruturada, em ingls Structured Query Language
SSL Camada de Soquetes Seguro em ingls Secure Socket Layer
TCP Transmission Control Protocol
TLS Transport Layer Security
URL Localizador Uniforme de Recursos, em ingls Uniform Resource Locator
VPN Rede Privada Virtual em ingls Virtual Private Network
ix
XML Extensible Markup Language

XSS Cross-Site Scripting
1
Captulo 1. Introduo
1.1 A problemtica da deteco de intrusos
Com base no estudo realizado nos trabalhos (ABBES; BOUHOULA; RUSINOWITCH, 2004)
e (DASGUPTA et al., 2005), percebe-se que grandes esforos esto sendo feitos na rea de
deteco de intruso de forma a tornar vivel a identificao de atividades maliciosas com
eficcia, procurando reduzir a quantidade de falso-positivos e falso-negativos. Porm, neste
contexto, ainda possvel observar diversas vertentes com grande carncia de pesquisas.
Uma dessas vertentes trata da identificao de ataques quando o alvo destes um
servio ou aplicao que utiliza mecanismos de criptografia na comunicao. Tais
mecanismos so utilizados com o intuito de garantir a confidencialidade dos dados e
autenticao de parceiros. Porm, ao realizar a criptografia dos dados, estes se tornam legveis
apenas para a entidade a que se destinam, tornando invivel a anlise do contedo por parte de
dispositivos de segurana existentes no ambiente, como sistema de deteco de intrusos e
firewall com funcionalidade de inspeo de contedo.
Desta forma, um atacante poderia fazer uso de um mecanismo adotado para aumentar
a segurana da aplicao e camuflar suas atividades ilcitas, sem que seja facilmente
detectado. Como exemplo, pode-se citar a utilizao do protocolo HTTPS como um canal
seguro para varrer sistemas WEB a procura por falhas ou explorar determinada
vulnerabilidade de um servio ou aplicao WEB.

2
Exemplo desta situao pode ser ilustrada pela vulnerabilidade UNICODE do servidor
IIS da Microsoft descoberta em outubro de 2000. Por meio de uma falha no processo de
decodificao de requisies, era possvel executar comandos do sistema operacional e
acessar o contedo das unidades lgicas, conforme reportado em (MICROSOFT, 2000).
Enquanto as correes no eram divulgadas pelo fabricante, a deteco desta falha somente
era possvel por meio de sistemas IDS. No entanto, as conexes realizadas sobre um canal
seguro de comunicao impossibilitavam a anlise dos pacotes.
Para contornar esta situao, a empresa McAfee lanou em meados de 2005 a soluo
Intrushield SSL Traffic Inspection and Prevention (MCAFEE, 2005), um sistema de deteco
de intrusos no qual a chave privada do servio seguro a ser protegido conhecida e utilizada
para decifrar toda a comunicao realizada entre o cliente e servidor. Posteriormente, a
soluo BreachView SSL (BREACH, 2005), voltada para sistemas Linux, foi apresentada pela
empresa Breach, partindo do mesmo princpio.
Estas duas solues, apesar de viabilizar a deteco de intrusos para situaes de
trfego criptografado, compartilham a chave privada dos servios seguros. Esta prtica pode
no ser aceita em muitas organizaes, visto que o compartilhamento da chave privada pode
infringir a poltica de segurana adotada.
De acordo com o recente estudo de PALLER (2005), o crescente aumento dos ataques
focados na camada de aplicao, como SQL Injection (SPI, 2002) e Cross-Site Scripting
(XSS) (ZUCHLINSKI, 2003), somado aos inmeros sistemas de comrcio eletrnico, permite
concluir que, apesar de todos os produtos de segurana disponveis, ainda existe carncia de
solues especficas.
3
1.2 Motivao
Na tentativa de sanar a deficincia existente nos sistemas de deteco atuais algumas solues
foram propostas visando detectar ataques em canais cifrados na camada de transporte e na
camada de aplicao da pilha TCP/IP, sem haver necessidade do conhecimento da chave
privada. Os trabalhos nos quais foram reportadas alternativas para identificao de ataques em
protocolos de segurana, baseiam-se na deteco de anomalias por perfis de trfego. Com
base em um perfil criado a partir de uma fase de treinamento utilizando requisies lcitas,
todos os pacotes que ultrapassarem o limite imposto pelo perfil pr-definido so classificados,
conforme (YASINSAC, 2002) e (LECKIE; YASINSAC, 2004).
Uma alternativa para os ataques direcionados camada de aplicao apresentada por
Joglekar e Tate (2004), na qual os autores propem uma soluo baseada no acoplamento de
um monitor junto a uma aplicao especfica, como um servidor SMTP, ou at mesmo ao
mdulo de criptografia de um servidor WEB. Esse monitor observa as mensagens de controle
do protocolo que so transmitidas entre cliente e servidor, o que torna possvel detectar
ataques baseado no comportamento anmalo do protocolo que monitorado, possibilitando,
ainda, conter certos tipos de ataques especficos. Neste trabalho, Joglekar e Tate convergem os
estudos propostos primeiramente em (SEKAR et al., 2002) e (YASINSAC, 2002) e acrescem
a funcionalidade de reduo da efetividade dos ataques em nvel de aplicao por meio da
insero de intervalos entre o processamento das requisies entrantes. A conteno de
ataques por meio do gerenciamento dos recursos do servidor uma prtica plausvel de ser
utilizada, conforme apresentado em (MEYLAN, 2004), onde tcnicas de qualidade de servio
(QoS Quality of Service) so empregadas para diminuir a quantidade de banda disponvel ao
endereo IP ofensivo, principalmente para ataques de DoS (Denial of Service).

4
PLAGGEMEIER e TLLE (2002) apresentaram o sistema de deteco de intrusos por
meio do agente procurador (proxy) criptogrfico EPIDS (Encrypted Proxy Intrusion Detection
System), no qual todas as conexes provenientes de um cliente SSH so intermediadas por um
proxy transparente capaz de extrair a informao do pacote cifrado, analisar e validar a
existncia de contedo malicioso e, na seqncia, repassar as requisies ao servio. A tcnica
adotada parte do princpio do ataque de Man-in-the-middle (BURKHOLDER, 2002), o qual
possibilita a interceptao e manipulao de pacotes criptografados por meio da interceptao
e troca da chave pblica original do servidor por uma chave pblica falsa.
1.3 Objetivo
Este trabalho apresenta a proposta de uma arquitetura de deteco, preveno e conteno de
ataques baseada em agente de aplicao. O agente de aplicao acoplado a uma aplicao
por meio de uma API genrica. Este agente, denominado ADACA (Agente de Deteco,
Anlise e Conteno de Ataques) capaz de realizar anlise das mensagens recebidas e
transmitidas pelo servidor e de identificar dados considerados anmalos ou maliciosos. Esta
proposta inclui, no somente a definio da arquitetura do agente de aplicao, mas tambm
sua insero em uma arquitetura de deteco distribuda e padronizada. Como estudo de caso,
ser apresentado um prottipo de agente para a situao de um servidor WEB seguro
(HTTPS) e a troca de mensagens entre o agente e um IDS central.
Diferente da abordagem inserida em (SEKAR et al., 2002) e utilizada em
(JOGLEKAR; TATE, 2004), que se baseiam na comparao das mensagens do protocolo com
os perfis pr-definidos (por exemplo, mensagens ClientHello e ClientKeyExchange provindas

5
de uma sesso SSL ou troca de mensagens de um servidor SMTP), a presente proposta
pretende realizar a deteco de ataques por meio da anlise das mensagens do protocolo de
aplicao imediatamente antes de seu processamento pela aplicao, no caso de uma
requisio, ou antes do envio de sua resposta ao cliente, permitindo inserir medidas de
preveno e conteno aos ataques.
1.4 Organizao do Trabalho
Os captulos deste trabalho esto organizados da seguinte forma.
O captulo 2 apresenta os conceitos atualmente empregados a respeito de sistemas
IDS/IPS e os padres e protocolos existentes para a intercomunicao entre esses sistemas,
como o IDMEF e IDXP. O captulo 3 reservado para descrever sobre trabalhos relacionados,
apresentando uma breve introduo ao projeto IDREF (SILVA, 2004), Protomon
(JOGLEKAR; TATE, 2004) e AppArmor (NOVELL, 2005).
A proposta da arquitetura contemplada no captulo 4, no qual conceituado e
introduzido o Agente de Deteco, Anlise e Conteno de Ataques (ADACA), bem como a
arquitetura de deteco e preveno de ataques, a arquitetura e interfaces do agente com os
outros elementos participantes, como o IDS Central e IDS Local. Os detalhes da
implementao da soluo, as peculiaridades das interfaces com os outros dispositivos e os
testes realizados so mostrados no captulo 5. O captulo 6 apresenta os resultados obtidos
para os diferentes modos de operao, um estudo de viabilidade e as limitaes da
implementao. Por fim, o captulo 7 conclui o trabalho e apresenta propostas que devero ser
aprofundadas futuramente.
6
Captulo 2. Conceitos e padres da rea de deteco de
intrusos
Segundo (BACE; MELL, 2001), IDS um sistema baseado em software ou hardware,
normalmente interconectado com outros elementos, capaz de monitorar um canal de
transmisso de dados e arquivos de registros de servidores em busca de trfego anmalo e
aes consideradas maliciosas, por meio de diferentes tcnicas de deteco. O agente IDS,
tambm conhecido como sensor, o elemento responsvel por capturar as informaes que
sero remetidas para anlise.
O IDS pode ser um sistema centralizado, contendo apenas um agente, ou distribudo,
de forma que todos os agentes reportem seus registros e alertas base central de eventos.
Neste contexto, sistemas de filtragem (firewalls) tambm podem ser considerados agentes IDS
quando enviarem notificaes base central.
A utilizao de tal sistema tem se mostrado bastante til frente ao aumento incessante
de ataques partindo da Internet e, at mesmo, internamente aos ambientes corporativos. De
acordo com os dados apresentados pelo Centro de Estudos, Resposta e Tratamento de
Incidentes de Segurana no Brasil (CERT.br), notvel o crescimento exponencial do nmero
de incidentes reportados. Uma breve anlise baseada na quantidade de incidentes reportados
at o ano de 2005, permite concluir que houve um aumento de aproximadamente 51% com
relao ao ano de 2004 (CERT.br, 2005). A Figura 2.1, apresenta a estatstica dos incidentes
reportados nos ltimos anos, exceto pelas ameaas do tipo worm.

7
Incidentes reportados ao CERT.br anualmente

60000
50668
50000
Total de Incidentes
40000 33455
30000
21192
20000 12301 12697
10000 5997
0
2000 2001 2002 2003 2004 2005
Ano Fonte: CERT.br
Figura 1. Estatstica sobre a quantidade total de incidentes reportados ao CERT.br
2.1 Agentes
Para um melhor entendimento sobre as funcionalidades da arquitetura proposta, necessrio
apresentar as diferenas entre as classes de agentes existentes. Os agentes so classificados em
relao a sua localizao e atividade.
2.1.1 Classificao de agentes em relao localizao
De acordo com o NIST (1999), existem trs principais tipos de agentes de deteco de
intruso, sendo:
Agente baseado em rede;
Agente baseado em mquina;
Agente baseado em aplicao.

8
2.1.1.1 Agente baseado em rede (NIDS)
Agente baseado em rede (Network-based Intrusion Detection System - NIDS), comumente
conhecido como sensor de rede, o tipo de IDS mais adotado pelas equipes de segurana
devido ao baixo custo do investimento e mnimo impacto sobre a topologia de rede. Sua
principal funcionalidade detectar a presena de trfego anmalo ou pacotes com dados
maliciosos por meio da escuta digital de pacotes e classific-los de acordo com o contedo,
gerando os alertas. Em seguida, os alertas podem ser reportados ao analisador central para
serem correlacionados e, opcionalmente, alguma contramedida pode ser definida para conter
futuras conexes maliciosas provindas do endereo ofensivo ou pacotes que contenham a
mesma informao.
Apesar das vantagens existentes na utilizao deste tipo de agente, como a
monitorao de enlaces de alta velocidade, este tipo de agente ineficaz na anlise do
contedo de fluxos de dados cifrados, visto que os pacotes somente podero ser abertos por
meio da chave privada armazenada na outra extremidade da comunicao.
2.1.1.2 Agente baseado em mquina (HIDS)
O agente baseado em mquina (Host-based Intrusion Detection System - HIDS) tem como
objetivo monitorar as atividades executadas no sistema operacional local. Entre elas, pode-se
citar a monitorao de processos ativos, trilhas de auditoria, usurios, entre outros. Esta forma
de deteco consome diversos recursos do servidor, como memria, processamento e banda,

9
devido ao constante monitoramento de arquivos e troca de informaes com o servidor central
do IDS, visto que parte das solues existentes analisam os dados em uma mquina remota.
2.1.1.3 Agente baseado em aplicao
O agente baseado em aplicao um subconjunto do HIDS, isso porque sua atuao tem
grande semelhana, sendo distinguido apenas pela monitorao direcionada apenas a uma
aplicao, como um antivrus em servidor de correio eletrnico. Neste contexto, o IDS de
aplicao, como chamado, capaz de validar toda a interao entre o usurio, os dados e a
aplicao (BACE; MELL, 2001).
Os agentes baseados em aplicao so diferenciados dos agentes baseados em mquina
por um limiar bastante estreito. POSEY (2005) ressalta que apesar do escopo de atuao ser
diferente, ambos consomem uma srie de recursos locais, como processamento e memria,
que podem causar atraso no funcionamento da aplicao.
Mesmo tendo grande eficcia no monitoramento da aplicao a ele designada, no
prov qualquer outra funcionalidade ao servidor, como interveno de atividades ilcitas,
podendo ser classificado como um agente passivo.
2.1.2 Classificao dos agentes em relao atividade
Atualmente, existem dois principais modos de operao para os agentes acima citados, sendo
classificados em passivo e ativo. Alm disso, existe um outro tipo de sistema denominado IPS
(Sistema de Preveno de Intrusos) que tem capacidade de bloquear contedo considerado

10
malicioso. Assim sendo, para um melhor entendimento das diferenas entre as formas
operacionais e caractersticas especficas, ser apresentado um resumo de cada um desses
modos.
2.1.2.1 Agente Passivo
O agente passivo um componente de ao limitada, responsvel por detectar ataques e
reportar possveis alertas ao IDS Central. Este tipo de agente no possui qualquer
funcionalidade de contramedida aos alertas gerados, cabendo ao IDS Central interagir com os
dispositivos do ambiente, firewalls e servidores, para conteno de ataques. Atualmente, essa
interao encontrada em solues proprietrias, as quais possibilitam interaes com
diversas marcas e tipos de equipamentos.
J para solues abertas como o Snort (ROESCH, 2005), existem componentes
adicionais, como o SnortSam (KNOBB, 2006) e o Guardian (STEVENS, 2004), que
permitem acionar uma regra de filtragem junto a alguns modelos de firewalls. Porm, a
compatibilidade bastante reduzida e, portanto, nem sempre vivel.
2.1.2.2 Agente Ativo
O agente ativo introduz o conceito mais aproximado ao Intrusion Prevention System (IPS)
(ZHANG; LI; ZHENG, 2004) no qual o agente tem as funcionalidades de prevenir o sucesso
da explorao de ataques ou minimizar o impacto de um ataque bem sucedido, por meio da
interveno direta na receptao dos pacotes considerados maliciosos. A tabela a seguir
resume as principais diferenas entre os dois agentes.

11
Tabela 1. Diferena entre os modos de operao de agentes
Modo de Operao Funcionalidade Conceito-Base

Passivo Deteco IDS
Ativo Deteco e Preveno IPS
2.1.2.3 IPS Sistema de Preveno de Intrusos
De acordo com ENDORF, SCHULTZ e MELLANDER (2004), o sistema de preveno de
intrusos (IPS) tem funcionamento anlogo ao IDS com relao captura e anlise de pacotes,
porm diferenciam-se pelo fato do IPS ser capaz de interceptar e bloquear requisies que no
se adequarem dentre as regras de trfego legtimo pr-estabelecidas.
A maior discusso a respeito do IPS sobre a interveno de conexes nas quais as
requisies so classificadas erroneamente, determinando um falso-positivo. Neste caso, o
sistema iria bloquear requisies provenientes de clientes legtimos.
Uma breve comparao conceitual entre as caractersticas do IDS e IPS pode ser
observada na tabela a seguir.
Tabela 2. Caractersticas bsicas de IDS e IPS
IDS IPS
Instalado em segmentos de rede e mquina Instalado em segmentos de rede e mquina
Observa a rede passivamente Observa e intercepta o trfego
Ineficaz para fluxos criptografados Melhor atuao sobre aplicaes
Controle de gerenciamento centralizado Controle de gerenciamento centralizado
Melhor para deteco de ataques em geral Ideal para bloquear pichaes de pgina
Ao reativa Ao preventiva
2.2 Padronizao de sistema de deteco de intrusos

12
Na grande maioria das vezes, o sistema IDS implementado de maneira distribuda, sendo
composto por diversos agentes alm da base central de alertas e gerenciamento. Para que este
sistema no sofra qualquer problema de interoperabilidade durante a comunicao de alertas e
mensagens de controle entre os componentes existentes, ou ainda, para tornar possvel a
utilizao dos alertas gerados pelos agentes de rede, mquina e aplicao na correlao de
eventos para o rastreamento, interveno e/ou preveno de certa atividade maliciosa, se faz
necessrio adotar um padro que viabilize a transmisso de mensagens uniformemente
(KAHN et al, 1998). Assim, algumas propostas que visam padronizar o formato e contedo
das mensagens e do protocolo de comunicao sero apresentadas a seguir.
2.2.1 CIDF
A arquitetura comum de deteco de intrusos CIDF (Commom Intrusion Detection
Framework) idealizada em (KAHN et al, 1998) e (STANIFORD-CHEN; TUNG;
SCHNACKENBERG, 1998) foi a tentativa inicial de padronizao de sistemas IDS, cujo
objetivo era prover a intercomunicao entre dispositivos de identificao de intrusos e os
sistemas de resposta, como os firewalls. Foi especificada uma linguagem chamada de CISL
(Common Intrusion Specification Language) que formaliza um protocolo para troca de
informaes de alertas, alm da elaborao de um modelo simplificado dos requisitos,
componentes e da arquitetura que compe o sistema. O CIDF prev em sua arquitetura
funcional, os seguintes elementos:
E-Box (Unidade de Eventos): responsvel por gerar eventos de segurana que podero se
tornar alertas, a partir da informao proveniente de uma fonte de dados. No caso de um

13
meio fsico, este mdulo encarregado por reconstruir o pacote de dados e repassar para
anlise;
A-Box (Analisador de eventos): neste onde ocorre toda a anlise e correlacionamento dos
eventos, alm da interao direta com o mdulo de resposta;
R-Box (Unidade de resposta): componente designado para realizar as atividades de
respostas no sistema IDS, sejam elas ativas (contramedida) ou passivas (informativa);
D-Box (Base de eventos): armazena o histrico dos eventos conforme a ocorrncia.
Figura 2. Arquitetura funcional CIDF
Apesar de o esforo inicial ter apresentado pontos positivos com relao
principalmente arquitetura, no mesmo ano de 1998 deu-se incio ao grupo IDWG, o qual
aplicou algumas das idias e conceitos introduzidos na especificao CIDF.

14
2.2.2 Intrusion Detection Exchange Format Working Group (IDWG)
No encontro do IETF de agosto de 1998, foi criado o Intrusion Detection Exchange Format
Working Group, o qual desde ento objetiva a padronizao do formato de dados e
procedimentos para viabilizar o intercmbio das informaes dos alertas.
Dentre os documentos elaborados pelo grupo destaca-se o documento dos requisitos
para a troca de mensagens de deteco de intrusos (WOOD; ERLINGER, 2002). Neste
documento especificado o padro do formato das mensagens (IDMEF Intrusion Detection
Message Exchange Format) e os requisitos necessrios para a implementao deste, alm da
definio do protocolo de comunicao IDP (IDMEF Communication Protocol). Para este
ltimo, foram apresentados diversos requisitos fundamentais para permitir a transmisso de
mensagens entre as entidades participantes. Alguns desses requisitos so:
Autenticao mtua entre sensores e console de gerenciamento;
Transmisso segura de mensagens por meio de mecanismos que garantam a
confidencialidade e integridade do contedo das mensagens durante o processo de
comunicao, devendo ser utilizado algoritmos de criptografia j existentes;
Resistncia a ataques de negao de servio (Denial of Service - DoS);
Proteo contra ataques do tipo replay, baseado no envio malicioso de mensagens
duplicadas.
Em seguida, foi proposto o modelo de dados para representao da informao dos
alertas a serem transmitidos a um IDS Central (DEBAR; CURRY; FEINSTEIN, 2005),
utilizando para tal um DTD (Document Type Definition) que descreve o formato dos dados
IDMEF por meio de documentos XML.

15
Posteriormente a estas publicaes, o grupo desenvolveu a especificao de dois
protocolos interoperveis para comunicao das mensagens IDMEF entre os dispositivos
envolvidos no sistema de deteco de intrusos: o Intrusion Alert Protocol (IAP) (GUPTA et
al., 2001), e o Intrusion Detection Exchange Protocol (IDXP) (FEINSTEIN; MATTHEWS;
WHITE, 2002).
Algumas destas especificaes foram submetidas ao Internet Engineering Steering
Group (IESG) e encontram-se em fase final de rascunho (draft) de padro.
2.2.2.1 Protocolo de comunicao interopervel
Com base no documento de requisitos do IDP, duas especificaes de protocolos foram
desenvolvidas pelo IDWG: IAP e IDXP.
O protocolo IAP foi a primeira tentativa do grupo IDWG em conceituar uma soluo
capaz de cumprir todos os requisitos previamente definidos. Por meio do documento
Intrusion Alert Protocol (GUPTA et al., 2001) foi proposto um protocolo em nvel de
aplicao para o intercmbio de dados de alertas entre as entidades do sistema de deteco,
semelhante ao protocolo HTTP com alguns conceitos de proxy, para autenticao e controle.
Porm, no 50 encontro do IETF foi definido que o desenvolvimento sobre o IAP deveria ser
desconsiderado e que os esforos fossem concentrados em um novo protocolo: o IDXP.
Herdando algumas caractersticas do IAP, o IDXP atende a todos os requisitos
necessrios para se adequar ao modelo proposto pelo IDWG como protocolo de transporte de
mensagens IDMEF.
16
A implementao do IDXP concretizada utilizando um arcabouo de
desenvolvimento de protocolos para camada de aplicao conhecido por Block Extensible
Exchange Protocol (BEEP) (ROSE, 2001) (BUCHHEIM et al., 2001), o qual contempla uma
srie de funcionalidades e mecanismos de controle que garantem integridade,
confidencialidade, autenticao de parceiros, entre outros quesitos. Neste contexto, o
protocolo BEEP funciona analogamente a uma rede privada virtual (VPN) em nvel de
aplicao, estabelecendo um tnel seguro e confivel entre dois pontos sob os quais so
criados canais de comunicao baseados em perfis1, que definem a sintaxe e semntica das
informaes trocadas. A Figura 3 representa um tnel BEEP e o estabelecimento de canais
padronizados por meio do perfil do IDXP e Syslog (NEW; ROSE, 2001). Vale ressaltar que a
forma de comunicao dentro do tnel assncrona, ou seja, no h limitaes para a
quantidade de canais e perfis utilizados simultaneamente entre duas entidades.
Figura 3. Canais de comunicao criados com diferentes perfis em uma nica sesso BEEP
Alm da fcil extensibilidade, uma das maiores vantagens da utilizao do BEEP est
relacionada ao baixo custo de segurana envolvido, pois o processo de autenticao e
1
A documentao referente ao BEEP e os perfis existentes podem ser encontrados em: http://www.beepcore.org
17
negociao pode ser realizado uma nica vez para o estabelecimento de um tnel de
comunicao seguro e confivel. Dentro deste tnel so criados os canais de comunicao
definidos pelos perfis, sem que haja necessidade de outros procedimentos de segurana, como
a autenticao.
2.2.3 SCXP - Secure Components Exchange Protocol
No sentido de tornar o escopo do IDXP mais abrangente, a proposta do protocolo SCXP,
inserida por (YANG; CHANG; CHU, 2003), tem como objetivo prover a integrao entre
todos os componentes de segurana presentes em uma rede por meio de um protocolo nico
de comunicao. Como exemplo pode-se citar o envio assncrono de notificaes (alertas)
detectadas por um firewall ao analisador e, at mesmo, o envio de mensagens de controle
(atuao) do IDS Central ao firewall, designando as aes a serem tomadas no caso de um
ataque.
Esta proposta no pertence aos esforos realizados pelo grupo IDWG e, desde sua
publicao, no foram encontrados outros trabalhos relacionados.
2.3 Situaes de mensagens fracionadas
Dentre os protocolos de comunicao, existem alguns que realizam a comunicao em
pequenos segmentos, como o caso do protocolo TELNET (RFC 318) e SSH (RFC 4251).
Estes protocolos enviam dados conforme a digitao do indivduo que est fazendo uso de tal
servio. De acordo com a implementao, os dados so enviados byte-a-byte ou em pequenos

18
grupos de bytes ao sistema remoto, sendo que a instruo s ser interpretada quando o
servidor receber o sinal de execuo. Se fizermos uma captura digital de pacotes no canal de
comunicao durante uma sesso de telnet, observa-se a seguinte situao (Figura 4).
Figura 4. Captura de comando "dir" em conexo telnet
As situaes de trfego fracionado fazem com que os sistemas de deteco de intrusos
necessitem armazenar o estado de cada um dos bytes enviados de forma a construir a
requisio completa e, somente ento, ser capaz de identificar uma possvel ao maliciosa.
19
Porm, tais eventos de mensagens fracionadas podem ocorrer de outras formas, como
o caso do processo de evaso de IDS, no qual se tem por objetivo burlar sistemas de
deteco.
2.3.1 Evaso de IDS
Evaso de IDS um processo no qual um atacante manipula maliciosamente as requisies
destinadas a um determinado servio de forma que possam passar despercebidas pelo
processo de deteco de intrusos ou subverter o sistema de anlise, diminuindo sua eficcia.
Para obter sucesso neste processo de camuflagem podem ser aplicadas diversas tcnicas,
como a fragmentao e segmentao.
2.3.1.1 Fragmentao
Fragmentao de pacotes uma tcnica adotada no padro do protocolo TCP/IP a fim de
viabilizar a transmisso de pacotes entre diferentes redes. O datagrama IP pode ter um
tamanho mximo de 64Kbits, porm muitas redes no tm capacidade de aceitar pacotes desta
dimenso e necessitam que estes sejam partidos em uma unidade menor para que todos os
elementos de rede presente entre as duas extremidades da comunicao possam trafeg-los.
Uma vez que todos os fragmentos tenham alcanado seu destino, sem necessidade de
obedecer a ordem de chegada, o sistema operacional remoto encarregado em remontar o
pacote.
20
As tcnicas de evaso por fragmentao apresentadas inicialmente por PTACEK e
NEWSHAM (1998) aproveitam este recurso do protocolo IP para fragmentar as requisies
maliciosas, na tentativa de dificultar o processo de deteco. Uma delas baseia na
fragmentao dos pacotes em unidades mnimas de informao, na tentativa de impossibilitar
o armazenamento e remontagem dos fragmentos por parte do sistema de deteco, visto o
grande volume de informao trafegado no enlace. Porm, esta tcnica j no mais eficiente
devido aos pr-processadores dos sistemas de deteco que tem capacidade de armazenar o
estado desses pacotes e identificar requisies maliciosas.
2.3.1.2 Segmentao
A tcnica de evaso por segmentao de pacotes bastante similar de fragmentao,
diferenciada pela atuao na camada de aplicao do protocolo TCP/IP.
Dentre as diversas tcnicas de segmentao de pacotes, pode-se destacar a
sobreposio de fragmentos. Esta tcnica visa transpassar o sistema de deteco devido
subverso na remontagem de pacotes. Seu funcionamento baseado no envio de requisies
segmentadas aplicao, sendo que a quantidade de bytes a serem interpretados pelo sistema
vtima controlado pelo nmero de seqncia do prximo segmento a ser recebido. Ou seja, o
ltimo byte do segmento 1 o primeiro byte do segmento 2. De acordo com a Figura 5, no
caso de um ataque realizado pela requisio HTTP GET /teste.idq a troca de pacotes entre
atacante e vtima se caracterizaria da seguinte forma.

21
Figura 5. Evaso por sobreposio de fragmentos
Alm da fragmentao por sobreposio, existem outras formas como fragmentao
por sobreescrio de bytes e por expirao do tempo de armazenamento no buffer de memria
do sistema de deteco.
22
Captulo 3. Trabalhos relacionados
Durante a etapa de pesquisa, foram encontrados projetos que se relacionam com o presente
trabalho. O projeto mais prximo desta proposta o Intrusion Detection Response Exchange
Format - IDREF (SILVA, 2004), que estende a utilizao do padro IDMEF com a
funcionalidade de envio de contramedidas aos ataques detectados. Outro projeto o
ProtoMon (JOGLEKAR; TATE, 2004), abreviao de Protocol Monitor, no qual
apresentada uma arquitetura de deteco baseada em comportamento anmalo de protocolos.
Mais recentemente foi encontrado o projeto AppArmor (NOVELL, 2005), suportado pela
equipe de desenvolvimento do sistema operacional SUSE da empresa Novell.
3.1 IDREF
Com o intuito de estender a utilizao e acrescer funcionalidades ao modelo de dados IDMEF,
descrito anteriormente, o IDREF tem por objetivo adotar mecanismos que possibilitem a um
operador enviar respostas aos alertas detectados pelo sistema IDS.
Com base no modelo IDMEF, foram realizadas modificaes somente sobre o
elemento resposta da arquitetura original (Figura 6), adicionando relacionamentos e
funcionalidades mais especficas, conforme pode-se observar na Figura 7.

23
Figura 6. Arquitetura IDS conforme definio do IDWG (SILVA, 2004).
Figura 7. Arquitetura IDS adaptada ao IDREF (SILVA, 2004).

24
Portanto, nota-se que os componentes adicionados na arquitetura do IDREF refletem
somente sobre as aes de resposta. Agora, o gerenciador, responsvel por centralizar os
alertas ocorridos no sistema de deteco e apresentar as informaes por meio da console ao
operador, responsvel tambm por controlar as aes de conteno pr-estabelecidas e
selecionadas pelo operador quando em situao de ataque, atuando sobre o componente
contramedida.
Tambm foram estipulados os possveis tipos de resposta a serem selecionados pelo
operador, sendo divididos em trs categorias:
Response: permite enviar ocorrncias de ataques aos operadores por meio de telefone,
pager e e-mail;
React: define as aes de conteno que podem ser atribudas a certos recursos como
bloqueio de arquivos, fechamento de conexes e finalizao de processos do sistema
operacional;
Config: permite alterar configuraes dos recursos, como alterao de permisso de
usurio ou arquivo, reconfigurao de regras de firewall, entre outros.
Toda esta arquitetura se baseia nos alertas gerados por um IDS de rede, ou seja,
mesmo havendo as funcionalidades de resposta e comunicao, esta arquitetura no capaz
de identificar ataques quando o protocolo de comunicao est criptografado, sendo este um
fator limitante.
A implementao do projeto limita-se na troca de mensagens entre os componentes de
deteco, anlise e gerncia. No foi abordada a forma como so realizadas as aes de
resposta, reao e configurao junto aos recursos do ambiente.

25
3.2 ProtoMon
O ProtoMon, proposto por Joglekar e Tate, tem como principal objetivo monitorar protocolos
de comunicao, a fim de identificar requisies maliciosamente manipuladas. Baseando-se
em perfis pr-definidos, realiza-se a identificao de anomalias nas requisies transacionadas
entre cliente e servidor,.
Os autores apresentam trs modos de operao para os agentes: aprendizado, deteco
e preveno. O modo de aprendizado a forma como se determinam os perfis de acesso pr-
definidos. Por meio da anlise do comportamento de conexes legtimas e da anlise
estatstica dos estados de transio de um protocolo, o ProtoMon permite definir o tipo de
requisio e resposta esperado. Ou seja, os agentes analisam todo o fluxo de mensagens
trocadas entre cliente e servidor desde o estabelecimento da conexo at a finalizao da
mesma, observando a ordem e freqncia da apario de mensagens do protocolo analisado.
Dessa forma, o ProtoMon viabiliza a identificao de ataques que tem por objetivo explorar
falhas em protocolos seguros, como o SSL. A Figura 8 apresenta as etapas utilizadas no
estabelecimento de uma conexo segura, as quais estariam sendo analisadas constantemente
pelo monitor do protocolo.

26
Figura 8. Troca de estados de uma conexo SSL
J o modo de deteco faz uso do perfil criado pelo modo de aprendizado como
padro de comportamento esperado. definido certo nvel de tolerncia para o trfego no
completamente condizente ao padro, de forma que o mesmo no seja classificado como
anmalo. Aps observada a presena de alguma conexo que esteja ultrapassando o limite
estabelecido, um alerta gerado e o modo de preveno pode ser acionado.
A nica ao pr-ativa capaz de ser acionada consiste no aumento do tempo de
resposta entre as requisies recebidas pelo servidor, a fim de evitar o sucesso do ataque. Esta
contramedida permite a conteno de ataques protocolos seguros do tipo timing
(KOCHER, 96) e side-channel (KESLEY et al., 2000), visto que esses ataques so baseados
no estabelecimento de milhares de conexes com o intuito de deduzir a chave privada
(BRUMLEY; BONEH, 2003).

27
Figura 9. Arquitetura genrica do ProtoMon (Fonte: (JOGLEKAR; TATE, 2004)).
Porm, h controvrsias com relao a este mtodo de conteno, uma vez que
existem ataques pontuais, como ataques do tipo DoS, nos quais poucas requisies seriam
suficientes para indisponibilizar ou causar algum dano ao servidor ou servio alvo, conforme
pode ser exemplificado pelos boletins de segurana da US-CERT (2005a)(2005b). Isso sem
contar que o sistema proposto por (JOGLEKAR; TATE, 2004) no capaz de atuar somente
sobre as conexes e requisies maliciosas, afetando o desempenho de resposta sobre toda
aplicao.
3.3 AppArmor
Uma proposta para delimitar o escopo de execuo de determinado processo, baseando-se na
utilizao de esquemas de controle de acesso mandatrios CAM - (SANDHU, 1993), foi

28
apresentada pela empresa Novell. A ferramenta AppArmor (NOVELL, 2005), como foi
nomeada, tem o propsito de inserir controles de leitura, escrita e gravao por usurio e
servio, o que remete ao conceito caixa de areia (SandBox). Todos os recursos necessrios
para execuo de determinada aplicao so mapeados e, ento, criado um perfil contendo
as permisses necessrias para o correto funcionamento.
Com isso, mesmo que os servios oferecidos ao usurio, como servio de correio
eletrnico, aplicaes WEB e compartilhamento de arquivos, contenham algum tipo de
vulnerabilidade, o sistema operacional bloqueia o acesso a qualquer recurso que no esteja
explicitamente definido. A figura a seguir define o perfil de execuo da pgina
localtime.php por meio da atribuio de restries aos recursos do sistema operacional
necessrios para exibio da pgina.
/usr/sbin/httpd2-prefork^/cgi-bin
localtime.php
{
/etc/localtime r,
/srv/www/cgi-bin/localtime.php r,
/usr/lib/locale/** r,
}
Figura 10. Acesso somente leitura (r) aos recursos acessados pela pgina localtime.php
Esta soluo, mesmo que bastante recente e ainda em desenvolvimento, j est inserida nas
distribuies do sistema operacional Suse, em sua verso comercial.
3.4 Concluso
29
Os trabalhos apresentados neste captulo trataram de pontos especficos relacionados a
deteco, conteno e preveno de ataques e, at mesmo, da padronizao de mensagens de
controle para sistemas IDS.
O IDREF prope a extenso da utilizao do padro do formato de mensagens
IDMEF, de forma a possibilitar a troca de mensagens de controle e envio de respostas a partir
do IDS Central de gerenciamento ao agente de deteco. O agente Protomon realiza a anlise
do protocolo por meio da utilizao de mquinas de estados e possibilita maximizar o tempo
de processamento das requisies em situaes de ataque, porm impactando tambm nas
conexes lcitas. A proposta da empresa Novell permite prevenir a ocorrncias de ataques
restringindo ao mximo os recursos do servidor que so utilizados pela aplicao.
Embora tais propostas tenham seus pontos fortes, ainda existem lacunas para
desenvolvimento de alternativas ainda no abordadas que envolvam, por exemplo, a anlise
do contedo de mensagens de protocolos seguros ou que integrem duas ou mais propostas
para realizao de um projeto mais homogneo.

30
Captulo 4. Proposta de arquitetura e seus componentes
Este captulo descreve a arquitetura de deteco, seus componentes e a arquitetura do agente
de deteco e preveno de ataques, objetivo principal deste trabalho.
A proposta do Agente de Deteco, Anlise e Conteno de Ataques (ADACA) faz
parte de uma arquitetura de deteco de intruso que composta por agentes IDS de rede,
agentes ADACA e a central de correlao de alertas e gerenciamento (IDS Central),
mostrado na Figura 11. O agente de aplicao, foco do trabalho, integrado diretamente
aplicao, o que permite obter maior controle sobre o fluxo de mensagens transacionadas.
Figura 11. Exemplo de arquitetura de deteco: aplicao com ADACA, sensores de rede e
central de gerncia e correlao.
A Figura 11 apresenta a topologia de rede adotada em uma soluo de IDS completa,
estando presente tanto os componentes propostos com o presente trabalho quanto outros
31
agentes de rede que realizam a deteco de eventos por meio dos dados trafegados no canal de
comunicao, contribuindo com o correlacionamento de eventos.
O ADACA um agente hbrido que pode ser configurado para operar nos modos ativo
e passivo, possibilitando realizar a deteco, preveno e conteno de requisies maliciosas
e respostas anmalas ou no autorizadas.
Os atos de preveno e conteno so obtidos por meio de medidas genricas, as quais
contm uma ao ou um grupo de aes a serem executadas quando uma medida for
instanciada. De acordo com o momento em que for instanciada que se distingue entre
medida de preveno ou conteno.
O conceito de medida de preveno definido por toda interao realizada no sistema
operacional pelo ADACA ou mesmo por processamento interno do agente, que tenha por
objetivo impedir que determinado ataque ou requisio maliciosa cause qualquer impacto ao
sistema alvo. Pode-se citar como exemplo de uma medida de preveno a insero de uma
medida que visa bloquear determinado endereo IP de origem, o qual tenha sido caracterizado
como endereo ofensivo pelo IDS Central.
As medidas de conteno, ou contramedida, so as interaes que visam conter ou
minimizar o impacto de um ataque quando este j esteja em andamento. Para citar um
exemplo pode-se supor a explorao de uma falha que tenha por objetivo obter uma console
remota no servidor alvo. Nesta situao, o atacante necessita realizar diversas conexes para
explorar e fazer uso da console obtida, as quais poderiam ser bloqueadas por uma medida de
conteno.
A preveno de ataques realizada em duas diferentes situaes. A primeira ocorre
quando o agente est configurado em modo ativo, pois a classificao e anlise dos dados so
realizadas sincronamente com o processamento da requisio pela aplicao. Nesta

32
configurao, o agente ADACA possibilita o descarte da requisio e at mesmo a insero de
uma medida preventiva para situaes nas quais j exista uma medida previamente definida.
O segundo caso independente do modo de operao do agente. realizado por meio
de mensagens de controle que so configuradas e enviadas por meio da console do IDS
Central ao ADACA, nas quais esto contidas as medida preventivas, fruto do
correlacionamento de eventos dos agentes distribudos.
Outra forma de atuao do ADACA por meio de medidas de conteno, ou
contramedidas. Estas medidas somente so aplicadas quando o agente estiver operando no
modo passivo, visto que a anlise dos dados realizada assincronamente pelo IDS Local.
Assim que houver correspondncia de uma medida pr-definida para o resultado da anlise e
classificao da mensagem, que se realiza a conteno do ataque.
Para realizao da troca de mensagens entre agente e IDS Central foram definidos
eventos de monitorao e controle (Figura 11), ambos podendo ser gerados e enviados
assincronamente. Os eventos de monitorao so as mensagens nas quais esto contidos os
alertas detectados pelos agentes distribudos ao longo do ambiente de rede e enviados ao IDS
Central a fim de inform-lo sobre a ocorrncia das atividades anmalas. J os eventos de
controle so mensagens enviadas unidirecionalmente pelo IDS Central aos agentes, quando
estes suportam tais mensagens, e neles esto contidos os comandos que devero ser
executados no agente.
Uma mensagem de controle emitida pelo IDS Central ao agente pode conter comando
de configurao, insero de medida ou programao de uma nova medida. Um comando de
configurao permite, por exemplo, ativar e desativar o agente, configurar o modo de
operao (ativo ou passivo), controlar gerao de registros (logs), entre outras.

33
O formato da mensagem e o protocolo de comunicao utilizado para informar o IDS
Central a respeito dos eventos ocorridos so baseados no padro IDMEF proposto em
(WOOD; ERLINGER, 2002) e (DEBAR; CURRY; FEINSTEIN, 2005), apresentado na seo
2.2.2.
A arquitetura do ADACA foi desenvolvida levando-se em considerao a
portabilidade entre diversos sistemas operacionais e a possibilidade de integrao a diferentes
aplicaes. Para isto, foi definido um ncleo nico genrico no qual esto compreendidos os
componentes de anlise, comunicao e atuao. A API ADACA define a interface deste
ncleo com a aplicao. Este ncleo tambm interage com mdulos externos por meio de
interfaces padronizadas apresentadas a seguir:
Interface com acionador: informa a medida a ser adotada pelo acionador;
Interface com classificador: possibilita a classificao da mensagem;
Interface com IDS Local: viabiliza a anlise da mensagem e deteco de alertas;
Interface com IDS Central: viabiliza a troca de mensagens de monitorao e controle;
A Figura 12 apresenta os elementos que compem o ADACA e as interaes
realizadas entre eles. Posteriormente, neste captulo, ser explanado com maiores detalhes o
modo operacional da arquitetura de deteco.

34
Requisio
Aplicao
Resposta
ADACA
API
aplicao
Ncleo
ADACA
Mdulo Mdulo
Medidas Central
Mdulo de
Comunicao
API API API API

Acionador Classificador IDS Central IDS Local
IDS IDS
Classificador Mdulo
Acionador
Adaptador Local Central
Sistema
Operacional
Rede Local
Figura 12. Arquitetura do ADACA e suas interaes com outros componentes
4.1 API ADACA
A API ADACA possibilita que a aplicao repasse ao ADACA mensagens para serem
analisadas. Desta forma, possvel ao agente observar e analisar as mensagens de requisio e
resposta. Na requisio, a aplicao, aps receber uma mensagem, deve repass-la ao
ADACA utilizando a funo Analisa_dados( ) da API ADACA. Na resposta, a aplicao,
aps a formatao da mensagem de resposta, pode submet-la para anlise utilizando esta
mesma funo.
35
A funo Analisa_dados( ) necessita, alm da mensagem, informaes sobre o
endereo IP e porta origem, endereo IP e porta destino, sentido e contexto. O contexto
qualquer informao adicional, mantida pela aplicao, que possa ser til ao agente ADACA.
A Figura 13 apresenta a sintaxe desta funo e seus argumentos.
Estado = Analisa_dados(sentido,IPo, Po, IPd, Pd, Mensagem, Contexto);
Figura 13. Sintaxe da funo Analisa_Dados( ) da API ADACA
Como j foi citado, o agente pode operar nos modos ativo e passivo. Esta configurao
obtida de um arquivo de configurao no momento de iniciao do agente, porm pode ser
redefinida atravs de mensagens de controle proveniente do IDS Central ou mesmo por meio
da funo Modo_operacao( ) da API ADACA.
Quando o agente estiver configurado para operar no modo ativo, a funo
Analisa_dados( ) aguarda o processo de anlise ser concludo para retornar o resultado
aplicao. Caso opere no modo passivo, a funo retorna imediatamente e o processo de
anlise ocorre paralelamente ao processamento da mensagem pela aplicao.
Mesmo quando o agente ADACA opera no modo passivo podem ser ativadas medidas
de conteno e preveno.
4.2 Mdulo central
O mdulo central coordena as atividades de anlise e aes realizadas pelo agente ADACA.
Quando um pedido de anlise requisitado pela aplicao, o mdulo central invocado. Este,
por sua vez, aloca o pedido em uma tabela de controle e, em seguida, ativa a funo
36
Classifica_mensagem( ) da API Classifica. No retorno desta funo, o resultado da
classificao registrado na tabela e, em seguida, requisitado ao IDS Local a anlise da
mensagem. Terminada a anlise, o mdulo central registra o resultado na tabela de controle.
Caso o IDS Local tenha detectado alguma mensagem anmala ou maliciosa, ativado
o mdulo comunica para submeter o alerta ao IDS Central. Independente do resultado do IDS
Local, o mdulo de medidas ativado a fim de verificar se para a mensagem em anlise existe
alguma medida registrada. O mdulo de medidas utiliza como base os parmetros registrados
na tabela de controle do ADACA e na tabela de medidas cadastradas. Caso exista, a medida
invocada e registrada na tabela de incidncias. A Tabela 3 apresenta um exemplo da tabela de
incidncias.
Tabela 3. Tabela-exemplo utilizada para armazenamento das incidncias detectadas
# Alerta Classific. IP P. IP P. Mensagem Contexto Id. Hora

Orig. Orig. Dest. Dest. medida Data
1 78 GET 10.0.0.10 4567 10.0.0.2 80 GET /etc/passwd 1 14:30:4567
05/01/06
2 67 GET 10.0.0.6 3205 10.0.0.2 80 GET /inc/global.asa 14:24:0345
05/01/06
3 X OPTIONS 10.0.0.13 3890 10.0.0.2 443 OPTIONS / 3 14:35:2309
05/01/06
4 54 POST 10.0.0.11 2015 10.0.0.2 443 POST /../../boot.ini 14:29:3678
05/01/06
A tabela de incidncias, apresentada na Tabela 3, registra os alertas, eventuais medidas
executadas e relaciona, tambm, as mensagens que geraram o alerta.
4.3 API Classifica
Esta interface realiza a ponte entre o mdulo central e o classificador. A principal funo
definida nesta API Classifica_mensagem( ) que possui como parmetros de entrada o

37
endereo IP e porta de origem, endereo IP e porta destino e a mensagem a ser classificada.
Como resultado da funo obtida a classificao da mensagem.
O classificador um mdulo opcional da arquitetura do ADACA. Sua funo
principal classificar a mensagem do protocolo de aplicao. Como exemplo, pode-se citar as
mensagens GET, POST e HEAD do protocolo HTTP e as mensagens HELO, RCPT TO,
VRFY, MAIL FROM do protocolo SMTP.
Devido varincia das regras de classificao, as quais so dependentes da aplicao,
o classificador foi definido como um mdulo externo ao ncleo do ADACA. De acordo com o
perfil estipulado, o classificador poderia implementar, inclusive, uma mquina de estado para
anlise das mensagens trocadas com um mesmo parceiro, incrementando funcionalidades ao
processo de classificao.
4.4 API IDS Local
O IDS Local, apesar de no fazer parte do agente, um elemento fundamental para o
funcionamento da arquitetura de deteco, uma vez que ele responsvel por analisar a
mensagem interceptada junto aplicao. Para permitir a integrao ao ADACA foi definida a
API IDS Local. Esta API tem como objetivo definir uma interface padronizada para
acoplamento de diferentes tipos de IDS.
Por padro, a API IDS Local converte os dados para o formato PCAP2, este suportado
por analisadores de pacotes e sistemas de deteco, como o Snort e Cisco NetFlow. De
2
Maiores informaes podem ser obtidas em http://www.tcpdump.org
38
qualquer forma, possvel definir um mdulo adaptador responsvel por converter os dados
recebidos para o formato especfico do sistema de deteco a ser empregado.
Para realizar a troca de informaes, foi definida a funo Analisa_IDS( ). Ao final do
processo de anlise, a funo retorna um dos dois possveis resultados: normal ou anmalo.
No caso de anmalo, a funo tambm informa o alerta gerado pelo IDS Local.
4.5 Tabela de controle
Para cada mensagem submetida ao agente ADACA para anlise criado um registro na tabela
de controle. Neste registro so mantidas informaes relevantes associadas ao processo de
anlise desta mensagem, incluindo os parmetros informados pela aplicao.
As informaes relacionadas ao sentido da mensagem, endereo IP origem, porta
origem, endereo IP destino, porta destino, mensagem e contexto foram obtidas da chamada
da funo Analisa_dados( ) da API ADACA. O instante determinado e registrado pelo
prprio agente ADACA. Os resultados da classificao e anlise da mensagem so registrados
aps o processamento do classificador e anlise do IDS Local, respectivamente.
Os prximos mdulos a serem apresentados iro utilizar as informaes registradas na
tabela de controle.
39
4.6 Mdulo Comunica
O Mdulo Comunica responsvel por gerenciar toda comunicao realizada entre o
ADACA e o IDS Central e adequar os eventos de monitorao ao padro IDMEF. J para o
recebimento de eventos de controle utilizado o formato IDREF (SILVA, 2004), apresentado
na seo 3.1.
A comunicao entre o agente ADACA e o IDS central realizada assincronamente,
de forma que os eventos de monitorao e de controle sejam independentes. Esses eventos so
transmitidos utilizando o protocolo IDXP por meio da API IDS Central.
4.7 API IDS Central
A API IDS Central define a interface de funes entre o agente ADACA e o IDS Central
remoto por meio das funes Enviar_alerta( ) e Callback_controle( ). A funo
Enviar_alerta( ) destina-se a notificar os eventos de monitorao ao IDS Central. J a funo
Callback_controle( ) permite receber mensagens de controle provenientes do IDS Central. O
mdulo central do agente responsvel por tomar as devidas providncias, de acordo com o
valor do parmetro tipo_controle informado na funo Callback_controle( ). Caso seja uma
mensagem de comando de configurao do modo de operao do agente, a funo
Modo_operacao( ) da API ADACA acionada. No caso de criao ou insero de uma
medida ativada uma funo do mdulo medidas.

40
4.8 Mdulo Medidas
O mdulo medidas tem como objetivos gerenciar as medidas existentes, registrar novas
medidas a serem executadas e analisar a existncia de alguma medida pr-definida para cada
uma das mensagens.
Para melhor entendimento do funcionamento deste mdulo ser primeiramente
apresentado o gerenciamento das medidas existentes. Para realizar o controle das medidas, foi
definida uma tabela de medidas que contm a identificao da medida, a condio em que
ativada, o tipo da ao a ser executada e o tempo de execuo, conforme mostrado na Tabela
4.
Tabela 4. Exemplo de tabela de medidas.
Id Classificao ID Ao Durao (min)

Medida Alerta
1 78 Bloqueia_ip 10
2 89 Bloqueia_porta 5
3 OPTIONS Bloqueia_porta 10
4 63 Shutdown
Com relao ao gerenciamento das medidas, ainda existe a funcionalidade de registrar
e remover medidas com base nas informaes recebidas pelo mdulo central. Este
procedimento realizado por meio da funo n_medida = Incluir_medida(Classificao,
ID_Alerta, Ao, Tempo) e Excluir_medida(n_medida), respectivamente.
Com base na tabela de controle, apresentada na seo 4.5, realizada uma consulta
tabela de medidas a fim de verificar a existncia de uma medida para a mensagem. Caso
41
exista, este mdulo torna-se responsvel por solicitar ao mdulo acionador a insero desta
medida pr-definida e controlar seu tempo de execuo.
Para realizao desta tarefa foi definida a funo
Executar_medida(entrada_tabela_controle). Como retorno desta funo informado ao
mdulo central a identificao da medida executada.
Uma outra tabela, denominada tabela de execuo de medidas, relaciona todas as
medidas executadas pelo agente ADACA. Nesta tabela esto presentes os endereos e portas
de origem e destino do ataque, o nmero da medida adotada e a data e hora. Esta tabela tem
como objetivo controlar o tempo de execuo de cada uma das medidas de acordo com a
especificao da mesma, sendo que ao trmino do tempo a medida automaticamente
desativada. A Tabela 5 apresenta um exemplo da tabela de medidas executadas.
Tabela 5. Tabela de exemplo de execuo de medidas
Id Data Hora Data Hora

Ao Dados
Medida Incio Incio Trmino Trmino
12 Bloqueia_ip 200.100.20.1 05/01/06 14:30 05/01/06 14:40
8 Bloqueia_porta 200.200.20.1:80 05/01/06 14:35 05/01/06 14:50
2 Desativa_interface Eth0 06/01/06 00:25
4 Shutdown 06/01/06 14:00
Como ltimo propsito, mas no menos significativo, a Tabela 5 serve como
repositrio de registros (logs) a serem utilizados para fins de auditoria.
4.9 API Aciona
A comunicao entre o mdulo medidas e o mdulo acionador estabelecida por meio da API
Aciona, que relaciona as aes que podem ser realizadas sobre os recursos do sistema
42
operacional. Como exemplo, pode-se citar a criao de uma regra junto ao firewall local, a
reiniciao de uma determinada conexo e o redirecionamento do trfego de um endereo IP
origem para outro destino, como, por exemplo, uma honeynet3.
O mdulo acionador a poro do agente responsvel por mapear as aes definidas
na API Aciona em comandos do sistema operacional.
Foi definido, no presente momento, um conjunto bsico de funes na API Aciona
para controlar as aes realizadas junto ao sistema operacional, sendo:
Estado bloqueia_IP (IPo);
Estado desbloqueia_IP(IPo);
Estado bloqueia_porta (IPo,Pd);
Estado desbloqueia_porta(IPo,Pd);
Estado Shutdown();
Estado Desativa_interface(interface);
Estado Ativa_interface(interface);
4.10 IDS Central
3
Rede simulada para atrair e avaliar a forma conduzida por atacantes. Maiores informaes podem ser obtidas no
site do projeto Honeynet: http://www.honeynet.org
43
Este elemento dispensvel para o funcionamento do agente, porm, sem ele no existiria a
arquitetura de deteco e somente um sistema de deteco isolado. Como j foi citado, o IDS
Central possui funo de gerenciador de agentes e repositrio unificado de alertas de todos
agentes distribudos ao longo da rede.
Como gerenciador de agentes, o IDS Central possibilita o monitoramento do estado e
configurao do modo de operao de cada um dos agentes, a programao de novas medidas
e o pedido de insero de uma medida. Como repositrio de alertas, permite a correlao dos
eventos que forem acontecendo ao decorrer do tempo em todo ambiente.
Com relao comunicao, o IDS Central capaz de receber eventos de monitorao
formatados sobre o padro IDMEF e enviar eventos de controle aos agentes utilizando o
formato IDREF. Esses dois tipos de eventos so independentes e ocorrem assincronamente
durante a operao do sistema. Os eventos de controle somente sero disparados por meio de
interao humana, de forma que seja possvel analisar claramente a veracidade das
informaes correlacionadas e impedir que uma medida de preveno seja adotada
equivocadamente.
4.11 Operao
Para representar o modo de operao do ADACA sero descritos os detalhes das interaes
entre os mdulos e componentes apresentados anteriormente na Figura 12.

44
Aps o estabelecimento da conexo, seja utilizando um tnel criptografado por meio
de protocolo de aplicao segura (HTTPS, SFTP, entre outras) ou em texto plano, inicia-se a
troca de mensagens entre cliente e servidor.
Quando uma requisio for recebida ou imediatamente antes de uma resposta ser
enviada ao cliente, a aplicao deve submet-la ao ADACA para anlise. Para isto, ativa a
funo Analisa_dados( ) da API ADACA que responsvel pelo registro dos parmetros
passados na funo em uma nova entrada da tabela de controle. Neste momento, se o agente
ADACA estiver operando no modo passivo, a funo retorna imediatamente para a aplicao.
Caso opere no modo ativo, a funo ir retornar somente aps finalizada toda anlise da
mensagem.
Dando continuidade ao processamento, o mdulo central do ADACA ativa o mdulo
classificador, por meio da funo Classifica_mensagem( ) da API Classifica, e, em seguida,
ativa a anlise da mensagem junto ao IDS Local, o qual utilizar suas tcnicas de deteco a
fim de determinar a presena de dados maliciosos. Ao final destes processos, os resultados so
retornados ao mdulo central, bem como o alerta detectado, se esta for a situao. Caso exista
um alerta, este encaminhado ao mdulo comunica para ser formatado e enviado ao IDS
Central.
Com base na entrada recm registrada na tabela de controle, o mdulo medidas
ativado para determinar a presena de alguma medida definida para a mensagem em anlise.
Caso no haja qualquer relacionamento com a tabela de medidas (Tabela 4), a requisio pode
ser considerada lcita e a funo Analisa_Dados( ) da API ADACA retorna informando que
no foi detectada anomalia na mensagem e a libera para processamento. Do contrrio, as
informaes sobre a mensagem, classificao e anlise so gravadas na tabela de incidncias
(Tabela 3), juntamente com a medida a ser adotada, se este for o caso.
45
Neste caso, a medida instanciada de acordo com as informaes constantes da
entrada na tabela de controle e sua execuo repassada ao mdulo acionador, o qual ir
realizar as devidas interaes com o sistema operacional para prevenir ou conter alguma
ameaa.
No mdulo comunica, o alerta formatado de acordo com o padro IDMEF e enviado
ao IDS Central. Paralelamente a estas atividades, o IDS Central realiza constantemente o
correlacionamento de eventos recebidos por todos os agentes.
Quando surgir a necessidade do IDS Central enviar um evento de controle, seja
destinado configurao do modo de funcionamento do agente, insero ou programao de
uma medida de preveno, a funo Callback_controle( ) da API IDS Central ativada e o
evento direcionado ao mdulo central do ADACA. Este mdulo determina a que propsito
se destina este evento de controle e interage com o mdulo medidas ou com a API ADACA.
Os mesmos procedimentos acima descritos so utilizados para analisar o trfego de
sada da aplicao, sendo que o mdulo classificador pode ser mais utilizado que o prprio
IDS Local, visto que as condies de classificao seriam mais dinmicas baseando-se nos
perfis adotados.
46
Captulo 5. Implementao e ambiente de testes
O objetivo a ser alcanado com a implementao de um prottipo do ADACA dentro do
contexto da arquitetura de deteco apresentada realizar uma prova de conceito que
possibilita avaliar a viabilidade de implementao do agente integrado a uma aplicao real.
5.1 Escopo da implementao
Para possibilitar a validao da arquitetura de deteco apresentada no captulo anterior, foi
desenvolvido o agente genrico de deteco em nvel de aplicao ADACA, conforme
ilustrado pela Figura 12. Porm, foi necessrio realizar algumas limitaes no escopo do
desenvolvimento do prottipo.
O componente IDS Local, indispensvel para o funcionamento do ADACA, no o
foco desta pesquisa. Portanto, para esta validao foi considerada a adoo da soluo Snort
como mecanismo de deteco, uma vez que esta ferramenta possui funcionalidades
especficas que satisfazem a necessidade da arquitetura proposta.
5.1.1 Simplificaes
O componente IDS Central foi implementado parcialmente. Foi desenvolvida uma
central de gerenciamento que possibilita enviar eventos de controle. O mecanismo de
correlao de eventos um componente de alta complexidade sobre o qual existem diversos

47
trabalhos especficos a respeito (WANG; ABDEL-WAHAB, 2005) (XU; NING, 2004) (WU;
FOO; MEI; BAGCHI, 2003), no sendo do escopo do trabalho e, portanto, no considerado
para a etapa de implementao.
Com relao comunicao de eventos de monitorao ao IDS Central, no ser
utilizado o protocolo de comunicao IDXP, baseado na especificao IDP. At o momento
da etapa de implementao, somente foi encontrada uma biblioteca na linguagem Java que
fosse capaz de implementar o protocolo IDXP, dificultando a integrao com este projeto.
Como o protocolo no foco do trabalho este recurso foi substitudo por um simulador de
comunicao na API Comunica do ADACA.
5.2 Definio da aplicao
Antes de ser iniciada a fase de codificao, foi necessrio definir uma aplicao representativa
para a fase de testes. Neste contexto, a aplicao escolhida para ser utilizada foi o servio
WEB, uma vez que o protocolo utilizado por este servio contempla a verso em texto-plano
(HTTP) e a verso segura (HTTPS), implementada sobre o SSL/TLS.
Uma vez definido o tipo de aplicao que seria utilizado como prova de conceito,
realizou-se uma pequena busca acerca das peculiaridades dos servidores WEB mais
utilizados, sempre focando as interfaces existentes para a integrao com o ADACA. Desta
forma, o servidor WEB Apache (www.apache.org) foi escolhido pois, alm de ser uma
soluo de cdigo aberto, o servidor utilizado por aproximadamente 67% dos 15 milhes de
sites avaliados, de acordo com a estatstica da Netcraft (2006).

48
Outra vantagem existente com esta escolha com relao ao suporte a plataformas
operacionais distintas, possibilitando a portabilidade do agente de deteco a diversos
sistemas operacionais.
Para a prova de conceito foi utiliza a verso 1.3.34 do Apache, atualmente a mais
recente da distribuio 1.3. As distribuies 2.0 e 2.2 no foram consideradas, pois realizam o
processamento das mensagens em mltiplas linhas de execuo (multithreads), o que
dificultaria a codificao do prottipo.
5.3 Ambiente de desenvolvimento
Para desenvolvimento dos componentes do ADACA foi utilizada a linguagem de
programao C. Esta linguagem foi escolhida pela portabilidade e por ser utilizada na
implementao do servidor WEB Apache, facilitando a adaptao deste aplicativo ao
prottipo.
O prottipo foi desenvolvido no sistema operacional Fedora Core 4 da Red Hat e o
compilador utilizado foi o GCC verso 4.0.
5.4 Implementao do agente
Conforme apresentado no captulo 4, o ADACA foi projetado em mdulos especficos e bem
definidos, facilitando o desenvolvimento e codificao do prottipo. A seguir, sero
apresentados alguns detalhes da fase de implementao.

49
5.4.1 Integrao do ADACA aplicao
Para tornar possvel integrao do ADACA, se fez necessrio realizar uma anlise detalhada
do cdigo-fonte e das funes utilizadas pelo Apache, no tratamento de requisies e
respostas. Foi identificado que a funo ap_process_request(), do arquivo http_request.c,
realiza o processamento das requisies no servidor Apache. Em seguida, foram mapeadas as
variveis que armazenam as informaes a respeito da mensagem, como endereos IPs e
portas.
At alcanar a funo Analisa_Dados() da API ADACA, inserida antes da funo
ap_process_request(), o Apache realiza diversas validaes da mensagem da requisio
entrante com o intuito de verificar a presena de requisies incompletas. Se este for o caso,
as informaes sobre a mensagem no passam pela API ADACA e retornada uma pgina de
erro padro do prprio Apache.
Para realizar a anlise da resposta a funo Analisa_Dados() da API ADACA ativada
entre a funo ap_process_request() e a funo ap_bhalfduplex(). A funo
ap_bhalfduplex() finaliza a formatao da mensagem de resposta antes que sejam gerados
os registros (logs) de auditoria e o envio da resposta ao cliente pelo Apache.
5.4.2 Modulo Comunica
Para implementao do Mdulo Comunica foi utilizada a biblioteca LibIDMEF (POPPI, S.;
MIGUS, A.; MCALERNEY, J., 2005) que possibilita a padronizao dos alertas ao formato
50
IDMEF. Tambm, foi identificado que o Snort tem como uma de suas funcionalidade a
gerao de alertas no formato IDMEF, baseado nesta mesma biblioteca.
No entanto, como a arquitetura do ADACA visa possibilitar a utilizao de outros
mecanismos de deteco como IDS Local, a biblioteca LibIDMEF foi integrada ao mdulo
comunica para formatao dos alertas, ao invs de obt-los padronizados a partir do Snort.
Apesar de no ser totalmente documentada, a integrao ao mdulo comunica pde ser
realizada de forma bastante satisfatria, sem haver necessidade de despender muito tempo.
5.4.3 IDS Local
Conforme citado anteriormente, apesar do IDS Local no ser o objeto de pesquisa deste
projeto, sua utilizao imprescindvel. Portanto, foi definido que a soluo Snort deveria ser
utilizada para anlise das mensagens recebidas pelo ADACA, pois, alm de ser uma
ferramenta de livre distribuio e portvel para diversos sistemas operacionais, possui
funcionalidades que facilitam a integrao ao ADACA. Entre elas, pode-se destacar a anlise
de pacotes por meio de arquivo de entrada no formato PCAP e o envio dos alertas detectados
por socket interno, possibilitando a comunicao entre processos.
5.5 Ambiente de testes
Para realizao dos testes se fez necessrio definir um ambiente que houvesse as mesmas
caractersticas de um ambiente real e que possibilitasse a execuo dos testes de viabilidade

51
com a utilizao do ADACA como soluo de segurana. A arquitetura apresentada na Figura
11 foi ligeiramente simplificada, levando em considerao um servidor WEB com o ADACA
integrado aplicao, a central de gerncia e clientes, conforme mostra a Figura 14.
Figura 14. Ambiente estruturado para validao do agente
O servidor WEB e o IDS Central foram alocados em duas mquinas equipadas com
processador AMD Atlhon XP 3.0 GHz, 1 Gbyte de memria RAM e sistema operacional
Fedora Core 4. Para os clientes foram utilizadas estaes com diversas configuraes, visto
que a simulao de requisies HTTP no demanda alto processamento.
5.6 Testes
A etapa de testes teve como principal objetivo realizar o estudo de viabilidade do ADACA e,
consequentemente, medir o tempo gasto por ele para verificar, em cada uma das mensagens, a
52
presena de dados maliciosos ou respostas no-autorizadas. Alguns testes foram definidos
para avaliar as funcionalidades do agente, conforme as etapas de operao descritas na seo
4.11.
Portanto, tambm se fez necessrio avaliar as caractersticas dos dois modos de
operao do agente, sendo considerada trs situaes:
Aplicao WEB sem agente;
Aplicao WEB e ADACA operando no modo passivo;
Aplicao WEB e ADACA operando no modo ativo.
Para cada situao, foram disparadas requisies normais e maliciosas com objetivo de
diversificar o tipo de trfego e explorar as funcionalidades implementadas pelo agente.
Portanto, foi possvel observar cada uma das etapas do processo de classificao, anlise e
tomada de deciso do agente.
Tambm, foram enviados eventos de controle contendo mensagens para insero e
programao de medidas, a partir do IDS Central ao ADACA, com o intuito de observar a
efetividade desta funcionalidade.
Os resultados dos testes apresentados nesta seo sero discutidos no prximo
captulo.
53
Captulo 6. Anlise de resultados
Neste captulo sero apresentados os resultados obtidos com a utilizao do ADACA para as
situaes consideradas no captulo anterior.
Como primeiro ponto relevante da anlise, deve ser observado que o prottipo
desenvolvido do agente ADACA operou de forma satisfatria, conforme a proposta inserida
no captulo Captulo 4. A partir deste resultado inicial que se pde dar continuidade dos
testes descritos na seo anterior.
Foi, ento, realizada a medio do tempo gasto pelo Apache sem acoplamento do
agente para executar a funo ap_process_request( ), a qual realiza o processamento da
requisio no Apache. Em seguida, foram colhidos os resultados computando a sobrecarga
adicionada com a insero do ADACA nos modos passivo e ativo.
A medida do tempo foi realizada por meio da funo getsystemtime( ), nativa da
linguagem C. Para as medies com o ADACA em operao, esta funo foi posicionada
antes da chamada funo Analisa_dados() da API ADACA e logo aps a funo
ap_process_request( ) do Apache. No caso das medies sobre a aplicao original, a
funo para obteno do tempo foi posicionada antes e depois da funo
ap_process_request(). Este ponto foi escolhido, pois reflete somente a sobrecarga
introduzida com a utilizao do ADACA.
Por meio de uma amostra de cem requisies a uma mesma URL, a mdia ponderada
do tempo de processamento de cada requisio obtida para o Apache original foi de 101 (
31) microssegundos. Com base na mesma amostragem, o valor mdio obtido para o Apache
com o ADACA no modo ativo foi de 270 (94) microssegundos. No foram observados
54
atrasos significativos no processamento de uma mensagem individual com o agente operando
no modo passivo. Portanto, observa-se que a utilizao do ADACA no modo ativo introduz
um aumento da latncia de resposta de aproximadamente duas vezes quando comparado
aplicao original e ao modo passivo.
A anlise dos resultados obtidos permite concluir que a insero do ADACA no
servidor WEB Apache no acarretou perdas considerveis de tempo, visto que a latncia
adicionada por requisio da ordem de microssegundos.
6.1 Limitaes da implementao
Durante a fase de implementao, foi considerada a utilizao da proposta IDREF,
introduzida por Silva (2004). Esta proposta possibilitaria enviar mensagens de controle ao
ADACA a partir do IDS Central, com base no mesmo modelo das mensagens IDMEF. Porm,
a biblioteca disponibilizada pelo autor foi construda na linguagem Java e a integrao com a
linguagem C demandaria muito tempo devido s dificuldades de integrao dessas duas
linguagens.
Outro fator limitante desta implementao que o prottipo desenvolvido no
reentrante, impossibilitando realizar anlises de mensagens em paralelo.

55
Captulo 7. Concluso
Este trabalho apresentou a arquitetura de deteco usualmente utilizada pelos sistemas IDS e
IPS e a proposta de uma arquitetura de agente de aplicao que fosse capaz de analisar
mensagens de requisies e respostas. Como principal motivador do trabalho, pode-se
destacar a atual incapacidade dos agentes tradicionais de realizar anlise de fluxos de
mensagem que focam uso de protocolos de comunicao seguros, como, por exemplo, SSL e
TLS.
O agente ADACA, da forma como foi proposto, pode ser posicionado nas
extremidades do canal cifrado ou, ento, utilizado em conjunto com o mdulo de
decodificao de mensagens que compartilham a chave privada.
Os resultados preliminares obtidos mostraram a capacidade de prevenir o
processamento de requisies maliciosas e o envio de contedo no-autorizado na resposta.
Alm disso, foi possvel instanciar as medidas de conteno e preveno por meio do mdulo
medidas e execut-las com o mdulo acionador. No caso de execuo de uma medida de
conteno (agente no modo passivo), notou-se que, para uma pgina contendo imagens, o
carregamento no se deu por completo, pois a medida surtiu efeito antes mesmo que as
requisies para aquisio das imagens fossem processadas.
Com relao ao desempenho, este trabalho apresentou o impacto da sobrecarga do
processamento realizado pelo agente nos diferentes modos de operao. Esta sobrecarga
decorrente, principalmente, das anlises realizadas pelo IDS local, o qual dependente de
cada aplicao e das tcnicas de anlise de pacotes por ele utilizada.

56
A principal desvantagem observada com a arquitetura proposta a necessidade de
modificar a aplicao para integrao da API ADACA, tornando necessrio realizar um
estudo das APIs contidas na aplicao para tal.
A anlise dos resultados obtidos com a medio do tempo despendido para anlise,
classificao e tomada de deciso por parte do ADACA permitiu concluir que a presente
proposta bastante aceitvel, visto que a latncia adicional inserida em cada mensagem da
ordem de microssegundos quando utilizado o modo ativo e no considervel para o modo
passivo.
Finalizando, pode-se citar como contribuies importantes do trabalho a proposta de
uniformizao da taxonomia de classificao de agentes de deteco e a definio de um
modelo de agente de aplicao e seus principais componentes, que pode ser utilizado como
referncia para trabalhos futuros da rea de deteco de intrusos.
7.1 Trabalhos futuros
Algumas propostas surgiram no decorrer deste projeto, as quais so agora apresentadas como
possveis caminhos para continuidade do desenvolvimento do ADACA e da arquitetura de
deteco.
No trabalho apresentado, o classificador tem uma funo bastante simples, porm
fundamental, a qual poderia ser incrementada por meio da implementao de uma mquina de
estados que possibilitaria definir novas funcionalidades para este mdulo, como a anlise das
mensagens trocadas com um mesmo parceiro.

57
As funes definidas para a API Aciona apenas abragem um conjunto mnimo de
funes. Portanto, necessrio realizar melhorias nesta API de forma a torn-la genrica, com
um conjunto de funes mais completo para as atividades de preveno e conteno.
A formatao das mensagens de controle utilizando a proposta IDREF e a
implementao do protocolo de comunicao IDXP so dois pontos importantes para a
padronizao e interoperabilidade entre sistemas de deteco de intrusos. Para tal, deve-se
criar uma interface de integrao entre as linguagens Java e C ou ainda realizar a interpretao
do cdigo fonte das bibliotecas disponveis em Java com a finalidade de reproduzir o mesmo
feito na linguagem C.
58
Referncias
ABBES, T; BOUHOULA, A; RUSINOWITCH, M. Protocol Analysis in Intrusion Detection

Using Decision Tree. IEEE International Conference on Information Technology: Coding and
Computing, v. 1, p. 404-408, 2004.
BACE, R.; MELL, P. Intrusion Detection Systems. NIST - National Institute of Standards and
Technology, Special Publication, 2001.Disponvel em:
<http://csrc.nist.gov/publications/nistpubs/800-31/sp800-31.pdf>
BURKHOLDER, P. SSL Man-in-the-Middle Attacks. SANS Reading Room, 2002.

Disponvel em:<http://www.sans.org/rr/whitepapers/threats/480.php>
BREACH. BreachView SSL White Paper. 2005 Disponvel em:

<http://www.breach.com/downloads/product/BreachView_SSL_White_Paper.pdf>.
BRUMLEY, D.; BONEH, D. Remote Timing Attacks are Practical. 12th USENIX Security
Symposium, 2003.
BUCHHEIM, T.; ERLINGER, M.; FEINSTEIN, B.; MATTHEWS, G.; POLLOCK, R.;
BETSER, J.; WALTHER, A. Implementing the Intrusion Detection Exchange protocol.
Computer Security Applications Conference. Proceedings 17th Annual, p. 32-41, Dezembro,
2001.
CERT.br - Centro de Estudos, Resposta e Tratamento de Incidentes de Segurana no Brasil.

Estatsticas do CERT.br. Disponvel em: <http://www.cert.br/stats/incidentes/>. Acesso em:
11 Jan. 2006.
DASGUPTA, D.; GONZALEZ, F.; YALLAPU, K.; GMEZ, J.; YARRAMSETTII, R.;
DUNLAP, G.; GREVEAS, M. CIDS: An Agent-based Intrusion Detection System.
Computers & Security Journal, v. 24, issue 5, p. 387-398, Agosto, 2005
DEBAR, H.; CURRY, D.; FEINSTEIN, B. The Intrusion Detection Message Exchange
Format. Internet Draft, IETF, Janeiro 2005. <http://www.ietf.org/internet-drafts/draft-ietf-
idwg-idmef-xml-14.txt>.
ENDORF, C., SCHULTZ, E., MELLANDER, J. Intrusion Detection & Prevention. Ed.
McGraw-Hill. 2004.
FEINSTEIN, B.; MATTHEWS, G.; WHITE, J. The Intrusion Detection Exchange Protocol
(IDXP). Internet Draft, IETF, Outubro, 2002. Disponvel em: <http://www.ietf.org/internet-
drafts/draft-ietf-idwg-beep-idxp-07.txt>.
GUPTA, D.; BUCHHEIM, T.; FEINSTEIN, B.; MATTHEWS, G.; POLLOCK, T. IAP:
Intrusion Alert Protocol. Internet Draft, IETF, Fevereiro, 2001. Disponvel em:
<http://www.ietf.org/internet-drafts/draft-ietf-idwg-iap-05.txt>.
59
JOGLEKAR, S. P.; TATE, S. R. ProtoMon: Embedded Monitors for Cryptographic Protocol

Intrusion Detection and Prevention. IEEE International Conference on Information
Technology: Coding and Computing, v. 1, p. 81-88, Abril, 2004.
KAHN, C.; PORRAS, P. A.; STANIFORD-CHEN, S.; TUNG, B., A Common Intrusion
Detection Framework. Journal of Computer Security, Julho, 1998.
KELSEY, J; SCHEINER, B.; WAGNER, D.; HALL, C. Side Channel Cryptanalysis of

Product Ciphers. Journal of Computer Security, v. 8, n. 2-3, p. 141-158, 2000.
KNOBB, F. SnortSam, 2006. Disponvel em: <http://www.snortsam.net>.
KOCHER, P. C. Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS and Other

Systems. Proceedings of the 16th Annual International Cryptology Conference on Advances
in Cryptology, p. 104-113, 1996.
LECKIE, T.; YASINSAC, A. Metadata for Anomaly Based Security Protocol Attack
Detection. IEEE Transactions on Knowledge and Data Engineering, Volume 16, Number 10,
Outubro, 2004.
MCAFEE. Encrypted Threat Protection: Network IPS for SSL Encrypted Traffic. 2005.
Disponvel
em:<http://www.mcafee.com/us/local_content/white_papers/wp_encr_th_prot.pdf>
MICROSOFT. Microsoft Security Bulletin (MS00-078): Patch Available for 'Web Server
Folder Traversal' Vulnerability. Outubro, 2000. Disponvel em:
<http://www.microsoft.com/technet/security/bulletin/MS00-078.mspx>.
NEW, D.; ROSE, M. Reliable Delivery for Syslog. RFC3195. Novembro, 2001.
NETCRAFT. Web Server Survey Archives. Fevereiro, 2006. Disponvel em: <
http://news.netcraft.com/archives/web_server_survey.html>
NIST. Acquiring and Deploying Intrusion Detection Systems. ITL Computer Security
Bulletins. NIST. Novembro, 1999.
NOVELL. Novell AppArmor Powered by Immunix Administration Guide. Novell (Suse),

Outubro, 2005.
PALLER, A. New reports finds significant shifts in software being targeted by attackers.
SANS TOP 20 MOST CRITICAL INTERNET VULNERABILITIES REPORT. Novembro,
2005.
PLAGGEMEIER, M.; TLLE, J. Secure Shell Proxy Intrusion Detection, Proc. of R.T.O.
Information Systems Technology Panel Symposium on Real Time Intrusion Detection, Maio,
2002.
PTACEK, T. H., NEWSHAW, T. N. Insertion, Evasion, and Denial of Service: Eluding

Network Intrusion Detection. Relatrio tcnico, Secure Networks, Inc. Janeiro, 1998.
60
POPPI, S. Snort IDMEF Plugin. 2005. Disponvel em: <http://sourceforge.net/projects/snort-

idmef/>. Acesso ao site: junho 2005.
POPPI, S.; MIGUS, A.; MCALERNEY, J. LibIDMEF. Disponvel em:

<http://sourceforge.net/projects/libidmef/>. Acesso ao site: junho de 2005.
POSEY, B. M. Choosing an intrusion detection system: Network, host or application-based

IDS. Searchwindowssecurity.com, 28 Abril 2005. Disponvel em:
<http://searchwindowssecurity.techtarget.com/tip/1,289483,sid45_gci1083969,00.html>
ROESCH, M. Snort - the de facto standard for intrusion detection/prevention. Verso 2.4.
Disponvel em: <http://www.snort.org>. Acesso em: 20 junho 2005.
ROSE, M. The Blocks Extensible Exchange Protocol Core. RFC3080, IETF, Maro, 2001.
SANDHU, R. S. Lattice-based access control models. IEEE Computer, Estados Unidos, v. 26,
n. 11, p. 9-19, 1993.
SEKAR, R.;GUPTA, A.; FRULLO, J.; SHANBHAG, T.; TIWARI, A.; YANG, H.; ZHOU, S.
Specification-based Anomaly Detection: A New Approach for Detecting Network Intrusions.
Proceedings of the 9th ACM Conference on Computer and Communications Security, p. 265-
274, 2002.
SILVA, P. F. Extenso do modelo IDWG para deteco de intruso em ambientes

computacionais. Dissertao de mestrado, 2004.
SPI DYNAMICS, Inc. SQL Injection Are Your Web Applications Vulnerable? 2002.
Disponvel em: <http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf>
STANIFORD-CHEN, S.; TUNG, B.; SCHNACKENBERG, D., The Common Intrusion

Detection Framework (CIDF). Information Survivability Workshop, Outubro, 1998.
STEVENS, A. Guardian Active Response for Snort, 2004. Disponvel em:

<http://www.chaotic.org/guardian/index.html>.
US-CERT: United States Computer Emergency Readiness Team. Microsoft Windows domain
controller denial of service in Kerberos message handling. Disponvel em:
<http://www.kb.cert.org/vuls/id/610133>. Acesso ao site: 16 Ago. 2005.
______. Microsoft Windows Remote Desktop Protocol service input validation vulnerability.
Disponvel em:<http://www.kb.cert.org/vuls/id/490628>. Acesso ao site: 16 Ago. 2005.
WANG, Y.; ABDEL-WAHAB, H. A correlative context-based framework for network

intrusion detection system. 10th IEEE Symposium on Computers and Communications
(ISCC), p. 463-468, 2005.
WOOD, M.; ERLINGER, M. Intrusion Detection Message Exchange Requirements. Internet

Draft, IETF, Outubro 2002. Disponvel em: <http://www.ietf.org/internet-drafts/draft-ietf-
idwg-requirements-10>.
61
WU, Y.; FOO, B.; MEI, Y.; BAGCHI, S. Collaborative intrusion detection system (CIDS): a
framework for accurate and efficient IDS. 19th Annual Proceedings on Computer Security
Applications Conference, December, 2003.
YANG, Y.; CHANG, J.; CHU, Y. The Security Components Exchange Protocol (SXCP).
Internet Draft, Dezembro, 2003.
YASINSAC, A. An Environment for Security Protocol Intrusion Detection. Journal of

Computer Security, v. 10, p. 177-188, 2002.
XU, D.; NING, P. Alert correlation through triggering events and common resources. 20th
Annual Computer Security Applications Conference, p. 360-369, Dezembro, 2004.
ZHANG, X.; LI, C.; ZHENG, W. Intrusion Prevention System Design. 4th International
Conference on Computer and Information Technology, p. 386-390, Setembro 2004
ZUCHLINSKI, G. The anatomy of Cross Site Scripting Anatomy, Discovery, Attack,

Exploitation. Novembro, 2003. Disponvel em: <http://www.net-
security.org/dl/articles/xss_anatomy.pdf>

Agente de Aplicacao para IDS PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Agente de Aplicacao para IDS PDF

Cargado por

Copyright:

Formatos disponibles

LEONARDO CAVALLARI MILITELLI

Proposta de um agente de aplicao para deteco,

Dissertao de Mestrado apresentada

Proposta de um agente de aplicao para deteco,

Dissertao de Mestrado apresentada

Orientador: Prof. Dr. Joo Antnio

Militelli, Leonardo Cavallari

Dissertao (Mestrado) - Escola Politcnica da Universidade

1.Segurana de redes 2.Segurana de computadores 3.Vrus

carinho, apoio e incentivo ao longo dos anos.

Bernal pela oportunidade, orientao direcionada e por toda ajuda oferecida.

junto ao longo do desenvolvimento do trabalho e contribuiram com uma parcela imensurvel

para a concretizao deste, mesmo sem terem tanta noo disto.

trajetria desde a graduao, com os quais pretendo enfrentar novos desafios.

discusses tcnicas, cooperao e colaborao no trabalho.

Como alternativa de contorno deste problema proposta a arquitetura de um agente de

Alm disso, o padro de formato de mensagens de alertas IDMEF (Intrusion Detection

Os resultados obtidos mostraram a viabilidade da utilizao de agentes de aplicao,

As an alternative to circumvent this problem, the present work proposes an agent-based

Lista de Figuras .......................................................................................................................vi

4.8 Mdulo Medidas....................................................................................................... 40

Figura 1. Estatstica sobre a quantidade total de incidentes reportados ao CERT.br ................. 7

Tabela 1. Diferena entre os modos de operao de agentes.................................................... 11

API Application Program Interface

XML Extensible Markup Language

1.1 A problemtica da deteco de intrusos

deteco de intruso de forma a tornar vivel a identificao de atividades maliciosas com

eficcia, procurando reduzir a quantidade de falso-positivos e falso-negativos. Porm, neste

Uma dessas vertentes trata da identificao de ataques quando o alvo destes um

servio ou aplicao que utiliza mecanismos de criptografia na comunicao. Tais

mecanismos so utilizados com o intuito de garantir a confidencialidade dos dados e

dispositivos de segurana existentes no ambiente, como sistema de deteco de intrusos e

firewall com funcionalidade de inspeo de contedo.

vulnerabilidade de um servio ou aplicao WEB.

decodificao de requisies, era possvel executar comandos do sistema operacional e

acessar o contedo das unidades lgicas, conforme reportado em (MICROSOFT, 2000).

seguro de comunicao impossibilitavam a anlise dos pacotes.

para decifrar toda a comunicao realizada entre o cliente e servidor. Posteriormente, a

empresa Breach, partindo do mesmo princpio.

Estas duas solues, apesar de viabilizar a deteco de intrusos para situaes de

infringir a poltica de segurana adotada.

foram propostas visando detectar ataques em canais cifrados na camada de transporte e na

camada de aplicao da pilha TCP/IP, sem haver necessidade do conhecimento da chave

protocolos de segurana, baseiam-se na deteco de anomalias por perfis de trfego. Com

conforme (YASINSAC, 2002) e (LECKIE; YASINSAC, 2004).

Uma alternativa para os ataques direcionados camada de aplicao apresentada por

um monitor junto a uma aplicao especfica, como um servidor SMTP, ou at mesmo ao

mdulo de criptografia de um servidor WEB. Esse monitor observa as mensagens de controle

ataques baseado no comportamento anmalo do protocolo que monitorado, possibilitando,

estudos propostos primeiramente em (SEKAR et al., 2002) e (YASINSAC, 2002) e acrescem

a funcionalidade de reduo da efetividade dos ataques em nvel de aplicao por meio da

insero de intervalos entre o processamento das requisies entrantes. A conteno de

utilizada, conforme apresentado em (MEYLAN, 2004), onde tcnicas de qualidade de servio

(QoS Quality of Service) so empregadas para diminuir a quantidade de banda disponvel ao

endereo IP ofensivo, principalmente para ataques de DoS (Denial of Service).

PLAGGEMEIER e TLLE (2002) apresentaram o sistema de deteco de intrusos por

System), no qual todas as conexes provenientes de um cliente SSH so intermediadas por um

proxy transparente capaz de extrair a informao do pacote cifrado, analisar e validar a

existncia de contedo malicioso e, na seqncia, repassar as requisies ao servio. A tcnica

adotada parte do princpio do ataque de Man-in-the-middle (BURKHOLDER, 2002), o qual

possibilita a interceptao e manipulao de pacotes criptografados por meio da interceptao

Este trabalho apresenta a proposta de uma arquitetura de deteco, preveno e conteno de

ataques baseada em agente de aplicao. O agente de aplicao acoplado a uma aplicao