Aproveitando patrick, pq vc não coloca em forma de artigo.. assim ficaria como um How-to.
Em 26/11/07, Patrick Tracanelli<[EMAIL PROTECTED]> escreveu: > 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 > -- Marcio Gomes =================== Linux pra quem odeia Windows BSD pra quem ama UNIX ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
