iptables tables - corrigindo um erro de digitação

Question

Eu passei algum tempo hoje auditando meu script do iptables. Eu sou um engenheiro de software, não um guru de Ops, mas tentei aprender o básico do iptables. Eu notei algo que deve ter sido quebrado por um longo tempo:

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -i lo -d 127.0.0.0/8 -j REJECT

Ok, parece que deveria ser:

-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT

certo?

O problema é que o servidor está executando o tráfego ao vivo. Embora isso pareça uma mudança inofensiva, eu trato o iptables com uma quantidade apropriada de deferência. Além disso, significa que estou aceitando tráfego de / 8 proveniente de outras interfaces. O que isso significa em termos do mundo real? Como a máquina receberia solicitações de 127/8 em uma interface diferente?

    

Answer 1

looks like it should be:

-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT

Right?

Provavelmente sim. O espírito desta regra parece ser bloquear qualquer coisa cujo destino IP seja 127.0.0.0/8 que não chegue na interface lo (loopback).

Veja esta pergunta sobre o posicionamento correto do caractere ! : Posição do estrondo dos iptables .

I've been accepting traffic from /8 that comes from other interfaces. What does that mean in real world terms?

Se alguém fabrica um pacote falso, destinado à sua máquina em uma de suas interfaces conectadas publicamente, você pode ter respondido e, em alguns casos degenerados, pode ter permitido acesso a daemons e serviços locais apenas ouvindo em uma interface de loopback . Eu ficaria surpreso se esse comportamento realmente ocorresse , e qualquer superfície de ataque em potencial fosse bastante remota.

Na realidade, as chances de explorar isso parecem, pelo menos para mim, ser remotas. O invasor precisa estar no mesmo segmento de rede que você para falsificar um cabeçalho IP enquanto mantém o cabeçalho Ethernet (em particular, o endereço MAC de destino) intacto. Os hosts remotos não seriam capazes de explorar um cabeçalho IP falsificado, porque o pacote seria descartado quando passasse pelos roteadores da rede. Quaisquer serviços na máquina explicitamente ligados ao endereço IP da interface de loopback devem responder apenas ao tráfego recebido, não aos pacotes falsificados que chegam em outras interfaces, então eu (pessoalmente) não vejo isso como um grande problema para você.

Trouble is, the server is running live traffic. While this looks like a harmless change, I treat iptables with a proper amount of deference.

Muito bem, qualquer alteração na configuração que envolva o risco de transformar uma máquina que esteja movendo pacotes ativamente em uma máquina que rejeite ativamente o tráfego de rede deve ser tratada com cautela, especialmente se o tempo de inatividade terá implicações financeiras. Você também deve pesar as conseqüências de tal mudança - as chances de este tipo errado levar a uma exploração que faz a máquina cair são finas , mas manipular a configuração do iptables em uma máquina em funcionamento tem maiores riscos de causar tempo de inatividade. Esse trade-off deve ser considerado com cuidado.

Uma mudança desse tipo deve ser inofensiva , mas ainda existem relativamente muitos modos de falha: fat-fingering em uma transação de teclado, entendendo mal a interação entre esse aspecto de seus iptables configuração e algumas outras entradas no firewall, etc.

Para todas as alterações de firewall não rotineiras, especialmente aquelas que lidam com regras REJECT , você deve planejar o tempo de inatividade. Se estiver realizando uma alteração em uma máquina a partir de um local remoto, certifique-se de ter algum outro meio de acesso à máquina que deve ser perdido - de preferência, isso deve estar disponível na janela de manutenção para que você pode evitar violar quaisquer SLAs. Uma conexão OOB via um controlador IPMI integrado ou um console serial ou, alternativamente, a capacidade de acessar fisicamente a máquina no data center durante o período at risk , seria tudo adequado aqui.