Discussion inutile : je cherchais à installer conntrack-tools !!! Or c’est le paquet ‘conntrack’ seul qu’il faut installer.
Je reprends le fil de mon travail sur les règles. Je patauge un peu avec les règles icmp. C’est pour çà que je voulais regarder un peu ce qui se passe pour le suivi des paquets icmp. Je ne sais pas si çà va m’aider. On verra …
Si tu veux ajouter des outils (= tools) à conntrack, tu peux voir conntrackd et nfct
apt show nfct conntrackdJ’ai rectifié la règle ‘icmp-request’ pour le ping.
J’utilise ‘netstat tln’ pour identifier les ports ouverts sur ma machine.
Je souhaiterais savoir quels ports sont ouverts sur une machine du reseau LAN.
C’est bien cette commande ?
netstat tln machine-ip
Parce que je ne vois pas le port tcp ouvert ‘normalement’ par l’application ‘gigatribe’.
Il s’agit du port '3728’
Je peux en déduire que l’application utilise un autre port ??
C’est plutôt “netstat -tnl” (avec un tiret), et il faut l’exécuter sur la machine dont on veut afficher les sockets. Elle ne fonctionne pas à distance. Pour découvrir les ports ouverts d’une machine distante, il y a le scan de ports avec nmap.
D’après ce que je lis sur Wikipédia, gigatribe n’est disponible que pour Windows. La commande netstat y est aussi disponible avec des options qui peuvent varier légèrement de la version GNU/Linux, mais il me semble que les options -t, -n et -l ont les mêmes effets (la flemme de démarrer une machine sous Windows pour vérifier).
Une chose qui m’a aidé à comprendre les états, c’est d’insérer des règles pour logger les paquets selon leur état, au début des chaînes PREROUTING (reçus) et OUTPUT (émis) de la table mangle (pas la table nat car tous les paquets ne passent pas par ses chaînes).
iptables -t mangle -A PREROUTING -p icmp -m state --state NEW -j LOG --log-prefix "NEW "
et ainsi de suite. Le résultat est dans les logs du noyau /var/log/kern.log
Tu peux ajuster les critères comme le protocole pour limiter les paquets loggés à ce qui t’intéresse.
çà je peux le faire. J’ai la flemme aussi !! Je vais utiliser nmap pour connaître les ports ouverts par les machines du reseau. Plus pratique pour moi.
Je post mon jeu de règles modifié ce soir. Il en reste encore pas mal à faire. C’est un début …
# nmap -sS -sU 172.16.10.3
Starting Nmap 7.40 ( https://nmap.org ) at 2017-11-22 21:13 CET
Nmap scan report for 172.16.10.3
Host is up (-0.0019s latency).
Not shown: 999 open|filtered ports, 996 filtered ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
5357/tcp open wsdapi
137/udp open netbios-ns
MAC Address: A4:2B:B0:A6:51:F4 (Tp-link Technologies)
Ben il est pas dedans !!!
J’ai fait un ‘netstat’ sur le windows 10 ce matin : plein de ports ouverts qui n’apparaissent pas au scan ‘nmap’.
Vérification faite, le netstat de Windows (7) n’a pas d’option -l, il faut utiliser l’option -a qui affiche toutes les sockets y compris celles en écoute, et le protocole tcp est spécifié par “-p tcp” et non -p qui a une autre signification.
Le résultat de ton nmap montre que la plupart des ports TCP et UDP sont filtrés, soit à cause des règles iptables de la machine source soit à cause d’un pare-feu sur la machine cible. Il me semble que Windows a un pare-feu activé par défaut qui bloque les connexions entrants.
Voici le jeu de règles (pas complet) ; je le modifierai en fonction des remarques. Il me faudra surtout ajouter certaines règles du ‘LAN vers l’extérieur’ (chaine FORWARD) en fonction des scans netstat de certaines applications des smartphones.
Pour déterminet (tcp/udp), j’ai fait le choix de me fier au scan de ports ‘netstat’ : j’ai simlement regardé si le n° de port était présent dans tcp et udp. Si non, j’en déduisais qu’il n’y avait qu’un seul port.
Sur le net, en revanche, ils sont quasiment tous en tcp/udp !?!
# Vider les tables actuelles
iptables -F
iptables -t nat -F
# Politique par défaut de la table FILTER sur DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
################################################# Sur la machine routeur Serveur-Debian ############################################
# Autoriser loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
############# du routeur vers le LAN ############
# On autorise toutes les connexions du routeur vers le LAN
#iptables -A INPUT -i br0 -m state --state ESTABLISHED -j ACCEPT
#iptables -A OUTPUT -o br0 -m state --state NEW,ESTABLISHED -j ACCEPT
# Autoriser ICMP
iptables -A OUTPUT -p icmp --icmp-type destination-unreachable -m state --state RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -m state --state RELATED -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type time-exceeded -o br0 -m state --state RELATED -j ACCEPT
iptables -A INPUT -p cimp --icmp-type time-exceeded -i br0 -m state --state RELATED -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type parameter-problem -m state --state RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type parameter-problem -m state --state RELATED -j ACCEPT
iptables -A OUTPUT -p icmp -o br0 --icmp-type echo-request -m state --state NEW -j ACCEPT
iptables -A INPUT -p icmp -i br0 --icmp-type echo-reply -m state --state ESTABLISHED -j ACCEPT
############ Du routeur Serveur-Debian vers l'extérieur #############################
# Dansguardian (tcp/? 8080)
iptables - A OUTPUT -p tcp --dport 8080 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --sport 8080 -i eth0 -m state --state ESTABLISHED -j ACCEPT
# dhcp (udp 67:68)
iptables -A OUTPUT -p udp --dport 67:68 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --sport 67:68 -i eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
# dns (tcp 53)
iptables -A OUTPUT -p tcp --dport 53 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp sport 53 -i eth0 -m state --state ESTABLISHED -j ACCEPT
# netbios (tcp/udp 137-138-139)
iptables -A OUTPUT -p tcp --dport 137:139 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --sport 137:139 -i eth0 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp --dport 137:139 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --sport 137:139 -i eth0 -m state --state ESTABLISHED -j ACCEPT
# samba (tcp 445)
iptables -A OUTPUT -p tcp --dport 445 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --sport 445 -i eth0 -m state --state ESTABLISHED -j ACCEPT
# web (tcp:80-443)
iptables -A OUTPUT -p tcp --dport 80 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --sport 80 -i eth0 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --sport 443 -i eth0 -m state --state ESTABLISHED -j ACCEPT
# squid (tcp:3128)
iptables -A OUTPUT -p tcp --dport 3128 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 3128 -i eth0 -m state --state ESTABLISHED -j ACCEPT
# cups (tcp/udp:631)
iptables -A OUTPUT -p tcp --dport 631 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 631 -i eth0 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp --dport 631 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --dport 631 -i eth0 -m state --state ESTABLISHED -j ACCEPT
# smtp (tcp/udp 25)
iptables -A OUTPUT -p tcp --dport 25 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --sport 25 -i eth0 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp --dport 25 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --sport 25 -i eth0 -m state --state ESTABLISHED -j ACCEPT
# nut (tcp 3493)
iptables -A OUTPUT -p tcp --dport 3493 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --sport 3493 -i eth0 -m state --state ESTABLISHED -j ACCEPT
# sunrpc (tcp/udp 111)
iptables -A OUTPUT -p tcp --dport 111 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --sport 111 -i eth0 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp --dport 111 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --sport 111 -i eth0 -m state --state ESTABLISHED -j ACCEPT
################## du LAN vers le routeur ###################
# On autorise toutes les connexions du LAN vers le routeur
iptables -A INPUT - i br0 -m state --state NEW, ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o br0 -m state --state ESTABLISHED -j ACCEPT
# On autorise l'accès au serveur ssh
iptables -A INPUT -p tcp --dport 2222 -i br0 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 2222 -o br0 -j ACCEPT
# Autoriser l'accès au serveur Samba (
iptables -A INPUT -p udp --dport 137 -i br0 -j ACCEPT
iptables -A OUTPUT -p udp --
# Accès SSH depuis le net (tcp:2222)
iptables -A INPUT -p tcp --dport 2222 -i etho -j ACCEPT
iptables -A OUTPUT -p tcp --sport 2222 -o eth0 -j ACCEPT
# Accès SSH depuis le LAN (tcp:2222)
iptables -A INPUT -p tcp --dport 2222 -i br0 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 2222 -o br0 -j ACCEPT
####################### Du LAN vers l'extérieur ##########################
# Tout ce qui est destiné à internet, qui arrive par le bridge et qui ressort par eth0 doit changer d'adresse.
iptables -t nat -A POSTROUTING -o eth0 -i br0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
# Intercepter toutes les requêtes qui arrivent sur le port 80 et les rediriger sur le port d'écoute de squid.
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
# Toutes les connexions qui sortent du LAN vers le Net sont acceptées
iptables -A FORWARD -i br0 -o eth0 -m state --state NEW, ESTABLISHED, RELATED -j ACCEPT
# Autoriser icmp sur le LAN
iptables -A FORWARD -p icmp --icmp-type destination-unreachable -m state --state RELATED -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type time-exceeded -m state --state RELATED -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type parameter-problem -m state --state RELATED -j ACCEPT
iptables -A FORWARD -p icmp -i br0-o eth0 --icmp-type echo-request -m state --state NEW -j ACCEPT
iptables -A FORWARD -p icmp -i eth0-o br0 --icmp-type echo-reply -m state --state ESTABLISHED -j ACCEPT
# Cupsd (accès imprimante partagée en wifi sur le LAN depuis n'importe quel poste du LAN)
iptables -A FORWARD -p tcp --dport 631 -i br0 -o eth0 -m --state NEW, ESTABLISHED, RELATED -j ACCEPT(autorisé à sortir)# On autorise toutes les connexions du routeur vers le LAN
#iptables -A INPUT -i br0 -m state --state ESTABLISHED -j ACCEPT
#iptables -A OUTPUT -o br0 -m state --state NEW,ESTABLISHED -j ACCEPT
La logique et la facilité de lecture voudraient qu’on écrive en premier la règle qui accepte les paquets dans la direction aller (état NEW). Tu l’as fait partout ailleurs sauf ici.
Et pourquoi avoir commenté ces règles ?
# Autoriser ICMP
Ces règles ICMP ne sont pas spécifiques au trafic du routeur vers le LAN. Elles mériteraient une section à part.
############ Du routeur Serveur-Debian vers l'extérieur #############################
# Dansguardian (tcp/? 8080)
Le routeur a besoin de se connecter à un serveur Dansguardian qui est accessible par eth0, côté extérieur ?
Même question pour le proxy squid, CUPS, NUT et RPC plus bas.
# dhcp (udp 67:68)
iptables -A OUTPUT -p udp --dport 67:68 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --sport 67:68 -i eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
Je suppose que ces règles servent pour la communication entre le client DHCP sur eth0 de la machine et le serveur DHCP de la box. DHCP est un peu particulier.
D’une part le port 67 est le port serveur et 68 est le port client, donc il faut plutôt écrire --dport 67 --sport 68 et vice versa.
D’autre part certains paquets envoyés par un client DHCP sont diffusés avec l’adresse source indéfinie 0.0.0.0 et/ou l’adresse destination de broadcast limité 255.255.255.255. Les paquets de réponse du serveur émis avec des adresses unicast n’auront donc pas l’état ESTABLISHED mais NEW également. De manière générale le suivi de connexion de netfilter ne fonctionne qu’avec les adresses unicast, pas avec les communications utilisant le broadcast ou le multicast. Comme l’état INVALID n’existe pas en UDP, et l’état RELATED ne peux exister en UDP qu’avec un “assistant” de suivi de connexion (conntrack helper) pour le protocole applicatif considéré (qui n’existe pas pour DHCP), les paquets DHCP sont forcément dans l’état NEW ou ESTABLISHED et il est inutile de tester cet état.
Tes règles fonctionnent, mais des règles plus propres seraient donc :
iptables -A OUTPUT -p udp --dport 67 --sport 68 -o eth0 -j ACCEPT
iptables -A INPUT -p udp --sport 67 --dport 68 -i eth0 -j ACCEPT
Dernier détail : compte tenu du rôle particulier du protocole DHCP, le client peut émettre et recevoir les paquets directement sur l’interface sans passer par la couche IP (puisqu’elle n’est pas forcément encore configurée), et ceux-ci ne sont donc pas soumis aux règles iptables. Bref, tout ça pour rien.
iptables -A INPUT -p tcp sport 53 -i eth0 -m state --state ESTABLISHED -j ACCEPT
Faute de frappe à sport.
Certaines requêtes DNS particulières peuvent aussi utiliser TCP, sur le même port 53.
# netbios (tcp/udp 137-138-139)
En parlant de broadcast et de conntrack helper, il y en a justement un qui sait gérer : celui pour le protocole Netbios Name Service (UDP/138), le module nf_conntrack_netbios_ns. Utile seulement si on utilise la résolution de nom Netbios.
# cups (tcp/udp:631)
iptables -A OUTPUT -p tcp --dport 631 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 631 -i eth0 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp --dport 631 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --dport 631 -i eth0 -m state --state ESTABLISHED -j ACCEPT
Les règles dans INPUT doivent contenir --sport pour accepter les paquets retour. Sinon, c’est comme si elles acceptaient les paquets entrants à destination d’un serveur CUPS qui tournerait sur le routeur.
iptables -A OUTPUT -p udp --dport 25 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
Inutile. Le protocole SMTP n’utilise que le transport TCP, pas UDP. Par contre il peut utiliser d’autres ports : 465 (SMTP/SSL) et 587 (submission, sous-ensemble de SMTP pour l’envoi de courriel par les clients).
# On autorise toutes les connexions du LAN vers le routeur
Note que ces règles peuvent être combinées avec celles pour les connexions en sens inverse, juste en complétant les états.
# Autoriser l'accès au serveur Samba (
iptables -A INPUT -p udp --dport 137 -i br0 -j ACCEPT
iptables -A OUTPUT -p udp --
Incomplet, et inutile puisque les règles précédentes autorisent déjà toutes les connexions du LAN vers le routeur.
# Accès SSH depuis le net (tcp:2222)
iptables -A INPUT -p tcp --dport 2222 -i etho -j ACCEPT
iptables -A OUTPUT -p tcp --sport 2222 -o eth0 -j ACCEPT
Ces règles ne devraient pas être dans la section “du LAN vers le routeur”.
# Toutes les connexions qui sortent du LAN vers le Net sont acceptées
iptables -A FORWARD -i br0 -o eth0 -m state --state NEW, ESTABLISHED, RELATED -j ACCEPT
Il ne faut pas d’espace après les virgules.
Il manque la règles pour accepter les paquets dans le sens retour.
iptables -A FORWARD -p icmp -i br0-o eth0 --icmp-type echo-request -m state --state NEW -j ACCEPT
iptables -A FORWARD -p icmp -i eth0-o br0 --icmp-type echo-reply -m state --state ESTABLISHED -j ACCEPT
Espace manquant entre br0 et -o.
# Cupsd (accès imprimante partagée en wifi sur le LAN depuis n'importe quel poste du LAN)
iptables -A FORWARD -p tcp --dport 631 -i br0 -o eth0 -m --state NEW, ESTABLISHED, RELATED -j ACCEPT(autorisé à sortir)
Il manque la règle pour accepter les paquets dans le sens retour.
Mais inutile puisque les règles précédentes acceptent toutes les connexions du LAN vers l’extérieur.
Eh bien…j’ai encore pas mal de travail 
Je ne comprends pas bien ce que tu veux dire : les règles pour DHCP ne sont pas nécessaires ?
Je me suis effectivement posé la question. Et…je ne sais plus ce que j’ai répondu à ce moment (dans ma tête). Je crois que j’ai dû pensé que ses programmes avaient besoin de se connecter à un serveur extérieur pour je ne sais quelle mise à jour éventuel et donc j’ai conclu qu’il fallait leur ouvrir l’accès extérieur. Donc :
-Dansguardian : non (la liste noire est un fichier .tar à récupérer sur le site de l’université de toulouse)
Les proxy des navigateurs des machines du LAN sont paramétrés sur le port 8080 (celui de Dansguardian) et Dansguardian écoute sur le port 3128 (celui de Squid).
A l’Aller : le paquet passe par Dansguardian puis Squid et sort sur le net.
Au retour : il fait le chemin inverse.
-Nut : il me semble qu’il a besoin de mettre à jour la date ou quelque chose de ce genre. Il lui faut donc un accès à l’extérieur ?
-RPC : je ne sais pas 
Je ne comprends pas. Peux-tu me donner un exemple ?
Tu as bien compris. Par expérience j’ai constaté qu’elles n’étaient pas toujours nécessaires. Je n’ai pas testé toutes les versions de clients DHCP, alors autant les garder par précaution, ça ne coûte rien.
Ces programmes sont des services qui acceptent des connexions de clients sur les ports correspondants. Mais lorsqu’ils se comportent eux-même en clients et se connectent à d’autres services, ils n’utilisent pas ces mêmes ports pour leurs connexions sortantes.
Quand un proxy HTTP comme squid se connecte à un site web sur demande d’un client, il utilise le port HTTP ou HTTPS du serveur, pas le port de proxy. Dansgardian ne se connecte pas à un autre serveur Dansguardian mais à squid qui tourne sur la même machine, donc avec du trafic sur l’interface de loopback uniquement. Pour sa mise à jour il récupère le fichier tar sur un serveur web en HTTP ou HTTPS.
Un navigateur ne sert pas du tout à aller sur le net. Il sert à aller sur des sites web qui peuvent être sur n’importe quel serveur accessible par le réseau (interne, externe…).
Je ne vois pas bien pourquoi un programme de gestion d’alimentation sans interruption (“onduleur”) aurait besoin de faire ça. La synchronisation de l’horloge se fait habituellement avec le protocole NTP (UDP port 123), mais c’est plutôt un démon comme ntpd qui s’en occupe.
Tu as les règles suivantes pour les connexions vers et depuis le LAN :
iptables -A INPUT -i br0 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o br0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT - i br0 -m state --state NEW, ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o br0 -m state --state ESTABLISHED -j ACCEPT
(au passage il y a un espace en trop entre - et i dans la 3e règle que je n’avais pas remarqué)
Tu noteras qu’il y a une certaine redondance entre ces règles. On peut combiner en deux règles :
iptables -A OUTPUT -o br0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i br0 -m state --state NEW, ESTABLISHED -j ACCEPTC’est çà dont je voulais parler !
Tu veux dire que tu as confondu NUT et NTP ?
Non, je pensais que le programme NUT avait un serveur de synchronisation d’horloge intégré. Grâce à toi je viens de me rendre compte que non. Il s’agit de NTP.