[gull] Pas mal d'exploits Linux kernel ces temps-ci, que faire?

[Marc SCHAEFER]

Salut,

On Tue, Sep 08, 2026 at 10:13:03AM +0200, Daniel Cordey via gull wrote:
> Merci à Marc pour ces explications (et suggestions) très intéressantes.

Et merci à toi pour tes compléments.

> que, dans la mesure du possible, il est recommandé de ne pas "tourner" les
> différents conteneur en "root" ! Ceci est facilement configurable, autant
> dans Docker (UUID), que dans Podman (par défaut).

Tout à fait, cela augmente le risque que le root du conteneur ait des
privilèges, et de tourner des services avec trop de droits.  Par contre,
la dernière fois que j'ai tourné un VPN dans un conteneur, j'ai dû
ajouter quelques capabilities Linux.  Donc ça dépend de ce que l'on
fait.

Attention aussi à regénérer souvent, ou à mettre à jour
semi-automatiquement, les dizaines de conteneurs répartis sur plusieurs
hosts qu'on utilise si l'on a appliqué un bon confinement des services.

Et se méfier des images de base qui peuvent être vérolées
accidentellement ou intentionnellement (mon concept est de générer des
mini-Debians moi-même comme image de base; et avec les versions
récentes de Debian on a moins de pollution/dépendances de bibliothèques,
en particulier parce que je n'utilise pas systemd dans les conteneurs,
cf mon premier mail pour sshd faisant référence à la vulnérabilité
xz/liblzma injectée par dépendance systemd il y a un peu plus d'un an,
ou la discussion sur cette mailing-list sur comment faire un jump
host sécurisé).

D'un autre côté, beaucoup de ces vulnérabilités kernel en modules dont
j'ai parlé étaient exploitables depuis des conteneurs non privilégiés
(ou, éventuellement, via des bugs de conteneurs privilégiés comme ceux
 gérant Kubernetes, par exemple).  C'est ça qui est ennuyeux dans
le "pattern" de ces attaques et ma solution en patche probablement
une bonne partie à l'avenir.

> tout faire. À mon humble avis, qui dit serveur dit "pare-feu". Ceci me

J'exploite plutôt des firewall couche 4, 3 voire 2.  Pas trop qui
font bcp de choses dans les couches supérieures, d'autant plus
si le trafic a ses données chiffrées (HTTPS par exemple): en bref
je ne donne pas la clé de déchiffrement au firewall.

En général, je préfère utiliser:

   - pare-feu simple (avec liste de blocage dynamique, détection de
     certains abus)
   - reverse-proxy (terminant le HTTPS, donc pouvant déjà voir certaines
     choses): détection déjà plus complexe d'abus dans les protocoles
     des couches supérieures
   - WAF ou approchant (couche de détection d'intrusion / filtrage soit dans le
     reverse-proxy, soit comme module apache2 comme mod_security)
   - serveur web
   - validation dans l'application web

Lorsque nécessaire (appli tierce) je combine du contrôle d'accès dans
l'application avec une authentification dans le serveur web. C'est un
peu plus lourd pour l'utilisateur mais cela bloque des attaques
pre-login dans les applications.  Sauf erreur Swissquote fait/faisait
ça aussi.

Dans des cas où le reverse-proxy n'est pas sur le même host que le
service, rechiffrer semble nécessaire aujourd'hui.

Lorsque le protocole n'est pas web, il existe souvent des modules de validation.

> suis aperçu que 59% des requêtes DNS étaient bloquées, car faisant partie de
> ces "black-list" (pubs non désirées)

Je maintiens une blacklist alimentée par mes honeypots (en DNS/RBL et en
téléchargement): https://wiki.alphanet.ch/Sandbox/ALPHANETBlackHoles

En interne, ces honeypots permettent assez rapidement de bloquer pas mal
d'attaques au niveau firewall.  J'utilise aussi des bases de données
comme AbuseIPdb ou d'autres. Certaines IP sont bloquées dynamiquement
assez rapidement pendant ou après la 1ère requête, ou redirigées
vers une notification de blocage dans les cas moins sûrs.

Le nombre d'attaques a beaucoup augmenté chez moi depuis le printemps
2025, mais quelques réflexions simples sur les stratégies des attaquants
ont permis de les détecter.

   https://attacks.alphanet.ch/

Reste le souci de l'IPv6: ma façon actuelle de gérer les attaques ne
marcherait pas bien en IPv6 (ou alors je devrais "escaler" assez
rapidement en bloquant des sous-réseaux énormes v6).  Je suis donc
revenu temporairement en arrière en n'offrant quasi plus rien en v6.

> Un aspect intéressant concerne aussi la confidentialité des requêtes DNS.
> Dans ce domaine, la solution de Technitium (https://technitium.com/dns/)

Je signale que SociétéNumérique propose un DNS over HTTPS (DoH).

> Tout ceci pour dire que la sécurité est un ensemble de solutions, dont
> chacune joue un rôle différent. Les attaques étant variées, il est important
> de pouvoir disposer de solutions et procédures répondant à cette variété qui
> ne cesse d'évoluer.

Ca devient toutefois compliqué (co-évolution: on n'est protégé des
attaques non ciblées que si on est un tout petit peu plus sûr que la
moyenne, sauf si on est une cible particulière et alors on doit être
bien mieux protégé que la moyenne, cf Reine Rouge).  Et on n'a pas
mentionné le rôle de l'IAgen :->

Bonne journée.