Ce que fait l'installateur

InfraFence est conçu pour les serveurs de production : l'installateur contrôle le serveur en lecture seule avant de modifier quoi que ce soit, et laisse de côté ce qu'il ne peut pas modifier sans risque.

Les étapes#

1. Jeton et root. Sans --token sur un serveur pas encore enregistré, il s'arrête avec Install token is required ; le dry run n'a pas besoin de jeton. Il doit s'exécuter en root.
2. Système. Linux uniquement ; il détecte le système d'init (systemd, upstart ou sysvinit) et l'architecture (amd64 ou arm64).
3. Certificats. Sur les systèmes de la famille RHEL, ou quand curl ne parvient pas à vérifier le téléchargement, il ajoute le certificat ISRG Root X1 (Let's Encrypt) à un bundle qui lui est propre, /etc/infrafence/ca-bundle.pem, et sur les systèmes de la famille RHEL aussi aux certificats du système. Le certificat fait partie de l'installateur et n'est jamais téléchargé ; là où openssl est présent, il est d'abord comparé à son empreinte SHA-256 fixée.
4. Dépendances. curl, iptables ou ca-certificates manquants sont installés avec apt-get, dnf ou yum ; sur les systèmes rpm, iptables est installé sous la forme iptables-nft là où ce paquet existe, pour que ses règles utilisent le même backend que firewalld et nftables. Si une autre opération sur les paquets est en cours, il attend jusqu'à 5 minutes (Another package operation is running — waiting for it to finish...). Il ne lance jamais dpkg --configure -a et ne répare jamais de lui-même des paquets cassés.
5. Téléchargement. Le binaire de l'agent pour l'architecture est téléchargé depuis la dernière release GitHub (github.com et release-assets.githubusercontent.com, la seule source de téléchargement) et vérifié par rapport à sa somme de contrôle SHA-256 publiée. La somme de contrôle est obligatoire : si elle ne peut pas être téléchargée ou ne correspond pas, rien n'est installé. --skip-checksum installe sans elle et n'est pas sûr.
6. Contrôle en lecture seule. Il lance infrafence-agent preflight avant d'installer quoi que ce soit (voir plus bas).
7. ipset. Installé seulement s'il manque, s'il n'est pas refusé avec --no-ipset, et si le contrôle indique que c'est sans risque : un gestionnaire de paquets est disponible et aucune opération sur les paquets n'est en cours.
8. Installation. Le binaire est placé dans /usr/local/bin/infrafence-agent, le service est créé, activé et démarré.
9. Enregistrement. L'agent s'enregistre avec votre jeton et stocke son propre jeton dans /etc/infrafence/config.json. Le jeton d'installation n'est pas conservé.
10. Vérification du démarrage. Il vérifie que le service tourne, et indique où lire les journaux.

Le téléchargement, l'enregistrement et le démarrage du service signalent leur résultat au tableau de bord (avec seulement les premiers caractères du jeton), pour qu'une installation ratée puisse être retracée.

Le contrôle en lecture seule (preflight)#

infrafence-agent preflight examine le serveur et ne modifie rien. L'installateur le lance avant d'installer, l'agent le lance à chaque démarrage puis une fois par jour, et vous pouvez le lancer à tout moment :

sudo infrafence-agent preflight
sudo infrafence-agent preflight --json

La sortie commence par InfraFence preflight (read-only — nothing was changed), puis une ligne par constat avec son niveau : ok, info, warn ou block. Sans --json, le code de sortie vaut 2 quand un constat est block, et 0 sinon.

Il examine :

• Pare-feu : si iptables est installé et utilisable, et son backend ; si ipset est présent ; les autres gestionnaires de pare-feu et outils de sécurité (ufw, firewalld, CSF, fail2ban, CrowdSec, netfilter-persistent, Docker, Kubernetes).
• Serveurs web : nginx, Apache (apache2 ou httpd), Caddy et LiteSpeed.
• Qui gère la configuration : les panneaux d'hébergement et les outils de gestion de configuration (Ansible, Puppet, Chef, Salt). Quand l'un d'eux est présent, InfraFence ne modifie jamais la configuration du serveur web.
• Paquets : le gestionnaire de paquets et toute opération sur les paquets en cours.
• Ressources : l'espace disque libre sur / (avertit sous 200 Mo), la mémoire disponible (avertit sous 128 Mo), le mode SELinux.

Le résultat arrive aussi au tableau de bord : l'onglet Hôte du serveur l'affiche sous Compatibilité du serveur.

Le dry run#

curl -fsSL https://github.com/infrafence/infrafence-agent/releases/latest/download/install.sh | sudo bash -s -- --dry-run

Il n'a pas besoin de jeton, et ne change rien non plus sur les systèmes de la famille RHEL : l'étape des certificats ne vaut que pour cette exécution. Il télécharge l'agent, lance le contrôle en lecture seule et affiche Dry run — nothing was installed or changed., suivi de ce que ferait une vraie exécution : installer le binaire et le service, installer ipset ou non, créer les chaînes de pare-feu INFRAFENCE (avec un saut depuis INPUT, et depuis DOCKER-USER si Docker est présent) et s'enregistrer. Les modifications de la configuration du serveur web et le blocage entrant des listes de renseignement sur les menaces restent désactivés jusqu'à ce que vous les activiez dans le tableau de bord.

Ce qu'il ne fait jamais#

• Il ne modifie jamais vos règles de pare-feu existantes : tout se trouve dans les chaînes propres à l'agent.
• Il ne termine jamais les configurations à moitié faites d'autres paquets (dpkg --configure -a), ce qui pourrait redémarrer des services.
• Il ne modifie jamais une configuration qui appartient à un panneau d'hébergement, à LiteSpeed ou à un outil de gestion de configuration.