Iptables+android

[toto69]

Je ne suis pas chez moi. Cela dit je viens de tester la commande de là où je suis :
çà se lit comment ce truc !?!

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:40:08.593645 IP 192.168.1.11.37472 > 216.58.213.174.443: Flags [P.], seq 1428189638:1428190157, ack 555947345, win 1324, options [nop,nop,TS val 745711 ecr 3299392057], length 519
15:40:08.593779 IP 192.168.1.11.37472 > 216.58.213.174.443: Flags [P.], seq 519:557, ack 1, win 1324, options [nop,nop,TS val 745711 ecr 3299392057], length 38
15:40:08.624415 IP 216.58.213.174.443 > 192.168.1.11.37472: Flags [.], ack 519, win 810, options [nop,nop,TS val 3299396002 ecr 745711], length 0
15:40:08.625790 IP 216.58.213.174.443 > 192.168.1.11.37472: Flags [.], ack 557, win 810, options [nop,nop,TS val 3299396004 ecr 745711], length 0
15:40:08.630040 IP 216.58.213.174.443 > 192.168.1.11.37472: Flags [P.], seq 1:81, ack 557, win 811, options [nop,nop,TS val 3299396008 ecr 745711], length 80
15:40:08.630242 IP 216.58.213.174.443 > 192.168.1.11.37472: Flags [P.], seq 81:127, ack 557, win 811, options [nop,nop,TS val 3299396009 ecr 745711], length 46
15:40:08.630442 IP 192.168.1.11.37472 > 216.58.213.174.443: Flags [.], ack 127, win 1324, options [nop,nop,TS val 745720 ecr 3299396008], length 0
15:40:08.630523 IP 192.168.1.11.37472 > 216.58.213.174.443: Flags [P.], seq 557:603, ack 127, win 1324, options [nop,nop,TS val 745720 ecr 3299396008], length 46
15:40:08.695421 IP 216.58.213.174.443 > 192.168.1.11.37472: Flags [.], ack 603, win 811, options [nop,nop,TS val 3299396034 ecr 745720], length 0
15:40:15.645350 IP 163.172.90.35.443 > 192.168.1.11.59408: Flags [P.], seq 2985886813:2985887150, ack 230399472, win 270, options [nop,nop,TS val 4183603829 ecr 745142], length 337
15:40:15.645391 IP 192.168.1.11.59408 > 163.172.90.35.443: Flags [.], ack 337, win 1924, options [nop,nop,TS val 747474 ecr 4183603829], length 0
15:40:15.645400 IP 163.172.90.35.443 > 192.168.1.11.59408: Flags [P.], seq 337:375, ack 1, win 270, options [nop,nop,TS val 4183603829 ecr 745142], length 38
15:40:15.645407 IP 192.168.1.11.59408 > 163.172.90.35.443: Flags [.], ack 375, win 1924, options [nop,nop,TS val 747474 ecr 4183603829], length 0
15:40:15.757084 IP 192.168.1.11.58836 > 81.253.149.9.53: 39256+ A? www.debian-fr.org. (35)
15:40:15.757099 IP 192.168.1.11.58836 > 81.253.149.9.53: 998+ AAAA? www.debian-fr.org. (35)
15:40:15.757503 IP 192.168.1.11.59408 > 163.172.90.35.443: Flags [P.], seq 1:579, ack 375, win 1926, options [nop,nop,TS val 747502 ecr 4183603829], length 578
15:40:15.781439 IP 81.253.149.9.53 > 192.168.1.11.58836: 39256 2/0/0 CNAME debian-fr.org., A 163.172.90.35 (65)
15:40:15.783048 IP 81.253.149.9.53 > 192.168.1.11.58836: 998 2/0/0 CNAME debian-fr.org., AAAA 2001:bc8:280a:1:ff:1:0:100 (77)
15:40:15.791464 IP 163.172.90.35.443 > 192.168.1.11.59408: Flags [P.], seq 375:417, ack 579, win 270, options [nop,nop,TS val 4183603830 ecr 747502], length 42
15:40:15.791510 IP 192.168.1.11.59408 > 163.172.90.35.443: Flags [.], ack 417, win 1926, options [nop,nop,TS val 747511 ecr 4183603830], length 0
15:40:15.791762 IP 192.168.1.11.59408 > 163.172.90.35.443: Flags [P.], seq 579:991, ack 417, win 1926, options [nop,nop,TS val 747511 ecr 4183603830], length 412
15:40:16.018702 IP 163.172.90.35.443 > 192.168.1.11.59408: Flags [.], ack 991, win 270, options [nop,nop,TS val 4183603830 ecr 747511], length 0
15:40:16.862070 IP 192.168.1.11.52380 > 216.58.204.130.443: Flags [P.], seq 1247792838:1247792884, ack 3369075077, win 340, options [nop,nop,TS val 747778 ecr 3081184926], length 46
15:40:16.886882 IP 216.58.204.130.443 > 192.168.1.11.52380: Flags [.], ack 46, win 217, options [nop,nop,TS val 3081243617 ecr 747778], length 0
15:40:16.887045 IP 216.58.204.130.443 > 192.168.1.11.52380: Flags [P.], seq 1:47, ack 46, win 217, options [nop,nop,TS val 3081243617 ecr 747778], length 46
15:40:16.930794 IP 192.168.1.11.52380 > 216.58.204.130.443: Flags [.], ack 47, win 340, options [nop,nop,TS val 747796 ecr 3081243617], length 0
^C
26 packets captured
26 packets received by filter
0 packets dropped by kernel

