Le pare-feu bloque toujours le port 53 malgré une liste contraire?

J'ai 3 nœuds avec pratiquement les mêmes règles iptables chargées à partir d'un script bash, mais un nœud particulier bloque le trafic sur le port 53 malgré la liste, il l'accepte:

$ iptables --list -v

ENTRÉE en chaîne (politique DROP 8886 paquets, 657 K octets)
 pkts bytes target prot opt in out source destination         
    0 0 ACCEPTER tout - lo n'importe où n'importe où            
    2 122 ACCEPTER icmp - n'importe quel n'importe où n'importe où n'importe où icmp echo-request 
20738 5600K ACCEPTER tout - n'importe quel n'importe où n'importe où n'importe où État CONNEXE, ÉTABLI 
    0 0 ACCEPTER tcp - eth1 n'importe où n'importe où node1.com multiport dports http, smtp 
    0 0 ACCEPTER udp - eth1 n'importe où ns.node1.com udp dpt: domaine 
    0 0 ACCEPTER tcp - eth1 n'importe où ns.node1.com tcp dpt: domain 
    0 0 ACCEPTER tout - eth0 n'importe quel nœud2.backend n'importe où            
   21 1260 ACCEPTER tout - eth0 n'importe quel noeud3.retour n'importe où            
    0 0 ACCEPTER tout - eth0 n'importe quel noeud4.backend n'importe où            

Chain FORWARD (politique DROP 0 paquets, 0 octets)
 pkts bytes target prot opt in out source destination         

SORTIE de chaîne (politique ACCEPTE 15804 paquets, 26M octets)
 pkts bytes target prot opt in out source destination

nmap -sV -p 53 ns.node1.com // Depuis le serveur distant

Démarrage de Nmap 4.11 (http://www.insecure.org/nmap/) au 2011-02-24 11:44 EST
Ports intéressants sur ns.node1.com (1.2.3.4):
VERSION DU SERVICE DE L'ÉTAT DU PORT
Domaine filtré 53 / TCP

Nmap terminé: 1 adresse IP (1 hôte) analysée en 0,336 secondes

Des idées?

Merci

domain-name-system firewall iptables

— À M
source

Réponses:

Je remarque que zéro paquet a réellement atteint vos iptablesrègles ACCEPT pour DNS. Je pense qu'il est probable que vos iptablesrègles spécifient une combinaison incohérente de conditions qui ne correspondent jamais aux requêtes DNS entrantes.

Dans votre cas, vos règles DNS ACCEPT spécifient que l'interface entrante doit être eth1et que l'adresse IP de destination doit être résolue en ns.node1.com. Vous devez vérifier si les requêtes DNS entrantes ns.node1.compeuvent arriver via l' eth1interface réseau.

Une autre possibilité est que vous ayez un autre filtre de paquets quelque part entre votre client de test et votre serveur qui bloque les paquets DNS.

— Steven Monday
source

Merci, je vais examiner cela. Le port se débloque lorsque j'arrête iptables, ce qui exclut un filtre de paquets au-dessus de mon serveur à l'origine du problème.

— Tom

Après avoir supprimé toutes les règles de pare-feu, sauf iptables -A INPUT -i eth1 -j ACCEPT, le port est toujours bloqué. Quand j'arrête iptables, c'est ouvert. Des idées maintenant?

— Tom

@Tom: Clairement, vos paquets de test n'atteignent pas la règle ACCEPT, sinon le port ne serait pas bloqué. La conclusion la plus probable est que vos paquets de test n'arrivent pas eth1. Êtes-vous certain que eth1c'est là qu'ils devraient arriver?

— Steven lundi

Je ne suis pas sûr, mais je vais expliquer ma configuration - eth0 a l'IP privée et eth1 a l'IP principale, eth1: 0 est le serveur de noms (et la destination souhaitée pour les paquets) et eth1: 1 est pour nginx. Mes 2 autres serveurs ont des interfaces et des alias d'interface identiques. La seule différence à laquelle je peux penser est eth1: 0 sur les 2 autres serveurs sont pour les serveurs de noms esclaves et eth1: 0 sur ce serveur est pour le serveur de noms maître. Cela donne-t-il un aperçu? Appréciez votre aide - cela me tue vraiment.

— Tom

Je dois mentionner que j'ai toujours eu ces règles standard dans le script bash avant et après les règles pour contrôler les services: iptables -F; iptables -Z; iptables -A ENTRÉE -i lo -j ACCEPTER; iptables -A ENTRÉE -p icmp -m icmp - requête d'écho de type -mp -j ACCEPTER; iptables -A INPUT -m state --state ESTABLISHED, RELATED -j ACCEPT; ## règles pour contrôler les services ici ## iptables -P OUTPUT ACCEPT; iptables -P INPUT DROP; iptables -P FORWARD DROP;

— Tom

Le port TCP est probablement bloqué par un autre pare-feu. Utilisez tcpdump / Wireshark pour déboguer le problème.

De moi:

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
source

Lorsque j'arrête iptables, le port s'ouvre.

— Tom