Diede
(usa Debian)
Enviado em 03/12/2009 - 14:50h
Olá magnolinux!
Bem, usar drop na tabela nat evita o atacante "natear" (desculpe o termo...) sem autorização, isso concordo. Mas, pelo pacote já ter entrado em nat, isso ocupa a tabela conntrack desnecessariamente.
Não é verdade para todos os casos, mas acontece. Eu fazia isso também, mas vi que é mais vantajoso em termos de performance bloquear direto na tabela raw, que é a primeira por onde os pacotes passam.
Liberar e bloquear na nat, realmente é possível, pela flexibilidade do netfilter, e é até viável.
magnolinux: "so para vc entender... o iptables trabalha com ganchos do netfilter... a tabela nat é lida da seguinte forma.."
Quanto aos ganchos eu entendo. Por este exato motivo que prefiro bloquear na tabela raw: Se não passar por ela, "não passa por nada"...
"PREROUTING -> INPUT ou FORWARD -> POSTROTUING"
Bem, esta ordem eu conheço :-)
magnolinux: "Antes de chegar na chain POSTROUTING, o pacote já tera passado na chain PREROUTING, onde é definido o roteamento dos pacotes, esse roteamento defini se o pacote é input ou forward e por ultimo vai para tabela POSTROUTING.
Entao, mesmo estando na chain POSTROUTING vc sera encaminhado para o proxy.."
Bem, depende como o pacote chegou na chain POSTROUTING.
Se nosso amigo adicionar "iptables -t nat -I PREROUTING -s IP_DO_CHEFE -j ACCEPT" esta será a primeira da PREROUTING que baterá com os pacotes vindos do chefe, o que pulará a regra de redirecionamento para a porta 3128. Chegando na POSTROUTING tendo pulado o redirecionamento (ou seja, com o pacote até então não modificado), o "iptables -t nat -A PREROUTING -s IP_DO_CHEFE -j MASQUERADE" irá fechar fazendo um SNAT nos pacotes, garantindo acesso a FTP, IRC, MSN, (etc) ao chefe.
Nesse embolo todo, acabou sendo feito o "temido" filter na tabela nat (iptables -t nat -I PREROUTING -s IP_DO_CHEFE -j ACCEPT), mas como você disse, e eu concordo, a flexibilidade do netfilter nos permite fazer....
magnolinux: "A tabela nat é utilizada para altera o conteudo do pacote, que seja porta de origem/destino ou ip de origem/destino "FIM"."
Sim, concordo, mas, pela flexibilidade do netfilter (ponto em que concordamos, eu acho), ela pode fazer filter também (de certa forma), embora isso seja "incorreto", por questões de organização. (e pelo fato de ocupar a conntrack desnecessariamente)
magnolinux: "A tabela filter é utilizada para filtro de Pacote "FIM"."
Sim!
magnolinux: "A tabela Mangle é utilizado para alterar o conteudo do pacote, definindo prioridade(TOS..etc) "FIM""
Sim, e bendito TOS... nada melhor que ter sempre um SSH com latência mínima!
magnolinux: "Mais uma vez eu reforço.. a tabela filter que é a tabela de "FIREWALL" bloqueia e libera."
Sim, exato!
Mas, quando digo que mexer na nat irá liberar acesso, não é "liberar" como "antônimo" de "bloquear", é um "liberar" voltado a recurso, como antônimo de "não ter".
Digo, o que tento dizer é:
No caso específico de nosso amigo, se os pacotes da máquina do chefe não tiverem um tratamento de DNAT/SNAT, eles nunca chegarão à internet, pois estão sob NAT, têm IP privado, não vai "sair vivos do nat"...
O "liberar" que digo neste caso, não quer dizer que sem o masquerade o pacote seria bloqueado porque a nat faz bloqueio, mas quer dizer que sem o masquerade o pacote seria bloqueado porque não haveria nenhuma regra que o fizesse passar pelo Nat com um IP público e chegar corretamente à Internet...