[PascalHambourg]

Ya moyen de filtrer le contenu pour ne récupérer que les protocoles udp puis tcp avec la commande ‘grep’ vers un fichier.txt ?

Il vaut mieux spécifier le protocole dans la commande tcpdump car la sortie normale peut occuper plusieurs lignes pour un paquet et ne comporte pas forcément la mention du protocole de transport.

tcpdump -n -i wlan0 host 172.16.10.3 and udp

Ou bien utiliser l’option -q qui affiche moins de détails sur le contenu des paquets mais juste les adresses, les ports, le protocole de transport et la taille.

tcpdump -n -q -i wlan0 host 172.16.10.3

çà se lit comment ce truc !?!

15:40:15.781439 IP 81.253.149.9.53 > 192.168.1.11.58836: 39256 2/0/0 CNAME debian-fr.org., A 163.172.90.35 (65)

Paquet IP vu à 15:40:15 et des poussières, source 81.253.149.9 port 53 (DNS), destination 192.168.1.11 port 58836. Il s’agit d’une réponse DNS (en UDP, implicite) pour debian-fr.org.

15:40:16.862070 IP 192.168.1.11.52380 > 216.58.204.130.443: Flags [P.], seq 1247792838:1247792884, ack 3369075077, win 340, options [nop,nop,TS val 747778 ecr 3081184926], length 46

Paquet IP vu a 15:40:16, source 192.168.1.11 port 52380, destination 216.58.204.130 port 443 (HTTPS). Il s’agit d’un paquet TCP envoyé par le client au serveur sur une connexion HTTPS établie (une demande de connexion aurait le flag [S]).

[toto69]

# tcpdump -n -q -i eth0 host 192.168.1.11 and udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:08:03.466404 IP 192.168.1.11.34198 > 81.253.149.9.53: UDP, length 35
16:08:03.466417 IP 192.168.1.11.34198 > 81.253.149.9.53: UDP, length 35
16:08:03.490177 IP 81.253.149.9.53 > 192.168.1.11.34198: UDP, length 65
16:08:03.492322 IP 81.253.149.9.53 > 192.168.1.11.34198: UDP, length 77
16:08:06.745215 IP 192.168.1.11.38885 > 81.253.149.9.53: UDP, length 33
16:08:06.745228 IP 192.168.1.11.38885 > 81.253.149.9.53: UDP, length 33
16:08:06.782967 IP 81.253.149.9.53 > 192.168.1.11.38885: UDP, length 83
16:08:06.784505 IP 81.253.149.9.53 > 192.168.1.11.38885: UDP, length 95

Bien !

