Digression Installation parefeu (iptables & ip6tables) "pour les nuls"

Support Debian
#421

[quote=“thuban”]Et visiblement, si on fait un joli en-tête, plus besoin de update-rc.d, un simple insserv mon_parefeu devrait suffire :
wiki.debian.org/LSBInitScripts/D … yBasedBoot

Je ne suis pas sûr de tout bien comprendre, mais est-ce que ce genre de chose pourrait suffire? :

[code]### BEGIN INIT INFO

Provides: mon_parefeu

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: Configure le parefeu

Description: Met en place les règles iptables.

END INIT INFO[/code][/quote]

:mrgreen:

#422

Je viens de me rendre compte d’un effet “pervers” du script:

-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh-ddos ... -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh-ddos ... -A fail2ban-ssh-ddos -j RETURN -A fail2ban-ssh-ddos -j RETURN ...

Au reboot de la machine, les règles fail2ban sont toutes multipliées par deux dans la sortie de iptables -S
Je suppose que c’est le déchargement/rechargement + démarrage de fail2ban qui provoque ça.

Un moyen de ne pas sauvegarder les règles fail2ban dans le fichier iptables-save ?

#423

Quelques idées :

  • Filtrer les lignes relatives à fail2ban dans le fichier
  • Ne pas enregistrer le fichier quand les règles fail2ban sont actives
  • Si fail2ban le permet, ne pas recréer les règles quand il démarre
#424

Salut,

[quote=“PascalHambourg”]Quelques idées :

  • Filtrer les lignes relatives à fail2ban dans le fichier
  • Ne pas enregistrer le fichier quand les règles fail2ban sont actives
  • Si fail2ban le permet, ne pas recréer les règles quand il démarre[/quote]

Merci pour les pistes.
Je pense décharger fail2ban avant la sauvegarde avec iptables-save. Ça laisse quelques secondes sans la protection de fail2ban, mais ce n’est pas critique.

#425

Bonjour,

une question me tarabuste : pourquoi établir un système de sauvegarde/réinsertion des règles iptables quand on peut tout simplement les mettre en dur dans un script ?

1/ seul root est sensé ajouter des règles et il lui suffit d’adapter le script au fil du temps et des services qu’il active, désactive
2/ ça évite d’avoir des règles qui fluctuent pour des raisons plus ou moins obscures (par exemple un fail2ban qui se duplique à chaque reboot)

En fait je comprends pas trop l’intérêt de donner cette dynamique aux règles de filtrage d’un firewall qu’on souhaiterait le plus stable/fiable possible.

Excusez moi si cette question a déjà été posée, je n’ai pas eu le courage d’éplucher toutes les questions/réponses depuis le 19 octobre 2004 (les meilleurs sujets traversent le temps).

Mazkagaz

#426

C’est un choix, qui a des avantages et des inconvénients.
Du côté des avantages, il suffit de modifier les règles actives et les modifications seront enregistrées. Certes selon le cas cela peut aussi être un inconvénient.
D’autre part la mise en place des règles avec une commande iptables pour chaque règle est beaucoup plus lente que la mise en place globale avec iptables-restore : à chaque exécution il faut charger la table entière depuis le noyau, la modifier et la renvoyer en entier au noyau. Si le nombre de règles est conséquent (milliers), cela peut prendre du temps.

#427

OK, je comprends mieux. Je ne savais pas qu’il y avait une différence entre le chargement basique des règles iptables et la restauration via iptables-restore (sur lequel je viens un peu de m’attarder).
Je n’entre pas dans le cadre des milliers de règles, j’en resterai donc au script basique :slightly_smiling:
Merci pour ces précisions

#428

Rien n’empêche d’utiliser iptables-restore tout en maintenant le fichier de règles soi-même, c’est ce que je fais partout.

#429

Oui, mais sous cette forme les règles sont un peu moins lisibles et pratiques à modifier.

#430

Tu aurais un exemple ? Perso je trouve ça plus clair justement (même syntaxe sans avoir à insérer la commande iptables devant sous une forme ou une autre, ça fait moins de bordel). Si j’ai besoin de variables je mouline ça bêtement à travers sed, bref j’arrive pas à voir en quoi l’appel via le shell est plus lisible ou pratique à modifier. Y’a même le format HEREDOC qui permet de se passer totalement de sed et de garder les règles dans le script lui-même (mais j’aime pas, je préfère avoir les règles dans un fichier séparé).

IP_LOCALE=192.168.1.2 /sbin/iptables-restore <<EOF *filter -P INPUT DROP [...] -A INPUT -d $IP_LOCALE ... COMMIT EOF

#431

Par exemple dans mes scripts j’aime bien regrouper les règles qui fonctionnent ensemble, comme les règles de NAT et de filtrage qui traitent un type de communication donnée :

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.0.2.9 iptables -t filter -A FORWARD -i eth0 -p tcp --dport 80 -d 192.0.2.9 -j ACCEPT
Cela m’évite d’en oublier une quand j’ajoute, modifie, ou supprime.
Or dans le format d’iptables-{save,restore}, les règles sont groupées par table.

Tu triches ! Si ton fichier doit passer à travers une moulinette avant d’être envoyé à iptables-restore, ce n’est plus le même format.

#432

Sur le groupement des tables, je te l’accorde. Moi ça ne me dérange pas, mais je pense que c’est surtout parce que dans l’ensemble je travaille assez peu avec les règles de routage.

Par contre sur le coup de tricher, je proteste : tous les coups sont bons ! :016

#433

Je suis assez d’accord avec Pascal, j’aime bien regrouper mes règles, y mettre mes petits commentaires. J’y vois plus clair.
Je me fais un diagramme sur papier, puis je regroupe mes règles par état et vérifie que toutes mes transitions sont listées. J’imagine que pour des milliers de règles, ça doit être un poil plus délicat…
Et puis comme le dit Pascal dans nombre de posts, dans tout choix, il y a toujours des avantages et des inconvénients. Alors du moment qu’on y trouve notre compte :slightly_smiling:

Ces réflexions m’amènent à me poser une autre question : utilisez-vous ou avez-vous entendu parler d’outils spécifiques qui traduiraient une conception sous forme de diagrammes du firewall en règles iptables ? Et je ne parle pas de la myriade d’interfaces graphiques qui servent simplement à traduire les commandes iptables en langage humain. Je parle d’un outil haut niveau dans lequel on créerait des diagrammes d’états-transitions et qui se démerderait pour les traduire en règles iptables.

En ce qui me concerne ce serait un peu un marteau-pilon pour écraser une mouche, mais je suis curieux :smiley:

#434

Bpnjour,
On doit faire quoi avec les runlevels qui ne fonctionnent pas du coup ?

root@lagache:/home/irena# update-rc.d mon_parefeu start 12 S . stop 08 0 6 . update-rc.d: using dependency based boot sequencing update-rc.d: warning: mon_parefeu start runlevel arguments (S) do not match LSB Default-Start values (2 3 4 5) update-rc.d: warning: mon_parefeu stop runlevel arguments (0 6) do not match LSB Default-Stop values (0 1 6

Dois-je basculer vers ceci (source du wiki…) ? est-ce toujours fiable/d’actualités etc… :

[code]### BEGIN INIT INFO

Provides: iptables

Required-Start: mountall

Should-Start: $local_fs

Required-Stop:

Should-Stop:

X-Start-Before: networking

X-Stop-After: networking

Default-Start: S

Default-Stop: 0 6

Short-description: iptables

Description: Firewall

END INIT INFO[/code]

Il faudrait peut-être mettre une annotation à ce sujet sur la page d’installation du forum,

#435

J’avoue que je ne sais plus quoi dire à ce sujet :blush:

#436

Salut,

Oui, nous en avions parlé, et j’avais ajouté ceci au Wiki: En-tête pour les utilisateurs de Squeeze

Ricardo ne voulait pas ajouter cette entête au T&A sans confirmation. :wink:
J’avais pris la liberté d’ajouter l’en-tête (qui fonctionne pour Squeeze) sur le Wiki debian-fr.org.

#437

C’est à tenter mais il faudra ptet modifié la correspondance plus bas dans le script ?

#438

Bonjour, j’ai un iptables comme ci dessous, il a pour but de proteger eth0 qui est sur WLAN et eth1 sur LAN
J’ai donc des lignes identique, devrais-je les supprimer ?

[code] iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all – anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp – anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN
ACCEPT tcp – anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN
REJECT all – anywhere anywhere reject-with icmp-port-unreachable
ACCEPT icmp – anywhere anywhere icmp echo-request
ACCEPT tcp – anywhere anywhere tcp dpt:squid flags:SYN,RST,ACK/SYN
ACCEPT tcp – anywhere anywhere tcp dpt:ms-v-worlds flags:SYN,RST,ACK/SYN
ACCEPT tcp – anywhere anywhere tcp dpt:http flags:SYN,RST,ACK/SYN
ACCEPT tcp – anywhere anywhere tcp dpt:smtp flags:SYN,RST,ACK/SYN
ACCEPT tcp – anywhere anywhere tcp dpt:ftp flags:SYN,RST,ACK/SYN
ACCEPT tcp – anywhere anywhere tcp dpt:https flags:SYN,RST,ACK/SYN
ACCEPT tcp – anywhere anywhere tcp dpt:bv-is flags:SYN,RST,ACK/SYN
RH-Firewall-1-INPUT all – anywhere anywhere
ACCEPT all – anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
DROP all – anywhere anywhere
DROP all – anywhere anywhere
RH-Firewall-1-INPUT all – anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT tcp – anywhere anywhere state NEW tcp dpt:domain
ACCEPT udp – anywhere anywhere state NEW udp dpt:domain [/code]

C’est un serveur wifi et j’ai des problemes de connexion et de lenteur, pourraient t’elles venir des iptables

#439

Hello
dans le tuto il faut penser aussi a l’ipv6 qui désormais est utiliser de plus en plus frécamment. un exemple simple:

udp6       0      0 2a02:a1:300:200:123 :::*                                110        14192       679/ntpd        
udp6       0      0 fe80::82b:34f:f3:123 :::*                                110        19579       679/ntpd

je connais mal l’ipv6 donc je suis mal placer pour dire quoi que ce soit.
les premières tentative son souvent fait en ipv6 quand c’est possible.

#440

Tu n’as pas dû lire les 3 premières lignes du tuto :

[quote]Voici une sorte de ‘tuto’ destiné à l’installation primaire d’un pare-feu (ou parefeu) sous Debian.
Ce qui suit n’a pas pour objectif de renseigner les utilisateurs accomplis, qui n’y apprendront rien de plus que ce qu’ils savent mais est plutôt dirigé vers les débutants, avec un maximum d’explications.[/quote]

Mais rien ne t’empêche d’écrire un tuto plus complet. :wink: