Problème iptables et Prosody

Bonjour à tous,

Je cherche à instaurer un script d’init (/etc/init.d) pour ajouter des règles iptables sur mon système.

J’ai commencé par tout interdire puis j’ouvre un par un les ports qui me sont utiles. Je bloque sur les ports utilisés par le serveur jabber Prosody.

Mon script ressemble pour le moment à ceci :

[code]#!/bin/bash

case $1 in

‘start’)
#########
# INPUT #
#########

# Tout est rejette par defaut
iptables -P INPUT DROP

# On accepte le trafic local
iptables -A INPUT -i lo -j ACCEPT

# Les paquets SSH sont acceptes en entree
iptables -A INPUT -p tcp -i eth0 --dport ssh -j ACCEPT

# On autorise HTTP et HTTPS
iptables -A INPUT -p tcp -i eth0 --dport http -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport https -j ACCEPT

# On autorise SMTP et IMAPS
iptables -A INPUT -p tcp -i eth0 --dport smtp -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport imaps -j ACCEPT

# On permet l'acces aux services Jabber
iptables -A INPUT -p tcp -i eth0 --dport xmpp-client -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport 5223 -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport 5280 -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport 5582 -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport xmpp-server -j ACCEPT
iptables -A INPUT -p udp -i eth0 --dport xmpp-client -j ACCEPT
iptables -A INPUT -p udp -i eth0 --dport 5223 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --dport 5280 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --dport 5582 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --dport xmpp-server -j ACCEPT
;;

‘stop’)
iptables -F
#iptables -X
iptables -P INPUT ACCEPT
;;

*)
echo “Utilisation : /etc/init.d/firewall {start|stop}”
;;

esac

[/code]

Vous pouvez voir que je bricole un peu dans la rubrique Jabber… Mes tests ne sont pas concluants : je peux me connecter à mon serveur jabber et voir mes contacts mais je ne peux pas me connecter à un salon.

Si je suis déjà connecté à un salon lorsque j’applique ces règles, alors poster un message supplémentaire ne sera effectif qu’après avoir coupé mon firewall (l’option stop débloque mes messages qui sont envoyés sur le salon).

Pour conclure : j’ai du mal à décider des ports que je dois ouvrir et je ne sais pas comment les toruver : j’ai tenté d’afficher les ports utilisés dans iftop ou encore de regarder un peu partout dans la configuration de Prosody mais sans succès.

Merci pour votre aide !

bonjour,

un netstat -lapute te donne quoi?

Bonjour darham et merci pour ton aide,

Voilà le retour de la commande que tu me conseilles :

