-----------[ Um proposta para um SO para Boxes IDS ]-----------

----[Por Antonio Marcelo - amarcelo@plebe.com.br

-----[ Introduo
A maioria dos programas de IDS hoje existentes no mercado, necessitam de um sistema operacional para a
sua execuo. Na maior parte dos casos, os mesmos so basicamente ambientes Unixes modificados
execuntando um IDS baseando em tcnicas de sniffer, ou escuta de portas. Estes sistemas funcionam hoje
como solues bsicas par este tipo de necessidade, mas podem ser vtimas de algumas armadilhas como
bufferoverflows, falsos alarmes em ataques, etc.
Como no esite um SO especfico para os sistemas de IDS, sendo que a maioria das tcnicas so baseadas em
ferramentas existentes, na maioria dos casos o administrador tem que intervir para visualizar problemas e
corrigir falhas do prprio software, devido a anomalias que causariam falsos alarmes, gerando reaes
desncessrias.
O foco destes artigo mostrar um caminho inicial para o leigo e o caminho que o autor hoje est trilhando, a
partir deste enfoque depois de diversos sitemas de IDS implementados em vrios locais. A concluso que
chegamos foi que o desenvolvimento para um SO para sistemas IDS, seria uma soluo, bastante vivel e
acima de tudo desejvel, j que com isto poderamos criar um sistema altamente especializado e voltado
exclusivamente para esta atividade.
-----[ Arquitetura do Sitema.
Arquitetura Fsica do Sistema :
Fisicamente nosso sistema seria configurado da seguinte maneira :
INTERNET ----- SO IDS ----- REDE INTERNA
Nosso SO IDS seguiria os padres clssicos de interligao entre a Internet e a nossa rede interna, como meio
inicial de passagem de pacotes.
Arquitetura Interne de Nosso SO :
Existem dezenas de conceitos do que um sistema operacional, uma das minhas preferidas que um SO
uma cama de software que cuida dos aspectos tcnicos da operao de um computador. O mais importante
elemento de um SO o seu Kernel, ou seja, utilizando uma analogia um piuco grosseira, seria o motor do
sistema.
Um Kernel pode adiquirir novos recursos, mediante o desenvolvimento do mesmo, como por exemplo um
suporte a um dispositivo qualquer de hardware, como uma placa de som, ou de rede. Basta algum escrever
um mdulo que suporte estes dipositivos, e o kernel poder carreg-lo, ou compile-o dentro do prprio
Kernel, transformando-o numa rotina propria do mesmo. Os SO de hoje so extremamente versteis e
poderosos, j que foram desenvolvidos a um ponto que permitem diversos recursos para que o usurio possa
utilizar uma gama de dipsositivos para os mais diversos fins d eatividades.
A utilizao de um SO j existente para o nosso sistema de IDS, esbarraria com alguns problemas, advindos
da prpria utilizao do sistema, para outros fins, gerando esgotamento de recursos desnecessrios dentro de
sua estrutura. Partimos od princpio que o nosso sistema seria extremamente enxuto, baseado em um padro
BSD e com a seguinte arquitetura :
Modulo Bayesiano
Modulo de Rede/IDS
Binrios/Bibliotecas Bsicas
----------
| Kernel |
----------
Explicaremos detalhadamente cada um dos componentes de nosso sistema :
a) Kernel A proposta para o nosso Kernel, seria extremamente radical, j que o mesmo teria uma srie de
implementaes consideradas bsicas para alguns problemas de segurana. Inicialmente todo o
tratamento de Heap, Stack , BufferIberflows e Format Strings deveriam j estar contidos dentro do
mesmo. Sabemos que a maioria dos problemas de invases bem sucedidas a servidores, so feitas atravs
destas tcnicas, ou atravs de format strings. Muitos dos casos observados in loco, foram analisados e a
concluso que isto um dos principais problemas neste sentido.
O kernel deve estar preparado para um tratamento matemtico bastante apurado. O porque disto devido
a outros mdulos do sistema que iro necessitar de clculos para rotinas de IA e de avaliao de
anomalias. (Mdulo Bayesiano)
O kernel ainda dever contar com um tratamento de filtro de pacotes, para a implementao de um
firewall com possibilidades de NAT, alterao de TOS e log de vrias anomalias de pacotes que chegam
ao sistema.
b) Bnrios/Bibliotecas Bsicas Nosso sistema dever contar com um conjunto de bibliotecas bsicas e
alguns utilitrios considerados essenciais. Um dos pontos mais importantes de nossa arquitetura seria a
disponibilizao de bibliotecas de tratamento matemtico e de IA para algumas opes do sistema.
c) Mdulo de Rede Este talvez seja um dos elementos bsicos para o sucesso de nosso sistema. O mdulo
de rede alm de congregar toda a Stack TCP/IP, ter rotinas de listening/sniffing de pacotes. Apesar de
que muitos pacotes de IDS atualmente possurem esta capacidade, a nossa idia que estas opes j
sejam caractersticas do prprio sistema. Ou seja, possibilitar que o sistema j possa fazer como uma
funo prpria. O mdulo IDS de rede j estaria integrado com o Kernel e o Mdulo Bayesiano,
passando informaes e recolhendo concluses e de uma maneria ativa, e reagir conforme a necessidade
junto com o Kernel. (um bloqueio de endereo, um bloqueio de porta, desligamento d eum servio, etc.)
d) Mdulo Bayesiano Este mdulo o crebro de nosso sistema. Reverendo Thomas Bayes desenvolveu
um teorema matemtico para predizer se uma determinada situao poderia ser verdadeira ou no. Basea-
va-se que certas concluses poderiam ser tomadas mediante algumas evidncias existentes. (Por exemplo
se uma parcela de uma populao poderia Ter no cancr mediante a dados sobre determinadas
evidncias advindas da mesma. Um excelente exemplo para o caso dos sistemas de IDS o paper de
Stefan Axelsson, tratando sobre o assunto, publicado na Raid 99, intitulado : The Base-Rate Fallacy and
its Implications for The Difficulty of Intrusion Detection.
A idia de um mdulo Bayesiano em nosso sistema faria as seguinte atividades :
- Conter uma biblioteca de assinaturas de ataques/pacotes comuns, disponveis para o sistema de IDS,
poder descartar se os mesmos j so ataques conhecidos;
- Em caso de pacotes anmalos, iniciar um sistema de anlise baseado no sistema de Bayes e atravs
de um sistema de IA, bloquear este pacote e a partir da, gerar uma nova assinatura e alimentar a base
do IDS. O pacote seria submetido a um sistema de quarentena, onde, antes da anlise liberada, o
sistema bloquearia sua origem temporariamente. Em caso de no concluso, bloqueio definitivo dos
mesmos;
- Medidas reativas tomadas juntos com o Kernel e o Mdulo de Rede, para bloqueio de pacotes,
endereos, desligamento de servios, etc. Em casos extremos desativar sistemas remotos, atravs de
sondas bayesianas instaladas em servidores na rede da qual esteja defendendo;
- Sistema de log criptografado, para que o atacante em nenhum momento possa modificar num caso
remoto de uma invaso.
- Falsificao de pacotes de resposta para o atacante, enviando respostas a tentativas de fingerprinting
e em certos casos mais extermos contra-ataques.
A idia que os bancos de assinatura sejam uma maneira mais rpida de de analisar e descartar pacotes,
deixando que em caso de anomalias, o sistema tenha uma maneira de isolar inicialmente e analisar com
mais calma, no tentando em tempo real, de uma maneira mais custosa verificar aquele pacote. A
anomalia de um pacote pode no ser um ataque, mas no uma coisa comum que dever ser
encaminhada a um destino dentro de uma rede.
--------[ Nosso Primeiro experimento
Para chegarmos ao princpio teorico de nosso SO, implementamos de maneira experimental e muito singela
um box que o que nos levou a iniciar o desenvolvimento de uma proposta mais sria. Montamos uma box
com as seguintes caractersticas :
Hardware :
1 Pentium 933 Mhz com 256 Mbytes de RAM
HD de 20 Gigabytes
2 placas de rede encore Realtek de 10/100 Mbits
Unidade de CD
Drive 3.1/2
Teclado
a) Um kernel linux 2.4.18, compilado com o patch da GR-Security (www.grsecurity.net) para tratamento de
overflows em geral, com suporte a flie system ext3 suporte built-in as placas de rede, suporte a iptables.
O Sistema fazia um mascaramento entre o roteador e o firewall, como uma DMZ.
Router --------eth0-eth1---------Firewall
b) Snort com uma biblioteca de regras padro para os principais ataques.
c) TCPDUMP gerando logs de pacotes
d) Um pequeno fake server na porta 22 simulando um servio de SSH bugado.
Deixamos este sistema no ar por cerca de 5 dias numa empresa com um link 1Mbit ligadi a Internet, e para
nossa supresa, detectamos os seguintes resultados interessantes :
a) 25 execues de scanning em servios vulnerveis;
b) 62 execues de scanning em backdoors clssicos (Bo, Netbus, Wincrash, etc.);
c) 3 tentativas de bufferiverflows no Fake Server SSH;
d) 4 pacotes desconhecidos.
Estes 4 pacotes que foram alvo de nossa anlise e descobrimos que um dos pacotes era uma estao da rede
interna que tentava atualizar-se com o site do antivrus do fabricante. Este logo foi descartado, mas os trs
restantanes eram e so ainda estranhos. Os trs seguintes tentavam contato a um range de portas do endereo
17000 ao 17009 TCP durante um perodo de 2 horas do terceiro dia. Levantamos o trfego e todos os servios
da rede em quest0 e no localizamos nada em nenhum dos servidores sendo executados nestas portas. Esta
assinatura foi ento criada e colocada no Snort, e at o final de nosso estudo, os pacotes no apareceram mais.
Estes 4 pacotes num universo de quase 100 tentativas de ataques/scanning, nos chamou a ateno para que
num universo bem amplo, podemos dizer que em universo de 100%, cerca de 3% poderiam ser ataques e
passveis de anlise mais profunda.
Se esta taxa for trazida para um sistema com maior porte e com uma amostragem de tempo maior, podemos
afirmar que em determinadas condies, o mdulo bayesaino de nosso sistema, ter uma baixo nvel de
anlise.
------ [ Problemas a serem discutidos
Durante nosso estudo foram apresentados alguns priblemas passveis de serem considerados :
a) Se o sistema for submetido a um nmero grande de pacotes anomalos, provocados por atacantes que
desejam provocar um overhead no sistema de anlise no modo Bayesiano e travar o IDS Esta sotuao
alvo de muitas anlises, e a proposta foi a criao de um sistema estanque, uma espcie de vlvula de
escape, onde os pacotes poderiam ser desviados para uma terceira rota, sob a forma de um placa de rede
apontando para um link rpido, uma espcie de bueiro. Esta tcnica seria similar a utilizada a sistemas de
defesa contra ataques DoS.
b) Um sistema que seja muito visado por invasores, o nvel de ataques poderia ser maior, que a amostragem
feita Esta situao foi discutida e neste caso o sistema j teria uma imensa biblioteca de assinaturas e
claro poderia cair na soluo do problema acima.
a) No ato de um exploit tornar-se pblico, sempre ococrre uma avalanche de ataques a sistemas que utilizam
este servio Esta situao temporria, e se a assinatura do ataque j estiver disponvel basta alimentar
a base.
Gostaria muito de discutir com outros administradores outros problemas para que pudesse auxiliar o incio de
minha pesquisa inicial. Acho os tpicos acima poderiam ser mais aprofundados e melhor visualizados.
-------- [ Concluses
A concluso deste trabalho que a minha proposta seja baseada em um sistema mais racional de anlise de
pacotes. Como a maioria dos sistemas est preocupado em analisar em tempo real o ataque,a minha idia
que o sistema isole temporariamente a fonte do ataque e analise com mais detalhe o que vem ser o mesmo :
um problema sem importncia ou um ataque real. Acho que importante o trabalho do tempo real em
grandes sistemas, mas a idia deste me SO para boxes IDS, uma espcie de barreira inicial, para um sistema
hbrido, que congregasse estes dois tipos de sistema.
Gostaria muito que as pessoas que lessem este artigo me mandassem suas crticas e opinies que pudessem
contribuir para a linha do desenvilvimento de meu trabalho. Atualmente estou escrevendo o sistema e
comeando a desenvolver o algortmo do mdulo bayesiano. Agardeceria e muito ouvir de todos o que
pensam de minha idia e deste artigo.
Antonio Marcelo especialista em segurana e atualmente est se dedicando a completar sua faculdade e seu
mestrado. Trabalha como consultor independente e professor. autor de 6 livros sobre Linux, entre eles
Linux Ferramentas Anti hackers, publicado pela editora Brasport. Seu email de contato
amarcelo@plebe.com.br.
----[EOF