IPTables - Historique des versions

Justine le 4 janvier 2023 à 13:53

2023-01-04T13:53:05Z

@@ Ligne 126 : / Ligne 126 : @@
 = Commandes =
 == Changer la stratégie par défaut ==
 Par défaut, toutes les chaînes finissent sur un ACCEPT. On peut modifier cela facilement:

Justine le 22 juin 2022 à 11:55

2022-06-22T11:55:34Z

← Version précédente		Version du 22 juin 2022 à 11:55
Ligne 1 :		Ligne 1 :
			[[Category:reseau]]
			[[Category:linux]]
	= Généralités : les pare-feux Linux =		= Généralités : les pare-feux Linux =
	https://cybersecuritynews.com/linux-firewall-iptables/		https://cybersecuritynews.com/linux-firewall-iptables/

Justine le 29 novembre 2021 à 15:11

2021-11-29T15:11:42Z

← Version précédente		Version du 29 novembre 2021 à 15:11
Ligne 430 :		Ligne 430 :

	_subnets=("224.0.0.0/3" "169.254.0.0/16" "172.16.0.0/12" "192.0.2.0/24" "192.168.0.0/16" "10.0.0.0/8" "0.0.0.0/8" "240.0.0.0/5")for _sub in "${_subnets[@]}" ; do iptables -t mangle -A PREROUTING -s "$_sub" -j DROPdoneiptables -t mangle -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP		_subnets=("224.0.0.0/3" "169.254.0.0/16" "172.16.0.0/12" "192.0.2.0/24" "192.168.0.0/16" "10.0.0.0/8" "0.0.0.0/8" "240.0.0.0/5")for _sub in "${_subnets[@]}" ; do iptables -t mangle -A PREROUTING -s "$_sub" -j DROPdoneiptables -t mangle -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP

			= Iptables, firewalld, et docker =
			Par défaut, Docker fait un peu ce qu'il veut avec les pare-feux. Notamment, si l'on utilise Firewalld, il ignore ce que l'on fait avec nos tables FirewallD : il se fait ses propres chaînes dans IPTables.

			C'est dû au fait que par défaut, Docker est lancé avec l'option --iptables (modifiable semble-t'il dans /etc/daemon.json.

			Hors, cela ne nous arrange pas forcément. Pour contrôler la façon dont docker accède au réseau, il va falloir modifier dans iptables sa chaîne DOCKER-USER. Par exemple, dans mon cas, je ne veux pas que l'on puisse accéder à mes conteneurs depuis mon interface menant sur le net, eth0. Je vais donc devoir lui dire :

			<source>
			iptables -I DOCKER-USER 1 -i eth0 -j DROP
			</source>

			Ici, je place ma règle à la première place, car autrement elle se retrouve après la règle qui laisse tout passer.
			En effet, docker se créée plusieurs chaînes dans IPTables : DOCKER (qu'il ne sert à rien de modifier : ça ne tient pas au reboot dans aucun cas.) et DOCKER-USER que l'on peut modifier.

			Mais... Ça n'est pas terrible. J'utilise firewalld sur tous mes serveurs, et j'aimerais bien dire à Docker de ne pas faire joujou avec iptables.

			Il va donc falloir lui dire ne plus y toucher ! Pour cela, on va changer ses options de lancement.

			Je lui créée un répertoire de config Systemd :
			<source>
			mkdir -p /etc/systemd/system/docker.service.d
			</source>

			Puis je lui créée une config modifiant ses options de lancement pour ajouter --iptables=false:
			<source>
			[Service]
			ExecStart=
			ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --iptables=false
			</source>

			Rechargement des fichiers, redémarrage pour voir :
			<source>
			systemctl daemon-reload
			systemctl restart docker
			systemctl status docker
			</source>
			Puis je reboote pour bien faire le ménage dans les chaînes IPTables. Au redémarrage, un iptables -L ne devrait plus montrer de chaînes DOCKER. Il ne reste plus qu'à vérifier que les conteneurs communiquent correctement.

Justine : /* Tout un tas de règles utiles */

2021-08-25T13:48:33Z

Tout un tas de règles utiles

← Version précédente		Version du 25 août 2021 à 13:48
Ligne 174 :		Ligne 174 :

	== Tout un tas de règles utiles ==		== Tout un tas de règles utiles ==
			https://www.andreafortuna.org/2019/05/08/iptables-a-simple-cheatsheet/

	=== Allow Loopback Connections ===		=== Allow Loopback Connections ===

Justine le 25 août 2021 à 13:47

2021-08-25T13:47:59Z

Voir les modifications

Justine le 25 août 2021 à 13:34

2021-08-25T13:34:12Z

@@ Ligne 77 : / Ligne 77 : @@
 * Non-terminating targets : Celles-ci ne terminent pas l'évaluation de la chaîne. Elles font une action et laisse l'évaluation de la chaîne continuer. Bien que toute chaîne doive donner une décision finale, un certain nombre de non-terminating targets peuvent avoir lieu entretemps.
 La disponibilité de chacune des targets dépend de la table et de la chaîne, cela est fonction du contexte.
 == Jumping et chaînes utilisateur ==
@@ Ligne 97 : / Ligne 124 : @@
 = Aller plus loin =
 [https://www.digitalocean.com/community/tutorials/how-to-choose-an-effective-firewall-policy-to-secure-your-servers Article sur les stratégies de fw]

Justine : /* Tables et chaînes */

2021-08-25T13:11:29Z

Tables et chaînes

← Version précédente		Version du 25 août 2021 à 13:11
Ligne 27 :		Ligne 27 :
	=== Tables et chaînes ===		=== Tables et chaînes ===
	[[Fichier:Iptablesstruct.jpg\|sans_cadre]]		[[Fichier:Iptablesstruct.jpg\|sans_cadre]]

	Iptables utilise des tables pour stocket ses règles : il s'agit de tables au même sens que dans une BDD. Ces tables sont chacune fonction d'un type de décision, et vont stocker des règles en rapport : par exemple, la table nat stocke tout ce qui a trait au nat. La table filter gère le filtrage des paquets en fonction de leur destination, par exemple.		Iptables utilise des tables pour stocket ses règles : il s'agit de tables au même sens que dans une BDD. Ces tables sont chacune fonction d'un type de décision, et vont stocker des règles en rapport : par exemple, la table nat stocke tout ce qui a trait au nat. La table filter gère le filtrage des paquets en fonction de leur destination, par exemple.

Justine le 25 août 2021 à 13:09

2021-08-25T13:09:22Z

← Version précédente		Version du 25 août 2021 à 13:09
Ligne 93 :		Ligne 93 :
	* SNAT : État virtuel dans lequel l'adresse source a été altérée par le NAT. Utilisé par le système de tracking pour qu'il soit au courant qu'il doit changer l'adresse lors de la réponse.		* SNAT : État virtuel dans lequel l'adresse source a été altérée par le NAT. Utilisé par le système de tracking pour qu'il soit au courant qu'il doit changer l'adresse lors de la réponse.
	* DNAT : Même chose, mais avec l'adresse de destination. Ainsi, le système saura qu'il doit changer l'adresse de réponse lors du routage du paquet.		* DNAT : Même chose, mais avec l'adresse de destination. Ainsi, le système saura qu'il doit changer l'adresse de réponse lors du routage du paquet.

			= Aller plus loin =
			[https://www.digitalocean.com/community/tutorials/how-to-choose-an-effective-firewall-policy-to-secure-your-servers Article sur les stratégies de fw]

Justine le 25 août 2021 à 13:05

2021-08-25T13:05:45Z

← Version précédente		Version du 25 août 2021 à 13:05
Ligne 83 :		Ligne 83 :
	Le suivi de connexion implémenté par-dessus netfilter a déjà été évoqué avec la table raw. Ce suivi de connexion permet à iptables de voir les paquets dans le contexte d'une connexion et non pas comme un simple paquet tout seul et ainsi d'avoir un pare-feu stateful.		Le suivi de connexion implémenté par-dessus netfilter a déjà été évoqué avec la table raw. Ce suivi de connexion permet à iptables de voir les paquets dans le contexte d'une connexion et non pas comme un simple paquet tout seul et ainsi d'avoir un pare-feu stateful.

	Le suivi de connexion s'applique très tôt après l'arrivée d'un paquet dans la stack.		Le suivi de connexion s'applique très tôt après l'arrivée d'un paquet dans la stack, et la seule logique appliquée avant ça est la table raw ainsi que certains contrôles de sanité. Le système vérifie chaque paquet en regard d'un ensemble de connexions existantes, et mets à jour le statut des connexions si besoin. Les paquets marqués avec NOTRACK dans une règle de la table raw échapperont à cette logique de connexion.

			Une connexion peut avoir plusieurs états:
			* NEW : Si un paquet arrive, qu'il n'est pas associé à une connexion et est valide en tant que premier paquet, une connexion NEW est ajoutée. Cela se produit pour TCP par exemple, mais aussi pour des protocoles sans connexion comme UDP.
			* ESTABLISHED : Une connection NEW qui reçoit une réponse valide passe à l'état ESTABLISHED. En TCP, cela signifie un syn/ack, et pour UDP ou ICMP une réponse ou la source et la destination du paquet sont inversées par rapport au premier paquet.
			* RELATED : Les paquets ne faisant pas partie d'une connexion mais étant en lien avec l'une de celles-ci sont marqués RELATED. Cela peut signifier une connexion "helper", comme avec le FTP et ses transmissions d'envoi de données ou bien des réponses ICMP à des tentatives de connexion d'autres protocoles.
			* INVALID : Les paquets n'étant pas liés à une connexion et ne pouvant pas commencer une connexion sont marqués comme INVALID. Ils peuvent par exemple être impossible à identifier, inroutables, etc.
			* UNTRACKED : Les paquets seront marqués UNTRACKED si une règle de la table raw leur fait bypasser le tracking.
			* SNAT : État virtuel dans lequel l'adresse source a été altérée par le NAT. Utilisé par le système de tracking pour qu'il soit au courant qu'il doit changer l'adresse lors de la réponse.
			* DNAT : Même chose, mais avec l'adresse de destination. Ainsi, le système saura qu'il doit changer l'adresse de réponse lors du routage du paquet.

Justine le 25 août 2021 à 12:54

2021-08-25T12:54:29Z

← Version précédente		Version du 25 août 2021 à 12:54
Ligne 57 :		Ligne 57 :
	Ainsi, un paquet entrant pour le système local va passer par PREROUTING et activer les chaînes des tables raw, mangle, nat; puis par INPUT et activer les chaines des tables mangle,filter,security,nat. Dans cet ordre.		Ainsi, un paquet entrant pour le système local va passer par PREROUTING et activer les chaînes des tables raw, mangle, nat; puis par INPUT et activer les chaines des tables mangle,filter,security,nat. Dans cet ordre.

	~~A CONTINUER A PARTIR DE LA SECTION IPTABLE RULES https~~://~~www.digitalocean.com~~/~~community~~/~~tutorials/a~~-~~deep~~-~~dive~~-~~into~~-~~iptables~~-~~and~~-netfilter-~~architecture~~		= Règles IPTables =
			Les règles se placent à l'intérieur des chaînes. Lorsqu'un paquet déclenche la chaîne, il est comparé aux règles, une par une et dans l'ordre.

			== Match ==
			La portion 'matching' d'une règle spécifie les critères pour lesquels un paquet pour l'action (ou target) de la règle soit exécutée. Le système de matching est souple et peut être étendu à l'aide des extensions d'IPTables disponibles au niveau du système. Les règles peuvent matcher sur :
			* protocole
			* adresse source / dst
			* port source / dst
			* réseau source / dst
			* interface entrée / sortie,
			* les headers
			* l'état de la connection
			* et autres, les critères pouvant être combinés.

			== Targets ==
			Les targets, qui sont les actions déclenchées lors d'un match, peuvent être divisées en 2 catégories:
			* Terminating targets : Ce genre de target termine l'évaluation de la chaîne : on ne traite plus de règles après celles-ci et on renvoie le contrôle au hook netfilter. En fonction de la valeur retournée, on peut dropper le paquet ou le laisser continuer sur la chaine.
			* Non-terminating targets : Celles-ci ne terminent pas l'évaluation de la chaîne. Elles font une action et laisse l'évaluation de la chaîne continuer. Bien que toute chaîne doive donner une décision finale, un certain nombre de non-terminating targets peuvent avoir lieu entretemps.
			La disponibilité de chacune des targets dépend de la table et de la chaîne, cela est fonction du contexte.

			== Jumping et chaînes utilisateur ==
			Bien que les chaînes soit fortement liées aux hooks netfilter, l'utilisateur peut créer ses propres chaînes qui seront prises en compte. Les jump targets sont des actions qui font que l'évaluation passera à une autre chaîne pour prise en compte. Les règles vont dans les chaînes utilisateurs de la même manière que pour les autres chaînes; cependant, elle ne seront atteintes qu'après un jump vers celle-ci. En effet, les chaînes utilisateur n'agissent que comme une extension de la chaîne y menant : lors de l'évaluation dans une chaîne utilisateur, l'évaluation retournera à la chaîne d'origine si on atteint une target RETURN ou le bout de la chaîne utilisateur. L'évaluation peut aussi JUMP vers une autre chaîne.

			= Suivi de connexions =
			Le suivi de connexion implémenté par-dessus netfilter a déjà été évoqué avec la table raw. Ce suivi de connexion permet à iptables de voir les paquets dans le contexte d'une connexion et non pas comme un simple paquet tout seul et ainsi d'avoir un pare-feu stateful.

			Le suivi de connexion s'applique très tôt après l'arrivée d'un paquet dans la stack.