Pare-feu IPv4/IPv6, versions bureau serveur

Support Debian
#1

Bonjour,

J’aurais besoin d’un petit renseignement au sujet du post sur Pare-feu IPv4/IPv6, versions bureau serveur https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur/68665.

J’espère ne pas me méprendre en disant que lorsque l’on utilise le paquet iptables-persistant, on ne doit pas créer le fichier init-firewall dans le dossier /etc/init.d mais seulement recopier , dans un terminal, les règles de ledit fichier avant d’inscrire les règles de configuration, c’est bien ça?

Exemple:

iptables -t filter -F
iptables -t nat -F
iptables -t mangle -F
iptables -t raw -F
iptables -t filter -P INPUT ACCEPT
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P INPUT ACCEPT
iptables -t nat -P OUTPUT ACCEPT
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT
iptables -t mangle -P FORWARD ACCEPT
iptables -t mangle -P INPUT ACCEPT
iptables -t raw -P OUTPUT ACCEPT
iptables -t raw -P PREROUTING ACCEPT

ip6tables -t filter -F
ip6tables -t nat -F
ip6tables -t mangle -F
ip6tables -t raw -F
ip6tables -t filter -P INPUT ACCEPT
ip6tables -t filter -P OUTPUT ACCEPT
ip6tables -t filter -P FORWARD ACCEPT
ip6tables -t nat -P PREROUTING ACCEPT
ip6tables -t nat -P POSTROUTING ACCEPT
ip6tables -t nat -P INPUT ACCEPT
ip6tables -t nat -P OUTPUT ACCEPT
ip6tables -t mangle -P PREROUTING ACCEPT
ip6tables -t mangle -P OUTPUT ACCEPT
ip6tables -t mangle -P POSTROUTING ACCEPT
ip6tables -t mangle -P FORWARD ACCEPT
ip6tables -t mangle -P INPUT ACCEPT
ip6tables -t raw -P OUTPUT ACCEPT
ip6tables -t raw -P PREROUTING ACCEPT


iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m conntrack --ctstate NEW -m limit --limit 1/s --limit-burst 1 -j ACCEPT
iptables -A INPUT -p tcp --dport xxxx -j ACCEPT
iptables -A INPUT -p udp --dport xxxx -j ACCEPT

ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT
ip6tables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -m conntrack --ctstate NEW -m limit --limit 1/s --limit-burst 1 -j ACCEPT
ip6tables -A INPUT -p tcp --dport xxxx -j ACCEPT
ip6tables -A INPUT -p udp --dport xxxx -j ACCEPT

sudo -s iptables-save -c

Merci de m’éclairer

#2

Non, ça crée plutôt deux fichiers : /etc/iptables/rules.v4 et /etc/iptables/rules.v6 qui est formaté autrement (mais c’est sensiblement compréhensible si tu comprends ton fichier).

#3

Oui, j’étais au courant que iptables-persistant créait deux fichiers mais je pensais supprimer certaines règles dans ces derniers par la suite: supprimer les règles ipv6 du fichier ipv4 et vice versa.

#4

Il n’y a pas de règles IPv6 dans le fichier IPv4 et vice versa. Les jeux de règles IPv4 et IPv6 sont distincts.

#5

J’ai du mal à comprendre!
Mon script est-il correct ou pas? Que dois-je modifier?

#6

En fait, je ne sais pas, j’ai plutôt l’habitude des fichiers de configuration de iptables-persistant ou du retour de iptables-save…

#7

Moi aussi j’utilise iptables-persistant. C’est pour cela que je me demande ce que je dois modifier dans mon script pour qu’il fonctionne avec iptables-persistant.

#8

En fait, il faut que tu lances ton script pour appliquer tes règles iptables, puis tu lances la configuration de iptables-persistant. C’est comme ça que je fais à chaque fois.

#9

oui d’accord mais les règles de mon script (https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003 )sont-elles correctes? Peut-on les utiliser avec iptables-persistant?

#10

iptables-persistent se fiche de ton script et des règles qu’il met en place. Il se contente de les rendre persistantes.
Quant à savoir si elles sont “correctes”, ça dépend de ce que tu veux qu’elles fassent.

#11

La configuration est destinée à une machine bureau. C’est pour cela que j’ai simplement recopié le script “Pour une machine de bureau” du tuto “Pare-feu IPV4/IPv6, versions bureau et serveur” (https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur/68665 )car je n’ai pas besoin de plus.
La seule question que je me pose est pour la première partie du script, celle dédiée au “nettoyage” du firewall: est-il indispensable de rajouter ces règles? D’habitude, je me contentai seulement de “ipatbles -F” et “iptables -X”.

