[FUGSPBR] Re: [extendido] Ipfw barrando telnet.

[Patrick Tracanelli]

Capriotti wrote:
> HAHAHAHA !
> 
> 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>

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 :/).

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
patrick em freebsdbrasil.com.br
"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/