...> leia o man com *muita*, mas *muita* mesmo, aten��o !!! como > est� dito no final (BUGS) o man ainda est� incompleto e > "generico" (muito superficial); mas tem tudo. Deveria constar > no BUGS: requer excelente conhecimento de TCP/IP,
...a rede em si e simples, um bloco privado atras de um firewall ligado a um ip publico. o fato gerador da *noia e uma possibilidade de DoS via syn+ack, que ao bater no nat (como indicado em _muitas_ literaturas, faqs, manuais, etc, deve estar no topo da lista de regras) faz com que ele chegue em niveis absurdos de utilizacao de cpu, tendo como consequencia a parada do
a ideia para minimizar o impacto:
1) criar uma regra para nat ver somente a saida 2) fazer bloqueios e liberacoes em portas, etc... 3) fechar o restante das portas (?) 4) criar uma regra para nat ver entrada (teoricamente pacotes NATeados) 5) fechar a interface
to babando na maionese ?
valeu !!
Inverta:
crie regras que bloqueie um syn+fin (e outros tipos de ataque/scans) **antes** da regra do NAT !!
algo assim:
- bloqueia scans (syn+fin, syn+rst, etc)
- bloqueia portas indevidas no NIC externa (137-139 p.ex)
- bloqueia "spoofing" (ip da rede intera vindo pela externa e ip externo vindo pela rede interna)
- NAT
- etc.. etc...
Isso vai evitar um bocado de dor de cabe�a....
[]s
Antonio Torres [EMAIL PROTECTED]
_______________________________________________________________ Sair da Lista: http://lists.fugspbr.org/listinfo.cgi Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
