Un processus écoute sur le port 53, et netstat peut dire lequel.
J’ai bien deux services dhcp qui écoutent sur deux ports différents :
udp 0 0 0.0.0.0:34212 0.0.0.0:* 1221/dhcpd
udp 0 0 0.0.0.0:67 0.0.0.0:* 1221/dhcpd
udp 0 0 0.0.0.0:68 0.0.0.0:* 713/dhclient
Est-ce que je peux fermer le port 34212 sachant que dhcp utilise le 67 et le 68 ?Je veux dire : dans mes règles iptables, je ne vais ouvrir que 67 et 68 pour dhcp.
Du coup, je me repose la question de la nécessité ou pas d’un serveur DNS sur mon routeur !?
P.S. Ya plein de boulettes dans mon fichier iptables !! Je suis en train de le refaire. Y’en aura d’autres mais celles-là je ne les verrai pas (rassurant !?!).
J’ai un peur de mal avec --dport,–sport et INPUT, OUTPUT
Exemple : dans l’ecriture des règles du LAN vers le routeur, pour autoriser l’accès au serveur ssh situé sur le serveur. --dport correspond au port situé sur le serveur ou sur le LAN ?
iptables -A INPUT -p tcp --sport 2222 -o br0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 2222 -i br0 -m state --state ESTABLISHED -j ACCEPTDans les paquets envoyés par un client à un serveur qui écoute sur un port N, N est le port destination donc --dport. Sur le serveur, ces paquets sont entrants et passent dans la chaîne INPUT. Dans cette chaîne, on ne peut que vérifier l’interface d’entrée donc -i.
Dans les paquets envoyés à un client par un serveur qui écoute sur un port N, N est le port source donc --sport. Sur le serveur, ces paquets sont sortants et passent dans la chaîne OUTPUT. Dans cette chaîne, on ne peut que vérifier l’interface de sortie donc -o.
Tu dois donc intervertir “–sport N -o” et “–dport N -i” dans les deux règles ci-dessus.
iptables -A INPUT -p tcp --dport 2222 -i br0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 2222 -o br0 -m state --state ESTABLISHED -j ACCEPTDonc,
J’avais pas vu que tu avais corrigé !! Je me demandais pourquoi je ne comprenais rien !!!
Autre question (j’en ai plein au fur et à mesure que j’écris les règles !):
–sport n’a de sens avec le protocole tcp que dans le cas d’un serveur comme ssh ? Dans le cas d’un serveur comme ‘netbios’, on ne peut pas savoir ou prévoir le port sur lequel le client (ici LAN) fait sa demande. Il n’y a donc pas de --sport ?
# Netbios
iptables -A INPUT -p tcp --dport 137 -i br0 -j ACCEPT
iptables -A OUTPUT -p udp --dport 137 -o br0 -j ACCEPTLes règles ne vérifient pas le port du client mais le port du serveur. Donc port destination dans les paquets du client au serveur, et port source dans les paquets du serveur au client. C’est valable pour quasiment toutes les connexions TCP.
(Il y a une exception en quelque sorte avec le port 20 des connexions de données FTP “actives” qui est le port côté serveur mais pour des connexions du serveur vers le client, donc inversion des roles du point de vue de TCP et iptables).
Que je sache, le port 137 de NetBIOS Name Service n’est utilisé qu’en UDP.
Donc tu veux dire que dans ce cas, --dport 2222 et --sport 2222 sont tous les deux sur le serveur (routeur serveur-deban ici)?
Je ne comprends pas le sens de ta question.
On est bien en train de discuter des règles de filtrage IP que tu veux mettre en place sur le serveur, n’est-ce pas ?
Donc dans ce cas, la première règle signifie que l’on accepte la connexion à destination du port 137 en provenance du LAN et la deuxième qu’on accepte la connexion qui vient du port 137 à destination du LAN ?
Oui. Et…je ne comprends pas ta remarque du coup ? En quoi ma question est-elle dérangeante ?
Oui, pourquoi ?
Oui, sauf qu’une telle connexion TCP n’arrivera jamais puisque Netbios n’utilise le port 137 qu’en UDP.
Pas exactement. Elle accepte les paquets UDP à destination du port 137 émis par le serveur vers le LAN.
Puisqu’on parle des règles du serveur, sur quoi d’autre pourraient être --dport 2222 et --sport 2222 ?
Pardon, c’était un exemple. J’aurais du prendre un autre port comme le port 80 par exemple.
Voilà pourquoi je ne comprends pas la nuance entre --dport et --sport.
Qui est ‘on’ dans mon cas et ‘elle’ dans ta réponse ? Netfilter ou le serveur ?
“On” et “elle”, c’est la règle iptables qui est appliquée par netfilter sur le serveur.
Un paquet TCP ou UDP contient un port source et un port destination. --sport teste la correspondance avec le port source et --dport teste la correspondance avec le port destination.
Dans ce cas, cela sous-entend qu’on devrait spécifier à chaque fois le port source !
Or, lorsque je me promène sur les forums je ne vois pas tout le temps le port source spécifié. Je ne comprends donc pas.
Dans l’exemple du ssh un peu plus haut, connexion TCP, c’est le service ssh qui choisit le port source ou pas ? Si oui, je n’ai pas besoin de le spécifier dans iptables. On peut donc remplacer --sport 2222 par --dport 2222.
Lorsque je fais un ‘netstat -tlnp’ sur mon serveur, je vois toujours le port 2222, jamais un autre ?
J’ai parfois deux ordinateurs (machine 1 et machine 2)connectés sur le serveur en ssh; Je pourrais vérifier depuis les pc du LAN que le port source est 2222 sur les deux pc ! Si oui je ne comprends plus.
Si non, cela prouverait que le service détermine tout seul quel port ouvrir pour la connexion.Il pourra dans ce cas choisir un autre port que le 2222 (2223 par exemple) puisque le 2222 est déjà pris par la machine 1
D’ où la nécessité dans ce cas de spécifier le port source dans les règles pour que le serveur sache à laquelle des deux machines il doit renvoyer le paquet.
Tu veux dire dans les règles iptables ? Non, pas forcément. Seulement quand c’est pertinent.
Il ne faut pas confondre les ports source et destination qui sont dans les paquets IP d’une part et les ports local et distant des sockets qui sont affichés par netstat d’autre part. Le port source du paquet correspond au port local de l’émetteur et le port destination du paquet correspond au port local du destinataire.
Dans les paquets émis par le client dans la direction aller, le port source correspond au port local du client et le port destination correspond au port local du serveur. Dans les paquets émis par le serveur dans la direction retour, le port source correspond au port local du serveur et le port destination correspond au port local du client.
En général seul le port local du serveur est fixe et pertinent et le port local du client est dynamique et non pertinent. Donc :
- dans les paquets émis par le client (direction aller), c’est le port destination qui est pertinent
- dans les paquets émis par le serveur (direction retour), c’est le port source qui est pertinent
Mais comme tu l’as constaté, les règles ne s’occupent pas toujours du port source des paquets émis par le serveur dans le sens retour, car ce n’est ni nécessaire ni suffisant. D’une part les paquets valides dans le sens retour sont déjà identifiés par l’état ESTABLISHED, et d’autre part le seul port source ne suffit pas à garatir qu’il s’agit d’un paquet de réponse valide. Il vaut mieux donc se fier à l’état ESTABLISHED, et la vérification du port source est relativement superflue.
C’est pourquoi on trouve le plus souvent une règle unique par chaîne qui accepte tous les paquets dans l’état ESTABLISHED.
Non, on ne peut pas remplacer --sport par --dport n’importe comment.
Ta question est incomplète car tu ne précises pas le port source de quels paquets. Par définition c’est l’émetteur d’un paquet qui fixe les ports source et destination à partir des ports local et distant de la connexion.
2222 est le port local de la socket ouverte en écoute par le service SSH. Par définition il est fixe pour que les clients sachent quel port distant utiliser pour se connecter en SSH.
Encore une fois, tu oublies de préciser le port source de quels paquets. 2222 est toujours le port source des paquets émis par le service SSH à tous ses clients.
Heureusement, cela ne se passe pas ainsi sinon ce serait inutilisable.
Pour une machine, une connexion est définie par l’ensemble (protocole, adresse locale, port local, adresse distante, port distant). Plusieurs connexions peuvent donc utiliser le même port local 2222 si leurs addresses ou ports distants sont différents.
Tu peux afficher les adresses et ports des connexions établies (au lieu des ports en écoute) avec netstat sans l’option -l.
Pas du tout. Les règles iptables n’ont rien à voir avec le routage des paquets.
J’avais pas encore vu ce mot là : socket !
Je retourne lire 
Il me faut un exemple concret pour comprendre :
Exemple avec le port 22 de ssh
Lorsque le paquet part de la machine 1, la machine 1 ‘choisit’ aléatoirement un port pour le message de retour (exemple 44444; dans le cas du TCP, la machine attend les flag SYN et ACK sur le port 44444. 44444 est un port local et le socket est ip machine 1 : 44444
Donc dans le paquet , on a
ip machine 1 | ip machine destination | port source 44444 | destination port 80.
Dans mon cas :
iptables -A INPUT -p tcp --dport 22 -i br0 -j ACCEPT
A ce stade, le paquet est autorisé à sortir du LAN par la chaine INPUT et l’interface -i br0 du port 44444 de la machine 1 vers le port 22 du serveur. port source = port local
Il faut maintenant autoriser le paquet à entrer sur le LAN :
Le serveur envoie les FLAG SYN ACK dans le paquet suivant
ip machine destination (serveur) | ip machine 1 | source port 80 | destination port 44444
iptables -A OUTPUT -p tcp --sport 22 -o br0 -j ACCEPT
Le paquet est autorisé à entrer sur le LAN par la chaine OUTPUT et l’interface -o br0.
Le port source est donc le port 80 du serveur. Et là …je ne pige plus 
Ben non, en fait c’est çà 
Pour toutes les mises à jour, j’ai besoin d’une connexion au net. Donc, du serveur vers l’extérieur, il me faut une règle :
iptables -A OUTPUT -p tcp --dport 80 -o eth0 -m state --state NEW,ESTABLISHED, RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -i eth0 -m state --state ESTABLISHED, RELATED -j ACCEPT
Pas besoin de règle --sport.