Melhorando a segurança do Firewall com Bridges usando Snort_Inline no Debian Etch

A segurança é algo preocupante para os administradores de sistema. Estamos acostumados a ver aquele firewall, que está ali na porta de saída da sua rede, apenas servindo de gateway para a internet e deixando trafegar dados sem qualquer controle. Vamos mostrar como melhorar o firewall bridge que criamos no outro artigo utilizando o Snort_Inline.

[ Hits: 37.417 ]

Por: Brivaldo Alves da Silva Jr em 06/06/2007 | Blog: http://blog.bibliotecaunix.org/


Tirando dúvidas



Com certeza deve ter gente lendo e não sabe o que e nem o que faz o Snort e muito menos o Snort_Inline, pensando nisso achei necessário deixar a descrição sobre cada um deles apenas como uma informação a mais.

Então, o que é o Snort?

O Snort é um software livre de detecção de intrusão para rede (NIDS) desenvolvido inicialmente por Martin Roesch, capaz de desenvolver análise de tráfego em tempo real e registro de pacote em redes IP. Executa análise de protocolo, busca/associa padrões de conteúdo e pode ser usado para detectar uma variedade de ataques, tais como buffer overflows, stealth port scans, ataques CGI, SMB probes, OS fingerprinting, entre outras. Esta ferramenta é suportada em arquiteturas RISC e CISC e em plataformas das mais diversas, como os vários sabores de Linux.

E o Snort_Inline?

