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 !
“Selon Luc Julia, l'intelligence est « réservée au vivant ». C'est un postulat, donc non prouvé” dixit l'article. Acceptons donc ce postulat.
Il faut maintenant définir le vivant ou plutôt le choisir pour pouvoir facilement le programmer (lui apprendre à donner des réponses correctes) et donc créer cette singularité.
Pour ma part, dire que l'IA n'est pas intelligente c'est comme ceux qui, début des années 80, disaient que l'ordinateur n'était pas intelligent.
Ils oubliaient l'essentiel : l'informatique allait devenir l'alphabet de notre société 40 ans après. Et j'ai bien fait de m'y intéresser puisque aujourd'hui c'est mon métier ! (:-)
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.
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?
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.
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.
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 !
“Selon Luc Julia, l'intelligence est « réservée au vivant ». C'est un postulat, donc non prouvé” dixit l'article. Acceptons donc ce postulat.
Il faut maintenant définir le vivant ou plutôt le choisir pour pouvoir facilement le programmer (lui apprendre à donner des réponses correctes) et donc créer cette singularité.
Les cellules synthétiques existent et la recherche Européenne investit voir par exemple ici : https://ai-med.io/artificial-intelligence-synthetic-bio/ .
Pour ma part, dire que l'IA n'est pas intelligente c'est comme ceux qui, début des années 80, disaient que l'ordinateur n'était pas intelligent.
Ils oubliaient l'essentiel : l'informatique allait devenir l'alphabet de notre société 40 ans après. Et j'ai bien fait de m'y intéresser puisque aujourd'hui c'est mon métier ! (:-)
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.
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?
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.
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.
Oui moi aussi j'avais perdu de vue Xavier de La Porte, ravi que cela aide d'autres personnes. Ses analyses sont toujours aussi intéressantes !
Bah il me semblait pas, mais du coup j'ai désactivé pour ton site et tout est rentré dans l'ordre :)