Marcio Antunes escreveu: > Aproveitando patrick, > > pq vc não coloca em forma de artigo.. assim ficaria como um How-to.
Porque é simples demais, e se resumiria em essência ao conteúdo desse e-mail. O resto é snort apenas, nada especifico com a abordagem. Outra abordagem bastante funcional é com snortsam colocando src e dst em tables distintas, ai o controle seria "from table(1) to table(2)" e vice-versa, diminuindo o problema dos p2p q mudam de protocolo no meio da conversa. > > > 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 >> > > -- 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