#12

Il est évident que des séquences comme

iptables -t filter -P INPUT ACCEPT
iptables -P INPUT DROP

où la seconde commande fait l’inverse de la première, sont absurdes.
D’autre part, si le but est d’effacer toute trace du jeu de règles antérieur, il manque les commandes -X pour effacer les éventuelles chaînes utilisateur.

En revanche la réinitialisation de toutes les tables, même celles que tu n’utilises pas, a du sens : en effet un jeu de règles enregistré par iptables-save (utilisé par iptables-persistent) ne réinitialise que les tables présentes lors de la sauvegarde.

#13

Donc, je dois commencer le script par:
sudo iptables -L
sudo iptables -X

Et ensuite, je réinitialise toutes les tables, c’est bien ça?

Je comprends que les 2 commandes soient absurdes mais pourquoi sont-elles présentes dans le fil https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur/68665 ?

#14
  1. On n’utilise pas sudo dans un script.
  2. Il faut faire la même chose pour toutes les autres tables (la table par défaut est “filter”).

“Ensuite” ? Les commandes ci-dessus font déjà partie des opérations ayant pour but de réinitialiser une table.

Je ne suis pas responsable de ce que les autres écrivent.

1 J'aime
#15

Petite erreur de frappe dans mon poste précédent. Ce n’était iptables -L mais iptables -F .

Voici le script rectifié:

#table filter
iptables -t filter -F
iptables -t filter -X
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT

#table NAT
iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

#table mangle
iptables -t mangle -F
itpables -t mangle -X
ptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT
iptables -t mangle -P FORWARD ACCEPT
iptables -t mangle -P INPUT ACCEPT

#table raw
iptables -t raw -F
itpables -t raw -X
iptables -t raw -P OUTPUT ACCEPT
iptables -t raw -P PREROUTING ACCEPT


#autorise lo
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

#maintenir les connexions établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


#accepte ping 
iptables -A INPUT -p icmp --icmp-type echo-request -m conntrack --ctstate NEW -m limit --limit 1/s --limit-burst 1 -j ACCEPT


# On log les paquets en entrée.
iptables -A INPUT -j LOG

# On log les paquets forward.
iptables -A FORWARD -j LOG
#16

Je n’avais même pas remarqué la coquille -L/-F.

  • Table nat (et non NAT, le nom des tables est en minuscule) : il manque la définition de la politique par défaut de la chaîne INPUT, pourtant présente dans ton script initial. Tu a peut-être été influencé par la lecture de scripts écrits avant que la chaîne INPUT soit ajoutée à la table nat (c’est relativement récent comparativement à l’âge d’iptables).

    iptables -t nat -P INPUT ACCEPT

  • Table mangle : faute de frappe à une commande.

    ptables -t mangle -P PREROUTING ACCEPT

  • Règles de filtrage :

iptables -A OUTPUT -o lo -j ACCEPT

Cette règle est redondante puisque la politique par défaut de la chaîne OUTPUT est déjà ACCEPT.

iptables -A INPUT -p icmp --icmp-type echo-request -m conntrack --ctstate NEW -m limit --limit 1/s --limit-burst 1 -j ACCEPT

Quel est la limitation précise que cette règle est supposée imposer ?

Il faut avoir à l’esprit que tous les paquets ICMP echo-request et echo-reply d’une même séquence sont considérés comme appartenant à la même “connexion” (au sens de netfilter), un séquence étant par exemple l’ensemble des paquets émis et reçus lors de l’exécution continue d’une commande ping. Par conséquent si le destinataire répond au ping, seul le premier paquet ICMP echo-request d’une séquence a l’état NEW, les suivants ont l’état ESTABLISHED.

La conséquence sur ton jeu de règles, qui accepte tous les paquets entrants dans l’état ESTABLISHED, est que le nombre de requêtes appartenant à une même séquence par seconde n’est pas limité ; seul le nombre de séquences différentes par seconde l’est. Est-ce bien ce que tu souhaites ?

1 J'aime
#17

Merci d’avoir rectifié le script.

Oui c’est vrai, j’ai lu plusieurs tutos qui datent d’années différentes.

Mon idée de départ était de bloquer les requêtes ICMP car je pense que cela n’a aucune utilité pour moi. Je n’ai jamais utilisé la commande ping et je ne le ferais sans doute jamais.

Les règles que je mettais étaient celles-ci :

iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j DROP