Connexions Internet actives (serveurs et établies) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat User Inode PID/Program name tcp 0 0 *:xmpp-client *:* LISTEN prosody 6223 2508/lua tcp 0 0 *:34064 *:* LISTEN root 5724 - tcp 0 0 *:xmpp-server *:* LISTEN prosody 6225 2508/lua tcp 0 0 localhost:6010 *:* LISTEN phil 540768 29701/0 tcp 0 0 192.168.2.1:xmpp-server hermes.jabber.org:46903 ESTABLISHED prosody 110560 2508/lua tcp 0 0 192.168.2.1:57829 apijab4.api:xmpp-server ESTABLISHED prosody 384820 2508/lua tcp 0 0 192.168.2.1:xmpp-server agama.yandex.net:54180 ESTABLISHED prosody 166946 2508/lua tcp 0 0 192.168.2.1:xmpp-server hermes.jabber.org:46912 ESTABLISHED prosody 110566 2508/lua tcp 0 0 192.168.2.1:xmpp-server px-out-f129.1e100:55090 ESTABLISHED prosody 161333 2508/lua tcp 0 0 192.168.2.1:50709 ezvan.fr:xmpp-server ESTABLISHED prosody 435278 2508/lua tcp 0 0 192.168.2.1:xmpp-server apijab1.apinc.org:58880 ESTABLISHED prosody 166944 2508/lua tcp 0 0 192.168.2.1:xmpp-server px-out-f129.1e100:64225 ESTABLISHED prosody 97044 2508/lua tcp 0 0 192.168.2.1:41466 apijab3.api:xmpp-server ESTABLISHED prosody 435504 2508/lua tcp 0 0 192.168.2.1:xmpp-server px-out-f129.1e100:11892 ESTABLISHED prosody 166778 2508/lua tcp 0 0 192.168.2.1:55712 el-in-f125.:xmpp-server ESTABLISHED prosody 523099 2508/lua tcp 0 0 192.168.2.1:54039 el-in-f125.:xmpp-server ESTABLISHED prosody 511372 2508/lua tcp 0 0 192.168.2.1:xmpp-server apijab1.apinc.org:39668 ESTABLISHED prosody 166943 2508/lua tcp 0 0 192.168.2.1:xmpp-server hermes.jabber.org:48121 ESTABLISHED prosody 379426 2508/lua tcp 0 0 192.168.2.1:44875 panoramix.l:xmpp-server ESTABLISHED prosody 434850 2508/lua tcp 0 0 192.168.2.1:xmpp-server px-out-f129.1e100.:7860 ESTABLISHED prosody 523000 2508/lua tcp 0 0 192.168.2.1:xmpp-server apijab1.apinc.org:44039 ESTABLISHED prosody 160624 2508/lua tcp 0 0 192.168.2.1:xmpp-server nezmar.jabbim.cz:57514 ESTABLISHED prosody 166945 2508/lua tcp6 0 0 localhost:6010 [::]:* LISTEN phil 540767 29701/0 tcp6 0 0 192.168.2.1%64699:https 2.168.20-93.rev.g:12186 TIME_WAIT root 0 - udp 0 0 *:57177 *:* root 5717 - udp 0 0 192.168.2.1:56540 dns2.proxad.net:domain ESTABLISHED prosody 167237 2508/lua

Effectivement, on y voit plus clair : dois-je comprendre que mon serveur prosody reçois des messages des autres serveurs Jabber via des ports aléatoirement choisis ?

Merci encore,
Philippe.

PS : j’ai un peu dégraissé le retour de netstat.

tu n’autorise que les entrées pour jabber dans tes regles iptables.

exemple avec cette regle

essaye en rajoutant à chaque fois

J’imagine que tu voulais parler de la chaîne OUTPUT plutôt non ?

J’ai ajouté quelques règles pour tester et en tout, j’en suis à ça :

iptables -A INPUT -p tcp -i eth0 --dport xmpp-client -j ACCEPT iptables -A INPUT -p tcp -i eth0 --dport 5223 -j ACCEPT iptables -A INPUT -p tcp -i eth0 --dport 5280 -j ACCEPT iptables -A INPUT -p tcp -i eth0 --dport 5582 -j ACCEPT iptables -A INPUT -p tcp -i eth0 --dport xmpp-server -j ACCEPT iptables -A INPUT -p udp -i eth0 --dport xmpp-client -j ACCEPT iptables -A INPUT -p udp -i eth0 --dport 5223 -j ACCEPT iptables -A INPUT -p udp -i eth0 --dport 5280 -j ACCEPT iptables -A INPUT -p udp -i eth0 --dport 5582 -j ACCEPT iptables -A INPUT -p udp -i eth0 --dport xmpp-server -j ACCEPT iptables -A OUTPUT -p tcp -o eth0 --sport xmpp-client -j ACCEPT iptables -A OUTPUT -p tcp -o eth0 --sport 5223 -j ACCEPT iptables -A OUTPUT -p tcp -o eth0 --sport 5280 -j ACCEPT iptables -A OUTPUT -p tcp -o eth0 --sport 5582 -j ACCEPT iptables -A OUTPUT -p tcp -o eth0 --sport xmpp-server -j ACCEPT iptables -A OUTPUT -p udp -o eth0 --sport xmpp-client -j ACCEPT iptables -A OUTPUT -p udp -o eth0 --sport 5223 -j ACCEPT iptables -A OUTPUT -p udp -o eth0 --sport 5280 -j ACCEPT iptables -A OUTPUT -p udp -o eth0 --sport 5582 -j ACCEPT iptables -A OUTPUT -p udp -o eth0 --sport xmpp-server -j ACCEPT

Cela ne marche toujours pas :S

Merci pour ton aide !
Philippe.

lol oui j’ai fait un copié collé au taf donc j’ai du faire assez vite. Je regarde dès que je peux pour t’aider.

D’accord :slightly_smiling: Merci beaucoup !

Up ?

Encore un up peut-être ? Je suis vraiment ennuyé de ne pas trouver de solution.

Salut
Je vais essayer de te donner quelques pistes, mais je débute en configuration de pare-feu, il faudra donc être indulgent :laughing:

Je comprends pas trop pourquoi tu as mis des règles sur les ports 5223 et 5582 ?
En effet, apparemment les ports principaux à ouvrir :
* 5222 (TCP & UDP) → communications client/serveur
* 5269 (TCP & UDP) → communications serveur/serveur
* 5280 (TCP & UDP) → communications http/serveur

Sauf erreur de ma part, (je ne connais pas bien jabber, pas du tout même, mais la remarque restera vrai dans la plupart des connexions client/serveur) dans ton premier script, tu as autorisé plein de trafic entrant, mais tu ne traites pas le trafic sortant qui peut être engendré par les réponses aux requêtes entrantes. En gros, il se peut que les requêtes arrivent bien sur ton serveur (règles INPUT OK, mais que ce dernier ne puisse pas y répondre car les OUTPUT sont DROP). Donc :

  • Les paquets de la chaîne OUTPUT, qu’en fais tu ?
  • Quel est le comportement par défaut du pare feu puisque tu n’as pas encore fait de règles sur la chaine OUTPUT dans ton script ?

Pour savoir ça, tu devrais, apres avoir lancé ton script, poster un (en root) : iptables -L

sudo /etc/init.d/prosody stop
netstat -ln > netstat-ln-proso.avant
sudo /etc/init.d/prosody start
netstat -ln > netstat-ln-proso.apres
diff netstat-ln-proso.*

Si tu regardes de plus près le netstat, tu vas voir que les ports sources (depuis lesquels les client émettent leur trafic) sont “aléatoires”, mais les ports de destinations sont toujours les mêmes : xmpp-server.
Toi en tant que client, tu te connectes tjs a un serveur distant sur le port xmpp-server, quand aux clients distants, ils se connectent sur le port xmpp-server de ton propre serveur.

Bonjour et merci pour ton aide dric64 !

Je fais des tests parce que je n’arrive à rien :slightly_smiling: En effet j’ai d’abord lu que les ports importants pour Jabber sont les 5222 et 5269.

[code]$ iptables -L
Chain FORWARD (policy ACCEPT)
target prot opt source destination

Rien ici ![/code]

[quote]sudo /etc/init.d/prosody stop
netstat -ln > netstat-ln-proso.avant
sudo /etc/init.d/prosody start
netstat -ln > netstat-ln-proso.apres
diff netstat-ln-proso.*[/quote]

Génial :slightly_smiling: Je n’y aurais pas pensé !

server-bl:/tmp# /etc/init.d/prosody stop Stopping Prosody XMPP Server: prosody. server-bl:/tmp# netstat -ln > /tmp/avant server-bl:/tmp# /etc/init.d/prosody start Starting Prosody XMPP Server: prosody. server-bl:/tmp# netstat -ln > /tmp/apres server-bl:/tmp# diff -u avant apres --- avant 2010-04-09 07:00:30.000000000 +0200 +++ apres 2010-04-09 07:00:49.000000000 +0200 @@ -3,6 +3,7 @@ tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN +tcp 0 0 0.0.0.0:5222 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:56680 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:3690 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN @@ -10,6 +11,7 @@ tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:34064 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:45201 0.0.0.0:* LISTEN +tcp 0 0 0.0.0.0:5269 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:51413 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN

Là je suis embêté, on dirait bien qu’il n’y a que le 5222 et le 5269 :frowning: Ceci dit, le serveur n’est pas vraiment actif… Il reste à rejoindre un salon mais j’ai fais le test, ça n’ouvre pas plus de ports semble-t-il.

[quote]Si tu regardes de plus près le netstat, tu vas voir que les ports sources (depuis lesquels les client émettent leur trafic) sont “aléatoires”, mais les ports de destinations sont toujours les mêmes : xmpp-server.
Toi en tant que client, tu te connectes tjs a un serveur distant sur le port xmpp-server, quand aux clients distants, ils se connectent sur le port xmpp-server de ton propre serveur.[/quote]

Qu’en est-il de la communication entre les serveurs Jabber ? Car j’arrive à me connecter à mon serveur, le problème se situe plutôt au niveau de mon entrée sur un salon de discussion (l’écran reste blanc comme dans un salon vide tant que je ne désactive pas mes règles iptables).

Merci beaucoup pour ton aide, une fois de plus !

D’accord :mrgreen: Bon, étant donné qu’ils n’apparaissent pas dans le netstat, il y a de fortes chances pour que les regles associées ne servent a rien pour ton problème.

Tu as posté le résultat complet de iptables -L ? :open_mouth:
Parce que je ne vois pas de chaine INPUT (qui devrait refléter au moins les règles que tu as écrites dans ton script) ni OUTPUT (dont la chaine + une politique par defaut (drop ou accept) devrait au moins exister, même si elle ne contient aucune règles) dans le résultat. Le FORWARD ici ne nous concerne pas, puisqu’il s’agit du routage de paquets.

C’est plutôt une bonne chose je pense.

[quote]
Qu’en est-il de la communication entre les serveurs Jabber ? Car j’arrive à me connecter à mon serveur, le problème se situe plutôt au niveau de mon entrée sur un salon de discussion (l’écran reste blanc comme dans un salon vide tant que je ne désactive pas mes règles iptables).[/quote]
d’après la doc, la communication serveur/serveur semble utiliser le port 5269 justement. La communication client/serveur le port 5222, et si tu te connecte va http (donc depuis un navigateur je suppose et non depuis un client), le port 5280.
D’autre part, je suppose que tu a un routeur ou une truc-box qui sépare ton LAN de l’Internet, et que donc tu as bien fais toutes les redirections entrantes nécessaires dejà à ce niveau vers les ports jabbers de ton serveur ?

Quel étourdi :slightly_smiling:

Je pensais avoir copié la chaîne OUTPUT justement (j’ai écarté le superflu).

Je fais une version non résumée cette fois :

[code]server-bl:/etc/init.d# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
fail2ban-ssh tcp – anywhere anywhere multiport dports ssh
ACCEPT all – anywhere anywhere
ACCEPT tcp – anywhere anywhere tcp dpt:ssh
ACCEPT tcp – anywhere anywhere tcp dpt:www
ACCEPT tcp – anywhere anywhere tcp dpt:https
ACCEPT tcp – anywhere anywhere tcp dpt:smtp
ACCEPT tcp – anywhere anywhere tcp dpt:imaps
ACCEPT tcp – anywhere anywhere tcp dpt:xmpp-client
ACCEPT tcp – anywhere anywhere tcp dpt:xmpp-server

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all – anywhere anywhere [/code]

(Après avoir fait /etc/init.d/firewall start).

Voici d’ailleurs le script en question en son état actuel :

[code]#!/bin/bash

case $1 in

‘start’)
#########
# INPUT #
#########

# Tout est rejette par defaut
iptables -P INPUT DROP

# On accepte le trafic local
iptables -A INPUT -i lo -j ACCEPT

# Les paquets SSH sont acceptes en entree
iptables -A INPUT -p tcp -i eth0 --dport ssh -j ACCEPT

# On autorise HTTP et HTTPS
iptables -A INPUT -p tcp -i eth0 --dport http -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport https -j ACCEPT

# On autorise SMTP et IMAPS
iptables -A INPUT -p tcp -i eth0 --dport smtp -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport imaps -j ACCEPT

# On permet l'acces aux services Jabber
iptables -A INPUT -p tcp -i eth0 --dport xmpp-client -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport xmpp-server -j ACCEPT
;;

‘stop’)
iptables -F
#iptables -X
iptables -P INPUT ACCEPT
;;

*)
echo “Utilisation : /etc/init.d/firewall {start|stop}”
;;

esac

[/code]

Si je fais “start” et que j’essaie de me connecter à mon serveur, tout se passe bien pour la connexion (je vois mes contacts) mais les salons de discussion Jabber restent vide (pas de connexion).

Ils finissent par se connecter une dizaine de secondes après que je passe le paramètre “stop” à mon script de firewall.

Note : J’ai tenu compte des commentaires précédents pour retirer ces ports farfelus (5223, etc.).

OK. Mais par rapport à la doc, je pense qu’il te manque toutes les règles qui autorisent l’entrée du trafic udp pour jabber :

iptables -A INPUT -p udp -i eth0 --dport xmpp-server -j ACCEPT
iptables -A INPUT -p udp -i eth0 --dport xmpp-client -j ACCEPT

De plus, perso j’ai pour habitude avant de charger de nouvelle règles, de vider toutes celles existantes c’est à dire de rajouter au tout début du script :

iptables -t filter -P INPUT DROP
iptables -t filter -P OUTPUT DROP # * pour celle ci dans ton cas, mettre à ACCEPT
iptables -t filter -P FORWARD DROP

et

iptables -F
iptables -X

Toi, il semble que tu veuilles tout laisser passer en OUTPUT, donc tu peux remplacer la ligne * par :
iptables -t filter -P OUTPUT ACCEPT

Enfin, je rajouterai une dernière règle juste après le groupe de règles "# Tout est rejette par defaut " :

iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Pour accepter les paquets ESTABLISHED et RELATED d’une connexion déjà établie.
Je ne sais pas si elle est vraiment pertinente dans la mesure ou dans aucune des suivantes, on ne tient spécifiquement comptes de l’état NEW… Si PascalHambourg ou Fran.b passaient par là, il sauraient nous dire :mrgreen:

Je vois en plus que tu as des règles fail2ban-ssh, qui ne viennent pas de ton script, mais qui sont ajoutées au démarrage du daemon fail2ban. Donc pour ne pas qu’elles giclent au redémarrage du pare feu (à cause des règles de nettoyage initiales -F et -X), je pense qu’il faut rajouter dans ton script, à la fin de ton case ‘start’) une ligne pour redémarrer le démon fail2ban afin qu’il réinjecte ces règles :

/etc/init.d/fail2ban restart

Ah, et une dernière chose aussi les ports jabber, ils sont bien tous déclarés dans /etc/services ?

~$less /etc/services|grep jabber
xmpp-client	5222/tcp	jabber-client	# Jabber Client Connection
xmpp-client	5222/udp	jabber-client
xmpp-server	5269/tcp	jabber-server	# Jabber Server Connection
xmpp-server	5269/udp	jabber-server

J’ai ajouté les ports udp et en bricolant avec l’instruction /etc/init.d/fail2ban start|stop dans mon script suite à tes conseils (c’est surtout dû au fait que mon script n’est pas terminé puisque je comptais le faire dans l’ordre de mes besoins et que je bloque sur Jabber) : ça a fonctionné !

Tu vas trouver ça bête mais j’avais brûlé quelques étapes dans la logique des tests donc j’ai du mal à reproduire le cas favorable mais je crois que c’est justement les lignes fail2ban (et notamment la notion de multiport) qui me gênent.

Tu vois quelques chose de particulier à ce niveau ?

Je ne sais pas tres bien comment fonctionne fail2ban en fait… mais dans ton cas, au vu des règles qu’il injecte dans le pare feu, il n’a l’air de s’occuper que des connexions ssh, et je suppose que un nombre défini de tentatives de connexions ssh infructueuses provoquerait l’ajout d’une règle drop sur l’ip source de ces mauvaises connexions. Conclusion : il ne me parait pas avoir d’influence sur le comportement des connexions jabber.