# tcpdump -n -q -i eth0 host 192.168.1.11 and tcp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:08:14.396030 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.398963 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.401915 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.401939 IP 192.168.1.11.58642 > 173.194.183.231.443: tcp 0
16:08:14.405184 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.408339 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.411538 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.414230 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.417470 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.420676 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.423845 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.426589 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.429762 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.432707 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.436015 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.436044 IP 192.168.1.11.58642 > 173.194.183.231.443: tcp 0
16:08:14.439185 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.442088 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.445309 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.448258 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.451449 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.454396 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.457648 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.460580 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.463754 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.466492 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.469675 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.469696 IP 192.168.1.11.58642 > 173.194.183.231.443: tcp 0
16:08:14.472909 IP 192.168.1.11.56508 > 163.172.90.35.443: tcp 46
16:08:14.472937 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.473407 IP 192.168.1.11.56508 > 163.172.90.35.443: tcp 31
16:08:14.473429 IP 192.168.1.11.56508 > 163.172.90.35.443: tcp 0
16:08:14.476153 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.479031 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.482000 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.485219 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.488399 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.491368 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.494301 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.497543 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.500483 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.503422 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.503455 IP 192.168.1.11.58642 > 173.194.183.231.443: tcp 0
16:08:14.506770 IP 163.172.90.35.443 > 192.168.1.11.56508: tcp 0
16:08:14.506815 IP 163.172.90.35.443 > 192.168.1.11.56508: tcp 0
16:08:14.506834 IP 192.168.1.11.56508 > 163.172.90.35.443: tcp 0
16:08:14.506842 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.506902 IP 163.172.90.35.443 > 192.168.1.11.56508: tcp 0
16:08:14.510359 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.513543 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.519556 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.519675 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.522909 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.525898 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.528799 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.531782 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.534956 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.538041 IP 173.194.183.231.443 > 192.168.1.11.58642: tcp 1420
16:08:14.538077 IP 192.168.1.11.58642 > 173.194.183.231.443: tcp 0

Yen a beaucoup plus !!

[PascalHambourg]

Là en UDP il n’y a que des requêtes et réponses DNS. Mais on ne voit pas le détail avec -q.

En TCP, du trafic HTTPS avec plusieurs serveurs.

Yen a beaucoup plus !!

Le réseau, c’est vite bavard. Surtout avec les sites web comme ce forum qui laissent la connexion active et transmettent des mises en jour en permanence.
C’est pourquoi lorsqu’on veut étudier le trafic généré par un programme il peut être utile d’arrêter les autres applications pour limiter le trafic “parasite”.

[toto69]

16:08:03.466404 IP 192.168.1.11.34198 > 81.253.149.9.53: UDP, length 35

Là on a un paquet IP provenant du serveur 81.253.149.9 qui émet sur le port 53 et qui envoie le paquet à mon pc sur le port 34198. Le tout en utilisant le protocole UDP.
Donc si je veux autoriser ce flux, je dois écrire cette règle: l’adresse ip n’est pas celle de mon reseau mais c’est pas grave, c’est un exemple.

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -p 34198 -s 192.168.1.11 -J ACCEPT

J’autorise les paquet qui proviennent de l’adresse ip 192.168.1.11 à sortir par le port 34198 avec le module de suivi de connexion.

Comme j’ai mis une cible DROP au début de mes règles il faut peut-être que j’autorise les connexions du LAN vers l’exterieur ?

iptables -P FORWARD DROP

iptables -A FORWARD -i br0 -o eth0 -m state --state NEW, ESTABLISHED, RELATED -J ACCEPT
iptables -A FORWARD -i eth0 -o br0 -m state --state NEW, ESTABLISHED, RELATED -j ACCEPT

Tant que j’y suis, je ne comprends pas l’intérêt de la cible MASQUERADE ? Pourquoi vouloir modifier les paquets IP venant du LAN afin de dissimuler certaines informations ? Et quelles informations ??

[PascalHambourg]

Ce n’est pas un flux, c’est un paquet. Un “flux” ou une “connexion” se compose de plusieurs paquets de caractéristiques communes, dans les deux sens. Ici ce n’est qu’un paquet de réponse. Il faut une règle pour les paquets de chaque sens.

