J'ai un pare-feu iptables assez simple sur un serveur qui fournit des services MySQL, mais iptables semble me donner des résultats très incohérents.
La politique par défaut sur le script est la suivante :
iptables -P INPUT DROP
Je peux ensuite rendre MySQL public avec la règle suivante :
iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
Avec cette règle en place, je peux me connecter à MySQL depuis n'importe quelle IP source vers n'importe quelle IP de destination sur le serveur sans problème. Cependant, lorsque j'essaie de restreindre l'accès à seulement trois IP en remplaçant la ligne ci-dessus par la suivante, je rencontre des problèmes (xxx=octect masqué) :
iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.XXX.XXX.184 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.XXX.XXX.196 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.XXX.XXX.251 -j ACCEPT
Une fois que les règles ci-dessus sont en place, il se passe ce qui suit :
-
I peut Je me connecte au serveur MySQL à partir des hôtes .184, .196 et .251 sans problème, tant que je me connecte au serveur MySQL en utilisant son adresse IP par défaut. ou un alias IP dans le même sous-réseau que l'adresse IP par défaut.
-
Je suis incapable pour me connecter à MySQL en utilisant des alias IP qui sont attribués au serveur à partir d'un sous-réseau différent de l'IP par défaut du serveur lorsque je viens des hôtes .184 ou .196, mais le .251 fonctionne parfaitement. Depuis les hôtes .184 ou .196, une tentative de connexion telnet se bloque...
# telnet 209.xxx.xxx.22 3306 Trying 209.xxx.xxx.22...
-
Si je supprime la ligne .251 (faisant de .196 la dernière règle ajoutée), l'hôte .196 ne peut toujours pas se connecter à MySQL en utilisant des alias IP (ce n'est donc pas l'ordre des règles qui est à l'origine du comportement incohérent). Je sais, ce test particulier était stupide car l'ordre dans lequel ces trois règles sont ajoutées ne devrait pas avoir d'importance, mais j'ai pensé que quelqu'un pourrait demander.
-
Si je reviens à la règle "public", tous les hôtes peuvent se connecter au serveur MySQL en utilisant les IP par défaut ou alias (dans l'un ou l'autre sous-réseau) :
iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
Le serveur fonctionne dans un conteneur CentOS 5.4 OpenVZ/Proxmox (2.6.32-4-pve).
Et, juste au cas où vous préférez voir les règles problématiques dans le contexte du script d'iptables, le voici (xxx=octect masqué) :
# Flush old rules, old custom tables
/sbin/iptables --flush
/sbin/iptables --delete-chain
# Set default policies for all three default chains
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT
# Enable free use of loopback interfaces
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
# All TCP sessions should begin with SYN
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
# Accept inbound TCP packets (Do this *before* adding the 'blocked' chain)
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow the server's own IP to connect to itself
/sbin/iptables -A INPUT -i eth0 -s 208.xxx.xxx.178 -j ACCEPT
# Add the 'blocked' chain *after* we've accepted established/related connections
# so we remain efficient and only evaluate new/inbound connections
/sbin/iptables -N BLOCKED
/sbin/iptables -A INPUT -j BLOCKED
# Accept inbound ICMP messages
/sbin/iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT
/sbin/iptables -A INPUT -p ICMP --icmp-type 11 -j ACCEPT
# ssh (private)
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -s xxx.xxx.xxx.xxx -j ACCEPT
# ftp (private)
/sbin/iptables -A INPUT -p tcp --dport 21 -m state --state NEW -s xxx.xxx.xxx.xxx -j ACCEPT
# www (public)
/sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# smtp (public)
/sbin/iptables -A INPUT -p tcp --dport 25 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 2525 -j ACCEPT
# pop (public)
/sbin/iptables -A INPUT -p tcp --dport 110 -j ACCEPT
# mysql (private)
/sbin/iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.xxx.xxx.184 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.xxx.xxx.196 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.xxx.xxx.251 -j ACCEPT
Des idées ? Merci d'avance :-)
1 votes
Est-ce que le
.184 or .196 hosts
Les hôtes du client ont également des adresses IP supplémentaires dans l'autre sous-réseau ? Si vous faites untcpdump -qn port 3306
et essayez de vous connecter à partir d'un de ces systèmes, qu'est-ce que vous voyez ? Voyez-vous l'adresse source que vous attendez ?1 votes
Merci, Zordache ! Cela a résolu le problème. L'hôte .251 n'avait pas d'IP attribuée depuis l'autre sous-réseau. Les deux autres hôtes en ont (.184 et .196), et donc lorsqu'ils se connectent à une IP sur l'autre sous-réseau, l'IP source sur ces hôtes passe à une IP dans le même sous-réseau. J'avais pensé que l'IP sortante/source serait toujours celle attribuée par défaut. Mais, tcpdump montre clairement que l'IP source passe au sous-réseau 209.xxx.xxx.xxx chaque fois qu'elle se connecte à une IP dans ce même sous-réseau. (J'ai dû exécuter tcpdump à partir de l'hôte physique de Proxmox, cependant.) Vous êtes un génie. Merci !