ip6tables configuration

raleur · 05-05-2019 14:12:10

Je ne me suis pas encore frotté à l'intégration directe d'iptables avec systemd ni NetworkManager.
Je n'ai mis en place des jeux de règles iptables que sur deux machines servant de pare-feu dédié. Aucune n'utilise NetworkManager. Une n'utilise pas systemd mais sysvinit avec insserv, j'ai donc mis en place un script d'init avec un en-tête LSB pour démarrer dans le runlevel S avant le réseau.

### BEGIN INIT INFO

# Provides: firewall

# Required-Start: $local_fs

# Should-Start:

# Required-Stop: $local_fs

# Should-Stop:

# X-Start-Before: $network

# X-Stop-After: $network

# Default-Start: S

# Default-Stop: 0 6

# Short-description: iptables-based firewall

### END INIT INFO

L'autre machine a systemd, mais je n'ai pas créé de service natif, j'ai utilisé la prise en charge des anciens scripts sysvinit. J'ai dû adapter l'en-tête LSB car le runlevel S ne semble plus pris en compte.

### BEGIN INIT INFO

# Provides: firewall

# Required-Start: $local_fs

# Should-Start:

# Required-Stop: $local_fs

# Should-Stop:

# X-Start-Before: $network

# X-Stop-After: $network

# Default-Start: S 1 2 3 4 5

# Default-Stop: 0 6

# Short-description: iptables-based firewall

### END INIT INFO

abumbra · 07-05-2019 20:28:47

Salutations !

Merci encore pour cette réponse.

J'ai fait pas mal de recherches et j'ai trouvé plusieurs solutions :

1) la tienne

2) créer un /usr/lib/systemd/system/iptables.service contenant :
[Unit]
Description=iptables firewall service
Before=network.target

[Service]
Type=oneshot
ExecStart=/home/nevermore/iptables start
RemainAfterExit=true
ExecStop=/home/nevermore/iptables stop
StandardOutput=journal

[Install]
WantedBy=multi-user.target

3) script dans /etc/init.d

4) if-pre-up malgré tout

5) variante de if-pre-up : dans /etc/network/interfaces, après wlo1 : pre-up iptables-restore < /etc/iptables_rules (règles le problème des applications multiples)

Même sans trop maîtriser systemd, tu pourras peut-être me dire quelle(s) option(s) te sembles les plus appropriés ?

EDIT : je crois que je me prend la tête pour rien : d'après le man :
"
pre-up command
Run command before bringing the interface up. If this command fails then ifup aborts, refraining from marking the interface as configured, prints an error message, and exits (...)"

Il semblerait donc qu'avec if-pre-up tout soit bien appliqué avant même la configuration de l'interface !

Aussi, on m'a fait remarquer "et ton nat et mangle ?". On est bien d'accord que sur une machine non routeur, je laisse tout à accepte. le fait qu'une vérification m'indique des paquets en nat, c'est normal et pas un problème niveau sécurité ?

Dernière modification par abumbra (07-05-2019 22:46:09)

LaFouine · 08-05-2019 04:01:43

Sinon un lien qui est une exelente doc https://www.inetdoc.net/guides/iptables-tutorial/

abumbra · 08-05-2019 10:29:18

Merci ! Je l'avais vu, et lu partiellement. D'ailleurs, mes questions quant à Nat et mangle sur un hôte non routeur étaient liées.

Ceci dit, s'il est plus que complet, je n'y ai étrangement rien trouvé pour appliquer les règles au boot. Ou je suis passé devant sans le voir, ou rien à ce sujet.

raleur · 08-05-2019 11:50:57

abumbra a écrit :

2) créer un /usr/lib/systemd/system/iptables.service

D'après la page de manuel de systemd.unit, les unités systemd créées localement devraient être dans placées dans /etc/systemd/system, pas dans /usr dont le contenu est censé provenir des paquets et qui peut être monté en lecture seule. D'autre part /usr/lib/systemd/system ne fait pas partie des répertoires mentionnés où systemd va chercher des unités. Pour les unités installés par les paquets, c'est plutôt /lib/systemd/system.

raleur a écrit :

ExecStart=/home/nevermore/iptables start

C'est une très mauvaise idée de faire exécuter avec les privilèges root un script placé dans un répertoire où un utilisateur normal peut écrire. D'autre part si /home est un système de fichiers séparé de la racine, il n'est pas garanti qu'il sera déjà monté lors de l'exécution.

abumbra a écrit :

3) script dans /etc/init.d

C'est la même chose que 1).

abumbra a écrit :

5) variante de if-pre-up : dans /etc/network/interfaces, après wlo1 : pre-up iptables-restore < /etc/iptables_rules (règles le problème des applications multiples)

C'est quoi, wlo1 ? Je croyais que la connexion réseau était gérée par NetworkManager ? Si une interface est configurée dans /etc/network/interfaces, par défaut elle est ignorée par NetworkManager.

abumbra a écrit :

Il semblerait donc qu'avec if-pre-up tout soit bien appliqué avant même la configuration de l'interface !

Seulement quand l'interface est configurée dans /etc/network/interfaces ! Aucune garantie quand l'interface est configurée par NetworkManager.
Certes, NetworkManager inclut un script /etc/NetworkManager/dispatcher.d/01ifupdown qui exécute les scripts d'ifupdown lorsque NetworkManager agit sur une interface, mais si on regarde dans le code on voit que l'exécution des scripts pre-up est désactivée.

abumbra a écrit :

Aussi, on m'a fait remarquer "et ton nat et mangle ?". On est bien d'accord que sur une machine non routeur, je laisse tout à accepte

Rien à voir avec le fait qu'une machine soit routeur ou non. Les tables mangle et nat ne sont pas faites pour le filtrage donc il n'y a aucune raison de mettre leurs politiques par défaut à DROP. Les chaînes des différentes tables sont en cascade, et quel que soit son chemin tout paquet passe forcément par une (et une seule) chaîne de la table filter qui permet de faire le filtrage.

Ceci dit, la dernière version de ton script ne laisse pas les politiques à ACCEPT, elle les laisse dans l'état où elles sont sans y toucher. Suffisant quand le script est exécuté au démarrage avant qu'iptables ait été utilisé, mais pas forcément pour remettre à l'état voulu après un bidouillage en cours de session.

abumbra a écrit :

e n'y ai étrangement rien trouvé pour appliquer les règles au boot. Ou je suis passé devant sans le voir, ou rien à ce sujet.

La dernière fois que j'ai parcouru ce tutoriel (il y a longtemps certes, je ne sais pas s'il évolue encore), il ne parlait pas des moyens de mettre en place un jeu de règles. C'est trop dépendant du système et de la distribution.

abumbra · 08-05-2019 16:24:16

Donc la meilleure solution serait bien la création d'un service ?

A condition de :

1) le placer dans le bon répertoire (il fonctionnait là où il était ceci dit)
2) placer le script dans /etc par exemple
3) ne pas l'exécuter en root ?! pourtant c'était le cas avec if pre up.

?

raleur · 08-05-2019 17:09:30

abumbra a écrit :

3) ne pas l'exécuter en root ?!

Je n'ai pas écrit cela. J'ai écrit que c'est un risque de sécurité d'exécuter en tant que root un programme qui peut être modifié par un utilisateur normal. Or /home/nevermore/ est modifiable par l'utilisateur nevermore. Si cet utilisateur est compromis, il peut remplacer le programme par un programme malveillant.
Les règles iptables ne peuvent être manipulées qu'avec la "capacité" CAP_NET_ADMIN. Je ne sais pas si on peut lancer un service avec seulement les capacités nécessaires, sinon il faut le lancer en root.

Dernière modification par raleur (08-05-2019 17:11:39)

abumbra · 08-05-2019 17:13:07

Bien ce que je me disais, mauvaise lecture de ma part.

Du coup, dans /etc/ avec chmod 740 sur le script, ça passe (je ne suis pas bien au point niveau permission, non plus).

raleur · 08-05-2019 17:29:10

Pas besoin de permissions particulières. Les permissions standard d'un exécutable système (755 = rwxr-xr-x), avec root:root comme propriétaire suffisent.

Dernière modification par raleur (08-05-2019 17:29:51)

abumbra · 08-05-2019 17:32:35

Donc, je résume avant d'appliquer :

1) je reprend mon fichier de création de service
2) je le place au bon endroit
3) l'exec vers mon script que j'aurai placé dans /etc
4) et point barre, pas besoin de s'embêter avec les permissions

ceci dit, j'ai un doute, en passant par un sudo nano ...adressedemonscript, le fichier est automatiquement créé sans pouvoir être modifié par l'utilisateur courant (le nevermore de plus tôt, bref, moi) ?

Ou un chown root:root est nécessaire ? Je m'y perd. Juste le chown, pas besoin d'un chmod xxx ?

Dernière modification par abumbra (08-05-2019 17:33:56)

raleur · 08-05-2019 17:35:58

Il ne peut pas être modifié mais peut être supprimé et remplacé si l'utilisateur a la permission d'écriture dans le répertoire.

abumbra · 08-05-2019 19:07:30

Ok, et de toute manière /etc est déjà root:root, logique, donc tout bon. Je vais mettre ça en place ce soit, merci !

Juste un autre petite chose, jusque là j'utilisais 750 pour rendre exécutables mes scripts. Tu m'as parlé de 755 ?

Aussi, plusieurs personnes me disent que même en ipv4, même si tout fonctionne, bloquer icmp n'est optimal, et surtout "pas génial" pour les autres ? Un intérêt à faire comme en icmpv6 et n'autoriser que certains types, quitte à imposer des limites ?

Dernière modification par abumbra (08-05-2019 19:14:13)

raleur · 08-05-2019 22:14:53

abumbra a écrit :

jusque là j'utilisais 750 pour rendre exécutables mes scripts. Tu m'as parlé de 755 ?

Le fait qu'il soit ou non lisible et exécutable par tout le monde ne fait pas une grosse différence si le script ne contient rien de sensible.

abumbra a écrit :

même en ipv4, même si tout fonctionne, bloquer icmp n'est optimal, et surtout "pas génial" pour les autres ? Un intérêt à faire comme en icmpv6 et n'autoriser que certains types, quitte à imposer des limites ?

Bien sûr. Il est préférable d'accepter les mêmes types d'erreur qu'ICMPv6 dans l'état RELATED, sauf packet-too-big qui n'existe pas en ICMPv4.

abumbra · 09-05-2019 07:03:05

raleur a écrit :

Bien sûr. Il est préférable d'accepter les mêmes types d'erreur qu'ICMPv6 dans l'état RELATED, sauf packet-too-big qui n'existe pas en ICMPv4.

C'est aussi simple que ça, simple copier coller, juste remplacer icmpv6 par icmp tout court, et supprimer packet-too-big ? Rien besoin de plus ?

raleur · 09-05-2019 07:29:02

Oui.

abumbra · 09-05-2019 07:56:19

Super, merci !

Aussi, juste pour te tenir au courant, après vérification, iptables.service démarre avant wpa-supplicant, raise network, network-manager via un systemctl -b. Donc c'est bien la bonne solution !

On est bien d'accord qu'avec iptables-restore, c'est vraiment immédiat ou du moins extrêmement rapide, les règles sont déjà appliquées même si wpa-supplicant, network manager démarrent quelques millisecondes après ? De toute façon, c'est ce que veux dire le before network.target, il me semble.

raleur · 09-05-2019 09:13:16

Que ce soit avec iptables ou iptables-restore, les règles sont en place dès le retour de la commande.

Je ne vois pas d'option -b dans la page de manuel de systemctl ?

abumbra · 09-05-2019 12:13:02

Journalctl, pardon. Avec toutes ces discussions à propos de systemd, lapsus.

Debian-facile

#51 05-05-2019 14:12:10

Re : ip6tables configuration

#52 07-05-2019 20:28:47

Re : ip6tables configuration

#53 08-05-2019 04:01:43

Re : ip6tables configuration

#54 08-05-2019 10:29:18

Re : ip6tables configuration

#55 08-05-2019 11:50:57

Re : ip6tables configuration

#56 08-05-2019 16:24:16

Re : ip6tables configuration

#57 08-05-2019 17:09:30

Re : ip6tables configuration

#58 08-05-2019 17:13:07

Re : ip6tables configuration

#59 08-05-2019 17:29:10

Re : ip6tables configuration

#60 08-05-2019 17:32:35

Re : ip6tables configuration

#61 08-05-2019 17:35:58

Re : ip6tables configuration

#62 08-05-2019 19:07:30

Re : ip6tables configuration

#63 08-05-2019 22:14:53

Re : ip6tables configuration

#64 09-05-2019 07:03:05

Re : ip6tables configuration

#65 09-05-2019 07:29:02

Re : ip6tables configuration

#66 09-05-2019 07:56:19

Re : ip6tables configuration

#67 09-05-2019 09:13:16

Re : ip6tables configuration

#68 09-05-2019 12:13:02

Re : ip6tables configuration

Pied de page des forums