O snort_inline [1] é basicamente uma versão modificada do Snort que aceita pacotes do iptables e IPFW (usado nos BSD's) via libipq (no GNU/Linux) ou sockets divert (no FreeBSD), ao invés da libpcap. Ele usa novos tipos de regras (drop, sdrop, reject) para dizer ao iptables/IPFW se o pacote deve ser dropado, rejeitado, modificado ou permitido a passar baseado nas regras definidas no snort. Pense nisso como um Sistema de Prevenção de Intrusão (IPS - Intrusion Protection System) que usa as assinaturas de um já existente Sistema de Detecção de Intrusão (IDS - Intrusion Detection System), para tomar decisões nos pacotes que atravessarem o snort_inline.

[1] http://snort-inline.sourceforge.net/

Página anterior     Próxima página

Páginas do artigo
   1. Começando
   2. Tirando dúvidas
   3. Pacotes necessários
   4. Compilando através do código fonte
   5. Configurando o Snort_Inline
Outros artigos deste autor

Mantendo seus dados em segurança com o EncFS

Criando um Firewall transparente com Bridges no Debian Etch

Configurando o Stardict com dicionário do Babylon

Controle de banda de domínios virtuais no Debian Etch

Leitura recomendada

Double Dragon: chkrootkit e portsentry, agora vai rolar pancadaria nos intrusos!

kvrt: O novo antivírus gratuito da Kaspersky para Linux

Capturando e-mails da rede com Mailsnarf

Armitage: a nova interface gráfica do Metasploit

Certificações em Segurança: para qual estudar?

  
Comentários
[1] Comentário enviado por y2h4ck em 06/06/2007 - 09:07h

Na verdade execução de um sistema de IDS executando no mesmo hardware do Firewall é algo um pouco arriscado, afinal um firewall deve ser um host onde não executem outros serviços alem do mesmo. O uso de um IDS pode produzir um uso excessivo dos recursos físico, e, como bem sabemos o Snort o faz.

Em um caso de um ataque massivo e persistente, como por exemplo um atacante realizando um probe em cima de um serviço publicado através deste firewall, o snort geraria uma quantidade de alertas mto grande, e os forks poderiam ocasionar um DoS no serviço de Gateway.

O recomendado e ter uma placa no firewall apenas para uso do IDS, esta placa ficaria no firewall em modo promiscuo, e assim o IDS ligado através de um cabo cross, poderia analisar de forma paralela os pacotes que trafegam na rede.

Como forma de IPS poderiamos utilizar o Iptables utilizando o fwsnort que gera regras para o firewall com base nas regras de Snort, sendo assim assinaturas conhecidas de ataques críticos podem ser rejeitadas antes de atravessar a rede.

Abraços.

Anderson

[2] Comentário enviado por condector em 08/06/2007 - 17:13h

É por isso que não usamos um IDS e sim um IPS... concordo contigo, mas a idéia deste artigo é integrar o snort_inline ao nosso firewall por bridges, ou seja, invisível na rede, o que torna um ataque em cima do firewall impossível, pois ele não tem IP na rede.

E é exatamente isso que estou dizendo no artigo... usando um firewall bridge como descrevi é possível usar o snort para bloquear os ataques muito antes de chegarem na rede... acho que você não uniu este artigo ao meu anterior sobre firewall bridge. Mesmo assim, se for pensar somente em IDS você está correto, mas no que eu proponho fazer, acredito que você tenha confundido algumas coisas.

Abraços,
Brivaldo Jr

[3] Comentário enviado por condector em 08/06/2007 - 17:13h

Ta bom vai, impossível é d+ pra quem conhece redes e softwares em geral, mas pelo menos improvável.

[4] Comentário enviado por y2h4ck em 09/06/2007 - 13:03h

Veja o seguinte, supomos que o atacante faça um packte injection na sua rede enviando fora do header do pacote, um local onde é considerado um uso-abusivo em protocolos de transporte convencionais, uma string do tipo:

"exe?+-+-+-+-+-+-+-+-+-+-+-+-+-+-+",

Seu IPS vai disparar um alerta contra o host e vai bloquá-lo certo ? Interessante, porém como sabemos um protocolo de camada mais baixo como por exemplo transporte, pode ser encapsulado facilmente dentro de um protocolo de camada mais alta "Aplicação" neste caso específico, sendo assim, poderiamos encapsular um DoS usando por exemplo o Velho UDP/Pong, onde enviamos um UDP na porta 65335 e um na 1024, fazendo seu IPS achar que se trata de um Scan Nmap usando o método de Varredura UDP.

Se colocarmos isto dentro de um packet generator como o yersinia ou nemesis por exemplo, podemos gerar uma repetição de forma que, seu IPS irá gerar 3 alertas diferentes para o mesmo pacote.
- 1 para o valor do payload onde setamos o string malicioso
- 1 para o "Nmap Scan"
- 1 para o Undefined UDP Packet (pacote UDP com conteúdo indefinido).


Agora imagine esta repetição acontecendo por meia hora seguida, com um link "generoso" de 512 kbps eu conseguiria gerar em torno de 16.000 alertas por segundo no seu firewall, e minha experiencia com o Snort diz que ... com um fluxo alto assim de pacotes nos pre-processadores ele aumenta consideravelmente o uso de recursos do Sistema.


Pensando pelo ambito que você está tratando de uma integração de seu host com o Iptables posso citar mais uma infinidade de falhas de segurança que podem ocorrer deste derivado de IDS + Firewall, porém não vem ao caso.

Não me confundi não, conheço muito bem oque é um IDS e um IPS :)

Não estou desmerecendo sua solução, apenas estou apontando um ponto falho que deve ser considerado no momento que se implementa algo deste tipo :)

Abraços e boa sorte.

[5] Comentário enviado por condector em 06/09/2007 - 11:29h

Bem, vendo por esse lado realmente você está correto. Quando falei da confusão foi porque a sua primeira resposta me deixou confuso no que você queria dizer.

A idéia de usar um IPS num bridge transparente evita em parte este problema que você falou pois você não sabe que tem um firewall no meio do caminho pois nem IP ele possui... sendo assim fica MUITO improvável porque você teria que conhecer a estrutura antes de ataca-lá. Seu pacote malicioso seria bloqueado e você não saberia porque, até porque nem o NMAP conseguiria definir quem ou quando foi bloqueado.

Este artigo como disse é um completemento ao firewall bridge invisível que descrevi em outro artigo aqui no VOL

[6] Comentário enviado por removido em 17/10/2009 - 09:21h

Não Conheço Muito o SNORT mas Ajudou muito este Artigo.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts