Vous n'êtes pas identifié(e).
Pages : 1
#!/bin/bash
iptables -t filter -F
iptables -t filter -X
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 20 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT
#iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5687 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 5687 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5688 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 5688 -j ACCEPT
Cordialement,
Laurent.
Pc sous debian 7.6 => noyau Linux 3.2.0
Serveur debian 7.6 => Linux 3.2.0
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Dernière modification par anonyme (22-11-2014 09:49:48)
Il vaut mieux montrer que raconter.
Hors ligne
=> la connexion passe
Mais ensuite, après avoir essayé :
ou même :
La connexion ne passe pas, la sonnerie se fait chez le client appelé dans les 3 cas mais impossible de communiquer.
Pourtant le port c2s - 5687 - (et même s2s - 5688 - qui n'est pas obligatoire) est ouvert en sortie avec ces 3 configs.
J'ai l'impression qu'il manque un port en entré et plus d'un en sortie...
Avant iptables, j'utiliser sur les 2 clients ufw, il suffisait pourtant d'ouvrir en sortie en udp 5687 et cela marcher sans problème.
Cordialement,
Laurent.
Dernière modification par laurent1 (22-11-2014 18:20:32)
Pc sous debian 7.6 => noyau Linux 3.2.0
Serveur debian 7.6 => Linux 3.2.0
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
iptables -t filter -P INPUT ACCEPT
[...]
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
C'est normal que cela fonctionne car le client accepte non seulement les connexions établies (qui émanent de lui) mais aussi toutes les autres en entrée vers lui.
Cas non fonctionnel, exemple 1:
iptables -t filter -P INPUT DROP
[...]
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Normal que ça ne marche pas, il n'accepte en entrée que les connexion faisant suite à celles que le client lance. Par définition, il n'est pas responsable des connexion faisant suite à un appel, il ne sait pas qui et comment on va l'appeler, ni sur quel port aléatoire (ça part du serveur par les ports que tu as définis mais ça arrive sur le client sur un port aléatoire).
Il te faudrait, sur les clients, une régle du style:
qui fait que les paquets entrants en provenance du port 5687 sont acceptés.
Dans le cas non fonctionnel N°2 même si tu ouvres par défaut tes ports en entrée, tu les restreints ensuite 3 lignes plus bas.
Or, de mémoire, les régles iptables sont appliquées dans l'ordre.
Dernière modification par sogal (22-11-2014 19:08:58)
Hors ligne
Normal que ça ne marche pas, il n'accepte en entrée que les connexion faisant suite à celles que le client lance.
Tu interprètes mal cette règle. Elle n'accepte que les paquets entrants appartenant (ESTABLISHED) ou liés (RELATED) à un connexion existante. Rien à voir avec le fait que le client soit ou non à l'origine de la connexion.
Pour rappel, les règles iptables traitent des paquets, pas des connexions.
te faudrait, sur les clients, une régle (...) qui fait que les paquets entrants en provenance du port 5687 sont acceptés.
Autant tout accepter en entrée alors, puisque c'est l'émetteur du paquet qui définit le port source.
Dans le cas non fonctionnel N°2 même si tu ouvres par défaut tes ports en entrée, tu les restreints ensuite 3 lignes plus bas.
Or, de mémoire, les régles iptables sont appliquées dans l'ordre.
Une règle avec la cible ACCEPT ne restreint rien du tout, au contraire.
Les règles d'une chaîne sont appliquées dans l'ordre mais la politique par défaut (-P) de la chaîne n'est appliquée que si le paquet atteint la fin de la chaîne après avoir traversé toutes les règles sans qu'aucune n'ait décidé de son sort.
Je pense que ça ne marche pas dans le cas n° 2 parce que les paquets sont bloqués à l'émission (et dans le cas n° 1 parce qu'ils sont bloqués à la réception).
Dernière modification par raleur (22-11-2014 20:51:42)
Il vaut mieux montrer que raconter.
Hors ligne
Elle n'accepte que les paquets entrants appartenant (ESTABLISHED) ou liés (RELATED) à un connexion existante. Rien à voir avec le fait que le client soit ou non à l'origine de la connexion.
Pour rappel, les règles iptables traitent des paquets, pas des connexions.
Certes, mais ce cas, qui crée la connexion pour que les paquets liés à celle-ci puisse être acceptés? c'est bien l'appelant dans son cas, le serveur donc, non?
sogalpunx a écrit :
te faudrait, sur les clients, une régle (...) qui fait que les paquets entrants en provenance du port 5687 sont acceptés.
Autant tout accepter en entrée alors, puisque c'est l'émetteur du paquet qui définit le port source.
L'émetteur du paquet est ici son serveur et il l'a paramétré pour que le port source soit le 5687 et 5688. Je ne comprends pas pourquoi tu dis qu'il pourrait aussi bien tout accepter?
Je pense que ça ne marche pas dans le cas n° 2 parce que les paquets sont bloqués à l'émission (et dans le cas n° 1 parce qu'ils sont bloqués à la réception).
Effectivement, ça aiderait de savoir si dans ses tests il a modifié le pare-feu sur le serveur.
Hors ligne
qui crée la connexion pour que les paquets liés à celle-ci puisse être acceptés? c'est bien l'appelant dans son cas, le serveur donc, non?
Si tu parles d'une connexion au sens du suivi de connexion de netfilter ("conntrack"), elle est créée par un paquet initial qui a l'état NEW et n'est pas bloqué. Oui, ce sont les paquets qui créent les connexions au sens de conntrack, pas leurs émetteurs. Les émetteurs envoient les paquets. Pas de paquet, pas de connexion. Paquet initial bloqué, pas de connexion. Pas de connexion, pas de paquet dans l'état ESTABLISHED ou RELATED.
Les règles présentées ici ne sont pas basées sur l'adresse source des paquets, donc peu importe que les paquets soient émis par le serveur ou par une autre machine.
L'émetteur du paquet est ici son serveur et il l'a paramétré pour que le port source soit le 5687 et 5688.
Le serveur utilise ce port source pour envoyer des paquets appartenant à une connexion établie par le client sur ce port. Je ne suis pas du tout convaincu qu'il l'utilise aussi à autre chose.
Je ne comprends pas pourquoi tu dis qu'il pourrait aussi bien tout accepter?
Parce qu'avec ta règle il suffirait à n'importe quelle machine d'envoyer un paquet vers n'importe quel port (=service) et il passerait à travers le pare-feu du moment que le port source est celui qui est accepté. C'est précisément pour éviter ce genre de chose qu'on a créé le suivi de connexion, pour accepter les paquets de réponse sans se baser uniquement sur le port source mais sur le fait qu'on a vu un paquet initial correspondant.
Effectivement, ça aiderait de savoir si dans ses tests il a modifié le pare-feu sur le serveur.
Il a écrit que tout fonctionne avec les règles sur le serveur.
Dernière modification par raleur (22-11-2014 22:21:52)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Parfois il est possible de spécifier un port ou une plage de ports à cet usage dans les paramètres de l'application, ce qui permet de restreindre les ports à autoriser dans le pare-feu.
Je n'ai pas trouver cette option sous empathy.
Ce que je fais dans ces cas-là, c'est ajouter une règle LOG à la fin de chaque chaîne dont la politique par défaut est DROP pour voir les paquets bloqués dans les logs du noyau (/var/log/kern.log).
Mais comment identifier ceux du flux provenant d'empathy ? Et ensuite mettre un script qui réactualiserai les règles iptables en fonction du port choisit ?
Question : Que signifient c2s - 5687 et s2s - 5688 ?
Le port c2s est celui qui permet la connexion du client au serveur, le s2s quant à lui permet la connexion entre 2 serveur xmpp
Cordialemnt,
Laurent.
Pc sous debian 7.6 => noyau Linux 3.2.0
Serveur debian 7.6 => Linux 3.2.0
Hors ligne
Mais comment identifier ceux du flux provenant d'empathy ? Et ensuite mettre un script qui réactualiserai les règles iptables en fonction du port choisit ?
Pour identifier les flux d'empathy, tu arrêtes toute autre activité réseau sur le poste le temps du test et tu ne regardes que les paquets dont la source est le serveur ou le poste avec lequel tu essaies d'ouvrir une communication.
Dans un premier temps le but est d'observer les paquets bloqués lors des tentatives de communication pour vérifier si les ports audio/vidéo sont vraiment aléatoires, certainement pas d'actualiser les règles iptables. Tu ne peux pas juste dire "j'ai vu que j'ai bloqué un paquet sur ce port, je vais laisser passer les suivants". Autant ne rien bloquer.
PS : dans le wiki d'ubuntu-fr, il est suggéré d'autoriser les ports 5800 et 5900. A vérifier.
Il vaut mieux montrer que raconter.
Hors ligne
Cordialement,
Laurent.
Pc sous debian 7.6 => noyau Linux 3.2.0
Serveur debian 7.6 => Linux 3.2.0
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
J'observe que la connexion avec le serveur jabber est sur le port 5800, alors que tu disais avoir configuré le port 5687.
Oui. C'était quand j'avais essayé de remettre la configuration par default pendant les réglages (mais le port est actuellement utilisé est bien 5687).
Mais après un tcpdump, il semble que empathy choisit un port, à ce que j'ai pu remarquer dans la plage 30000 à 65000 (pour les clients), en sortie. Il n'a besoin que de cela pour établir la communication.
Avec une règle :
cela fonctionne sans problème.
Est-il possible d'un peu plus sécurisé la règle sachant que le client envoie directement les paquets au second client avec lequel il veut communiquer (qui lui aussi fait de même) ?
Pc sous debian 7.6 => noyau Linux 3.2.0
Serveur debian 7.6 => Linux 3.2.0
Hors ligne
Dernière modification par raleur (04-01-2015 15:25:36)
Il vaut mieux montrer que raconter.
Hors ligne
Pages : 1