Grâce à ces deux commandes, mon PC ne répond plus aux requêtes « ping ». Mais me permettent-elles quand même d’effectuer des pings ? Peut-être qu’un jour j’aurais besoin de vérifier si un serveur est joignable !

#18

La seconde règle est inutile car si les requêtes echo-request sont bloquées, aucune réponse echo-reply n’est émise.

Note qu’il y a un autre moyen plus simple d’empêcher ta machine de répondre au ping :

net.ipv4.icmp_echo_ignore_all=1

dans /etc/sysctl.conf ou dans un fichier /etc/sysctl.d/*.conf pour désactiver la réponse au ping.

Ces deux règles n’empêchent pas le ping sortant qui fait intervenir des paquets ICMP echo-request ayant l’état NEW ou ESTABLISHED dans la chaîne OUTPUT et des paquets ICMP echo-reply ayant l’état ESTABLISHED (dans le cas d’un ping unicast) ou INVALID (dans le cas d’un ping broadcast ou multicast, le suivi de connexion de netfilter ne gérant pas ces modes de communication) dans la chaîne INPUT.

#19

Je vais alors plutôt modifier le fichier systctl.conf.
J’ai donc réécrit le script :

#table filter
iptables -t filter -F
iptables -t filter -X
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT

#table nat
iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P INPUT ACCEPT
iptables -t nat -P OUTPUT ACCEPT

#table mangle
iptables -t mangle -F
itpables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT
iptables -t mangle -P FORWARD ACCEPT
iptables -t mangle -P INPUT ACCEPT

#table raw
iptables -t raw -F
itpables -t raw -X
iptables -t raw -P OUTPUT ACCEPT
iptables -t raw -P PREROUTING ACCEPT


#autorise lo
iptables -A INPUT -i lo -j ACCEPT

#maintenir les connexions établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# On log les paquets en entrée.
iptables -A INPUT -j LOG

# On log les paquets forward.
iptables -A FORWARD -j LOG

Quelques dernières questions :

Du point de vue de la sécurité, ne serait-il pas plus prudent de droper aussi l’OUTPUT de la table filter et ensuite de maintenir les connexions établies et d’accepter en sortie lo…

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack ! --ctstate INVALID -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -i lo -j ACCEPT (enfin, peut-être que cette règle est superflue vu que je maintiens les connexions établies en OUTPUT)

J’ai aussi lu qu’il fallait autoriser tout le trafic loopback et droper tout le trafic vers 127/8 qui n’utilise pas lo.
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i lo -d 127.0.0.0/8 -j DROP

Pour ce qui est de se protéger des scans XMAS et NULL:

iptables -A INPUT -p tcp --tcp-flags FIN,URG,PSH FIN,URG,PSH -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
#20

J’ai mentionné le fichier sysctl.conf car c’est l’emplacement historique où on plaçait ce genre de réglage. Cependant il est géré en “conffile” (fichier de configuration) du paquet procps par dpkg, donc si une mise à jour du paquet fournit une nouvelle version du fichier, le système détectera que le fichier d’origine a été modifié localement et il faudra choisir entre conserver le fichier ou le remplacer par la nouvelle version. La tendance actuelle est plutôt de créer un fichier *.conf dans /etc/sysctl.d/. Avantages : on peut créer des fichiers distincts pour différentes catégories de réglages (réseau, gestion de la mémoire, du noyau…), ce qui facilite la maintenance, et ces fichiers ne sont pas affectés par les mises à jour de procps. La même tendance existe pour les fichiers de configuration de modprobe et X.org.

Bof. Ça ne fera que bloquer les paquets ayant l’état INVALID émis par la machine. Et je ne vois pas le rapport avec l’interface de loopback. Il n’y a pas plus de paquets INVALID émis sur l’interface de loopback que sur les autres interfaces. Au passage la première règle est superflue puisque la seconde accepte la même chose et plus encore. La troisième règle est en doublon avec un règle déjà présente dans le script.

Contre quel type de menace veux-tu protéger ta machine en filtrant dans OUTPUT ? Si tu veux vraiment filtrer dans OUTPUT, il faut n’accepter que les flux dont tu as besoin, comme en INPUT. La difficulté étant de lister exhaustivement ces flux.

Ton script le fait déjà, pas besoin d’en rajouter.

Oui. Il me semble que la pile IP de Linux le fait déjà nativement, mais il y a longtemps que j’ai étudié ce genre de choses. Ça ne coûte pas cher d’ajouter une règle pour être tranquille.

Pourquoi pas, mais ces combinaisons de drapeaux TCP sont invalides et les paquets devraient être classés dans l’état INVALID par le suivi de connexion.