RELATED n’a pas lieu d’être : un paquet DNS n’est jamais dans cet état. Seuls les paquets ICMP ou les paquets de protocoles spéciaux utilisant un flux principal et un flux secondaire peuvent avoir cet état.
Ta syntaxe est approximative : c’est -j et non -J, et -p spécifie le protocole et non un port.
Le port significatif car fixe dans une réponse DNS est le port source 53, pas le port destination qui dépend du port source aléatoire qu’a choisi le client pour envoyer la requête. De même le port significatif dans une requête est le port destination 53. Il en est de même pour la plupart des protocoles.
Pour durcir il est courant de spécifier les interfaces d’entrée et de sortie du paquet.

iptables -A FORWARD -i br0 -o eth0 -m state --state NEW,ESTABLISHED -p udp --dport 53 -s 192.168.1.11 -j ACCEPT
iptables -A FORWARD -i eth0 -o br0 -m state --state ESTABLISHED -p udp --sport 53 -d 192.168.1.11 -j ACCEPT

Tant que j’y suis, je ne comprends pas l’intérêt de la cible MASQUERADE ? Pourquoi vouloir modifier les paquets IP venant du LAN afin de dissimuler certaines informations ?

Il ne s’agit pas tant de dissimuler que de remplacer l’adresse source du client, car le paquet va être transmis à la box mais celle-ci n’a pas de route correcte pour cette adresse (hors de son réseau), et ne pourra pas renvoyer les paquets de réponse. On lui fait donc croire que les paquets proviennent du routeur dont l’adresse est dans le même réseau qu’elle.
L’alternative consiste, quand c’est possible, à ajouter la route dans la table de routage de la box.

[toto69]

un paquet DNS n’est jamais dans cet état.

Je ne sais pas ce que c’est. Pas plus ce qu’est un paquet ICMP.

Je vais peut-être remuer le couteau dans la plaie mais pourquoi wlan0 est-elle citée. Je pensais qu’elle était dans le bridge. Y a encore un truc qui m’échappe !?!

De retour chez moi, j’ai fait depuis mon roteur Serveur-Debian un :

tcpdump -n -q -i br0 host 172.16.10.10 and udp
tcpdump -n -q -i wlan0 host 172.16.10.10 and udp
tcpdump -n -q -i eth0 host 172.16.10.10 and udp

J’ai 0 paquets capturés.

172.16.10.10 est l’adresse d’un des smartphones.

Par contre en ‘tcp’ j’ai plein de paquets.

?!?

Une petite recherche sur le net donne çà pour twiter :

We recommend users open/forward the following ports on their router: TCP: 80, 443, 20002, 30840, 30850, 30870 UDP: 30840-30859, 30870-30879

Ah çà y est, j’ai plein de UDP ; c’est certainement plus long à scanner !?!

[toto69]

Je suis en train de faire un plan des règles de filtrage :

1/ Vidage des tables
2/ Fermer tout
3/ Autoriser le reseau local à communiquer entre lui (lo)
4/ Serveur-Debian vers l’exterieur
5/ LAN vers Internet

[PascalHambourg]

un paquet DNS n’est jamais dans cet état.

Je ne sais pas ce que c’est. Pas plus ce qu’est un paquet ICMP.

Ah… Si tu ne connais pas les principaux protocoles, types de paquets et leurs rôle, ça va être compliqué d’écrire des règles iptables qui ont pour but de filtrer les paquets.

pourquoi wlan0 est-elle citée.

Erreur de ma part, il s’agit en réalité de br0. J’ai corrigé.

Une petite recherche sur le net donne çà pour twiter

Qu’est-ce que “twiter” ?

3/ Autoriser le reseau local (lo)

lo et le réseau local ne sont pas la même chose.
Le réseau local, c’est le LAN.
lo, c’est l’interface de loopback interne.

[toto69]

Si tu ne connais pas les principaux protocoles, types de paquets et leurs rôle, ça va être compliqué d’écrire des règles iptables qui ont pour but de filtrer les paquets.

Eh bien je vais me documenter …
A tout hasard, tu n’aurais pas sous la main un doc dans lequel on trouve tout çà en une fois. Un truc simple au début. Histoire de gagner du temps …

J’ai corriger pour (lo). Je voulais dire que les machines peuvent communiquer entre elles à l’intérieur du réseau. Interface lo.

Je dois avaler le modèle OSI et ses 7 couches ou seules quelques unes sont concernées par le filtrage avec Iptables. Déjà la couche 2 est exclu ,normalement.

[PascalHambourg]

A tout hasard, tu n’aurais pas sous la main un doc dans lequel on trouve tout çà en une fois.

Non. Mais au début tu vas essentiellement avoir affaire aux protocoles TCP, UDP et ICMP.

J’ai corriger pour (lo). Je voulais dire que les machines peuvent communiquer entre elles à l’intérieur du réseau. Interface lo.

Je répète que l’interface lo ne sert pas à communiquer avec les autres machines du réseau local. Elle sert uniquement à une machine à communiquer avece elle-même.

[toto69]

Je répète que l’interface lo ne sert pas à communiquer avec les autres machines du réseau local. Elle sert uniquement à une machine à communiquer avece elle-même.

Ok, je n’avais pas compris.

au début tu vas essentiellement avoir affaire aux protocoles TCP, UDP et ICMP

Oui, j’ai déjà commencé à lire. Effectivement, avec Iptables, il n’est surtout question que de ces trois protocoles.
Dois-je absolument comprendre les histoires d’en-tête de paquet ou est-ce que je peux laisser tomber. C’est que c’est pas très simple à comprendre tous ces bits et autres caractéristiques IP ?

Pour l’identification des ports utilisés ou à l’écoute, je peux utiliser aussi netstat ? Si oui, je pourrais peut-être identifier chaque machine sur le LAN en renseignant le fichier /etc/hosts ?
Par exemple :

172.16.10.10 pc-louise

Pour comprendre iptables, je lis çà actuellement. Dedans on trouve çà, entre autre :
https://www.inetdoc.net/guides/iptables-tutorial/statemachine.html

Le traçage de connexion est entièrement pris en charge dans la chaîne PREROUTING, sauf pour les paquets générés en local, qui sont pris en charge dans la chaîne OUTPUT. Ceci signifie qu’iptable effectue tous les calculs d’état dans la chaîne PREROUTING. Si on envoie le premier paquet d’un flux, l’état est défini comme NEW dans la chaîne OUTPUT, et quand on reçoit un paquet de réponse, l’état passe à ESTABLISHED, et ainsi de suite. Si le premier paquet n’est pas envoyé par nous-mêmes, l’état NEW est naturellemt défini dans la chaîne PREROUTING. Ainsi, tous les changements d’état et calculs sont réalisés dans les chaînes PREROUTING et OUTPUT de la table nat.

Donc pas besoin de spécifier le module ni les états dans iptables puisque tous les paquets passent par la table NAT et la chaine PREROUTING !?

[PascalHambourg]

Dois-je absolument comprendre les histoires d’en-tête de paquet ou est-ce que je peux laisser tomber. C’est que c’est pas très simple à comprendre tous ces bits et autres caractéristiques IP ?

Tu n’as pas besoin de connaître tous les détails des en-têtes IP, TCP… mais au moins la signification des champs principaux utilisés dans les règles iptables.

• IP : adresses source et destination, protocole
• UDP : ports source et destination
• TCP : ports source et destination, drapeaux SYN, ACK, RST, FIN
• ICMP : type, code

Pour l’identification des ports utilisés ou à l’écoute, je peux utiliser aussi netstat ?

Oui.

Si oui, je pourrais peut-être identifier chaque machine sur le LAN en renseignant le fichier /etc/hosts ?

Je ne vois pas le rapport avec les ports en écoute, mais oui, pourquoi pas. Il faut renseigner le fichiers host des machines qui doivent résoudre le nom, pas seulement de celle qui a le nom.

Attention à l’utilisation de noms à la place des adresses dans une règle iptables : les noms sont résolus en adresse lors de la création de la règle, et ce sont les adresses qui sont enregistrées dans la règle. A savoir en cas de changement de l’adresse associée à un nom. Et si un nom a plusieurs adresses, une règle avec chaque adresse est créée.

Pour comprendre iptables, je lis çà actuellement. Dedans on trouve çà, entre autre

Cet extrait est un ramassis de bêtises.
Le suivi de connexion est indépendant d’iptables et n’est pas réalisé dans les chaînes d’aucune table. Les positions sont représentées par les ovales gris étiquetés “conntrack” dans le schéma de netfilter.

Donc pas besoin de spécifier le module ni les états dans iptables puisque tous les paquets passent par la table NAT et la chaine PREROUTING !?

Quel module ?
Non, tous les paquets ne passent pas par la chaîne PREROUTING de la table nat. Seul le premier paquet d’une nouvelle connexion entrante passe par cette chaîne. La table nat n’est pas conçue pour faire du filtrage mais seulement du NAT, comme son nom l’indique.

[toto69]

Cet extrait est un ramassis de bêtises.

Voilà pourquoi je te demandai si il y avait un doc qui faisait référence. On trouve de tout sur le net. Et en matière d’informatique, je ne peux pas discerner le vrai du faux.

[toto69]

Les positions sont représentées par les ovales gris étiquetés “conntrack” dans le schéma de netfilter.

Le moins que l’on puisse dire c’est que ton schéma est plus complet que le mien

[PascalHambourg]

Ce n’est pas mon schéma, c’est celui qui figure dans les pages netfilter et iptables de Wikipedia. Il a été créé par un développeur de Netfilter et mis à jour avec les nouveautés.

D’aucuns diraient qu’il est trop complet et confus si on n’a pas besoin du pontage ou des “transformations” (abrégé en “xfrm”, utilisé par IPsec).

Une documentation de bonne qualité mais qui date un peu est l’“Iptables Tutorial” écrit par Oskar Andreasson. Une version française existe.

[toto69]

Je ne comprends pour quelle raison j’ai plusieurs ports à l’écoute sur le serveur dhcp :

root@serveur-debian:~# netstat -anup |grep dhcp
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          
udp6       0      0 :::15665                :::*                                1221/dhcpd

[toto69]

root@serveur-debian:~# netstat -uln
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat       
udp        0      0 0.0.0.0:34212           0.0.0.0:*                          
udp        0      0 0.0.0.0:53              0.0.0.0:*

Cela signifie-t-il que le routeur serveur-debian est en écoute sur le port 34212 ? J’en déduis çà car le port 53 est le port utilisé pour le DNS.
Pour adresse distante et adresse locale, j’ai la même 0.0.0.0. Que signifie le ‘:*’ juste après ?

Je joins ma config ‘iptables’. C’est certainement plein d’erreurs mais faut un début à tout
Iptables.txt (3,1 Ko)

[PascalHambourg]

Je ne comprends pour quelle raison j’ai plusieurs ports à l’écoute sur le serveur dhcp

Les requêtes DHCP utilisent le port 67. Je ne connais pas les deux autres. Sur mon serveur, ils sont différents.

Pour adresse distante et adresse locale, j’ai la même 0.0.0.0.

0.0.0.0 est l’adresse indéfinie, qui équivaut à “n’importe quelle adresse”.

Que signifie le ‘:*’ juste après ?

C’est le séparateur entre l’adresse et le port.

[toto69]

Je ne connais pas les deux autres. Sur mon serveur, ils sont différents.

J’en déduis quoi ??
# nmap -sS 172.16.10.1

Starting Nmap 7.40 ( https://nmap.org ) at 2017-11-11 23:10 CET
Nmap scan report for 172.16.10.1
Host is up (0.000020s latency).
Not shown: 992 closed ports
PORT      STATE SERVICE
53/tcp    open  domain

53 UDP domain - Domain Name System (DNS)

C’était le port utilisé par Dnsmasq. Je l’ai supprimé. Je n’ai pas besoin d’un serveur dns puisque la livebox en a un.