[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? :
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 ?
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.
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).
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.
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
Merci pour ces précisions
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
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.
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 !
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
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
Ricardo ne voulait pas ajouter cette entête au T&A sans confirmation.
J’avais pris la liberté d’ajouter l’en-tête (qui fonctionne pour Squeeze) sur le Wiki debian-fr.org.
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 ?
Chain FORWARD (policy ACCEPT)
target prot opt source destination
DROP all – anywhere anywhere
DROP all – anywhere anywhere
RH-Firewall-1-INPUT all – anywhere anywhere
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.
