[gull] Attaque locale root kernel Linux / risque pour les services hébergés

[Marc SCHAEFER]

On Fri, May 01, 2026 at 12:41:45PM +0200, Félix Hauri via gull wrote:
> Relativement équivalent. Un peu plus ``bourrin'', mais tant qu'à faire:
> pourquoi renommer un fichier qui ne te servira à rien sinon à compromettre
> ta machine. Pour moi la méthode ``bourrin'', serait:
>   # find /lib/modules/ -type f -name algif_aead.ko -delete

Risque: en cas de mise à jour du package (au même endroit: pour le
kernel il me semble que c'est plutôt rare), il va revenir.

D'où l'idée de la diversion.

Exemple plus clair:

shakotay:~# dpkg-divert --list | grep awstats
local diversion of /usr/lib/cgi-bin/awstats.pl to /usr/lib/cgi-bin/awstats/awstats.pl

Si j'avais juste supprimé, alors à la prochaine mise à jour du package,
il serait revenu dans /usr/lib/cgi-bin ce qui peut poser des risques
de sécurité si l'on n'a pas explicitement interdit ce répertoire dans
la config apache2.

Cas concret: il y a un .htaccess dans /usr/lib/cgi-bin/awstats.

> Mais je préfère la méthode recommandée, plus system-friendly...

Tout à fait, et comme dit, ça loggue, le jour où on veut comprendre
pourquoi XXX ne marche plus.

>  - analyse des logs

Evidemment, si l'attaquant est devenu root, il peut aller modifier les
logs ...

Si on est parano, on envoie tous les logs à une machine séparée (par
rsyslog UDP/TCP, ou par partage de fichiers ou autre), qui n'a pas
les mêmes accès, de manière à assurer des logs plus ou moins immutables.

Autre avantage: parsing + firewalling + reporting + évt. analyse
plus poussé centralisée des logs.

Il y a "un certain temps", j'avais mis une imprimante matricielle série
(ligne-à-ligne) sur la sortie d'un firewall/VPN.  Ainsi la secrétaire
pouvait voir en temps réel qui se connectait (en plus ça faisait du
bruit, pratique).  Et il fallait physiquement déchirer le papier continu
de l'imprimante (donc visible) pour cacher un login :)

Je n'ai plus ce genre d'imprimantes en stock, mais à voir on en trouve
sur ebay et ricardo :->  Alternative: un raspi, ou un apu2, branché
en série, pas branché sur le réseau, qui loggue en SSD, éventuellement
même en chattr +a et/ou app-armor et interdire à root, sauf loggué
sur la console, de pouvoir changer le niveau de sécurité du système.

> L'informatique c'est très simple, ce ne sont que des 1 et des 0.
> Le truc, c'est qu'il y en a de plus en plus....

:)