Ver Feed RSS

The JEdi lair's

HLBR - Sistema de Prevenção de Intrusão

Avalie este Post de Blog
No inicio, a Internet e as redes de computadores eram lugares harmoniosos, onde todos se respeitavam e viviam felizes.

Há muito, o descrito acima deixou de ocorrer. Onde muitos viram oportunidades e um canal de comunicação rápido e confiável (até então) e tentaram utilizá-la para facilitar suas vidas. Outros buscaram meios, técnicas e ferramentas para profanar a paz da rede. Não faltam relatos sobre ações maliciosas.

Haja vista, diversos esforços vem sendo feitos para assegurar algumas propriedades básicas da redes como autenticidade, confidencialidade, disponibilidade e integridade. Esses estão entre os pilares da segurança da informação.

Esse post vem a falar brevemente sobre sistemas de firewall e a apresentar a solução de prevenção de intrusão HLBR.

1 - Sistemas de Firewall

Segundo Eriberto Motta, sistemas de firewall são todo e qualquer esforço voltado a preservação da segurança de uma rede de computadores.

Portanto, se você colocar o Zé Faxineiro olhando um LED vermelho e avisá-lo que quando estiver acesso ele deve apertar o botão 666, que leva a impedir uma ação maliciosa em sua rede, ele faz parte de seu sistema de firewall... Esse é o exemplo mais didático que já escutei (acho que ouvi do Eriberto)... hehehe

Ou seja, sistemas de firewall são bem mais que um simples filtro de pacotes de camada de rede. Envolve sistemas de detecção e prevenção de intrusão, proxies, anti-.*, e outras soluções. A figura 1.0 mostra um diagrama de soluções aplicadas a cada camada do modelo TCP/IP.

http://under-linux.org/fotos/pedroar...cpsecurity.png
Figura 1.0: Soluções de segurança das camadas do modelo TCP/IP

O diagrama acima não pretende de forma alguma ser exaustivo, apenas para dar uma pequena idéia das soluções existentes.

Na camada mais inferior, a física, estão todos os esforços contra o acesso físico indevido e catastrofes eventuais. A lista poderia ser extendida com sistemas de nivelamento automático, que protejem contra choques físicos relacionados a terremotos e desmonoramentos, dentre outras soluções.

No enlace, os principais mecanismos são os filtros de frames de camada de enlace. No Linux, temos o ebtables. Semelhante ao Netfilter/iptables, ele é capaz de realizar filtragem a nível de enlace, podendo verificar campos como o MAC de origem/destino, interface física do pacote, inteface lógica (em caso de bridges), além das matchs extensions. Ainda nessa camada, temos mecanismos de autenticação a nível de enlace, tal qual o PPPoE.

Na terceira camada, os elementos que figuram disparados são os filtros de camada de rede, como o grandioso Netfiltet/iptables. Como ele podem ser analisados os mais diversos campos do cabeçalho IP. Alguns dos campos também podem ser modificados, tal como faz a target extension TTL.

O transporte, além de garantir entrega de pacotes confiável e multiplexação, também muni os dispositivos de segurança com mais alguns dados valiosos. Com tais dados, filtros de pacotes como Netfilter/iptables permitem ainda mais precisão na tomada de decisão.

Atualmente muito é pesquisado na área de inteligência computacional na tentativa do desenvilvimento de um sistema auto-adaptativos baseado na correlação da informação presentes em cabeçalhos (da 1ª, 2ª e 3ª camada). O simpósio de segurança da informação e de sistemas computacionais, SBSEG, em sua edição de 2008, teve diversas apresentações sobre tal assunto. Confiram SBSeg'08 - About SBSeg´08 , tem alguns PDFs.

Na quinta e ultima camada do modelo TCP/IP temos os proxy de aplicações, os anti-malwares, além dos sistemas de detecção e prevenção de intrusão, como o Snort e o HLBR. Essa camada tange os protocolos de aplicação, tipo o FTP e SSH, e tem seus próprios (e numerosos) desafios. A exemplo, como tratar do fluxo de protocolos stateless, tal o HTTP? Quais mecanismos usar para garantir que não se tenha evasões e falsos positivos/negativos? Codificação? E por ai vai...

Uma observação válida e pertinente é que a maioria dos sistemas de segurança se utilizam de mais de uma camada do modelo para suas análises. O Snort e o HLBR, a exemplo, realizam verificações de payload somente após verificação da origem e destino. O Netfilter/iptables possui funcionalidades padrão e agregadas que vão desdo o enlace (módulo mac) até a camada de aplicação (módulo ipp2p, layer7).

2 - Sistemas de detecção intrusão

Sistemas de detecção de intrusão (Intrusion Detection System) analisam o tráfego de rede e relacionam informação presentes nos diversos cabeçalhos com os dados da camada de aplicação e geram alertas, caso exista a possibilidade de um ataque. A topologia física tradicional para a implantação de tais sistemas está representada na figura 2.0.

http://under-linux.org/fotos/pedroar...e-intrusao.png
Figura 2.0 Topologia física tradicional dos sistemas de detecção de intrusão

