[FUG-BR] RES: Filtro L7

Segunda Novembro 26 16:11:02 BRST 2007

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<eksffa em freebsdbrasil.com.br> 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
>> 316601 em sip.freebsdbrasil.com.br
>> 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
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"