Este iptables NAT é explorável do lado externo?

Question

Você poderia, por favor, dar uma olhada neste simples iptables / NAT-Setup, eu acredito que ele tenha um problema de segurança bastante sério (devido a ser muito simples).

Nesta rede existe uma máquina conectada à internet (rodando Debian Squeeze / 2.6.32-5 com iptables 1.4.8) atuando como NAT / Gateway para um punhado de clientes em 192.168 / 24.

A máquina possui dois NICs:

eth0: internet-faced
eth1: LAN-faced, 192.168.0.1, the default GW for 192.168/24

Tabela de roteamento é padrão de duas NICs sem alterações manuais:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
(externalNet)   0.0.0.0         255.255.252.0   U     0      0        0 eth0
0.0.0.0         (externalGW)    0.0.0.0         UG    0      0        0 eth0

O NAT é ativado apenas e meramente por essas ações, não há mais regras de iptables:

echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# (all iptables policies are ACCEPT)

Isso faz o trabalho, mas sinto falta de várias coisas aqui que acredito que possam ser um problema de segurança:

1. não há restrições sobre interfaces de origem ou redes de origem permitidas

2. não há partes de firewall como:

   (defina políticas para DROP)
   / sbin / iptables -A ENCAMINHAR -i eth0 -o eth1 -m estado - estado RELACIONADO, ESTABELECIDO -j ACEITAR
   / sbin / iptables -A FORWARD -i eth1 -o eth0 -j ACEITAR

E assim, as perguntas das minhas noites sem dormir são, enquanto a primeira é mais importante para mim:

1. Este serviço NAT está disponível para qualquer pessoa na mesma sub-rede ISP que define esta máquina como seu gateway padrão?
   Eu diria que sim, porque existe nada indicando que uma conexão externa de entrada (via eth0) deve ser tratada de forma diferente de uma conexão interna de entrada (via eth1), desde que a interface de saída seja eth0 - e roteamento que vale para clientes externos e internos que desejam para acessar a internet. Então, se eu estiver certo, qualquer um poderia usar essa máquina como proxy aberto fazendo com que seus pacotes sejam NATted aqui. Então, por favor, me diga se está certo ou porque não está. Como um "hotfix" eu adicionei uma opção "-s 192.168.0.0/24" para o comando NAT-inicial. Eu gostaria de saber se não usar essa opção era realmente um problema de segurança ou apenas irrelevante, graças a algum mecanismo que eu não conheço.

2. Como as políticas são todas ACCEPT, não há restrição no encaminhamento de eth1 para eth0 (interno para externo). Mas quais são as implicações efetivas de atualmente NÃO ter a restrição de que somente os estados RELATED e ESTABLISHED são encaminhados de eth0 para eth1 (externos para internos)?
   Em outras palavras, devo preferir alterar as políticas para DROP e aplicar as duas regras de "firewall" mencionadas acima ou a falta delas não afeta a segurança?

Obrigado pelo esclarecimento!

    

Answer 1

1. Sim, no entanto, a máquina deve estar na mesma sub-rede que você no lado do ISP. Mas, nesse caso, o invasor pode simplesmente forjar seus endereços IP de origem para serem seus ou usar um endereço não alocado. No entanto, como suas regras são escritas, um invasor externo pode navegar em sua LAN, no entanto, ele terá que lidar com o fato de que seu servidor pode mascarar os pacotes no caminho de retorno. Assim, você deve descartar pacotes indo para 192.168.0 / 16 de eth0 usando iptables (não, usar o roteamento de políticas é muito tarde aqui).

2. O encaminhamento de pacotes inválidos pode resultar em vazamentos de endereços privados na Internet ou em pacotes não traduzidos que chegam aos hosts. MASQUERADE pode se recusar a mascarar / desmascarar pacotes inválidos, ou esses pacotes inválidos podem nem mesmo atingir a tabela nat. Geralmente, é uma boa ideia, pelo menos, descartar pacotes no estado INVALID. Então aceite somente pacotes de eth0 com o estado ESTABLISHED ou RELATED. Eu não acho que poderia ter qualquer problema de segurança se os hosts em sua LAN se comportassem corretamente, mas eu faria de qualquer maneira.

Answer 2

1) resposta curta "o mundo inteiro" - não , pessoas da sua rede externa, sim .

Você só pode configurar o gateway para estar em sua LAN atual, para que qualquer pessoa do externalNet possa definir sua caixa como gateway e até acessar as máquinas por trás dele (por exemplo, ele pode acessar 192.168.0.2 atrás do NAT - os pacotes serão encaminhados, mas os pacotes que retornam serão NAT para externalNet-ip , que ele terá que traduzir novamente - o que é factível).

A regra "-s" corrigirá o problema "proxy", mas você também deve bloquear todos os pacotes que chegam a eth0 com 192.168.0.0/24 como o destino.

2) Depende. Se você confia nos clientes por trás do NAT e deseja não ter restrições, então tudo bem. Se você deseja bloquear / permitir apenas determinados serviços, é necessário bloqueá-los (por exemplo, permitir somente as portas tcp de destino 80.443 e a porta 53 tcp / udp, etc. e bloquear todo o resto).

Se você permitir apenas conexões estabelecidas e relacionadas no tráfego de saída, não haverá maneira de estabelecer a conexão, portanto, nada ocorrerá.

    

Answer 3

1) Sim. ISP ethernet part - O MAC addr é usado para transporte de gateway.

2) Eu recomendaria dar uma olhada na configuração padrão nas distribuições RedHat / Fedora / CentOS, eles sabem o que e por que estão fazendo isso: link

BTW: NÃO USE REJEIÇÃO COM A CORRENTE ANTERIOR link

    

Answer 4

Se eu estou lendo corretamente supondo que você promulgar essas regras propostas, isso deve aliviar sua inquietação.

Você tem uma política padrão para eliminar qualquer coisa que atinja a cadeia INPUT ou FORWARD.

Em seguida, você permite apenas o encaminhamento de pacotes RELATED, ESTABLISHED que chegam na sua interface externa e saem pela interface interna.

Assim, a única maneira de os NOVOS pacotes serem encaminhados é coberta pela última regra, somente os pacotes que chegam pela interface interna e saem pela interface externa serão encaminhados.

Portanto, mesmo se um host na rede externa tentasse usar seu host como um gateway, um pacote NOVO chegaria à eth0, acessaria a cadeia de encaminhamento e, em seguida, cairia, porque não há regra.