Vejam que os IDSs se encontram em paralelo a rede. A implicação direta disso é que tais sistemas não recebem pacotes diretamente. Esses são cópias dos pacotes originais, como ilustrado na figura 2.0.

Devido a topologia acima, IDS tem o previlégio de realizar computações mais "pesadas" devido a atrasos gerados pelo processamento dos pacotes não acarretarem em atrasos na rede em questão.

Desses sistemas, o mais notável deles é o IDS open source Snort, desenvolvido pela Source Fire. Estando equipado com diversos preprocessadores, o Snort é capaz de de alterar seu comportamento em tarefas como defragmentar pacotes IP e pacotes TCP adulterados, assumindo o mesmo perfil que os sistemas finais.Para informações adicionais sobre o Snort e detecção de intrusão, recomendo visitas ao site oficial Snort - the de facto standard for intrusion detection/prevention e visitas ao site da comunidade brasileira Comunidade Snort Brasil.

3 - Sistemas de prevenção de intrusão

Sistemas de prevenção de intrusão (Intrusion Prevention System) analisam o tráfego da rede relacionam informações presentes nos diversos cabeçalhos com os dados da camada de aplicação e tomam decisões acerca desses, podendo derrubar a conexão, derrubar somento o pacote ou gerar um alerta, como fazem os IDSs. A topologia física tradicional para a implantação de tais sistemas se encontra ilustrado na figura 3.0.

http://under-linux.org/fotos/pedroar...e-intrusao.png
Figura 3.0: topologia física tradicional dos sistemas de prevenção de intrusão


A topologia representada acima é denominada in-line. Ou seja, o IPS está em linha com a rede. Portanto, o mesmo pacote recebido pelo IPS é recebido pelo sistema final.

O IPS necessitam de tomar suas decisões o mais rápido possível. Caso a computação dos pacotes leve tempo demasiado, os clientes podem sentir essa diferença ou até mesmo o IPS pode tornar-se um gargalo na rede.

De fundamental importância é a convivência dos IDS e dos IPS. Como já citado, existe uma diferença conceitual entre os dois no tempo computacional disponível. Os IDSs podem levar um intervalo de tempo arbitrário para chegar a uma conclusão acerca do tráfego. Já os IPSs, devem tormar a decisão o mais rápido possível. Haja vista as afirmação anterioires, devemos sempre ter os sistemas presentes em nossa rede: IDS minuciosos e IPS velozes.

Aqui o Snort também dispara em popularidade, apesar de não ser o mais rápido dos sistemas. Seu modo de operação in-line permite que o mesmo trabalhe como ponte entre segmentos de rede e utilize sua vasta base de dados para realizar as decisões.

Nessa categoria, também se enquadra o HLBR, o qual falaremos mais um pouco na próxima sessão!

3 - HLBR

O HLBR é um sistema de prevenção de intrusão livre, desenvolvido principalmente por brasileiros. Ele é baseado no Hogwash, criado por Jason Larsen e descontinuado em 2003. Após diversas tentativas de se juntar a equipe do Hogwash, os líderes do projeto HLBR resolveram criar o fork.

Diferentemente do Snort, que recebe seu pacotes através da target QUEUE do Netfilter/iptables, o HLBR os recebe diretamente da camada de enlace. Apesar de dificultar o processo de análise, pois os protocolos devem ser decodificados pelo HLBR, essa decisão tem implicações diretas na performance do sistema. No baixo nível, a tecnologia envolvida com a captura dos pacotes são os raw sockets.

Funcionando como uma bridge, HLBR não associa endereços MAC ou IP as interfaces, o que lhe possibilita atuar de forma invisível a topologia pois além da absência de endereçamento, o mesmo não modifica os cabeçalhos dos protocolos presentes nos frames. O processo de captura e tomada de decisão são realizadas pelo engine do HLBR, sendo o mesmo capaz de analisar frames Ethernet em meio ao uso de decodificadores implementados com base nas camadas do Modelo TCP/IP.

A análise dos pacotes são realizados com base em regras. Estas podem ser estáticas ou dinâmicas. Regras estáticas especificam conteúdos a estar presente no payload dos pacotes. Regras dinâmicas especificam padrões. A criação de regras dinâmicas envolve o conhecimento de Expressões Regulares seguindo o padrão PCRE (Perl Compatible Regular Expressions).

3.1 - Instalando o HLBR

Nas distribuições Debian e Ubuntu, a instalação do HLBR se dá de forma simples, bastando apenas digitar no terminal:
# apt-get install hlbr
No Slackware, é necessário compilar o HLBR em meio ao código fonte. Também é uma tarefa simples. As dependência para a compilação são PCRE e PThreads, ambas presentes nos discos de instalação do Slackware. O código fonte do HLBR pode ser baixado em http://ufpr.dl.sourceforge.net/sourc...lbr-1.6.tar.gz . Tendo baixado, a primeira tarefa é descompactá-lo:
$ tar -xvzf hlbr-1.6.tar.gz
Logo em seguida, são iniciados os passos da compilação:
$ cd hlbr-1.6
$ ./configure
$ make
# make install
Na etapa de configure será perguntando acerca de qual lingua se deseja que o HLBR seja criado. Por padrão, a lingua é a inglesa, bastando apenas pressionar enter. Para aqueles menos familiarizados, pode-se optar pela lingua portuguesa. Basta digitar "p" e em seguida enter. Vale salientar que a lingua é válida para o arquivo de configuração.

