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

Support Debian
#221

Pour les problèmes de warning et d’erreur. C’est dut a des incompatibilitées entre Debian et la LSB.
insserv c’est très peu documenté grosso modo si la page man ne vous suffit pas tampis pour vous. Il y a pas de système pour demander lancer un script avant l’initialisation du réseau et pire que ça la solution de modifier le script ifupdown n’est pas viable car network-manager et wicd ne passent pas par là par exemple.

Bon j’ai pas de bonne solution et ça commence à me taper sur les nerfs donc je vais sortir.

#222

[quote=“MisterFreez”]Pour les problèmes de warning et d’erreur. C’est dut a des incompatibilitées entre Debian et la LSB.
insserv c’est très peu documenté grosso modo si la page man ne vous suffit pas tampis pour vous. Il y a pas de système pour demander lancer un script avant l’initialisation du réseau et pire que ça la solution de modifier le script ifupdown n’est pas viable car network-manager et wicd ne passent pas par là par exemple.

Bon j’ai pas de bonne solution et ça commence à me taper sur les nerfs donc je vais sortir.[/quote]
Bonne ballade alors! On finira bien par trouver :wink:

#223

Recoder une partie du programme et soumettre un patch ? :wink:

#224

@Pascal : merci bien pour toutes ces indications détaillées.
Je pense avoir saisi oui pour la majorité.

  • Le ping passé à 5
  • le syn en DROP
  • j’ai retiré la règle globale et traité au cas par cas plutot pour les flag related/established et en ai profité pour mettre où il le fallait le flag new
  • ip_conntrack_ftp en modprobe au start
  • les machines sont toutes avec du eth0 et en fr, mais j’ai commenté ma règle et le fait mannuellement (javais pas pensé aux machines us)

La seule remarque que je ne comprend pas trop, c’est concernant le port 53

Comment un user pourrait-il se connecter sur un port local autre que je n’ai pas ouvert en passant par le 53 ?
il lancerait une connexion sur le 53 puis changerait de port bénéficiant du flag related,established ok… mais jvois vraiment pas comment ? bref… tu me conseillerais de parer cela comment alors ?

#225

Ahlala… Les posts de PascalHambourg sur iptables… C’est toujours clair, net et précis, sans ambiguité. :041 :079
J’ai appris énormément de trucs sur les bases d’iptables dans un post assez ancien ou tu intervenais (avec fran.b d’ailleurs), qu’il faudrait que je retrouve…

Edit : ah, ben le voila : viewtopic.php?f=3&t=20495&hilit=iptable
Je conseille aux débutants de le lire, guigui traduisait chaque remarque de Pascal par un nouveau script complet et corrigé, ca aide énormément à la compréhension quand on n’est pas familier avec les règles.

#226

Simplement grâce aux règles suivantes :

$IPT -A INPUT -p udp --sport 53 -j ACCEPT
$IPT -A OUTPUT -p udp --dport 53 -j ACCEPT
$IPT -A INPUT -p tcp --sport 53 -j ACCEPT
$IPT -A OUTPUT -p tcp --dport 53 -j ACCEPT

Si une machine distante envoie un paquet TCP (ou UDP) vers n’importe quel port destination mais avec le port source 53, la première (ou troisième) règle qui ne vérifie que le protocole et le port source l’accepte. Le paquet de réponse émis par ta machine, avec le port destination 53, sera accepté par la deuxième (ou quatrième) règle qui ne vérifie que le port destination. Même chose avec le port whois.

En général, la vérification du port source n’apporte pas grand chose. Pour contrôler les requêtes on vérifie le port destination et pour contrôler les réponses on vérifie l’état (state ESTABLISHED).

#227

Concrètement, je remplace :
A INPUT -i lo -j ACCEPT
par quelle ligne ?

#228

Ah non, la règle tu la gardes, elle est bonne. C’est juste le commentaire qui ne correspondait pas.

Y en a même qui utilisent NOTRACK pour ne pas faire de suivi de connexion avec les paquets émis sur l’interface de loopback et ainsi économiser un peu de mémoire et de temps CPU. A moins que le trafic sur lo soit important, ça ne doit pas faire une grosse différence.

iptables -t raw -A OUTPUT -o lo -j NOTRACK iptables -t raw -A PREROUTING -i lo -j NOTRACK # pas sûr que cette règle soit nécessaire

#229

Ok, j’avais mal interprété et ça m’étonnais d’ailleurs mais comme je te fais une confiance aveugle dans ce domaine …
Je vais modifier tout ça dans la journée.

#230

Bon, les choses les unes après les autres :

1/ Je n’ai pas retrouvé où tu “disais du mal” de ‘icmp’.
Est-ce que, dans mon cas 'établissement d’un “parefeu de base”, qui se veut simple, je dois SUPPRIMER purement et simplement la ligne :

:question: :question: :question:

2/ Pour ton observation sur les runlevel :

est-ce que la ligne suivante est correcte :
update-rc.d mon_parefeu start 35 S
Sinon, veux-tu me donner celle qui convient.
Merci.

#231

Je n’ai pas dit du mal d’ICMP mais de ta règle concernant ICMP.

Oui. La règle globale ESTABLISHED,RELATED devrait prendre en compte les paquets ICMP légitimes. Il y a quelques exceptions comme les réponses à un ping en broadcast car le suivi de connexion de netfilter ne sait pas traiter les broadcasts, mais c’est rarement gênant. Si on veut accepter des requêtes comme le ping, ça mérite AMA des règles explicites avec le type ICMP, comme pour un port TCP ou UDP.

[quote=“ricardo”]est-ce que la ligne suivante est correcte :
update-rc.d mon_parefeu start 35 S[/quote]
J’ai oublié la syntaxe, mais si ça veut dire créer un symlink /etc/rcS.d/S35mon_parefeu, ça doit être bon. Les puristes voudraient peut-être des stop dans les runlevels 0 et 6 pour arrêter le pare-feu lors du reboot ou de l’arrêt.

#232

Alors, pour le runlevel, j’ai trouvé l’exemple qui semble tout à fait convenir dans … le man :wink:

Exemple de commande pour installer un script système d'initialisation et d'arrêt : update-rc.d foobar start 45 S . stop 31 0 6 .

Par exemple, si tu peux me faire un cours succinct sur les priorités … je ne comprends pas pourquoi "plus petit que 40, parce qu’il y a maxi 40 scripts :question:
pourquoi dans l’exemple du man, ils mettent 45 et ils passent à 31 pour le stop :question:
J’ai mis dans le tuto, 35 dans les deux cas en attendant tes explications.

#233

[quote=“PascalHambourg”][quote=“ricardo”]est-ce que la ligne suivante est correcte :
update-rc.d mon_parefeu start 35 S[/quote]
J’ai oublié la syntaxe, mais si ça veut dire créer un symlink /etc/rcS.d/S35mon_parefeu, ça doit être bon. Les puristes voudraient peut-être des stop dans les runlevels 0 et 6 pour arrêter le pare-feu lors du reboot ou de l’arrêt.[/quote]
Ce que je trouve dommage c’est que ça outre passe complètement le système de dépendance de Debian (à partir de Squeeze). Une dépendance serais vraiment appréciable (pas de réseau avant la mise en place du firewall). Mais je n’ai pas trouvé de solution pour le faire ce qui est vraiment dommage.

Si on veut utiliser les mécanisme de dépendance on doit donner à notre script aucune dépendance et normalement il seras exécuté avant la configuration du réseau, mais je considère pas ça comme une situas satisfaisante. De la même manière si un jour une mise à jour, déplace l’initialisation du réseau dans l’ordre de boot, le problème reviendras.

#234

@ricardo :
Lors de l’entrée dans un runlevel N les scripts dans /etc/rcN.d/ sont exécutés dans l’ordre croissant de leurs numéros, tous ceux qui commencent par K avant tous ceux qui commencent par S, par exemple :

K40truc
K60machin
S10bidule
S30chose

Les scripts K sont exécutés avec le paramètre stop et les scripts S avec le paramètre start, sauf dans les runlevels 0 (arrêt) et 6 (redémarrage) ou tous sont exécutés avec le paramètre stop. D’après le contenu de ces deux runlevels, je suppose que c’est pour distinguer entre l’arrêt des services qui ont été démarrés dans un runlevel utilisateur (K, en premier) d’une part et l’arrêt des services démarrés dans le runlevel S et les actions propres à l’arrêt ou au redémarrage (S, en dernier).

Note : ce fonctionnement est probablement spécifique à Debian.

Comme le réseau est démarré par /etc/rcS.d/S40networking [1], il faut que le script de démarrage du pare-feu soit lancé avant, donc avec un numéro inférieur à 40. Pas trop inférieur (j’ai pris 39 pour ma part) afin d’être à peu près sûr que tout ce qui peut être nécessaire au réseau soit déjà démarré. Je n’ai pas mis d’arrêt car mon script n’en a pas besoin, il fonctionne différemment du tien.

