[MASOCH-L] RES: Regra frag no ipfw

[Renato Frederick]

Aqui eu tenho esta habilitada:

00600    506328    596481538 deny log udp from any to any frag
00700         7          280 deny log tcp from any to any frag

E recebo constantemente em meus logs:


Nov 19 17:15:40 X kernel: ipfw: 600 Deny UDP 200.230.105.80 187.xin via ste3
(frag 8108:1480 at 1480+)
Nov 19 17:15:40 X kernel: ipfw: 600 Deny UDP 200.230.105.80 187.x in via
ste3 (frag 8108:1480 at 2960+)
Nov 19 17:15:40 X kernel: ipfw: 600 Deny UDP 200.230.105.80 187.x in via
ste3 (frag 8108:1480 at 4440+)
Nov 19 17:15:40 X kernel: ipfw: 600 Deny UDP 200.230.105.80 187.x in via
ste3 (frag 8108:1480 at 5920+)
Nov 19 17:15:40 X kernel: ipfw: 600 Deny UDP 200.230.105.80 187.x in via
ste3 (frag 8108:999 at 7400)
Nov 19 17:15:41 X kernel: ipfw: 600 Deny UDP 200.150.135.185 187.x in via
ste3 (frag 29508:1480 at 1480+)
Nov 19 17:15:41 X kernel: ipfw: 600 Deny UDP 200.150.135.185 187.x in via
ste3 (frag 29508:1480 at 2960+)
Nov 19 17:15:41 X kernel: ipfw: 600 Deny UDP 200.150.135.185 187.x in via
ste3 (frag 29508:1480 at 4440+)
Nov 19 17:15:41 X kernel: ipfw: 600 Deny UDP 200.150.135.185 187.x in via
ste3 (frag 29508:1480 at 5920+)
Nov 19 17:15:41 X kernel: ipfw: 600 Deny UDP 200.150.135.185 187.x in via
ste3 (frag 29508:959 at 7400)

Os IP internos acima 187.x são de meus NAT para clientes. Até o momento, não
tive reclamações. A propósito, mesmo sem clientes ativos em minha LAN(este
circuito ficou quase 1 mês ativo e sem uso), já havia estes fragmentos
bloqueados, juntamente com portscan e outras..



> -----Mensagem original-----
> De: masoch-l-bounces at eng.registro.br [mailto:masoch-l-
> bounces at eng.registro.br] Em nome de Julio Arruda
> Enviada em: quarta-feira, 19 de novembro de 2008 14:40
> Para: Mail Aid and Succor, On-line Comfort and Help
> Assunto: Re: [MASOCH-L] Regra frag no ipfw
> 
> Danton Nunes wrote:
> > On Wed, 19 Nov 2008, Julio Arruda wrote:
> >
> >>> cuidado com bloqueio de fragmentação. costuma dar besteira tanto em
> >>> UDP quanto em TCP. você corre sério risco de bloquear tráfego
> >>> perfeitamente válido, mas que foi fragmentado 'en route'. Recomendo
> >>> fortemente não fazer isso!
> >>
> >> Na verdade, era realmente para ser bem menos comum (trafego valido
> com
> >> fragmentacao) em TCP do que em UDP, ja que 'em teoria' o PMTU
> >> Discovery esta ai para isto :-).
> >
> > ahá, mas tem uns manés que bloqueiam ICMP também, aí junte uma coisa
> com
> > a outra e está aberto o caminho do desastre.
> 
> 
> Sim :-)...Como o default de determinado sistema, e' nao detectar "PMTUD
> blackhole" :-)...
> A MS ja acordou e mudou o default :-) ? Ou continuam com esta deteccao
> desabilitada no Vista/Windows7 ?
> 
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l