Vou tentar resumir o ambiente que eu uso pra filtrar L7, aja que a thread esta bem grande.
Instale via ports o snort_inline, e entao configure o snort_inline.conf com algo proximo a isso (pode comecar com isso e depois customizar): ### Network variables var HOME_NET [192.168.0.0/16,10.0.0.0/8,200.X.Y.0/22] #var HOME_NET any var HONEYNET any var EXTERNAL_NET any var SMTP_SERVERS any var TELNET_SERVERS any var HTTP_SERVERS any var SQL_SERVERS any var HTTP_PORTS 80 var SHELLCODE_PORTS !80 var ORACLE_PORTS 1521 var DNS_SERVERS any var SSH_PORTS 22 2222 2022 #config checksum_mode: all config ipfw_reinject_rule: 65500 var RULE_PATH /usr/local/share/snort_inline/rules preprocessor flow: stats_interval 0 hash 2 output alert_fast: inline_fast include /usr/local/share/snort_inline/classification.config include /usr/local/share/snort_inline/reference.config #include /usr/local/share/snort_inline/rules/classification.config include $RULE_PATH/FBSDBR/patrick.rules include $RULE_PATH/FBSDBR/patrick-p2p-drop.rules include $RULE_PATH/p2p.rules include $RULE_PATH/bleeding-p2p.rules Na regra 65500 u tenho um "add count tag 30 all from any to any keep-state" E logo abaixo faco queue (Wf2Q+) de tudo "tagged 30". Um pipe obviamente também serve. No comeco de tudo, faca um "skipto 65500 all from any to any tagged 30". As dicas são: - resuma seu firewall a regras antes da 65500, de forma que nada que nao for desviado/reinjetado para 65500 jamais chegue nela (ou seja: "add 65499 deny all from any to any" pra ter a politica antes desse pool final de regras. Desvie para a 65500 apenas pelo snort_inline - o .conf acima ja esta configurado pra isso); - desvie para o snort_inline o trafego desejado, NO MOMENTO que voce jugar necessario: comece com "divert 8000 all from any to any" pra testes, depois seja seletivo: "divert 8000 all from $minharede to any out", "divert 8000 all from any to $minharede in" - lembre-se que apos o desvio 2 coisas acontecem: se o snort_inline nao classificar o pacote com as regras carregadas, o pacote volta pra proxima regra do firewall, se bater com as regras, o pacote sera reinjetado para a ipfw_reinject_rule configurada; - porque usar "tag" e "count" e "keep-state"? porque voce nao quer permitir, nem negar, nem ja jogar pro controle de banda, apenas aquele pacote; voce quer com base no pacote conhecer a sessao toda (keep-state), e taggear *todos* os pacotes da sessao, e depois manipula-los Por ultimo, eleve o net.inet.ip.fw.dyn_udp_lifetime, eu uso-o em 300 sem dó (sim, 5 minutos). Agora algumas considerações: - SANS Security recomenda que toda analise de payload nao seja feita pelo firewall, e preferencialmente seja feita por aplicacoes de userlevel pois se comprometidas nao desestabiliza o sistema (ao contrario de analise me kernel); - O custo de desviar pra uma aplicacao de userland com divert em relacao ao processamento que seria feito se fosse em kernel, é de 2 syscall para os pacotes nao classificados (praticamente todos) e 3 syscall para os classificados; isso realmente gera impacto no seu ambiente? - O custo de processamento do snort_inline, que atua de forma pró-ativa (veja bem: snort convencional: passivo, snort com flexresp: responsivo, snort com snortsam ou OSSEC evocando rotinas externas: resposta ativa, snort_inline = pró-ativo pois se o snort não reinjetar, não volta pro firewall e consequentemente não volta pra pilha IP) é no máximo 5% superior ao snort atuando em modo passivo. Você não tem CPU suficiente para o snort com meia duzia de rules seletivas? Por último, algumas considerações adicionais: - Impacto negativo: você está desviando um dado fluxo para o snort_inline, isso quer dizer que se não tive nada ouvindo na porta 8000 protocolo div4, aquele fluxo vai pra /dev/null (ou seja, tudo para); mas o snort_inline nunca morre sozinho; se mesmo assim você tem medo: daemontools pra que te quero. - Você pode anular o ponto negativo anterior trocando "divert" por "tee" na regra de firewall. Nesse caso uma cópia vai para o snort_inline e outra, do pacote, fica no firewall. Portanto voce vai querer repensar seu firewall pra copia q fica nao cair num "allow" antes de cair no seu controle de banda. Dica: skipto vai resolver. - Funciona 100%? Não! Digamos, uns 70%. Porque? Porque tem alguns P2P que detectamos via TCP mas o tráfego vai por UDP. Nesse caso precisaria de um tipo de "keep-state" no firewall que mantesse a sessão apenas por IP, sem se ligar em porta ou protocolo. Ai sim funcionaria perfeitamente. Tai algo q mereceria ser investigado e feito no ipfw. - Eu amenizei todas as situações onde os "30%" q nao funcionava era um problema analisando com tcpdump os trafegos e criando minhas proprias regras. Ai que mora outra vantagem: regras snort, nada mais facil de fazer. Finalmente, consideracoes de experiencia propria: - Nessa mauqina: # dmesg | grep "CPU:\|memory" CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (2010.15-MHz 686-class CPU) real memory = 1072103424 (1022 MB) avail memory = 1031237632 (983 MB) Eu filtro 34Mbit/s, load avg dela nesse momento: load averages: 0,98 1,23 1,22 Latencia maxima percebida com divert pro snort_inline, comparado com sem o divert, foi de 83ms. Não é pouco. Mas para internet não é significativo. Essa é a máxima, a latencia média é inferior a 20ms. Ultima consideração: H323 não funciona!! Não descobri o porque, o pacote é reinjetado numa boa, mas não passa nada H323 depois do divert. Ta certo que H323 é um lixo, mas as vezes esse lixo na sua rede não pode ser substituído por RTP. Foi o meu caso. A solução foi permitir o tráfego H.323 pro meu gatekeeper antes do divert. Bom, essa é a melhor abordagem que eu conheço, funcional, e a que eu uso - portanto a que eu recomendo. Espero que lhes seja útil. -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd