Vous n'êtes pas identifié(e).
L'icône rouge permet de télécharger chaque page du wiki visitée au format PDF et la grise au format ODT →
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
doc:reseau:iptables-pare-feu-pour-un-client [06/01/2019 03:13] Beta-Pictoris |
doc:reseau:iptables-pare-feu-pour-un-client [31/05/2023 20:57] (Version actuelle) lagrenouille [iptables: un pare-feu pour un client] |
||
---|---|---|---|
Ligne 4: | Ligne 4: | ||
* Niveau requis : {{tag> avisé}} | * Niveau requis : {{tag> avisé}} | ||
* Commentaires : //Contexte d'utilisation du sujet du tuto. // | * Commentaires : //Contexte d'utilisation du sujet du tuto. // | ||
- | * Suivi : {{tag>à-tester}} | + | * Suivi : {{tag>à-placer}} |
* Création par [[user>Hypathie]] 08/10/2014 | * Création par [[user>Hypathie]] 08/10/2014 | ||
* Testé par <...> le <...> | * Testé par <...> le <...> | ||
Ligne 42: | Ligne 42: | ||
Comme un pare-feu classique, iptables contrôle les ports sur une interface réseau par laquelle les paquets peuvent entrer, transiter, sortir, être rejetés.\\ | Comme un pare-feu classique, iptables contrôle les ports sur une interface réseau par laquelle les paquets peuvent entrer, transiter, sortir, être rejetés.\\ | ||
- | Ce reporter à la documentation interne (lien en vert) pour la mise en place des services listés ci-dessous.\\ | + | Se reporter à la documentation interne (lien en vert) pour la mise en place des services listés ci-dessous.\\ |
Vous y trouverez : leur installation et leur configuration, tel que la modification du port par défaut pour certains de ces protocoles.\\ | Vous y trouverez : leur installation et leur configuration, tel que la modification du port par défaut pour certains de ces protocoles.\\ | ||
Ligne 120: | Ligne 120: | ||
>> **''destination''** : l'IP de destination de l'ordinateur auquel on se connecte (pour OUTPUT) | >> **''destination''** : l'IP de destination de l'ordinateur auquel on se connecte (pour OUTPUT) | ||
- | > **La troisième ligne ''Chain FORWARD (policy ACCEPT)''** concerne les paquets qui passent d'une interface à une autres d'un PC (**''FORWARD''**). La maîtrise par iptables de la chaîne FROWARD permet de rediriger le trafique. | + | > **La troisième ligne ''Chain FORWARD (policy ACCEPT)''** concerne les paquets qui passent d'une interface à une autres d'un PC (**''FORWARD''**). La maîtrise par iptables de la chaîne FORWARD permet de rediriger le trafic. |
> En dessous les mêmes titres de la futur table qui est vide pour l'instant. | > En dessous les mêmes titres de la futur table qui est vide pour l'instant. | ||
Ligne 256: | Ligne 256: | ||
<note important> | <note important> | ||
- | Depuis debian **Stretch**, **conntrack** ne va plus associer de paquets à l'état **RELATED**, sauf pour le protocole **icmp**.\\ | + | Depuis debian **Stretch**, **conntrack** ne va plus marquer de paquets en **RELATED**, sauf pour le protocole **icmp**.\\ |
\\ | \\ | ||
- | Si vous voulez faire du filtrage sur des paquets dans l'état **RELATED** pour d'autres protocoles, il va falloir déclencher l'activation d'un module **conntrack**, appelé module **helper**, en cas de connexion sur un port particulier.\\ | + | Par conséquent, si vous voulez faire du filtrage sur des paquets dans l'état **RELATED** pour d'autres protocoles qu'**icmp**, vous devrez créer une règle particulière, de **PREROUTING**, dans la table **raw**.\\ |
\\ | \\ | ||
- | Pour cela, il va falloir créer une règle particulière, de **PREROUTING**, dans la table **raw**.\\ | + | Cette règle va déclencher l'activation d'un module **conntrack** (appelé module **helper**) en cas de connexion sur un port particulier.\\ |
\\ | \\ | ||
A noter, la cible de cette règle s'appelle **CT** (Pour **C**onn**T**rack ?).\\ | A noter, la cible de cette règle s'appelle **CT** (Pour **C**onn**T**rack ?).\\ | ||
\\ | \\ | ||
- | Par exemple, pour le protocole **ftp**, si on veut qu'une nouvelle connexion **tcp** entrante, vers le port 21 du serveur, puisse générer une réponse dans l'état **RELATED** :\\ | + | Par exemple, pour le protocole **ftp**, si vous souhaitez qu'une nouvelle connexion **tcp** entrante, vers le port 21 du serveur, puisse permettre une réponse dans l'état **RELATED** :\\ |
- | <code root>iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp</code> | + | |
- | Pour information, la règle précédente va activer le module **nf_conntrack_ftp**.\\ | + | |
\\ | \\ | ||
- | **conntrack** associera, donc, l'état **RELATED** a une nouvelle connexion **tcp**, sortante du port 20 du serveur (cas d'un serveur ftp actif) à condition qu'une nouvelle connexion **tcp** entrante, vers le port 21 du serveur ait été acceptée.\\ | + | <code root>iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp</code> |
+ | Pour information, la règle précédente va activer le module **helper** //nf_conntrack_ftp//.\\ | ||
\\ | \\ | ||
- | Pour cela, on autorise de nouvelles connexions entrantes sur le port 21 :\\ | + | Vous devez aussi autoriser de nouvelles connexions entrantes sur le port 21 :\\ |
<code root>iptables -A INPUT -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT</code> | <code root>iptables -A INPUT -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT</code> | ||
\\ | \\ | ||
- | On devra, donc, utiliser la règle suivante pour autoriser la suite de l'échange sur le port 20 (cas d'un serveur ftp actif) :\\ | + | **Conntrack** associera l'état **RELATED** au nouveau paquet **tcp** sortant du port 20 du serveur (cas d'un serveur ftp actif). |
+ | Vous devez, donc, autoriser la connexion :\\ | ||
<code root>iptables -A OUTPUT -p tcp --sport 20 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT</code> | <code root>iptables -A OUTPUT -p tcp --sport 20 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT</code> | ||
\\ | \\ | ||
Vous devez, donc, toujours, traiter les paquets étant dans l'état **RELATED** à partir du moment où ils existent, sinon ils seront perdus et cela entrainera des problèmes de communication !\\ | Vous devez, donc, toujours, traiter les paquets étant dans l'état **RELATED** à partir du moment où ils existent, sinon ils seront perdus et cela entrainera des problèmes de communication !\\ | ||
\\ | \\ | ||
- | Si le module helper, qui gère l'état **RELATED**, n'est pas activé, **conntrack** associera les paquets à l'état **NEW**.\\ | + | Si vous ne souhaitez pas activer le module helper, qui gère l'état **RELATED**, **conntrack** associera les paquets à l'état **NEW**. Vous devrez, donc, utiliser la règle suivante :\\ |
- | On devra, donc, utiliser la règle suivante :\\ | + | |
<code root>iptables -A OUTPUT -p tcp --sport 20 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT</code> | <code root>iptables -A OUTPUT -p tcp --sport 20 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT</code> | ||
- | L'état **RELATED** est plus sûr que l'état **NEW** puisque qu'il n'autorise de nouvelles connexions que si une connexion préalable existait déjà sur un autre port ou avec un autre protocole. | + | Pourquoi préférer l'état **RELATED** à l'état **NEW** ?\\ Parce qu'il est plus sûr car il n'autorise de nouvelles connexions que si une connexion préalable existait déjà sur un autre port ou avec un autre protocole. |
</note> | </note> | ||