D'accord avec toi sur le principe. À mon humble avis, la place de SELinux est effectivement sur des serveurs RHEL. Je pense qu'une fois qu'on en a cerné les bases - et c'est précisément pour cela que j'ai écrit l'article - ce n'est pas si difficile que ça.
SELinux est véritablement une purge et un emmerdement quotidien sur mon poste de travail quotidien avec Fedora Workstation. Qu'il soit installé sur des gros serveurs RHEL certes, mais sur une station de travail cela n'a aucun intérêt.
Mais merci pour ton article riche et en français qui démystifie un peu cette soupe ésotérique qu'est SELinux. :)
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)
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?
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.
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.
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.
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 !
Tu peux demander à l'autre sur twitter par exemple @poroot … moi je suis tombé sur blog tout récemment et n'‘avait pas souvenir de le voir poster ici :)
J'avoue une profonde détestation pour SeLinux, je le passe en permissif sur tous les serveurs où je bosse. A mon avis c'est un machin fait par les administrateurs pour emmerder les dev.
Il est malheureusement souvent plus convaincant d'appuyer quand ça fait mal lors des pannes des services centralisés GAFAMesques que de tchatcher sur l'éthique et la vie privée…
D'accord avec toi sur le principe. À mon humble avis, la place de SELinux est effectivement sur des serveurs RHEL. Je pense qu'une fois qu'on en a cerné les bases - et c'est précisément pour cela que j'ai écrit l'article - ce n'est pas si difficile que ça.
SELinux est véritablement une purge et un emmerdement quotidien sur mon poste de travail quotidien avec Fedora Workstation. Qu'il soit installé sur des gros serveurs RHEL certes, mais sur une station de travail cela n'a aucun intérêt.
Mais merci pour ton article riche et en français qui démystifie un peu cette soupe ésotérique qu'est SELinux. :)
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)
Ha ha ha ;)
Tcho !
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?
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.
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.
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
Y'avait pas “gratuitement désobligeant comme d'habitude”, du coup j'ai mis “troll”. Mais je ne le referai plus, promis.
Ta remarque est dure, ne pas oublier que CentOS et RHEL ont des durées de support très sexy/importantes.
Tcho !
Merci de ne pas mettre troll sur un commentaire qui est certes peu plaisant mais qui donne un point de vue argumenté.
Tcho !
Chouette article, merci. À noter que ça ne marche pas pour les rollbacks d'une certaine ampleur.
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)
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é.
Tu peux demander à l'autre sur twitter par exemple @poroot … moi je suis tombé sur blog tout récemment et n'‘avait pas souvenir de le voir poster ici :)
Je pensais comme toi, et puis j'ai regardé la présentation de Thomas Cameron, qui m'a fait changer d'avis.
https://www.youtube.com/watch?v=MxjenQ31b70
Du coup j'ai pris le temps de me documenter, et j'ai écrit cette intro pour les autres.
Je vais devoir mettre des <div>Merci de désactiver votre bloqueur de publicité</div> :-)
J'avoue une profonde détestation pour SeLinux, je le passe en permissif sur tous les serveurs où je bosse. A mon avis c'est un machin fait par les administrateurs pour emmerder les dev.
Il est malheureusement souvent plus convaincant d'appuyer quand ça fait mal lors des pannes des services centralisés GAFAMesques que de tchatcher sur l'éthique et la vie privée…