Salut,
J’opère un serveur de jeu sous Debian 10 (oui, 10, car c’est un très vieux jeu, avec un B3/BigBrotherBot, dont les librairies, notamment python, qui descendent avec les versions supérieures de Debian ne sont plus compatibles, et compliquent substantiellement le fonctionnement…) sur un dédié OVH. Le serveur héberge accessoirement aussi quelques sites web sous apache2 (un forum, un Echelon pour la gestion de la modération du jeu, et un adminer pour l’administration des bases de données) et les les bases de données qui vont avec (MariaDB)
Le serveur a les sécurités d’usages :
- un pare-feu iptables avec une politique de blocage par defaut, seuls les ports nécessaires sont autorisés qui démarre avec l’activation du réseau (script de configuration executable placé dans if-up.d)
- du fail2ban qui ne chôme pas, ça ban à tour de bras les bot, scanneurs, scripts kiddies…
- les sites sont en https, avec une gestion du renouvellement des certificats via Let’s encrypt (procédure suivie selon la doc OVH)
- j’ai desactivé IPV6 car on n’en a pas besoin, et puis iptables ne le gère pas…
Tout marchait plutôt très bien jusqu’il y a peu, où, lors d’un redémarrage du serveur, celui ci s’est retrouvé bloqué sur une ligne :
audit : type=1400 […] apparmor=« STATUS » operation=« profile_load » profile=« unconfined » name=« snap-update-ns.core » pid = 563 comm=« apparmor_parser »
Je vous passe les détails pour démmerder ce genre de problème sur un serveur distant (obligé de se loguer en KVM en mode « rescue », car pas de réseau, donc pas de SSH, montage de la partition, diagnostic, correction, repassage au mode normal, reboot, etc…)
J’ai eu le nez creux, et me suis immédiatement aperçu que le problème ne se produisait que lorsque le pare-feu était actif : En panne d’inspiration (et de connaissance suffisante), je me suis résolu à contourner le problème en différant un peu le démarrage du pare-feu une fois le reseau « up », ce qui évite à présent de bloquer le démarrage.
Cependant, bien conscient que cela n’est ni une correction, ni bonne solution car peu secure (j’ai en tête une position du célèbre PascalHambourg indiquant qu’un pare feu doit toujours démarrer avant l’activation de l’interface réseau, et ne s’arrêter qu’après la désactivation de celle ci), j’en appelle à vos compétences pour m’aider à comprendre comment résoudre le plus proprement possible ce problème (peut-être une règle à rajouter dans mon script de conf. de iptables, mais je ne vois vraiment pas laquelle…).
Je pourrais communiquer mon script iptables, si nécessaire, mais sachant qu’il a très bien fonctionné pendant plus de 3 mois, je doute qu’il soit directement en cause, si ce n’est par absence d’une autorisation spécifique à ce « apparmor ».
Merci d’avance.
Dric64