Et bien moi, j'ai trouvé ça très intéressant ^^. Question, il y a plusieurs fois l'action “LOG” (“-j LOG” en tout cas) dans les commandes, mais pas dans la partie “Les différentes actions”; quelle est la différence? Y a-t-il des LOG/DROP, LOG/REJECT et LOG/ACCEPT?
Si d'autres se posaient la même question, la réponse se trouve dans la “man iptables-extensions” :
LOG
Turn on kernel logging of matching packets. When this option is set for a rule,
the Linux kernel will print some information on all matching packets (like most
IP/IPv6 header fields) via the kernel log (where it can be read with dmesg(1) or
read in the syslog).
This is a “non-terminating target”, i.e. rule traversal continues at the next
rule. So if you want to LOG the packets you refuse, use two separate rules with
the same matching criteria, first using target LOG then DROP (or REJECT).
Merci pour les fleurs. Et concernant les logs, le principe ici c'est que tout ce qui n'est pas accepté est journalisé. Après, ne pas oublier qu'il s'agit d'une introduction de prise en main qui se veut générale. Pour les détails, il vaut mieux voir la doc écrite par Oskar Andreasson, beaucoup plus assomman^^^^^complète. :o)
“tu” (la machine) analyses ce qui se passe, en premier… LOG
et, ensuite “tu” décides de l'action à émettre, souvent du DROP ou du REJECT, et parfois tu peux, en tant qu'administrateur décider de laisser passer les paquets (règles ACCEPT). Cette action très ciblée dépend du besoin…
Car non, les LOG ne servent pas qu'à journaliser ce qui doit être rejeté ou supprimé sans avis. Ils servent à analyser la situation, correspondant à un critère. Ensuite, vient l'action.
Mis à part qu'il est clairement recommandé de ne plus utiliser Iptable car considéré obsolète.. et qu'il (f|v)aut se mettre à son remplaçant nftables !
(un coup de manpage sous Debian, c'est explicite)
un article obsolète, en retard de plusieurs années !
Merci pour le commentaire, je savais pas que iptables était jugeait obsolète. Après avoir lu le wiki debian, c'est principalement la complexité du “framework” iptables qui l'a amené à être mis au rebus.
Je suis également d'accord avec Cascador, ton commentaire est très dur. L'article de kikinovak est très bien et complet. Le fait qu'il présente le fonctionnement d'une technologie amené à être considéré obsolète en 2024, soit dans 5 ans n'en fait pas du tout un article obsolète en retard de plusieurs années !
edit : après avoir pris quelques minutes pour faire des recherches, j'ai pas l'impression que nftables soit unanimement validé. Je vais rester sur iptables en attendant que cela se décante.
Je suis très surpris de voir les réactions si négatives et les intentions qui me sont données.
Si on ne peut donner son avis, sans être si durement jugé, c'est une farce et une pantomine.
Rien dans ma remarque n'est désobligeant, et encore moins trollesque. Il faudrait revoir les définitions des termes. Que le commentaire soit considéré comme dur, voire très dur, je peux le comprendre. Mais ça ne mérite en rien le déchaînement de passion négative et l'assaut en règle de celui-ci !
Je suis mesuré dans mes propos… et je tiens à le reste. Je ne me permet aucune attaque ad hominem.
Et il est normal qu'on le reste aussi. @kikinovak n'a pas l'air d'apprécié qu'on ne soit pas d'accord avec lui. Son effort de vulgarisation est louable, mais ces petites imprécisions m'agacent. Et, j'ai le droit de le ressentir… mais apparemment pas de l'exprimer, puisque cela déchaîne des vélléités destructrices à mon encontre.
Je n'y peut rien, personnellement, si systemd jette aux oubliettes iptables, et met aux alouettes nftables.
Je n'y peut rien, si systemd tend à imposer certaines choses.
De toute façon, j'ai de plus en plus tendance à fuir Debian, et de fait, Linux, à cause des pratiques ‘systemd’ - surtout quand je vois la facilité d'administration d'OpenBSD, auquel je suis coutumié depuis quelques années… et quand je vois la simplicité de PF - Packet Filter - face ne serait qu'à côté d'Iptables - et, je ne parle même pas de nftables et autres consorts - je suis très sceptique sur le reste.
Mon seul regret est que Debian GNU/kFreeBSD ne décolle pas. Au moins, on garderait l'avantage des deux mondes, et le meilleur de ces deux mondes.
(il est vrai, malheureusement, que pour OpenBSD, il est strictement nécessaire d'avoir du matériel compatible ; pour ce qui est des autres Linux, autres que Debian, voire Ubuntu, je n'en sais strictement rien, ils ne m'ont jamais attiré, même si j'ai eu pratique SuSE en environnement entreprise, mais jamais aimé.)
Mais je retiens la leçon : ne rien exprimer de contre à-propos de ce monsieur et de ces articles.
Donc, dorénavant, quand je verrais un article de @kikinovak, je passerais carrément mon chemin, aussi pertinent soit son analyse, ou pas.
Une suggestion pour l'avenir : comprendre la différence entre la critique descriptive et la critique prescriptive.
Exemple de critique descriptive : “L'auteur écrit un article sur Iptables, une technologie encore actuelle dans les distributions Linux de qualité entreprise, mais tendant à être remplacée par $NOUVELLE_TECHNOLOGIE dans les années à venir. D'ailleurs, une erreur factuelle s'est glissée dans le Xème paragraphe, lorsque […]”
Exemple de critique prescriptive : “Ça devrait être interdit de publier des articles pareils.”
Toute critique constructive de mes articles est évidemment bienvenue. En règle générale, quand il m'arrive d'écrire une ânerie, mes lecteurs me le font très vite savoir en ajoutant un commentaire en bas de l'article correspondant. Je suis toujours reconnaissant pour ça, parce que ça crée un contrôle de qualité qui me semble caractéristique du monde de l'Open Source.
Der Ton macht die Musik. (proverbe de mon pays natal)
Pfff nftables… complètement dépassé, ce n'est même pas la peine d'y jeter un coup d'oeil. Son taux d'adoption est quasi-nul, et il est déjà en passe d'être remplacé par BPF.
Plus sérieusement, d'après ce que je lis ce n'est probablement vraiment pas la peine de s'investir dans nftables. netfliter va être remplacé par bpfilter avec une compatibilité de l'ABI avec iptables. nftables semble voué aux oubliettes.
Sinon, travaillant dans un environnement professionnel très varié, je constate que le choix des briques est souvent complexe.
Le choix de Redhat, avec sa politique de support encourage parfois à un attentisme. Il est vrai qu'entre stabilité et innovation l'équilibre est parfois difficile !
Plus généralement, je conseille la lecture de l'excellent ouvrage “Trop Vite” de Jean-Louis Servan-Schreiber, qui traite de l'effet néfaste de l'accélération de notre quotidien dans tous les domaines (technique, financier, politique, amoureux, etc.) et de toutes ces cibles mouvantes qui nous pourrissent la vie. Ne pas confondre avec le bouquin de Nabilla qui porte le même titre, hein.
Et bien moi, j'ai trouvé ça très intéressant ^^. Question, il y a plusieurs fois l'action “LOG” (“-j LOG” en tout cas) dans les commandes, mais pas dans la partie “Les différentes actions”; quelle est la différence? Y a-t-il des LOG/DROP, LOG/REJECT et LOG/ACCEPT?
Si d'autres se posaient la même question, la réponse se trouve dans la “man iptables-extensions” :
LOG
Turn on kernel logging of matching packets. When this option is set for a rule, the Linux kernel will print some information on all matching packets (like most IP/IPv6 header fields) via the kernel log (where it can be read with dmesg(1) or read in the syslog).
This is a “non-terminating target”, i.e. rule traversal continues at the next rule. So if you want to LOG the packets you refuse, use two separate rules with the same matching criteria, first using target LOG then DROP (or REJECT).
Merci pour les fleurs. Et concernant les logs, le principe ici c'est que tout ce qui n'est pas accepté est journalisé. Après, ne pas oublier qu'il s'agit d'une introduction de prise en main qui se veut générale. Pour les détails, il vaut mieux voir la doc écrite par Oskar Andreasson, beaucoup plus assomman^^^^^complète. :o)
Le principe est très simple :
Car non, les LOG ne servent pas qu'à journaliser ce qui doit être rejeté ou supprimé sans avis. Ils servent à analyser la situation, correspondant à un critère. Ensuite, vient l'action.
Bonjour,
Mis à part qu'il est clairement recommandé de ne plus utiliser Iptable car considéré obsolète.. et qu'il (f|v)aut se mettre à son remplaçant nftables ! (un coup de manpage sous Debian, c'est explicite)
un article obsolète, en retard de plusieurs années !
Désolé.
Ta remarque est dure, ne pas oublier que CentOS et RHEL ont des durées de support très sexy/importantes.
Tcho !
Merci pour le commentaire, je savais pas que iptables était jugeait obsolète. Après avoir lu le wiki debian, c'est principalement la complexité du “framework” iptables qui l'a amené à être mis au rebus.
Je suis également d'accord avec Cascador, ton commentaire est très dur. L'article de kikinovak est très bien et complet. Le fait qu'il présente le fonctionnement d'une technologie amené à être considéré obsolète en 2024, soit dans 5 ans n'en fait pas du tout un article obsolète en retard de plusieurs années !
edit : après avoir pris quelques minutes pour faire des recherches, j'ai pas l'impression que nftables soit unanimement validé. Je vais rester sur iptables en attendant que cela se décante.
Sur les systèmes RHEL/CentOS, iptables sera officiellement obsolète le 30 juin 2024.
Wenn wir zum Guten dieser Welt gelangen, Dann heißt das Beßre Trug und Wahn. (Goethe, Faust)
Merci de ne pas mettre troll sur un commentaire qui est certes peu plaisant mais qui donne un point de vue argumenté.
Tcho !
Y'avait pas “gratuitement désobligeant comme d'habitude”, du coup j'ai mis “troll”. Mais je ne le referai plus, promis.
Ha ha ha ;)
Tcho !
Je suis très surpris de voir les réactions si négatives et les intentions qui me sont données. Si on ne peut donner son avis, sans être si durement jugé, c'est une farce et une pantomine.
Rien dans ma remarque n'est désobligeant, et encore moins trollesque. Il faudrait revoir les définitions des termes. Que le commentaire soit considéré comme dur, voire très dur, je peux le comprendre. Mais ça ne mérite en rien le déchaînement de passion négative et l'assaut en règle de celui-ci !
Je suis mesuré dans mes propos… et je tiens à le reste. Je ne me permet aucune attaque ad hominem. Et il est normal qu'on le reste aussi. @kikinovak n'a pas l'air d'apprécié qu'on ne soit pas d'accord avec lui. Son effort de vulgarisation est louable, mais ces petites imprécisions m'agacent. Et, j'ai le droit de le ressentir… mais apparemment pas de l'exprimer, puisque cela déchaîne des vélléités destructrices à mon encontre.
Je n'y peut rien, personnellement, si systemd jette aux oubliettes iptables, et met aux alouettes nftables. Je n'y peut rien, si systemd tend à imposer certaines choses.
De toute façon, j'ai de plus en plus tendance à fuir Debian, et de fait, Linux, à cause des pratiques ‘systemd’ - surtout quand je vois la facilité d'administration d'OpenBSD, auquel je suis coutumié depuis quelques années… et quand je vois la simplicité de PF - Packet Filter - face ne serait qu'à côté d'Iptables - et, je ne parle même pas de nftables et autres consorts - je suis très sceptique sur le reste. Mon seul regret est que Debian GNU/kFreeBSD ne décolle pas. Au moins, on garderait l'avantage des deux mondes, et le meilleur de ces deux mondes.
(il est vrai, malheureusement, que pour OpenBSD, il est strictement nécessaire d'avoir du matériel compatible ; pour ce qui est des autres Linux, autres que Debian, voire Ubuntu, je n'en sais strictement rien, ils ne m'ont jamais attiré, même si j'ai eu pratique SuSE en environnement entreprise, mais jamais aimé.)
Mais je retiens la leçon : ne rien exprimer de contre à-propos de ce monsieur et de ces articles. Donc, dorénavant, quand je verrais un article de @kikinovak, je passerais carrément mon chemin, aussi pertinent soit son analyse, ou pas.
Bonne fin de week-end !
Une suggestion pour l'avenir : comprendre la différence entre la critique descriptive et la critique prescriptive.
Exemple de critique descriptive : “L'auteur écrit un article sur Iptables, une technologie encore actuelle dans les distributions Linux de qualité entreprise, mais tendant à être remplacée par $NOUVELLE_TECHNOLOGIE dans les années à venir. D'ailleurs, une erreur factuelle s'est glissée dans le Xème paragraphe, lorsque […]”
Exemple de critique prescriptive : “Ça devrait être interdit de publier des articles pareils.”
Toute critique constructive de mes articles est évidemment bienvenue. En règle générale, quand il m'arrive d'écrire une ânerie, mes lecteurs me le font très vite savoir en ajoutant un commentaire en bas de l'article correspondant. Je suis toujours reconnaissant pour ça, parce que ça crée un contrôle de qualité qui me semble caractéristique du monde de l'Open Source.
Der Ton macht die Musik. (proverbe de mon pays natal)
Et c'est toi qui me répond cela avec les jugements de valeur, à l'emportée, tels que tu les as faits.
Merci du conseil. Bye !
Pfff nftables… complètement dépassé, ce n'est même pas la peine d'y jeter un coup d'oeil. Son taux d'adoption est quasi-nul, et il est déjà en passe d'être remplacé par BPF.
;-P
Plus sérieusement, d'après ce que je lis ce n'est probablement vraiment pas la peine de s'investir dans nftables. netfliter va être remplacé par bpfilter avec une compatibilité de l'ABI avec iptables. nftables semble voué aux oubliettes.
Eh oui certaines technologies dans des environnement très évolutifs comme les container montrent leurs limites. Voici un chouette article en anglais sur BPF : https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-iptables/ et qui montrent pourquoi BPF est apprécié.
Sinon, travaillant dans un environnement professionnel très varié, je constate que le choix des briques est souvent complexe.
Le choix de Redhat, avec sa politique de support encourage parfois à un attentisme. Il est vrai qu'entre stabilité et innovation l'équilibre est parfois difficile !
Plus généralement, je conseille la lecture de l'excellent ouvrage “Trop Vite” de Jean-Louis Servan-Schreiber, qui traite de l'effet néfaste de l'accélération de notre quotidien dans tous les domaines (technique, financier, politique, amoureux, etc.) et de toutes ces cibles mouvantes qui nous pourrissent la vie. Ne pas confondre avec le bouquin de Nabilla qui porte le même titre, hein.