10 votes

iptables n'autorise pas les connexions mysql vers des ips aliasés ?

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 un tcpdump -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 !

8voto

jammus Points 1796

Les hôtes du client .184 ou .196 ont-ils également des adresses IP supplémentaires dans l'autre sous-réseau ?

Si vous faites un tcpdump -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 ? Il s'agit probablement d'un simple problème de routage.

Lorsqu'un système prend une décision concernant un itinéraire, il consulte la table des itinéraires. Les tables de routage sont une liste qui est toujours consultée dans un ordre spécifique. Les routes de liaison pour les réseaux locaux sont presque toujours les routes les plus préférées, et seront utilisées avant une route qui utilise une passerelle (routeur). La passerelle par défaut est toujours la route qui est utilisée lorsqu'aucune autre route ne s'applique. Si une route donnée a une src définie, alors cette adresse sera préférée et très probablement utilisée lorsque cette route sera utilisée.

10.2.13.0/24 dev eth1  proto kernel  scope link  src 10.2.13.1 
10.2.4.0/23 dev eth0  proto kernel  scope link  src 10.2.4.245 
default via 10.2.4.1 dev eth0 

Ainsi, dans cet exemple de table de routage pour un système multi-homed, tout ce qui est destiné à 10.2.13.0/24 viendra de 10.2.13.1 et tout ce qui est destiné à 10.2.4.0/23 viendra de 10.2.4.245 .

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X