PigMeet: projeto nacional para integrar firewall e IDS

Esta integração é útil em poucos casos. O grande problema é que você pode gerar falsos positivos e gerar uma denegação de serviços com muito pouco tráfego. Basta fazer spoofing de vários endereços de proxys de provedores grandes e enviar os pacotes para a rede que tem este tipo de integração. O IDS informará ao Firewall do ataque e este bloqueará o acesso. Com isso nenhum usuário desses provedores conseguirá acesso. E nem precisou mandar grandes volumes de pacotes para conseguir o efeito.

Tipo o snortsam? (www.snortsam.net)

Concordo com o Flávio.

Acho perigoso o conceito dessa solução: criar regras dinâmicas baseadas em alertas de IDS pode ser o próprio ataque! Justamente pq a solução se baseia em agentes externos para assim criar sua ação, ou seja, a manipulação de pacotes externos e seus payloads (packetfactory.net) são justamente o trigger para manipulação de bloqueios. Como autenticar pacotes, evitando spoofs, principalmente no caso de scans ou DoS ?
É complicado...

Descordo em partes...
conheci o pigmeat em maio no encontro da GUS em sampa (FIAP) , e de lá pra cá venho me interessando mais ainda pelo software.
Na minha rede funciona bem, falsos positivos e negativos sempre vão existir, mas o que é mais importante é que o pigmeat+snort+acid bem configurados reportarão muito menos falsos negativos e positivos...

Implantei o pigmeat+acid+snort a alguns meses aqui na minha rede e estou satisfeito, no começo tive problema com assinaturas falsas , ataques a unicode do windows,scan proxy, etc,,, mas dei uma reconfigurada, defini algumas signatures a serem descartadas e agora está tudo normal...

e estou ancioso esperando o pigmeat 1.0 e pra ver novas mudanças no mesmo..

Parabens ae Cabelo(o cara que antes da palestra sempre rola um cigarro com coca cola pra relaxar)
heheheh

perai, acho que vc não entendeu...
Não estou dizendo que a ferramenta é ruim, mas sim o princípio da solução. Quer um exemplo?
Vc configura seu snort para criar alertas de IPs que estão fazendo scans em certo momento. Se um scan for detectado, vc bloqueia esse ip por um período X. Ele poderia solucionar um problema real? Sem dúvida.

O ponto é: o que impede que eu criei regras específicas para manipular regras no seu firewall?
Imagine que eu use uma funcionalidade do nmap chamada decoy:

" -D
Causes a decoy scan to be performed which makes it appear to the remote host that the host(s) you specify as decoys are scanning the target network too. Thus their IDS might report 5-10 port scans from unique IP addresses, but they won't know which IP was scanning them and which were innocent decoys."

... em outras palavras, o nmap cria pacotes 'spoofando' o endereço IP que eu quiser (o seu por exemplo), que baseado em suas regras, deve-se adicionar uma regra de bloqueio contra seu endereço IP ! Ou seja, se isso fosse realizado em um servidor http, e eu soubesse que ele utiliza essa prática (não muito difícil de descobrir), eu poderia fazer via spoof que o site negasse serviço para vc. Em outras palavras, teu browser iria ganhar um belo 'connection refused'.

Este é o problema, na minha opinião, desta solução.

Nem sabia q estavam falando do pigmeet aqui, agora que vi, bom, tenho que responder algumas coisas afinal sou o autor dessa coisa chamada agora PigMeet com ee)
Sobre falsos positivos, abordado pelo Flavio:
Em caso de spoofing de ips dos rootcasts por exemplo, cabe a vc ignorar esses ips para nao serem bloqueados, o mesmo com a sua propria rede. Existem mecanismos que voce pode usar para identificar sspoofing, comparando o pacote recebido de um ip com uma resposta daquele ip a um pacote gerado por vc.. comparanddo os fingerprints vc reduz o falso positivo em caso de spoofing.

Sobre o nmap e decoys..
Como foi dito, realmente, o problema nao esta na ferramenta, esta na solucao. Nao ha como, pela maneira que tudo funciona, uma maneira eficaz de impedir ataques. Por isso solucoes deste tipo etao comecando a focar nao o bloqueio permanente do ip, mas apenas aquela conexao (vide snort inline) ou mesmo bloquear por um curto periodo de tempom tendo como objetivo inpemir a continuidade daquela conexao.
O snort inline eh muito bom, mas precisa estar na maquina do firewall, este eh o problema.
A complexidade do pigmeet eh necessaria justamente pq esta nova versao foi desenhada para controlar todo um anel de firewalls atravez de varios sensores.

Sobre o snortsam: eh PARECIDO. O snort sam tem seus meritos.. bloquear em pix, fw1 e etc, infelizmente eu nao tenho como desenvolver isto sem ter um para testes.
Mas o snort SAM eh suscetivel a um DoS, coisa que o pigmeet tem todo um cuidado especial. O SnortSam tem poucas funcoes. Hoje no pigmeet vc tem como com um comando no client consultar todos os frws e saber quem esta bloqueado em cada um, e sincronizar esta lista. Quando/se um dia o pigmeet suportar fw-1 pix, acl cisco e etc, isto tb sera possivel.

Eh aquilo: a solucao se propoe a algo que nao eh por definicao perfeito, e que vai dar trabalho pra manter sim. O ideal eh vc implantar e ir aprendendo com isso. O pigmeet tem recursos para tentar diminuir falsos-positivos, como por exemplo ignorar alguns tipos de signatures vindo de algum IP, caso vc tenha alguem na rede q por mah configuracao gere akilo (minha adsl do velox me ataca direto, akele UPnP misc...)
Daih o snort continua logando, e o pigmeet nao blokeia.
Eh claro, q o ideal eh configurar bem o snort, ateh mecher nos aarquivos de rules.
Quando voce implementa uma solucao dessas, supoe-se ue voce tenha seu ids mto bem configurado. Regras de ataque ao seu web server por exemplo: se eh apache, nao use as regras de iis pois nao vai afeta-lo mesmo.. somnte qnd for com destino ao web server de fato. e etc. Essas coisas, q ajudam a reduzir o volume de alerts e consequentemente torna-los mais precisos.

http://pigmeet.databras.com.br -> nao tenho tempo pra fazer uma pagina legal hehe, mas vejam o HOW-TO que fiz que tah muito bem explicado.