Serão criados os diretórios /etc/hlbr e /var/log/hlbr, bem como serão criados os scripts de inicialização (em /etc/init.d/hlbr) e os arquivos de configuração padrão.

3.2 - Configurando o HLBR

A configuração do HLBR é feita pelo arquivo hlbr.config, encontrado, por padrão, no diretório /etc/hlbr.

O arquivo de configuração está organizado em seções. As principais delas são System, Interfaces, Actions e Routes.

3.2.1 - Seção Sytem

Em System, os principais parâmetros a serem alterados são o Name, que especifica o nome do sensor. Esse parâmetro serve principalmente para identificar de qual instância do HLBR foi gerado o log, caso tenha-se um mecanismo de registros centralizados; ID, que tem função semelhante a Name; Threads, que especidica se o HLBR deverá usar mecanismos multi-threads em sua execução. É fortemente recomendado deixar essa opção intocada (1); AlerHeader, especifica o formato dos alertas gerados. Algumas flags poderão ser usadas, como %dip para o endereço IP de destino, %sp para a porta de origem, dentre outras. Recomendo uma lida breve no arquivo de configuração; PidFile especifica o arquivo que conterá o PID de execução do HLBR. Esse é usado internamente. Lembre-se de manter esse arquivo num lugar acessível. Segue um exemplo de configuração da seção system.
<system>
Name=HLBR_WEB
ID=1
Threads=1
AlertHeader=%y-%m-%d %h:%m:%s %ac %sip:%dp >> %dip:%dp
PidFile=/var/run/hlbr.pid
</system>
Aqui podemos ver que teremos um sensor chamado HLBR_WEB com número de identificação 1 usando threads. Mais a seguir veremos os como configurar o destino dos alertas, porém adianto um modelo de aleta gerado pelo AlertHeader acima:
2009-03-04 03:38:46 00000001 192.168.0.60:3483 >> 192.168.0.61:80 (webattacks-9) open proxy use attempt
3.2.2 - Seção Interfaces

Na seção interface especificamos quais dispositvos de rede farão parte do sistema de prevenção. Nessa devemos inserir o nome da inteface, seu tipo e o protocolo utilizado. Os exemplos serão mais práticos:
<interface eth0>
type=linux_raw
proto=Ethernet
</interface>

<interface eth1>
type=linux_raw
proto=Ethernet
</interface>
O campo type precisa ser ajusto levando em cosideração o sistema opercional utilizado. Para Linux, o tipo é linux_raw; OpenBSD, bsd_bpf; ... Um tipo que é interessante comentar é o tcpdump. Esse recebe um arquivo PCAP e utiliza como uma interface, podendo gerar alertas quanto ao tráfego gerado.

3.2.3 - Seção IPLists

A seção IPLIst associa um conjunto de endereços IP a um nome. Serve para facilitar a confecção de regas. Com uma simples sintaxe, o mais didático que podemos chegar é um exemplo:
<IPList www>
192.168.0.10
192.168.0.11
</IPList>

<IPList dns>
192.168.0.20
192.168.0.21
</IPList>

<IPList servers>
www
dns
</IPList>
Como podem ver, uma IPList pode fazer parte de outra IPList, vide o exemplo de IPList servers.

3.2.4 - Seção Actions

Seguindo, chegamos a seção actions. Nela devemos configurar para onde irão os alertas. As opções são DROP, ou seja, derrubar o pacote; alert console, envia o alerta para o consolo o qual o sistema está rodando; alert file(arquivo), joga a saída para arquivo; alert syslog(fac, prio , opt), envia a saída para o sistema de registro como a facility fac, a prioridade prio e opçoes especiais opt; e dump packet(arquivo), gerá um arquivo pcap com o pacote que conferiu; Seguem exemplos e suas explicações:
<action action1>
response=alert file(/var/hlbr/hlbr.log)
response=dump packet(/var/hlbr/hlbr.dump)
response=drop
</action>

<action action2>
response=alert file(/var/hlbr/hlbr.alert.log
response=dump packet(/var/hlbr/hlbr.alert.dump)
</action>
A o primeiro exemplo, action1, irá gerar um alerta no arquivo /var/hlbr/hlbr.log, um dump do pacote em /var/hlbr/hlbr.dump e derrubará o pacote. Ou seja, o pacote não chegará ao host de destino. O segundo exemplo, por sua vez, irá gerar os mesmo alertas que o primeiro exemplo, porém não derrubará o pacote.

3.2.5 - Seção Routing

A seção routing associa placas de rede para que seja realizada o repasse de pacotes entre essas. As interfaces a serem usadas aqui devem ter sido especificadas na seção interfaces.

As principais opções aqui são SBridege e MacFilter. A primeira associa duas interfaces, realizando uma ponte entre elas. A segunta pode associar um número arbitrário de interface, atuando tal qual um switch. Sempre que possível, é preferível que se utiliza o método SBridge pois esse é muito mais eficiente que o MacFilter.

Segue exemplo de configuração:
<routing>
SBridge(eth0, eth1)
</routing>

<routing>
MacFilter(eth2, eth3. eth4)
</routing>
A primeira das seções criará uma bridge entre as interfaces eth0 e eth1. A segunda, por sua vez, realizará a comutação de pacotes entre as interfaces eth2, eth3 e eth4. Deveido a necessidade da descoberta dos endereços ARP, o método MacFilter pode levar um tempo até iniciar a troca de pacotes.

3.2.6 - Seção Decoders

Como dito anteriormente, o HLBR funciona em meio ao uso de decoders. Sendo a seção mais recente, o único decoder que aceita parâmetros em sua configuração é o decoder HTTP.

O Decoder HTTP, para prover um ganho em usa performance, decodifica apenas os métodos especificados em sua configuração. O arquivo de modelo do HLBR provê entradas para os principais métodos HTTP e WebDAV. Devem ser especificados na configuração, separados por virgúlas, todos os métodos que trafegam em sua rede. Caso um método não esteja presenta na configuração, o decoder HTTP não o vaculhará. Segue um exemplo de configuração:
<decoder http>
GET,POST
</decoder>
Nessa configuração, apenas os métodos GET e POST serão decodificados. Todos os outros, passarão despercebidos pelo decoder HTTP.

3.3 - Rodando o HLBR

Estando o HLBR devidamente configurado, devemos agora iniciar sua execução. Porém, primeiro é necessário configurar as interfaces de rede. Para que se mantenha invisível, o HLBR necessita que não haja endereços IPs configurados nas interfaces. Podemos fazê-lo de duas maneiras:
# ifconfig eth0 0.0.0.0
ou
# ip addr flush dev eth0
Feito isso, podemos agora iniciar o serviço:
# hlbr -c /etc/hlbr/hlbr.config -r /etc/hlbr/hlbr.rules
Config file is hlbr.config
Rules file is hlbr.rules
Loaded 119 rules
A linha de comando acima inicia o HLBR usando o arquivo de configuração /etc/hlbr/hlbr.config e o arquivo de regras /etc/hlbr/hlbr.rules. O sistema foi carregado com 119 regras.

Rodando dessa maneira, o terminal ficará bloqueado pela aplicação. Para contornar esse problema, pode-se usar a flag -d, que fará o HLBR rodar como um daemon, Também é possível iniciar o processo em background, adicionando-se & ao final da linha de comando.

Usuários Slackware poderão adicionar as linhas
ifconfig eth0 0.0.0.0 up
ifconfig eth1 0.0.0.0 up
/etc/init.d/hlbr start
no arqivo /etc/rc.d/rc.local. Isso para a configuração de uma SBridge envolvendo as interfaces eth0 e eth1.

Usuários Ubuntu e Debian, devem usar a ferramente update-rc.d para iniciar o HLBR no runlevel desejado (vide http://www.debuntu.org/how-to-manage...th-update-rc.d).

3.4 - Testando sua configuração

Aparti desse momento, a segurança de sua rede já deve ter sido aprimorada. Para um teste simples faça:
$ links 'http://www.endereçodowww.com.br/search.php?query=/etc/passwd'
Onde www.endereçodowww.com.br deve ser resolvido para um dos endereços presentes na lista www. Se a requisição não puder ser completada, o HLBR está funcionando corretamente e você poderá ver no arquivo /var/log/hlbr.log uma entrada semelhante com a seguinte:
2009-03-08 01:49:44 00000001 192.168.0.10:33244 >> 192.168.0.11:80 (passwd-1) /etc/passwd call
3.5 - Otimizando o conjunto de regras

O HLBR possui um conjunto de 140 regras, relacionadas com os mais diversos serviços. Dessas, apenas 119 estão ativadas por padrão. Apesar de apresentarem uma baixa taxa de falsos positivos (apenas um, e foi comigo ), considero uma boa prática desativar algumas delas para aumentar a performance do sistema de prevenção.

Exemplo: digamos que eu não possua roteadores cisco em minha rede. Então, posso ir ao arquivo hlbr.rules e comentar a linha relativa ao arquivo cisco.rules:
<include rules/awstats.rules>
<include rules/bufferoverflow1.rules>
<include rules/bufferoverflow2.rules>
<include rules/bufferoverflow3.rules>
#<include rules/cisco.rules>
<include rules/codered-nimda.rules>
<include rules/coppermine.rules>
<include rules/dnsattacks.rules>
<include rules/joomla.rules>
<include rules/mailvirus.rules>
<include rules/passwd.rules>
<include rules/shell.rules>
<include rules/spam.rules>
<include rules/webattacks.rules>
Caso não possua clientes µSoft Janelas em minha rede, posso também comentar a regra relativa ao codered-numda.rules.

Existem também quatro linhas relativas a arquivos de regras que estão comentados por padrão, são estes:
#<include rules/http.rules>
#<include rules/php.rules>
#<include rules/sql-xss.rules>
#<include rules/www.rules>
Estas DEVEM ser analisadas pois podem causar falso positivos e DoS em sua rede. São relativas a métodos HTTP, tipos de páginas que podem ser requisitadas e a argumentos passados para página dinâmicas.

Recomendo a visualização de cada arquivo para que se tenha uma noção precisa do que cada regra bloqueia. Além, deve-se também diminuir a quantidade de parâmetros em regras. Por exemplo, todos as regras relacionadas a bufferoverflow, estão com as portas 1-1023 listadas. Caso esteja somente filtrando o tráfego de um servidor WEB, pode somente colocar 80 (ou a porta adequada) como parâmetro.

3.6 - Criando Regras

As regras no HLBR seguem a seguinte sintaxe:
<rule>
decoder teste(argumento)
decoder teste(argumento)
...
decoder teste(argumento)
message=mensagem
action=action
</rule>
Muito pouco intuitivo... É melhor apresentar um exemplo real:
<rule>
ip dst(servers)
tcp dst(13,37,53,123)
tcp content(/etc/passwd)
message=(passwd-1) /etc/passwd call
action=action1
</rule>
Então, na primeira linha temos a tag <rule> que indica o início de uma regra; A segunda diz que os dados a serem analisados são os do decoder IP e que o teste a ser realizado é o DST; A terceira diz que os dados a serem analisados são os do decoder TCP e o teste a ser realizado é o DST; A quarta também verifica o TCP, porém os teste a ser realizado é o CONTENT; A quinta linha especifica a mensagem a ser registrada caso algum pacote case com a regra; a sexta especifica a ação a ser tomada; e por ultimo, porém não menos importante, </rule> termina a declaração de uma regra.

Então, sumarizadamente, as regras consistem em especificar quais dados devem ser analisados e quais testes realizar. Segue abaixo uma lista com os decoders e seus principais testes.

Ethernet
src - permite verificar o endereço MAC de origem. Ex: ethernet src(ff:ff:ff:ff:ff:ff)
dst - permite verificar o endereço MAC de destino. Ex: ethernet dst(ff:ff:ff:ff:ff:ff)
type - permite verififcar o tipo do protocolo encapsulado. Ex: ethernet type(IP)
IP
src - permite verificar o endereço IP de origem. Ex: ip src(192.168.0.1, servers)
dst - permite verificar o endereço IP de destino. Ex: ip src(192.168.0.1, www)
proto - permite verificar o protocolo encapsulado. Ex: ip proto(TCP,UDP)
TCP
src - permite verificar a porta TCP de origem. Ex: tcp src(2222)
dst - permite verificar a porta TCP de destino. Ex: tcp dst(80)
content - permite verificar a presença de um conteúdo estático em um payload TCP, levando em consideração a caixa. Ex: tcp content(/etc/passwd)
nocase - permite verificar a presença de um conteúdo estático em um payload TCP, sem levar em consideração a caixa. Ex: tcp content(
regex - permite verificar a presença de um padrão definido por uma Expressão Regular em um payload TCP. Ex: tcp regex(/etc/(passwd|shadow))
UDP
src - vide TCP, porém aplicado ao protocolo UDP
dst - vide TCP, porém aplicado ao protocolo UDP
content - vide TCP, porém aplicado ao protocolo UDP
nocase - vide TCP, porém aplicado ao protocolo UDP
regex - vide TCP, porém aplicado ao protocolo UDP
HTTP
content - vide TCP, porém no protocolo de aplicação HTTP
nocase - vide TCP, porém no protocolo de aplicação HTTP
regex - vide TCP, porém no protocolo de aplicação HTTP
method - verifica o método do cabeçalho HTTP.
Vejam que os protocolos TCP e HTTP possuem alguns testes em comum. A diferença básica entre eles é que, no decoder HTTP, os caractéres URL Encoded são decodificados e passados em texto puro para o teste. Por exemplo, caso o atacante tente se aproveitar de uma falha em um script PHP, ele poderia evadir a regra TCP usada como exemplo da seguinte forma:
GET /scriptvulneravel.php?include=%2f%65%74%63%2fpasswd HTTP/1.0
Ou seja, ele poderia passar o "/etc/" de forma codificada pois esses caractéres não estariam visíveis pelo teste content do decoder TCP. Já usando o decoder HTTP, o texto seria primeiramente passado para sua forma "human-readable" e casaria com a seguinte regra:
<rule>
ip dst(servers)
tcp dst(13,37,53,123)
http content(/etc/passwd)
message=(passwd-3) /etc/passwd call
action=action1
</rule>
Portanto, sempre que sua regra estiver direcionada ao protocolo HTTP, use o decoder HTTP.

Outro detalhe sobre o uso do teste content, é que esse permite análisar bytes brutos. Por exemplo, caso queira verificar a presença de uma caractére de controle backspace, pode ser feito da seguinte maneira:
...
tcp content(ASD| 08 |DSA)
...
Onde 08 é o código hexadecimal do caractére backspace, o qual deve ser substituido pelo caractére desejado. Os delimitadores suportam sequencias de bytes ( |08 13 29| ). O mesmo vale para o teste nocase. Já nas expressões regulares, usa-se o escape \x seguido do código hexadecimal:
...
http regex (ASD\x08DSA)
...
Na diretiva message, deve-se especificar a mensagem que aparecerá nos registros do sistema. Também é possível fazer a substituição de algumas flags (%sip, %dip, %sp, ...), como feito no AlertHeader, porém, visto que todas as informações que se deseja armazernar já está especificado no AlertHeader, não há muita vantagem em fazê-lo. Uma frase simples e objetiva se mostra bastante eficiente.

A diretiva action especifica qual a ação a ser tomada para o pacote que casa com a regra. O valor dela poder ser qualquer um entre os identificadores das actions criadas no arquivo de configuração.

3.6.1 - Depurando novas regras

Ao HLBR, é permitido tomar decisões relativas ao tráfego de rede, podendo até mesmo bloqueá-lo. Acredito que isso já ficou claro até aqui. Portanto, deve-se ter um cuidado especial com novas regras pois estas podem levar a falsos positivos e a negação de serviço. Portanto, ao desenvolver uma nova regra, aconselho que a mantenha com uma action que não derrube o pacote. É interessante também gerar os dumps dos pacotes. Utilizando um arquivo de configuração padrão, esse comportamento pode ser conseguido utilizando-se a action2.

Os dumps são de fundamental importância pois permitem que as regras sejam validadas. Ou seja, com eles em mão, você pode utilizar seu analisador de pacotes preferido, desde que compatível com PCAP, e validar seus resultados.

3.6.2 - Ferramentas de depuração

Após escrever as regras, se mostra proveitoso criar a aplicar casos de testes. As ferramentas descritas (brevemente) a seguir possibilitam a aplicação de casos de testes, não estando sua utilidade limitada somente a depuração de regras do HLBR. Recomendo estudar cada uma em separado.

3.6.2.1 - Hping3

O Hping3 é um gerador de pacotes de rede de propósito geral. Permite especificar todos os detalhes do pacote, desde o protocolo reportado pelo campo proto do protocolo IP até o número de sequência do protocolo TCP. Claro, também permite determinar os dados do payload. Exemplo:
hping3 192.168.0.10 -p 80 --ack -e 'GET / HTTP/1.0

'
3.6.2.2 - NetCat

O canivete suíço do TCP/IP. Uma boa pedida para o NetCat é gerar tráfego malicioso. Então, seja a.data um arquivo binário com tráfego malicioso,
nc -u 192.168.0.20 53 < a.data
Irá enviar o conteúdo de a.data via UDP para a porta 53 do host 192.168.0.20. Na Internet existem milhões e milhões de tutoriais sobre o NetCat, com os mais variados exemplos.

3.6.2.3 - Scapy

O Scapy é um poderoso programa interativo de manipulação de pacotes. Com ele é possível gera ou decodificar pacotes de vasto número de protocolos, enviá-los, capturá-los, e muito mais. Utilizando-se da linguagem de programação Python como seu backend, o Scapy permite gerar e enviar tráfego de forma mais automatizada e dinâmica que a maioria das ferramentas.

Devido a complexa (mas não complicada) utilização, não serão mostrado exemplos de utilização do Scapy. Mas fica o link para quem desejar se aprofundar: http://www.secdev.org/projects/scapy/doc/usage.html

3.6.2.4 - KRegExpEditor

Essa não é uma ferramenta de rede, porém se apresenta como uma poderosa aliada na escrita/depuração de regras baseadas em Expressões Regulares. Sendo uma das opções de testes mais poderosas do HLBR, as Expressões Regulares podem apresentar alguns dificuldades, principalmente para aqueles que estão iniciando.

O KRegExpEditor é um editor gráfico de Expressões Regulares. Seu interface consiste em um campo para a digitação da ER, um campo para a entrada de casos de testes e um visualizador interativo da ER digitada. A medida que se digita a ER, o visualizador é atualizado. Caso a ER case com algum caso de teste, a porção casante é destacada do restante do texto.

O único problema com KRegExpEditor é a compatibilidade somente com o padrão POSIX, pois o HLBR utiliza-se do PCre. Mas mesmo assim, é uma ótima ferramenta.

3.7 - Análisando os registros

Uma parte importante da prevenção de intrusão é analisar quais ataques estão sendo realizados e barrados em sua rede. Portanto, se mostra fundamental a visualização e interpretação frequente dos registros gerados pelo sistema.

A principal e mais simples ferramenta para essa tarefa é o TCPDump. Bastante conhecida entre os administradores de rede, o TCPDump permite a captura e a visualização do tráfego de uma interface ou do tráfego presente em um arquibo PCAP, além de permitir o uso de regras de filtragem. No HLBR, o TCPDump é utilizado das duas maneiras descritas. Primeiro, podemos abrir qualquer uma das interfaces:
tcpdump -i eth0
tcpdump -i eth1
tcpdump -i any
Segundo, podemos abrir os arquivos gerados pelas actions:
tcpdump -r /var/log/hlbr/hlbr.dump -n -s 1500 -A
Para tornar a análise mais eficiente, podemos também utilizar filtros e visualizar somente os pacotes relevantes a um dado host ou protocolo:
tcpdump -r /var/log/hlbr/hlbr.dump -n -s 1500 -A dst host 192.168.0.10 and dst port 80
A regra de filtragem acima irá mostrar somente os pacotes destinados a porta 80 do host 192.168.0.10. O manual do TCPDump (man tcpdumo) é bem completo e possui diversos exemplos de regras de filtragem.

Outra ferramente útil, principalmente para aqueles menos acostumados com o terminal, é o Wireshark. Possuindo os mesmo recursos do TCPDump, o Wireshark é capaz de gera gráficos de fluxo de pacotes, reconstuir fluxos, analisar dados de I/O, além de interpretar os principais protocolos das mais diversas camadas.

Os dumps são as mais completas fontes de dados, porém, muitas vezes é relevante somente um sumário das ameaças barradas. Nos arquivos de log são impressos somente os dados especificados no AlertHeader do hlbr.config. Portanto, apresentam somente informações básicas como o IP de origem/destino, porta de origem/destino, hora do ocorrido, mensagem e mais alguns dados, dependendo da configuração realizada. Estando armazenados como arquivos de texto plano, os logs podem ser visualizados com ferramentas como o less, cat e more.

3.7.1 - Validação das decisões

Apesar de todas as informações disponíveis, ainda cabe ao administrador do sistema julgar as decisões do HLBR e destivar regras que estejam causando problemas. Não sendo um cenário comum, falsos positivos podem ocorrer quando não se tem a devida atenção no momento da otimização do conjunto de regras (3.5).

Portanto, bastant cautela durante a seleção das regras do seu IPS. Como já dito, tente manter novas regras em estado de quarentena (sem impedir a passagem). Caso haja dúvida quanto ao funcionamento de alguma regra, tente manté-la também em quarentena e verifique se algum acesso lícito a seu sistema casa com a regra, o que a tornaria uma fonte de falsos positivos.

No mais, bom senso é a melhor das virtudes.

3.8 - Futuro do HLBR

Bem, o desenvolvimento do HLBR anda a todo vapor, estando em fase de testes a otimização para arquiteturas multi-core e agendadas o porte para 64 bits.

Caso alguém venha a testar o HLBR, gostaria de ter o feedback e também ouvir sugestões de melhoras e de funcionalidades.

3.9 - Comunidade

O HLBR possui um grupo de discussão onde rolam anúncios e suporte ao uso da ferramenta. O endereço do grupo é http://br.groups.yahoo.com/group/hlbr/ . Se inscreva e estaremos lá, sempre que possível, para tirar dúvidas e discutir opniões.

Caso seja desenvolvedor, o HLBR é todo desenvolvido em linguagem C. As únicas bibliotecas as quais estamos sujeitos é a PCRE e a Pthreads. Também, claro, a biblioteca padrão, mas não vem ao caso. Se quiserem colaborar conosco, basta entrar no grupo e expor as idéias.

4 - Pra finalizar...

Bom pessoal, espero que tenham gostado do post. Custou muito para finalizá-lo pois a faculdade não está me deixando fazer muita coisa além dos trabalhos... Quem tiver dúvidas, sugestçoes ou erratas, podem usar os comentários! Estamos sempre abertos a melhorias!

Estou agendano os próximos post para falar sobre virtualização com User-Mode Linux e programação Multi-thread com Python. Pelo menos algo de proveitoso aprendi com os milhares de trabalhos da faculdade... Alguém se interessa sobre esses temas?

Quem usar Twitter ou Identi.ca pode me adicionar... Meu perfis são http://(twitter.com|indenti.ca)/pedroarthurjedi. Para quem não conhece, o Identi.ca utiliza-se do ambiente de micro-bloggin livre Laconica (http://laconi.ca), e é bem mais Nerd e menos main-stream que o Twitter.

Até a próxima... Nos vemos nós fóruns... Falouz!
Categorias
Não Categorizado

Comentários

  1. Avatar de jeanfrank
    Muito bom este post seu Pedro
    Parabens pela sua iniciativa e continue assim(depois dos elogios rsrsrs) vem a duvida e ja me desculpe pela ignorancia, tenho aqui um provedor de internet onde utilizo o mk pra todos os serviços que preciso e trabalho tambem com serviodor linux debian que funciona como proxy em paralelo ao mikrotik, gostaria de saber como poderia implementar esta solução que vc postou...seria possivel o que vc indica, estou enfrentando varios problemas com virus na rede e esta solução parece interessante

    abraços

    jeanfrank
  2. Avatar de PEdroArthurJEdi
    Citação Postado originalmente por jeanfrank
    Muito bom este post seu Pedro
    Parabens pela sua iniciativa e continue assim(depois dos elogios rsrsrs) vem a duvida e ja me desculpe pela ignorancia
    Valeu, motiva a continuar...

    Estamos aqui para discutir tecnologia. A dúvida e o questionamento são os primeiros passos para o entendimento.

    Citação Postado originalmente por jeanfrank
    tenho aqui um provedor de internet onde utilizo o mk pra todos os serviços que preciso e trabalho tambem com serviodor linux debian que funciona como proxy em paralelo ao mikrotik, gostaria de saber como poderia implementar esta solução que vc postou...seria possivel o que vc indica, estou enfrentando varios problemas com virus na rede e esta solução parece interessante
    Pois bem... Sou desenvolvedor do HLBR. O que posso lhe dizer é que ele não está preparado para esse tipo de aplicação. Somos poucos e, infelizmente, não temos muito tempo para nos dedicar a criação de regras. Permanecemos mais na otimização e desenvolvimento do núcleo do sistema. Portanto, a maioria das regras estão adaptadas a nossa realidade. Ou seja, as investidas maliciosas que acontecem em nossas redes. Porém, caso seja possível, tente capturar tráfego malicioso e gerar novas regras. Estarei sempre disponível a discutir e, caso suas regras sejam viáveis, podemos incluir no pacote oficial.

    Caso não tenha experiência em análise de tráfego, posso tentar fazê-lo para você. Contudo, não poderei dar uma resposta imediata pois tenho minhas ocupações (faculdade e pesquisa). Se optar por enviar o tráfego, garanto que todas as informações presentes permanecerão confidenciais e serão usadas somente para a confecção de regras, nada mais.

    Infelizmente, desenvolvedor de soluções livres não é uma profissão muito valorizada.

    E pra quem mais estiver interessado em ajudar o projeto: PRECISAMOS DE REGRAS!!! Caso tenha experiência com análise de tráfego e tenha disponibilidade para participar do projeto gerando assinaturas, entre na lista de discussão que estaremos lá prontos para discutir as soluções e o melhor jeito de integrá-las ao pacote oficial.
  3. Avatar de info24hs
    Muito bom esse post, eu ja tinha lido quando postou e agora decidi usa-lô. Parabéns!

    3.3 - Rodando o HLBR
    Estando o HLBR devidamente configurado, devemos agora iniciar sua execução. Porém, primeiro é necessário configurar as interfaces de rede. Para que se mantenha invisível, o HLBR necessita que não haja endereços IPs configurados nas interfaces. Podemos fazê-lo de duas maneiras:
    # ifconfig eth0 0.0.0.0
    ou
    # ip addr flush dev eth0
    Amigo, se eu entendi bem vc diz que é necessário que as interfaces não tenham ips fixo... ocorre que eu preciso ter os ips das interfaces configurados.. existe uma solução para isto?
  4. Avatar de PEdroArthurJEdi
    Citação Postado originalmente por info24hs
    Amigo, se eu entendi bem vc diz que é necessário que as interfaces não tenham ips fixo... ocorre que eu preciso ter os ips das interfaces configurados.. existe uma solução para isto?
    Não entendi bem qual o propósito, por isso pergunto: o IP é para a administração do serviço? Caso sim, não tem problema em atribuir um endereço IP a uma das interfaces. O único problema é que o HLBR trabalha na camada de enlace e mesmo a máquina recebendo o pacote, ele continuará repassando para a outra interface. Se você tiver um loop em sua topologia, irá receber diversos pacotes duplicados.

    Mais foi muito boa sua colocação. Acho que vou implementar uma funcionalidade para que se o pacote for direcionado a uma das interfaces do HLBR, ele não seja repassado. Mas claro, isso virá com diversos problemas que ainda preciso pensar.

    Valeu pelo interesse!
  5. Avatar de info24hs
    O que eu quero dizer exatamente é que eu preciso que o arquivo interfaces tenha configurado o ip, mascara, etc.. das interfaces, tenho 3 placas de rede 2 internet 1 local, e não pode ser por dhcp..
  6. Avatar de PEdroArthurJEdi
    Se entendi bem, você quer colocar o HLBR como um gateway. É isso? Se sim, não dá. O HLBR é um elemento intermediário. Por exemplo, ele deve estar entre o gateway e o roteador, entre o switch e um servidor. Em outras palavras, o HLBR funciona como uma bridge, sendo a única diferença a possibilidade de filrar determinado conteúdos.
  7. Avatar de info24hs
    Minha rede é a seguinte:
    ADSL 1 ==> eth1=192.168.1.10---Linux---eth0=192.168.0.1
    ADSL 2 ==> eth2=192.168.2.10---Linux---eth0=192.168.0.1
    Preciso que os ips das interfaces sejam pré determinados, acho que é isso..
    Não dá né..
    No caso o HLBR fornece um ip para as eth1 e eth2 ?

+ Enviar Comentário