Combat avec Iptables sous Debian
Fermé
Starnight
-
Modifié par Starnight le 5/12/2011 à 21:51
Starnight-P Messages postés 5 Date d'inscription lundi 5 décembre 2011 Statut Membre Dernière intervention 9 décembre 2011 - 9 déc. 2011 à 17:07
Starnight-P Messages postés 5 Date d'inscription lundi 5 décembre 2011 Statut Membre Dernière intervention 9 décembre 2011 - 9 déc. 2011 à 17:07
A voir également:
- Combat avec Iptables sous Debian
- Modern combat 4 - Télécharger - Jeux vidéo
- Combat naruto pain episode netflix ✓ - Forum Cinéma / Télé
- Mettre debian en français ✓ - Forum Linux / Unix
- Miroir de l'archive debian corrompu - Forum Debian
- Fedora ou debian - Guide
4 réponses
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
6 déc. 2011 à 19:57
6 déc. 2011 à 19:57
Personnellement je ne suis vraiment pas fan de webmin, car il a tendance à mettre les vrais problèmes sous le tapis, mais bon :-)
après enregistrement des règles, un Iptable -v me liste correctement ces dernières
Ce ne serait pas plutôt :
Je pense avoir oublié une règles, c'est sûr, mais après mainte et mainte lecture, elle ressort pas, de ce fait je fait appel à vos idées.
Ci-dessous je te mets la démarche complète même si à mon avis le problème vient de (4).
1) Vérifier que mysql tourne et écoute le trafic réseau
En tout cas dans un premier temps je t'invite à vérifier côté serveur que le démon mysql tourne et qu'il écoute sur le port que tu crois :
A priori un serveur mysql n'écoute que du trafic local à la machine, donc sa bind-address devrait être 127.0.0.1, tu devrais donc voir dans la ligne correspondante "127.0.0.1:3306".
Si ce serveur est sensé écouter du trafic extérieur (par exemple venant d'un serveur apache installé sur une autre machine), alors cet bind-adress sera probablement 0.0.0.0. Celle-ci est configurée dans /etc/mysql/my.cnf (voir bind-address). Attention à penser à relancer mysql si tu modifies ce fichier pour que les changements soient pris en compte :
2) Vérifier que le compte du client mysql est correct
Côté mysql tu devras donc créer un profil mysql pour cette IP distante (par exemple 'toto'@'11.22.33.44' ou 'toto'@'mon.client.com'. Note que tu peux utiliser la wildcard '%'.
http://dev.mysql.com/doc/refman/5.0/fr/create-user.html
Dans l'idée, mysql examine dans la table mysql.user chaque profil enregistré et prend le plus spécifique. Tu peux donc restreindre l'utilisation d'un login à une plage d'adresses IP (clientes) ou de hostnames (clients).
En bref il faut vérifier que ton utilisateur client est valide pour les IP autorisées par mysql. Ainsi, si ce client se loggue en toto depuis l'IP 11.22.33.44 tu dois avoir a priori un profil 'toto'@'%', 'toto'@'11.22.33.44' ou '%'@'11.22.33.44' présent dans cette base.
https://dev.mysql.com/doc/refman/8.0/en/adding-users.html
https://dev.mysql.com/doc/refman/8.0/en/connection-access.html
3) Vérifier côté client que le port mysql est visible
Ici on part du principe que le client mysql et le serveur mysql sont deux machines différentes, et donc soumis au problème de bind-address (voir (1)) et/ou d'iptables. Dans un premier temps désactive les iptables côté serveur pour voir si ce sont bien elles qui sont en cause. Puis lance depuis le client (en admettant que l'IP du serveur soit 44.55.66.77, le login toto, le port 3306) :
Si tu arrives à te connecter les points (1,2) sont hors de cause. Réactive les iptables, quitte ta session cliente (ctrl d), puis relance-là. Si ce sont bien les iptables qui posent problème.
Si ça échoue, installe nmap et vérifie si le port mysql du serveur est visible. Par exemple pour installer nmap (sous debian) :
Ensuite on scanne le serveur :
Normalement le port 3306 devrait être visible. Si ce n'est pas le cas, ça peut arriver que nmap ne le voit pas même si le port est réellement ouvert, mais c'est généralement mauvais signe.
Dans ce cas, vérifie qu'un proxy ou un pare-feu ne bloque pas la connexion. Ça peut concerner n'importe quelle machine entre le client et le serveur (les intermédiaires, le client et le serveur). La vérification de ce point pour le serveur est décrite dans le point (4).
4) Vérifier les iptables
Toujours en admettant que le client mysql soit sur une machine distincte du serveur, iptables devrait autoriser les connexions sur le port mysql (3306 par défaut, voir /etc/mysql/my.cnf côté serveur). Sous ces hypothèses il manque donc une règle pour accepter le trafic sur ce port.
Bonne chance
après enregistrement des règles, un Iptable -v me liste correctement ces dernières
Ce ne serait pas plutôt :
iptables -L
Je pense avoir oublié une règles, c'est sûr, mais après mainte et mainte lecture, elle ressort pas, de ce fait je fait appel à vos idées.
Ci-dessous je te mets la démarche complète même si à mon avis le problème vient de (4).
1) Vérifier que mysql tourne et écoute le trafic réseau
En tout cas dans un premier temps je t'invite à vérifier côté serveur que le démon mysql tourne et qu'il écoute sur le port que tu crois :
netstat -ntlp
A priori un serveur mysql n'écoute que du trafic local à la machine, donc sa bind-address devrait être 127.0.0.1, tu devrais donc voir dans la ligne correspondante "127.0.0.1:3306".
Si ce serveur est sensé écouter du trafic extérieur (par exemple venant d'un serveur apache installé sur une autre machine), alors cet bind-adress sera probablement 0.0.0.0. Celle-ci est configurée dans /etc/mysql/my.cnf (voir bind-address). Attention à penser à relancer mysql si tu modifies ce fichier pour que les changements soient pris en compte :
service mysql restart
2) Vérifier que le compte du client mysql est correct
Côté mysql tu devras donc créer un profil mysql pour cette IP distante (par exemple 'toto'@'11.22.33.44' ou 'toto'@'mon.client.com'. Note que tu peux utiliser la wildcard '%'.
http://dev.mysql.com/doc/refman/5.0/fr/create-user.html
Dans l'idée, mysql examine dans la table mysql.user chaque profil enregistré et prend le plus spécifique. Tu peux donc restreindre l'utilisation d'un login à une plage d'adresses IP (clientes) ou de hostnames (clients).
mysql -u root -p -e "select user, host, password from mysql.user"
En bref il faut vérifier que ton utilisateur client est valide pour les IP autorisées par mysql. Ainsi, si ce client se loggue en toto depuis l'IP 11.22.33.44 tu dois avoir a priori un profil 'toto'@'%', 'toto'@'11.22.33.44' ou '%'@'11.22.33.44' présent dans cette base.
https://dev.mysql.com/doc/refman/8.0/en/adding-users.html
https://dev.mysql.com/doc/refman/8.0/en/connection-access.html
3) Vérifier côté client que le port mysql est visible
Ici on part du principe que le client mysql et le serveur mysql sont deux machines différentes, et donc soumis au problème de bind-address (voir (1)) et/ou d'iptables. Dans un premier temps désactive les iptables côté serveur pour voir si ce sont bien elles qui sont en cause. Puis lance depuis le client (en admettant que l'IP du serveur soit 44.55.66.77, le login toto, le port 3306) :
mysql -u toto -h 44.55.66.77 -p -P 3306
Si tu arrives à te connecter les points (1,2) sont hors de cause. Réactive les iptables, quitte ta session cliente (ctrl d), puis relance-là. Si ce sont bien les iptables qui posent problème.
Si ça échoue, installe nmap et vérifie si le port mysql du serveur est visible. Par exemple pour installer nmap (sous debian) :
aptitude update aptitude safe-upgrade aptitude install nmap
Ensuite on scanne le serveur :
nmap -P0 44.55.66.77
Normalement le port 3306 devrait être visible. Si ce n'est pas le cas, ça peut arriver que nmap ne le voit pas même si le port est réellement ouvert, mais c'est généralement mauvais signe.
Dans ce cas, vérifie qu'un proxy ou un pare-feu ne bloque pas la connexion. Ça peut concerner n'importe quelle machine entre le client et le serveur (les intermédiaires, le client et le serveur). La vérification de ce point pour le serveur est décrite dans le point (4).
4) Vérifier les iptables
Toujours en admettant que le client mysql soit sur une machine distincte du serveur, iptables devrait autoriser les connexions sur le port mysql (3306 par défaut, voir /etc/mysql/my.cnf côté serveur). Sous ces hypothèses il manque donc une règle pour accepter le trafic sur ce port.
-A INPUT -p tcp --dport 3306 -j ACCEPT
Bonne chance
Starnight-P
Messages postés
5
Date d'inscription
lundi 5 décembre 2011
Statut
Membre
Dernière intervention
9 décembre 2011
6 déc. 2011 à 21:10
6 déc. 2011 à 21:10
Effectivement c'est bien :
iptables -L
Le client MySql ce trouve sur le mm serveur, de ce fait ouvrir le port 3306 n'est pas obligatoire à mon avis
1) Vérifier que mysql tourne et écoute le trafic réseau
Tout fonctionne parfaitement si IpTables n'est pas activé tel que dit lors de mon 1er post <<Après l'activation au démarrage d'Iptables (activation : oui sur la page Firewall Linux sous WebAdmin) et après seulement un reboot, l'accès à ma base de donnée MySql est cassé
log Daemon : ... connect to server at 'localhost' failed >>
de ce fait, les paragraphes 2 et 3 sont correct
Je suis sûr qu'une règle est manquante, mais après tout les lecture de divers forum, wiki et autre, je n'ai rien trouvé qui correspondait à mon cas
A) mais ce qui me chagrine c'est ceci:
par quel moyen un appel sur Localhost est véhiculé quand c'est la mm machine qui appelle, lo ou eth0 ?
Via ETH0 cela m'étonnerai bcp
lo ?
Là j'avoue que j'ai qq lacune sur le chemin.
a- Venant de l'extérieur ( réseau privé ou internet) c'est via la connexion ETH0, ça ok c'est évident
b- Venant de la propre machine ( serveur web vers MySql via localhost) par ou cela transite !!!!
si c'est lo : cette règle accepte tout de localhost : -A INPUT -d 127.0.0.1 -i lo -j ACCEPT
si c'est ailleur !!! j'ai testé ceci sans succès : -A INPUT -d 127.0.0.1 -j ACCEPT
merci
iptables -L
Le client MySql ce trouve sur le mm serveur, de ce fait ouvrir le port 3306 n'est pas obligatoire à mon avis
1) Vérifier que mysql tourne et écoute le trafic réseau
Tout fonctionne parfaitement si IpTables n'est pas activé tel que dit lors de mon 1er post <<Après l'activation au démarrage d'Iptables (activation : oui sur la page Firewall Linux sous WebAdmin) et après seulement un reboot, l'accès à ma base de donnée MySql est cassé
log Daemon : ... connect to server at 'localhost' failed >>
de ce fait, les paragraphes 2 et 3 sont correct
Je suis sûr qu'une règle est manquante, mais après tout les lecture de divers forum, wiki et autre, je n'ai rien trouvé qui correspondait à mon cas
A) mais ce qui me chagrine c'est ceci:
par quel moyen un appel sur Localhost est véhiculé quand c'est la mm machine qui appelle, lo ou eth0 ?
Via ETH0 cela m'étonnerai bcp
lo ?
Là j'avoue que j'ai qq lacune sur le chemin.
a- Venant de l'extérieur ( réseau privé ou internet) c'est via la connexion ETH0, ça ok c'est évident
b- Venant de la propre machine ( serveur web vers MySql via localhost) par ou cela transite !!!!
si c'est lo : cette règle accepte tout de localhost : -A INPUT -d 127.0.0.1 -i lo -j ACCEPT
si c'est ailleur !!! j'ai testé ceci sans succès : -A INPUT -d 127.0.0.1 -j ACCEPT
merci
Bonjour,
Tu peux déjà essayer le 4 de Mamiemando, juste pour voir si c'est bien iptables qui bloque ou pas. Mais en production je te déconseille de laisser le port MySQL ouvert s'il n'a besoin d'être accédé que depuis ton serveur.
Je suis aussi perplexe que toi car ces règles sont censées accepter tout le trafic local (si l'IP de ton serveur est bien 192.168.1.2). Et d'ailleurs la 2e est superflue puisque c'est juste un cas particulier de la première :
Normalement, la façon dont ton code PHP va se connecter à MySQL dépend du code source de la page :
1) Si tu précises 127.0.0.1, il va se connecter via lo ;
2) Si tu précises 192.168.1.2, il va se connecter via eth0 ;
3) Si tu précises localhost, je crois qu'il va se connecter via le socket Unix de MySQL. Ca peut valoir le coup de vérifier qu'il est bien configuré dans le php.ini.
Vérifie aussi les GRANT de ta base car les utilisateurs sous MySQL sont identifiés avec leur host (ou adresse IP) d'origine. Par exemple : user@127.0.0.1
Tu peux déjà essayer le 4 de Mamiemando, juste pour voir si c'est bien iptables qui bloque ou pas. Mais en production je te déconseille de laisser le port MySQL ouvert s'il n'a besoin d'être accédé que depuis ton serveur.
Je suis aussi perplexe que toi car ces règles sont censées accepter tout le trafic local (si l'IP de ton serveur est bien 192.168.1.2). Et d'ailleurs la 2e est superflue puisque c'est juste un cas particulier de la première :
-A INPUT -i lo -j ACCEPT -A INPUT -d 127.0.0.1 -i lo -j ACCEPT -A INPUT -s 192.168.1.2/24 -j ACCEPT
Normalement, la façon dont ton code PHP va se connecter à MySQL dépend du code source de la page :
1) Si tu précises 127.0.0.1, il va se connecter via lo ;
2) Si tu précises 192.168.1.2, il va se connecter via eth0 ;
3) Si tu précises localhost, je crois qu'il va se connecter via le socket Unix de MySQL. Ca peut valoir le coup de vérifier qu'il est bien configuré dans le php.ini.
Vérifie aussi les GRANT de ta base car les utilisateurs sous MySQL sont identifiés avec leur host (ou adresse IP) d'origine. Par exemple : user@127.0.0.1
Starnight-P
Messages postés
5
Date d'inscription
lundi 5 décembre 2011
Statut
Membre
Dernière intervention
9 décembre 2011
7 déc. 2011 à 21:04
7 déc. 2011 à 21:04
Merci gm pour ton aide
J'avais évidement fait le test, mais rien n'y change ://
et effectivement le serveur étant en production, le port 3306 est fermé de l'extérieur
apres mainte et mainte test afin d'essayer de comprendre ....
car même si tout est accepté INPUT, OUTPUT, FOWARD .... cela buge
Et bien il semblerait que ce ne soit pas iptable qui bloque mais simplement le fait de l'activer au démarrage quelque chose fait que .. crac boumm
named: (couldn't add command channel 127.0.0.1#953: address not available)
mysql : (connect to server at 'localhost' failed)
gdm-simple-greeter : WARNING: Failed to send buffer
a ce moment là, un iptables -L donne :
:FORWARD ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
toute les règles ne sont plus listé, mais tjrs présente dans le fichier de conf (/etc/iptables.up.rules).
notons bien que c'est uniquement quand je reboot le serveur après avoir activé iptable au démarrage (activation = oui -> sur la page Firewall Linux sous WebAdmin)
et quand je désactive iptable au demarrage :(activation = non -> sur la page Firewall Linux sous WebAdmin)
named : any newly configured zones are now loaded
mysql : ready for connections
gdm-simple-greeter : widget not within a GtkWindow ceci est une petite info de config, mais pas d'erreur
a ce moment là, un iptables -L donne tjrs :
:FORWARD ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
et là, tout est ok, les sites accède bien à mysql, phpmyadmin fonctionne, tout vas bien dans le meilleur des mondes ^^
J'essaie de vous lister la totalité des log de redémarrage et je reviens ( pas évident de trouver le début et la fin dans le fichier daemon.log) à moins que vous ayez une idée ^^
J'avais évidement fait le test, mais rien n'y change ://
et effectivement le serveur étant en production, le port 3306 est fermé de l'extérieur
apres mainte et mainte test afin d'essayer de comprendre ....
car même si tout est accepté INPUT, OUTPUT, FOWARD .... cela buge
Et bien il semblerait que ce ne soit pas iptable qui bloque mais simplement le fait de l'activer au démarrage quelque chose fait que .. crac boumm
named: (couldn't add command channel 127.0.0.1#953: address not available)
mysql : (connect to server at 'localhost' failed)
gdm-simple-greeter : WARNING: Failed to send buffer
a ce moment là, un iptables -L donne :
:FORWARD ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
toute les règles ne sont plus listé, mais tjrs présente dans le fichier de conf (/etc/iptables.up.rules).
notons bien que c'est uniquement quand je reboot le serveur après avoir activé iptable au démarrage (activation = oui -> sur la page Firewall Linux sous WebAdmin)
et quand je désactive iptable au demarrage :(activation = non -> sur la page Firewall Linux sous WebAdmin)
named : any newly configured zones are now loaded
mysql : ready for connections
gdm-simple-greeter : widget not within a GtkWindow ceci est une petite info de config, mais pas d'erreur
a ce moment là, un iptables -L donne tjrs :
:FORWARD ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
et là, tout est ok, les sites accède bien à mysql, phpmyadmin fonctionne, tout vas bien dans le meilleur des mondes ^^
J'essaie de vous lister la totalité des log de redémarrage et je reviens ( pas évident de trouver le début et la fin dans le fichier daemon.log) à moins que vous ayez une idée ^^
Ca me donne l'impression qu'iptables est chargé avec un profil droppant tout, puis ton serveur lance ses démons (qui se voient alors refuser des connexions), puis charge seulement alors la config de ton fichier de conf.
Malheureusement je ne sais pas comment Debian est censé charger la config iptables...
Ou alors ton service network est lancé bien trop tard, ce qui serait bizarre.
Malheureusement je ne sais pas comment Debian est censé charger la config iptables...
Ou alors ton service network est lancé bien trop tard, ce qui serait bizarre.
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
Modifié par mamiemando le 8/12/2011 à 23:43
Modifié par mamiemando le 8/12/2011 à 23:43
L'hypothèse de gm est crédible, il faudrait voir ce que donne "iptables -L" quand tu redémarres. Il y a forcément une règle qui jette le trafic qui t'intéresse (vérifie également que les autres points dont j'ai parlé restent juste, en outre que ton serveur est lancé et écoute correctement).
Bonne chance
Bonne chance
Starnight-P
Messages postés
5
Date d'inscription
lundi 5 décembre 2011
Statut
Membre
Dernière intervention
9 décembre 2011
9 déc. 2011 à 06:25
9 déc. 2011 à 06:25
Je fait les tests ce week end, car mon temps m'est compté actuellement
Une idée pour récupérer que les log d'un reboot? ( pas évident de trouver le début et la fin dans le fichier daemon.log
Merci
Une idée pour récupérer que les log d'un reboot? ( pas évident de trouver le début et la fin dans le fichier daemon.log
Merci
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
9 déc. 2011 à 08:39
9 déc. 2011 à 08:39
Bah je ne comprends pas ce qui est compliqué dans daemon.log, on t'indique à chaque fois la date et le démon concerné... Par exemple si c'est le démon named
Sur le même principe, tu peux retrouver la date de reboot ou d'un arrêt avec /var/log/message :
Bonne chance
grep named /var/log/messages
Sur le même principe, tu peux retrouver la date de reboot ou d'un arrêt avec /var/log/message :
grep shutdown /var/log/messages
Bonne chance
Starnight-P
Messages postés
5
Date d'inscription
lundi 5 décembre 2011
Statut
Membre
Dernière intervention
9 décembre 2011
9 déc. 2011 à 17:07
9 déc. 2011 à 17:07
c'est vrai, c'est pas compliqué, mais le fait de faire un restart, les secondes se suivent et de ce fait le point de restart n'est pas évident à trouver, et je pensai qu'il y avait une commande pour lister uniquement les log du restart et aussi je doit avouer un poil de fainéantise de ma part ;)
Dans tout les cas, depuis mes péripéties je n'avais pas eu l'occasion d'être sûr du bon fonctionnement des règles et d'iptables, pas de log de rejet.
Aujourd'hui, enfin (je ne vais pas non plus les attirer ^^ ) , c'est fait, plusieurs IP ont été rejeté, donc cela me confirme que mes règles sont bonne, et surtout qu'Iptables fonctionne,
Hacker ...IN=eth0 OUT= MAC=00:11:d8:a9:e0:c2:00:1d:68:32:63:3a:08:00 SRC=58.218.199.227 DST=192.168.1.210 ......
Reste plus qu'a voir ce pb de démarrage
Comme dit pans mon précédent post, je fait vos test ce week end, et vous dirai tout évidement
pour répondre à mamiemando du 8 déc. 2011 à 23:43
L'hypothèse de gm est crédible, il faudrait voir ce que donne "iptables -L" quand tu redémarres
j'ai noté dans mon post du 7 déc. 2011 à 21:04
l'activer au démarrage quelque chose fait que
...........
a ce moment là, un iptables -L donne :
:FORWARD ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
Merci pour vos aides
Starnight
Dans tout les cas, depuis mes péripéties je n'avais pas eu l'occasion d'être sûr du bon fonctionnement des règles et d'iptables, pas de log de rejet.
Aujourd'hui, enfin (je ne vais pas non plus les attirer ^^ ) , c'est fait, plusieurs IP ont été rejeté, donc cela me confirme que mes règles sont bonne, et surtout qu'Iptables fonctionne,
Hacker ...IN=eth0 OUT= MAC=00:11:d8:a9:e0:c2:00:1d:68:32:63:3a:08:00 SRC=58.218.199.227 DST=192.168.1.210 ......
Reste plus qu'a voir ce pb de démarrage
Comme dit pans mon précédent post, je fait vos test ce week end, et vous dirai tout évidement
pour répondre à mamiemando du 8 déc. 2011 à 23:43
L'hypothèse de gm est crédible, il faudrait voir ce que donne "iptables -L" quand tu redémarres
j'ai noté dans mon post du 7 déc. 2011 à 21:04
l'activer au démarrage quelque chose fait que
...........
a ce moment là, un iptables -L donne :
:FORWARD ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
Merci pour vos aides
Starnight
