O firewall ainda está bloqueando a porta 53, apesar de listar o contrário?

Eu tenho 3 nós com praticamente as mesmas regras de iptables carregadas de um script bash, mas um nó específico está bloqueando o tráfego na porta 53, apesar de listar que está aceitando:

$ iptables --list -v

ENTRADA EM Cadeia (pacotes DROP 8886 da política, bytes de 657K)
 pkts bytes alvo prot opt in out origem destino         
    0 0 ACEITAR tudo - lo em qualquer lugar e lugar            
    2 122 ACEITAR icmp - qualquer solicitação de eco icmp em qualquer lugar e em qualquer lugar 
20738 5600K ACEITAR tudo - qualquer estado em qualquer lugar e em qualquer lugar RELACIONADO, ESTABELECIDO 
    0 0 ACEITAR tcp - eth1 em qualquer lugar multiport node1.com dports http, smtp 
    0 0 ACEITAR udp - eth1 em qualquer lugar ns.node1.com udp dpt: domain 
    0 0 ACEITAR tcp - eth1 em qualquer lugar ns.node1.com tcp dpt: domain 
    0 0 ACEITAR tudo - eth0 qualquer node2.backend em qualquer lugar            
   21 1260 ACEITAR TODOS - eth0 qualquer node3.backend em qualquer lugar            
    0 0 ACEITAR tudo - eth0 qualquer node4.backend em qualquer lugar            

Cadeia FORWARD (política DROP 0 pacotes, 0 bytes)
 pkts bytes alvo prot opt in out origem destino         

SAÍDA em cadeia (pacotes de política ACEITAR 15804, 26M bytes)
 pkts bytes alvo prot opt in out origem destino

nmap -sV -p 53 ns.node1.com // Do servidor remoto

Iniciando o Nmap 4.11 (http://www.insecure.org/nmap/) em 24-02-2011 11:44 EST
Portas interessantes em ns.node1.com (1.2.3.4):
VERSÃO DE SERVIÇO DO ESTADO DO PORTO
Domínio filtrado 53 / tcp

Nmap concluído: 1 endereço IP (1 host ativo) verificado em 0,336 segundos

Alguma ideia?

obrigado

domain-name-system firewall iptables

— Tom
fonte

Respostas:

Percebo que zero pacotes realmente atingiram suas iptablesregras de ACEITAR para DNS. Eu acho que é provável que suas iptablesregras estejam especificando uma combinação inconsistente de condições que nunca correspondem às consultas DNS recebidas.

No seu caso, suas regras de ACEITO DNS especificam que a interface de entrada deve ser eth1e o endereço IP de destino deve ser resolvido ns.node1.com. Você deve verificar se as consultas DNS recebidas ns.node1.compodem chegar pela eth1interface de rede.

Outra possibilidade é que você tenha outro filtro de pacotes em algum lugar entre o cliente de teste e o servidor que está bloqueando pacotes DNS.

— Steven segunda-feira
fonte

Obrigado, vou analisar isso. A porta é desbloqueada quando eu paro o iptables, o que exclui um filtro de pacotes acima do meu servidor, causando o problema.

— Tom

Depois de remover todas as regras de firewall, exceto iptables -A INPUT -i eth1 -j ACCEPT, a porta ainda está bloqueada. Quando eu paro o iptables, ele está aberto. Alguma idéia agora?

— Tom

@ Tom: Claramente, seus pacotes de teste não estão cumprindo a regra ACEITAR, caso contrário, a porta não seria bloqueada. A conclusão mais provável é que seus pacotes de teste não estão chegando eth1. Você tem certeza de que eth1é para onde eles deveriam chegar?

— Steven segunda-feira

Não tenho certeza, mas vou explicar minha configuração - eth0 tem o IP privado e eth1 tem o IP principal, eth1: 0 é o servidor de nomes (e o destino desejado para os pacotes) e eth1: 1 é para nginx. Meus outros 2 servidores têm interfaces idênticas e aliases de interface. A única diferença que consigo pensar é eth1: 0 nos outros 2 servidores para servidores de nomes escravos e eth1: 0 neste servidor é para o servidor de nomes mestre. Isso fornece algum insight? Agradecemos sua ajuda - isso está realmente me matando.

— Tom

Devo mencionar, eu sempre tive essas regras padrão no script bash antes e depois das regras para controlar serviços: iptables -F; iptables -Z; iptables -A INPUT -i lo -j ACEITAR; iptables -A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT; iptables -A INPUT -m state --state ESTABELECIDO, RELACIONADO -j ACEITA; ## regras para controlar os serviços aqui ## iptables -P OUTPUT ACCEPT; iptables -P INPUT DROP; iptables -P GO FORWARD DROP;

— Tom

Provavelmente a porta TCP está bloqueada por outro firewall. Use tcpdump / Wireshark para depurar o problema.

De mim:

nmap -sV -p 53 x.x.x.x

Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-25 02:32 YEKT
Interesting ports on x.x.x.x:
PORT   STATE SERVICE VERSION
53/tcp open  domain  ISC BIND Not available

— ooshro
fonte

Quando eu paro o iptables, a porta fica aberta.

— Tom