Eu pensei que o seguinte fosse necessário para o HTTP de saída em um desktop (não servidor):
iptables -A INPUT -p tcp -m multiport --sports 80,443 -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
Mas, acontece que eu preciso desses dois para fazer funcionar. Eu não sei porque:
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
Eu sei que a última regra permite o UDP para a interface lo .
Mas, pensei que tudo o que eu precisava era de outgoing TCP for NEW/ESTABLISHED connections + incoming TCP for ESTABLISHED connections . Pareceu-me contra-intuitivo (porque ainda estou aprendendo).
Você obviamente não precisa de lo para acesso à Internet. Mas talvez você tenha um servidor DNS local (encaminhador) em execução. O DNS usa o UDP, e o acesso à web requer DNS além do HTTP.
Suas regras não permitem respostas (relacionadas) do ICMP BTW. Isso provavelmente causará problemas (a menos que você use valores baixos para MSS / MTU). Mas você nem permite o ICMP de saída para que a descoberta do MTU do caminho nem funcione.
Eu só posso fazer suposições porque você não listou suas políticas padrão. Encontrado no topo da saída de iptables -S . Eu suponho que você está sendo restritivo e você tem algo assim.
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
Ótimo! Sua máquina agora está completamente invisível, vendada, amarrada e amordaçada em relação aos pacotes IP. Isso é quase tão bom quanto desconectá-lo da sua rede Ethernet.
Então, se você quer ter esperança neste mundo cruel e sombrio, você terá que colocar algumas regras para aceitar alguns pacotes, talvez encontrar alguém com uma faca para cortar suas cordas, mas quais pacotes são os certos queridos?Uma regra de saída é necessária para permitir que os pacotes alcancem as portas que os servidores usam para o tráfego http / https
-A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
É necessária uma regra de ENTRADA para permitir que os pacotes do seu navegador sejam usados pelas portas usadas para o tráfego http / https.
-A INPUT -p tcp -m multiport --sports 80,443 -m conntrack --ctstate ESTABLISHED -j ACCEPT
Agora, você pode ESTABELECER NOVAS conexões http / https a partir do seu navegador, e receber informações retornando através dessas conexões ESTABELECIDAS.
Qual é o problema então? Não há nenhuma maneira de obter informações de DNS, você deve ser capaz de inserir o endereço IP dos sites que deseja visitar em seu navegador, mas isso não é exatamente o que queremos. O tráfego de DNS é manipulado pela porta 53 com o protocolo UDP.
-A OUTPUT -p udp --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
E para receber essas respostas úteis, precisaremos cortar mais alguns buracos nessa venda.
-A INPUT -p udp --sport 53 -m conntrack --ctstate ESTABLISHED -j ACCEPT
Agora há alguma luz, você pode ouvir, dizer se você fizer uma consulta dns para um dos servidores do Google
dig @8.8.8.8 slashdot.org
Tal resposta! Mas talvez o seu navegador ainda não consiga descobrir onde o slashdot realmente está no mundo. Pelo menos uma distribuição (Ubuntu) é configurada para usar um proxy DNS interno, então você precisa ser capaz de falar consigo mesmo (o resto do mundo é chato mesmo assim) configurando regras para permitir que você se comunique como um servidor porta 53
-A OUTPUT -o lo -p udp --sport 53 -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A INPUT -i lo -p udp --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
Observe a diferença sutil entre essas regras, "Eu sou meu próprio servidor", e a anterior, "Eu só quero ver as regras do mundo". Além disso, -o lo e -i lo indicam que este servidor só servirá esta máquina, uma boa medida para evitar ser sugado por algum tipo complicado de ataque de rejeição do DNS.
Agora você deve ver que seu navegador funciona novamente.
Dependerá se as cadeias INPUT e / ou OUTPUT estão definidas como ACCEPT pacotes não correspondidos. Se forem, você não precisa de nenhuma regra. Se você não mudou isso é provavelmente o padrão.
Essas duas últimas regras permitem qualquer tráfego de ou para a interface lo (ou seja, 127.0.0.1 / :: 1), não apenas para UDP. A menos que você esteja se conectando a um servidor da Web na área de trabalho local, eles não terão relevância para o HTTP.
Tags iptables