Pourquoi 45 et 31 dans l’exemple ? Je ne sais pas, ce n’est peut-être qu’un exemple arbitraire. Normalement plus un service est démarré tôt, plus il doit être arrêté tard de sorte que les services qui en dépendent soient arrêtés avant. Traditionnellement on prend numéro d’arrêt = 100 - numéro de démarrage.

Le réseau est arrêté par /etc/rc[06].d/S35networking (voir particularité des runlevels 0 et 6 ci-dessus). Par conséquent pour arrêter le pare-feu plus tard, il faut “paradoxalement” créer dans ces deux runlevels un lien S (start) et non K (stop), avec un numéro plus grand que 35. Par exemple :

[1] Mais il peut arriver que udev, hotplug, et les gestionnaires de réseau graphiques configurent des interfaces avant ou après. De même la nouvelle gestion des scripts d’init par dépendance à partir de squeeze risque de changer les choses.

#235

J’en profite pour demander une précision : si un script est lancé en start au niveau 39, puis le suivant au niveau 40 (par exemple), est-ce qu’ils s’exécutent réellement l’un après l’autre (= le 40 ne démarre que lorsque le 39 a renvoyé son code de sortie), ou est-ce qu’ils sont démarrés l’un après l’autre mais sans attendre que le précédent ait fini de s’exécuter ?

#236

L’un après l’autre. Mais tout ceux qui ont le même nombre sont lancés en parallèle.

#237

@ PascalHambourg :
Un grand merci pour tes explications, on ne peut plus claires. Pour une fois, j’ai tout compris.
J’ai une question subsidiaire toutefois :
Pourquoi des rc[06].d et un rcS.d ?
je comprends bien le rôle du 0 et du 6 mais je pige mal pourquoi il y a plusieurs autres [15] ?
Aussi, le rôle de ‘S’, quel est sa différence par rapport aux autres, c’est le premier à être pris en compte au démarrage ?

#238

Hé, les réponses à ces questions sont dans la documentation !

Pour résumer, les scripts du runlevel S sont effectivement exécutés en premier au démarrage avant ceux du runlevel définitif (et les seuls au moment de l’invite si on démarre en mode single-user). Le runlevel 1 est le mode mono-utilisateur, ses scripts servent essentiellement à arrêter les services démarrés dans le runlevel multi-utilisateur courant avant de passer en mono-utilisateur. Les runlevels 2 à 5 sont les modes multi-utilisateur “normaux”. Debian utilise le runlevel 2 par défaut mais les autres sont identiques (sauf personnalisation par l’administrateur) ; d’autres distributions utilisent deux runlevels différents, un qui démarre l’interface graphique et l’autre qui reste en console.

#239

Merci pour ta confirmation.
Tu vas encore me renvoyer à la doc mais j’aime tellement tes cours que je ne peux résister :mrgreen: :
runlevel par défaut (sous Debian) = 2, je crois.
Donc, en dehors du 1 et du 6, et maintenant du S, pour lesquels, on sait à quoi s’en tenir,
À quoi servent les autres ?
Quel est l’avantage/inconvénient d’en déclarer un ‘différent’ de celui qui est ‘default’ ?
Si mes questions te gonflent, envoie-moi un lien, merci.

#240

Les runlevels 2 à 5 permettent de définir différents services à démarrer pour chacun. Par exemple comme je l’ai décrit précédemment, un mode graphique et un mode texte. Pour faire cela avec Debian, il faudrait transformer le lien de démarrage (S) de gdm (si c’est gdm qui démarre X) en un lien d’arrêt (K) dans le runlevel 3 ; ainsi quand on démarre en runlevel 3 on est en mode texte et quand on démarre en runlevel 2 on est en mode graphique.

A la limite, on pourrait imaginer une machine qui démarre des services totalement différents selon le runlevel.

Quant à l’avantage d’utilise l’un plutôt que l’autre, s’ils sont identiques il n’y en a pas. J’ai dit plus haut que les runlevels 2 à 5 étaient identiques, mais vérification faite dans /etc/inittab ce n’est pas tout-à-fait vrai : par défaut ils démarrent les mêmes services mais les runlevels 2 et 3 démarrent 6 consoles virtuelles tty1 à tty6 alors que les autres runlevels ne démarrent que la console virtuelle tty1. Ne me demande pas pourquoi.