Capriotti wrote:
HAHAHAHA !hahaha vixi, eh pra poupar processamento. Acho que minha convivencia com o Jean e suas solucoes "embedded" de freebsd me fizeram ficar paranoico quanto a processamento (afinal quando se tem processador de 2Ghz blz, mas quando se tem de 50 a 80 mhz :/).
T� falando japon�s agora, meu filho ??? hehehe
Essa ficou extremamente herm�tica para quem n�o estudou pelo menos por 15 minutos a man do ipfw !
hehehe
[]s
add <n> drop log tcp from not 200.200.200.200/32 to me in recv <interface>
Tipo, "in recv" tu garante que o pacote ja sera bloqueado ao entrar pela interface. Se nao coloca "in" ele fica verificando in recv e out xmit (gasta processamento), entao vamos barrar logo na entrada. O "not XX" faz o host virar uma exclusao `a regra, bem bunitinho alem de economizar ciclos de processamento economiza memoria (ja que nao precisa existir outra regra carregada tratando a situacao).
Essa e' uma sintaxe generica (serve pro IPFW1 e IPFW2) mas quem tiver IPFW2 pode abusar das virgulas, {}, or e and. Segundo a explicacao do Luigi Rizzo (mantenedor do IPFW) e' interessante trabalhar assim pois a economia de processamento e memoria fica clara, ja que as regras vao ser interpretadas como (analogia dele) uma especie de meta-ACL interna (com instrucoes `a la bpf)
por exemplo
add drop log icmp from 10.0.0.0/6{8,16,27} to not { 200.200.200.200/32 or 200.200.222.0/24 } keep-state out xmit wi0 icmtypes 0,18,13
seria mais ou menos (a forma como eu entendi as analogias do kra)
ACL-from = 10.0.0.0/6, 10.0.0.0/8, 10.0.0.0/16, 10.0.0.0/27
ACL-to = !(200.200.200.200/32), !(200.200.222.0/24)
<subc 1> = acao, protocolo
<subc 2> = direcao, opcoes
enta a regra se constitui em
<subc 1> ACL-from ACL-to <subc 2>
A economia se da onde <subc 1> e <subc 2> sao definicoes constantes em memoria pra aquela regra, e as variaveis ACL-from/ACL-to sao as unicas que precisam ser "procesadas" durate a verificacao de "matching". Caso exista o "match" a acao (drop log) que ja estava em memoria e' processada. Senao passa pra proxima regra.
No IPFW1 *sem* usar "not" seriam necessarias *mais de* 8 regras, todas elas carregadas e com as acoes e opcoes (<subc 1> e <subc 2>) multiplicadas entre as regras (processamento redundante).
Eu nao sei se questao do processamento das instrucoes funcionam da mesma forma para icmptypes e ipoptions por exemplo. Caso funcione, teriamos uma especie de ACL 3 controlando "icmptype 0 ou icmptype 8 ou...". Nao sei se seria uma constante a verificacao pelas N opcoes ou variavel. Teria que ler o codigo ou apurrinhar o luigi hehehe.
Eh, me extendi no assunto, mas espero ter me justificado hehe.
--
Atenciosamente,
Patrick Tracanelli
FreeBSD Brasil LTDA.
The FreeBSD pt_BR Documentation Project
http://www.freebsdbrasil.com.br
[EMAIL PROTECTED]
"Long live Hanin Elias, Kim Deal!"
_______________________________________________________________
Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr
Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
