SysWarden v4 : orchestrer nftables sur un serveur Linux exposé

Un serveur exposé sur Internet est scanné en permanence. SysWarden écrit et tient à jour, à votre place, les règles du pare-feu de cette machine, celui du noyau Linux, nftables. Il y injecte des listes d'adresses malveillantes connues, sait refuser des pays entiers, resserre les réglages du système, et lit les journaux de vos services pour bloquer une source qui insiste. Tout se pilote en ligne de commande, sur un serveur loué chez un hébergeur, une machine d'accès ou un petit serveur web. Cette page documente la version 4.04.3, publiée le 7 septembre 2026 et mesurée en machine virtuelle sur Debian 13 et AlmaLinux 10.2.

Ce que vous allez apprendre

• Situer SysWarden : ce qu'il pilote, et pourquoi il ne remplace pas un pare-feu applicatif.
• Installer la v4.04.3 par paquet, en vérifiant l'artefact avant de l'installer.
• Lire la configuration TOML modulaire et savoir quel module porte quel réglage.
• Migrer une configuration v3 sans perdre de réglage, et savoir ce qui n'est pas repris.
• Synchroniser deux nœuds, et diagnostiquer les refus.
• Désinstaller proprement, y compris ce que la désinstallation ne défait pas.

Prérequis

• Un serveur amd64 sous Debian 13, Ubuntu 24.04 ou 26.04, Fedora 44, AlmaLinux 9 ou 10, ou Alpine 3.22 ou 3.24
• Accès root ou sudo
• La commande curl ou wget
• L'adresse d'administration depuis laquelle vous vous connectez
• Un accès de secours hors SSH (console de l'hyperviseur, KVM, IPMI)

Prévoyez un accès de secours avant de commencer

SysWarden pose une politique de filtrage et durcit SSH. La détection automatique de l'adresse d'administration échoue quand l'installation passe par le gestionnaire de paquets : la variable SSH_CONNECTION n'existe pas dans ce contexte, et le journal affiche [WARN] Could not safely determine Admin IP from environment. Ce message est apparu à chaque installation mesurée, en v4.04.3 comme en v3. Renseignez votre adresse dans whitelist_ips et gardez une console de secours ouverte.

SysWarden est-il un WAF ?

Non. Un WAF, pour Web Application Firewall, est un pare-feu applicatif : il inspecte chaque requête HTTP avant qu'elle n'atteigne l'application, et refuse celles qu'il juge hostiles. SysWarden ne fait pas cela, et son aide en ligne de commande le dit sans détour :

SYSWARDEN is a host firewall orchestrator and out-of-band security-log
analysis toolkit; it is not an inline WAF.

La distinction est structurelle, pas cosmétique. Un WAF en coupure comme BunkerWeb se place dans le chemin de la requête : il la reçoit, l'inspecte, la modifie ou la rejette avant que l'application ne la voie. SysWarden ne voit jamais la requête. Il lit les journaux que les services ont déjà écrits, en tire une décision, et l'applique au niveau réseau en ajoutant l'adresse à nftables. C'est ce qu'on appelle travailler hors bande : à côté du trafic, pas dedans.

application / reverse proxy
        |  écrit ses journaux
        v
SysWarden observe, normalise, décide
        |
        v
nftables applique la décision

Trois conséquences pratiques découlent de ce schéma, et elles décident si l'outil répond à votre besoin.

• La décision arrive après coup. La requête qui a déclenché la détection est déjà arrivée jusqu'à l'application.
• Le blocage est par adresse, pas par requête. SysWarden ne sait pas refuser une seule URL ; il refuse une source entière.
• Il ne protège que ce qui écrit un journal qu'il sait lire. Un service qui ne journalise pas, ou dans un format inconnu, est invisible pour lui.

Ce que SysWarden orchestre en v4

Le paquet dépose trois binaires Go dans /opt/syswarden/bin/, en -rwxr-x--- root:root, donc invisibles à un utilisateur non privilégié.

Composant	Rôle
syswarden-cli	Orchestration : installation, configuration, gestion des adresses, audit
syswarden-core	Moteur d'analyse de journaux et service de synchronisation, en démon
syswarden-tui	Tableau de bord terminal, local

Glissez pour voir

Autour de ces binaires, l'outil agrège des mécanismes qui restent, pour l'essentiel, ceux de la génération précédente.

Mécanisme	Ce qu'il fait
Politique nftables	Trois tables posées : netdev syswarden_hw_drop, inet syswarden, arp syswarden_arp
Listes de blocage	Flux de renseignement, vérifiés par quorum de trois origines HTTPS indépendantes
Filtrage par pays	Activé, mais sans aucun pays listé par défaut en v4.04.3
Filtrage par AS	Un AS est un bloc d'adresses appartenant à un même opérateur : on refuse tout un hébergeur d'un coup
Honeyports	Ports leurres : qui s'y connecte se désigne comme hostile. 6379 et 23 par défaut
Protection L2	Limitation du débit ARP
WireGuard	Tunnel d'administration, désactivé par défaut
Haute disponibilité	Synchronisation de la liste de blocage entre deux nœuds
Durcissement	Réglages du noyau et du système selon le CIS Benchmark niveau 2, un référentiel public de configuration sûre

Glissez pour voir

Le filtrage par pays est à régler vous-même

Le mécanisme est activé, mais 10-network.toml porte blocked_countries = [] : la liste est vide, donc rien n'est bloqué par pays tant que vous ne la remplissez pas. L'audit le signale par GeoIP Threat Intelligence (Skipped by user). Si vous venez de la v3, où 77 codes étaient pré-remplis, c'est le réglage à reprendre en premier.

Quelles plateformes sont réellement supportées ?

La v4 a resserré sa matrice par rapport à la v3, et c'est un choix de qualification assumé par le projet plutôt qu'un abandon : la release ne publie que ce qu'elle qualifie.

Famille	Versions annoncées	Paquet
Debian	13	.deb
Ubuntu	24.04, 26.04	.deb
Fedora	44	.rpm
AlmaLinux	9, 10	.rpm
Alpine	3.22, 3.24	.apk

Glissez pour voir

La release v4.04.3 publie trois paquets, tous en amd64. Le site du projet le dit explicitement : « ARM64/AArch64 and FreeBSD packages are not part of the supported release matrix ». Si vous faisiez tourner SysWarden sur un ARM ou sur FreeBSD en v3, la v4 ne vous couvre plus.

Installer SysWarden v4.04.3

L'installation se fait en deux temps : le paquet dépose les fichiers, puis syswarden install applique la politique. Cette seconde passe n'est pas facultative, et son caractère obligatoire dépend de la famille de paquet.

1. Récupérer le paquet et ses preuves

   La release publie deux fichiers de sommes, un SBOM et un manifeste signé. Commencez par le paquet et les sommes ; l'étape 3 récupérera le reste.

   VERSION=4.04.3
   BASE="https://github.com/duggytuxy/syswarden/releases/download/v${VERSION}"
   curl -fsSLO "${BASE}/syswarden_${VERSION}_amd64.deb"
   curl -fsSLO "${BASE}/SHA256SUMS.txt"
   curl -fsSLO "${BASE}/RELEASE_SHA256SUMS.txt"

2. Vérifier l'empreinte, et savoir ce que cette vérification prouve

   Les deux fichiers de sommes couvrent les trois paquets.

   grep "syswarden_${VERSION}_amd64.deb" SHA256SUMS.txt | sha256sum -c -

   La sortie doit afficher syswarden_4.04.3_amd64.deb: OK. Toute autre réponse arrête l'installation.

   Ce contrôle prouve l'intégrité, pas la provenance. Il compare le paquet à un inventaire téléchargé depuis la même source : qui remplace l'un remplace l'autre. Mesuré le 2026-09-21 en substituant le paquet et en réécrivant sa ligne dans SHA256SUMS.txt, la commande ci-dessus répond toujours OK.

3. Authentifier l'éditeur, pour un téléchargement manuel

   C'est l'étape qui manque au contrôle précédent. La release publie un manifeste signé en Ed25519 et sa signature détachée. Le vérificateur du projet confronte le manifeste aux clés de publication du dépôt, à la version attendue et aux tailles et empreintes des trois paquets.

   curl -fsSLO "${BASE}/syswarden-${VERSION}-1.x86_64.rpm"
   curl -fsSLO "${BASE}/syswarden_${VERSION}_x86_64.apk"
   curl -fsSLO "${BASE}/syswarden-update-manifest-v1.json"
   curl -fsSLO "${BASE}/syswarden-update-manifest-v1.json.sig"

   Le vérificateur vit dans le dépôt, et il lui faut donc un clone et la chaîne Go. La confiance que vous accordez à ce clone est ce qui fonde tout le reste : établissez-la par votre processus habituel, pas en téléchargeant une clé à côté du paquet.

   ARTEFACTS="$PWD"
   sudo apt-get install -y git golang-go
   git clone --depth 1 --branch "v${VERSION}" \
     https://github.com/duggytuxy/syswarden.git /tmp/syswarden-src
   cd /tmp/syswarden-src

   La vérification se lance sans sudo :

   GOFLAGS=-mod=readonly go run ./scripts/ci/update_manifest.go verify \
     --repository "$PWD" \
     --tag "v${VERSION}" \
     --packages "$ARTEFACTS" \
     --manifest "$ARTEFACTS/syswarden-update-manifest-v1.json" \
     --signature "$ARTEFACTS/syswarden-update-manifest-v1.json.sig"

   Sur le paquet substitué de l'étape précédente, il répond ERROR: manifest metadata does not match package syswarden_4.04.3_amd64.deb et sort en 1. Sur l'inventaire authentique, il sort en 0. Le vérificateur exige l'inventaire complet, y compris le .rpm et l'.apk que vous n'installerez pas.

4. Installer le paquet

   L'étape précédente a changé de répertoire pour le clone : on revient d'abord là où les paquets ont été téléchargés.

   cd "$ARTEFACTS"
   sudo apt-get install -y ./syswarden_${VERSION}_amd64.deb

   Sur Debian, le paquet tire une trentaine de dépendances sur une image minimale, dont nftables, rsyslog et cron.

5. Appliquer la politique

   sudo syswarden install

   La commande enchaîne dépendances, configuration SSH, téléchargement des flux, politique de pare-feu, intégrations, durcissement, unités systemd et tâches planifiées. Elle se termine par [SYSWARDEN] v4.04.3 native installation complete.

6. Vérifier

   systemctl is-active syswarden-core syswarden-firewall
   sudo nft list tables

   Les deux services doivent répondre active, et nft list tables afficher les trois tables syswarden_hw_drop, syswarden et syswarden_arp.

Sur RHEL, AlmaLinux et Fedora, appelez la commande par son chemin absolu

Le paquet pose un lien symbolique dans /usr/local/bin/syswarden, un répertoire que le secure_path de la famille RHEL ne contient pas. sudo syswarden audit y répond donc command not found alors que la commande existe. Écrivez sudo /usr/local/bin/syswarden, ou ajoutez /usr/local/bin au secure_path de votre sudoers une fois pour toutes. Les commandes de cette page s'écrivent sudo syswarden : sur ces distributions, préfixez-les.

Pourquoi la seconde passe est indispensable

Le comportement diffère selon la famille de paquet, et c'est mesuré sur les deux.

Famille	Après l'installation du paquet seul
DEB (Debian, Ubuntu)	Les deux unités systemd sont déjà enregistrées et actives
RPM (AlmaLinux, Fedora)	Aucune unité n'existe, systemctl status syswarden-firewall répond could not be found

Glissez pour voir

Sur la famille RPM, le paquet dépose les binaires et un fichier de complément systemd, mais la politique et les services ne viennent qu'avec syswarden install. Lancer cette seconde passe dans tous les cas évite d'avoir à retenir la différence.

Avec SELinux, vérifiez la politique avant d'installer

L'installation fonctionne avec SELinux en Enforcing : elle compile au passage un module SELinux pour le pont rsyslog. Cette compilation exige que la politique selinux-policy-targeted soit présente. Sans elle, semodule échoue sur Failed to resolve typeattributeset statement et l'installation s'arrête avant de créer les services. Vérifiez donc rpm -q selinux-policy-targeted avant de lancer la seconde passe.

Où vit la configuration en v4 ?

C'est le changement le plus profond depuis la v3, et celui qui rend toute documentation antérieure inutilisable. La configuration n'est plus un fichier de variables d'environnement mais une arborescence TOML modulaire, sous /etc/syswarden/config/.

• Répertoireetc/

  • Répertoiresyswarden/

    • Répertoireconfig/

      • config.toml
      • Répertoiremodules/

        • 00-core.toml
        • 10-network.toml
        • 20-security.toml
        • 30-waap.toml
        • 40-integrations.toml
        • 99-user.toml

Le fichier racine config.toml ne porte que trois réglages : la version de schéma, le répertoire des modules et le niveau de journalisation. Tout le reste vit dans les modules, chargés par ordre de numéro croissant, le dernier gagnant.

Module	Ce qu'il porte
00-core.toml	cis_l2_hardening, firewall_backend, hardening_enabled, ssh_port
10-network.toml	Listes blanches, sous-réseaux de confiance, AS, listes de blocage, pays, WireGuard
20-security.toml	Honeyports, surveillance de conformité, protection ARP
30-waap.toml	Seuil et fenêtre de force brute, mode d'application, journaux ModSecurity
40-integrations.toml	AbuseIPDB, BunkerWeb, haute disponibilité, SIEM, Wazuh, webhooks
99-user.toml	Vos surcharges, priorité absolue sur tous les autres

Glissez pour voir

Le fichier 99-user.toml est livré entièrement commenté et mérite d'être compris avant d'éditer quoi que ce soit : il existe pour que vous ne touchiez pas aux autres, que le produit peut réécrire lors d'une mise à jour. Un réglage posé ici survit aux montées de version.

/etc/syswarden/config/modules/99-user.toml

[network.geo]
blocked_countries = ["ru", "cn"]

[waap]
bruteforce_threshold = 3

Le chemin affiché par l'aide du CLI

Le drapeau global --config affiche (default "/opt/syswarden/syswarden-auto.conf"). Ce fichier n'existe pas sur une installation v4 neuve : la configuration est bien l'arborescence TOML décrite ci-dessus. Inutile de le chercher ou de le recréer.

Les réglages qu'il faut regarder en premier

Trois valeurs décident du comportement de l'outil sur votre machine, et méritent une lecture avant la première application.

Réglage	Module	Défaut mesuré	Pourquoi il compte
whitelist_ips	10-network	[]	Le plus important : votre adresse d'administration
firewall_backend	00-core	'keep'	Décide si un pare-feu existant est préservé
blocked_countries	10-network	[]	Vide : aucun pays n'est bloqué tant que vous ne remplissez pas

Glissez pour voir

sudo syswarden config-get network.whitelist_ips

La commande config-get lit une valeur par sa clé pointée, sans ouvrir d'éditeur. C'est la façon la plus sûre de vérifier un réglage depuis un script ou un playbook.

Que devient un pare-feu déjà en place ?

SysWarden ne reprend pas la main sur un frontal existant. Le défaut firewall_backend = 'keep' signifie exactement cela, et la mesure le confirme sur les deux familles.

Avec UFW actif sur Debian, puis syswarden reload :

Avant	Après
ip filter, ip6 filter	conservées, UFW reste active
(aucune table SysWarden)	syswarden_hw_drop, syswarden, syswarden_arp ajoutées

Glissez pour voir

Avec firewalld actif sur AlmaLinux, le résultat est identique : la table inet firewalld survit, les trois tables SysWarden s'ajoutent à côté. Le produit l'annonce dans son journal :

[INFO] Preserving the operator-managed firewall frontend without
       service-manager changes.

Ce qui rend cette cohabitation possible, c'est le cloisonnement par table de nftables : deux outils peuvent poser des règles sur le même hook sans se marcher dessus, chacun dans sa propre table. La question « qui possède le ruleset » a donc une réponse nuancée : chacun possède la sienne, et les décisions s'additionnent. Une adresse acceptée par SysWarden mais refusée par UFW reste refusée.

La conséquence pratique

Ne désactivez pas votre pare-feu existant avant d'installer SysWarden : ce n'est pas nécessaire, et vous perdriez vos règles. En revanche, sachez que deux jeux de règles cohabitent : quand un flux ne passe pas, regardez les deux, avec sudo nft list ruleset plutôt qu'avec le seul outil que vous avez l'habitude d'interroger.

Migrer une configuration v3 vers le format TOML

Le CLI embarque une commande dédiée. Elle lit /opt/syswarden/syswarden-auto.conf, écrit les six modules, puis renomme le fichier d'origine en .migrated avec ses permissions 0600.

sudo syswarden migrate-config

La sortie liste chaque fichier créé, et préserve 99-user.toml s'il existait déjà :

Created: /etc/syswarden/config/modules/00-core.toml
...
Preserved: /etc/syswarden/config/modules/99-user.toml
Configuration migrated successfully.

La conversion a été vérifiée avec une configuration v3 complète, et elle est fidèle sur tous les réglages qui avaient un équivalent.

Variable v3	Résultat en TOML
APPLY_CIS_L2_HARDENING="y"	cis_l2_hardening = true
SYSWARDEN_LAN_SUBNETS	lan_subnets préservé à l'identique
SYSWARDEN_ARP_PROTECT="y"	arp_protect = true
SYSWARDEN_GEO_CODES="ru,cn,kp,ir"	blocked_countries = ['ru', 'cn', 'kp', 'ir']
SYSWARDEN_HA_ENABLED="y"	[integrations.ha] enabled = true

Glissez pour voir

Relisez deux modules après la migration

La migration ne reprend que ce qui existait en v3. Les réglages apparus avec la v4 n'ont aucune source dans l'ancien fichier, et arrivent donc vides plutôt qu'à leur valeur par défaut. Deux cas mesurés : honeyports vaut [] au lieu de ['6379', '23'], et modsec_logs vaut '' au lieu de /var/log/modsec/*.log. Après toute migration, relisez 20-security.toml et 30-waap.toml et repositionnez ce que vous voulez activer.

Exploiter au quotidien

Le CLI expose une vingtaine de sous-commandes. Celles qui servent tous les jours tiennent en un tableau.

Commande	Usage
syswarden check <adresse>	Où en est une adresse : listes, noyau, dérogations
syswarden block <adresse>	Ajouter à la liste de blocage persistante
syswarden unblock <adresse>	Retirer de la liste de blocage
syswarden whitelist <adresse>	Ne jamais bloquer cette adresse
syswarden allow-ssh <adresse>	Dérogation SSH sans liste blanche globale
syswarden list	Tous les registres personnalisés
syswarden audit	Diagnostic local, phase par phase
syswarden alerts	Flux d'événements en direct
syswarden tui	Tableau de bord terminal
syswarden update-feeds	Rafraîchir les flux de renseignement

Glissez pour voir

La commande check est la plus utile en incident, parce qu'elle distingue le stockage du noyau :

sudo syswarden check 1.2.3.4

[Storage] Global Blocklist (v4) : PRESENT
[Kernel]  Active Nftables       : FOUND in active memory

Ces deux lignes répondent à deux questions différentes. La première dit que l'adresse est dans la liste persistante, donc qu'elle survivra à un redémarrage. La seconde dit qu'elle est effectivement dans le jeu de règles chargé. Un écart entre les deux signale une politique qui n'a pas été appliquée, et se corrige par syswarden reload.

Le diagnostic intégré, et ce qu'il ne prétend pas prouver

sudo syswarden audit

L'audit se déroule en sept phases, de l'orchestration cron à la posture de persistance. Son intérêt tient surtout à son honnêteté de formulation : chaque constat est marqué [OBSERVED] et non « conforme », et l'en-tête pose la limite.

[INFO] This diagnostic reports only the checks shown below; it is not a
       compliance certification or a complete kernel-state assessment.

Plusieurs lignes vont plus loin et disent ce qu'elles n'ont pas vérifié, par exemple SYSWARDEN UDS socket path exists; listener readiness was not exercised. C'est exactement ce qu'on attend d'un outil de diagnostic, et cela change la façon de le lire : l'audit ne remplace pas une vérification de bout en bout, il inventorie des points de contrôle.

Comment le moteur d'analyse lit-il les journaux ?

Le pont est un jeu de règles rsyslog imfile installé dans /etc/rsyslog.d/99-syswarden-waf-bridge.conf, qui suit sept chemins et les transmet à une socket Unix, /run/syswarden.sock, en 0660 root:root.

/var/log/nginx/*.log      /var/log/auth.log     /var/log/syslog
/var/log/apache2/*.log    /var/log/secure       /var/log/messages
/var/log/httpd/*.log

Le réglage de détection vit dans 30-waap.toml, et ses valeurs par défaut sont explicites : 5 échecs en 60 secondes, en mode enforcing.

[waap]
bruteforce_threshold = 5
bruteforce_window_seconds = 60
enforcement_mode = 'enforcing'

Le moteur lit effectivement ces journaux : chaque connexion SSH réussie produit une ligne de télémétrie visible dans syswarden alerts, de la forme [SYSWARDEN L7] [ALLOWED] 10.0.2.15 -> SERVICE: sshd.

Une [ALLOWED] ne prouve pourtant pas grand-chose sur la détection des échecs : elle vient d'un observateur distinct, celui des connexions réussies. Voir passer cette ligne ne garantit donc pas que le collecteur d'attaques a reçu, ni reconnu, une tentative ratée. C'est un piège de diagnostic que la section suivante mesure.

Journaux d'un WAF en coupure, et découverte automatique

Si vous alimentez SysWarden avec les journaux d'un WAF en coupure, renseignez waap.modsec_logs explicitement : la découverte automatique de la v4.04.3 peut proposer des chemins de la famille Red Hat sur une Debian, où ils n'existent pas. Le correctif est mergé sur main depuis le 21 septembre 2026, avec la prise en charge des journaux d'accès, d'erreur et d'audit ModSecurity de BunkerWeb, mais il n'est pas dans la release stable. Les chemins que vous déclarez vous-même restent soumis au contrôle de propriété et de permissions dans les deux cas.

Sur Debian 13, la détection SSH ne reconnaît pas les journaux

C'est le point à connaître avant de compter sur cette fonction, et il se mesure. En v4.04.3, la signature d'échec SSH attend un horodatage classique et le processus sshd. Or Debian 13 écrit dans /var/log/auth.log un horodatage ISO 8601 et, depuis qu'OpenSSH 9.8 a scindé son démon, le processus sshd-session :

2026-09-21T09:34:00.327193+00:00 sw-debian sshd-session[7676]: Failed password
for invalid user admin from 198.51.100.7 port 45088 ssh2

Les deux écarts se cumulent, et chacun suffit à empêcher toute détection. Le tableau croise les deux variables, avec une source routable distincte à chaque fois et huit tentatives pour un seuil de cinq :

Horodatage	Processus	Résultat
ISO	sshd-session	rien, c'est le cas de Debian 13
ISO	sshd	rien
classique	sshd-session	rien
classique	sshd	bannissement

Glissez pour voir

Quand la signature reconnaît, la chaîne complète se déroule : une observation SHADOW-ALERT, puis l'injection dans le pare-feu, puis action=BANNED. L'absence de SHADOW-ALERT dans vos journaux est donc le signe qu'aucune ligne n'a été reconnue, et non que l'observation manque.

Deux conséquences pratiques. Sur une distribution à journal ISO, gardez Fail2ban en place. Le correctif existe, réparti sur deux contributions, l'une pour le nom de processus et l'autre pour l'horodatage, et les deux sont nécessaires ; elles sont fusionnées sur main dans le candidat v4.10.0, donc absentes de la release stable. Tant que la publication n'a pas eu lieu, un paquet installé reste en v4.04.3. Et pour vérifier chez vous, cherchez SHADOW-ALERT dans le journal de syswarden-core plutôt qu'un bannissement : l'observation arrive en premier, et elle apparaît même sur une source que le produit refuse de bannir.

Une source privée ne prouvera rien

SysWarden refuse d'agir sur les adresses non routables ou à usage spécial, et le dit : protected firewall target: non-routable or special-use address. Retirer votre plage de lan_subnets ne lève pas cette garde. Un test lancé depuis votre réseau local ne conclut donc rien : déclenchez la détection depuis une adresse publique que vous maîtrisez.

Désactiver les mots de passe ne coupe pas la détection SSH

C'est l'idée reçue qui découle naturellement de ce qui précède, et elle est fausse. Sur la plupart des images cloud et après tout durcissement CIS, PasswordAuthentication no est déjà posé, souvent par le paquet OpenSSH lui-même. Une tentative par mot de passe ne produit alors jamais Failed password, et l'on en conclut volontiers que le moteur n'a plus rien à lire.

Il lui reste pourtant une ligne, et elle est écrite par défaut. Voici ce que sshd journalise quand on tente une connexion avec un compte inexistant, sur une Debian 13 dont l'authentification par mot de passe est refusée :

… sshd-session[6965]: Invalid user utilisateur-absent-1 from 127.0.0.1 port 53260
… sshd-session[6965]: Connection closed by invalid user utilisateur-absent-1 … [preauth]

La seconde ligne, une fermeture de connexion, ne compte effectivement pas comme un échec. Mais la première, Invalid user, est un motif de détection à part entière. Rejouée au format que la signature attend, elle produit la chaîne complète : SHADOW-ALERT, injection dans le pare-feu, puis action=BANNED. Au format réel de Debian 13, elle ne produit rien, exactement comme Failed password.

Ce n'est donc pas le mot de passe désactivé qui empêche la détection, c'est le format du journal. La distinction change la conduite à tenir : sur une distribution à journal classique, un hôte durci reste protégé contre le balayage de comptes ; sur une distribution à journal ISO, c'est la signature qu'il faut attendre, pas une configuration SSH à affaiblir. La documentation amont retient la même formulation.

Synchroniser deux nœuds

La haute disponibilité réplique la liste de blocage d'un nœud vers l'autre. En v4.04.3, elle repose sur une API HTTPS sur le port 62026, servie par syswarden-core uniquement quand la fonction est activée.

40-integrations.toml

[integrations.ha]
enabled = true
peer_ips = ['10.0.2.20']
peer_port = 62026
token = 'un-secret-partage-entre-les-deux-noeuds'

Après syswarden reload, le journal confirme l'ouverture, et le pair est automatiquement ajouté à la liste blanche :

[INFO] Configuring HA peer allowlist: [10.0.2.20] on port 62026
[INFO] Auto-whitelisting HA Peer IP: 10.0.2.20
[+] HA Cluster Sync ENABLED.

Activer la haute disponibilité ouvre un port

Une installation v4 n'ouvre aucun port, mais activer la synchronisation ouvre le 62026, et syswarden-core y écoute sur toutes les interfaces. Si la machine a une patte publique, restreignez-y l'accès au seul pair dans votre filtrage amont.

La synchronisation échoue tant que les certificats ne sont pas distribués

C'est l'étape que l'on ne devine pas. Chaque nœud génère un certificat auto-signé dans /var/lib/syswarden/ha/server.crt, d'émetteur O=SYSWARDEN HA Cluster, valable un an, avec un nom alternatif correct pour son adresse. Aucun des deux ne connaît celui de l'autre.

[ERROR] HA Peer 10.0.2.20 GET failed: tls: failed to verify certificate:
        x509: certificate signed by unknown authority

La parade tient en trois commandes, à jouer sur chaque nœud avec le certificat de l'autre. Le CLI accepte un magasin de confiance dédié, /etc/syswarden/ha-ca.pem : quand ce fichier existe et qu'il est valide, il fournit les racines de confiance de la HA à la place du magasin système.

# Sur le nœud A, récupérer le certificat du nœud B
ssh operateur@10.0.2.20 "sudo cat /var/lib/syswarden/ha/server.crt" \
  | sudo tee /etc/syswarden/ha-ca.pem > /dev/null

sudo chown root:root /etc/syswarden/ha-ca.pem
sudo chmod 0644 /etc/syswarden/ha-ca.pem

Préférez ce fichier au magasin système, et la raison n'est pas cosmétique. Passer par /usr/local/share/ca-certificates/ suivi d'update-ca-certificates fonctionne aussi, mais fait alors confiance à ce certificat auto-signé pour tous les clients TLS de la machine : curl, le gestionnaire de paquets, vos propres services. Le magasin dédié cantonne cette confiance à SysWarden. Mesuré le 2026-09-21 : après la procédure ci-dessus, /usr/local/share/ca-certificates/ reste vide et aucun certificat SYSWARDEN n'entre dans le bundle système.

Aucun redémarrage n'est nécessaire. Le CLI relit ce fichier à chaque appel, là où le magasin système n'est lu qu'au démarrage du processus. Mesuré en retirant puis en reposant le fichier : ha-sync échoue immédiatement sans lui, et aboutit aussitôt qu'il revient, sans toucher au service.

Le fichier doit être un fichier régulier, pas un lien symbolique, appartenir à root et n'être inscriptible ni par le groupe ni par les autres. Un bundle invalide échoue en refusant, il ne bascule pas discrètement sur le magasin système : HA CA bundle is invalid: bundle contains no certificate.

Une fois les deux nœuds en confiance mutuelle, la synchronisation aboutit.

sudo syswarden ha-sync

[INFO] Found 1 IPs missing on peer 10.0.2.20. Synchronizing...
[+] HA Peer 10.0.2.20 is synchronized.

Côté pair, l'adresse apparaît dans les deux couches, Global Blocklist (v4) : PRESENT et Active Nftables : FOUND in active memory.

Diagnostiquer un refus de synchronisation

Les refus sont explicites et se distinguent par leur code HTTP. Dans tous les cas, ha-sync rend un code de retour 1, ce qui permet de le surveiller depuis une tâche planifiée.

Symptôme	Cause	Correction
x509: certificate signed by unknown authority	Certificat du pair inconnu	Le poser dans /etc/syswarden/ha-ca.pem. Aucun redémarrage
HTTP status 401	Jeton différent entre les deux nœuds	Aligner token des deux côtés
HTTP status 400	Une des adresses du lot est non routable ou à usage spécial	Retirer cette entrée de la liste locale
HA CA bundle is invalid	/etc/syswarden/ha-ca.pem vide, illisible ou mal formé	Le reconstruire. Le CLI refuse, il ne retombe pas sur le magasin système

Glissez pour voir

Le dernier cas demande une précision utile au diagnostic. Le transfert est tout ou rien : une seule adresse invalide dans le lot fait échouer la synchronisation entière, et le message n'indique pas laquelle. Si une synchronisation qui fonctionnait se met à rendre 400, cherchez ce que vous avez bloqué depuis, en particulier une adresse privée ou une plage de documentation.

Vérifiez la version que vise la documentation technique

Le dépôt documente une HA v2 avec authentification mutuelle TLS, empreintes de certificat épinglées et rôles writer et standby. Le changelog la date de v4.10.0, la branche de développement : la release stable v4.04.3 ne l'embarque pas, et son module ne porte que enabled, peer_ips, peer_port et token. N'y recopiez donc ni v2_enabled, ni peer_cert_sha256, ni v2_secret_file.

Le projet a publié le 21 septembre 2026 un document qui tranche cette question page par page, Version-aware operator guidance : il porte un tableau des différences entre la stable v4.04.3 et le candidat v4.10.0, et chaque document technique du dépôt annonce désormais la version qu'il vise. À lire avant d'appliquer quoi que ce soit venant de main.

Ce que le durcissement modifie sur le système

Avec hardening_enabled = true et cis_l2_hardening = true, tous deux actifs par défaut, l'installation ne se limite pas au pare-feu. Elle applique une série de mesures inspirées du CIS Benchmark niveau 2, annoncées ligne par ligne dans le journal.

 -> Disabling obscure filesystems (CIS 1.1.1.1 - 1.1.1.8)
 -> Disabling uncommon network protocols (CIS 3.3.1 - 3.3.4)
 -> Applying strict kernel parameters (CIS 1.5, 3.2)
 -> Enforcing hard limits on core dumps (CIS 1.5.1)
 -> Applying CIS Level 2 SSH Hardening (CIS 5.2)
 -> Securing cron directories permissions (CIS 5.1)
 -> Locking down Crontab to root only
 -> Purging non-root users from privileged groups

La dernière ligne mérite votre attention avant d'installer : l'outil retire les comptes non-root des groupes privilégiés. C'est le principe du moindre privilège, et la conséquence est concrète, l'accès administrateur des autres comptes saute. Recensez-les avant, remettez-les après.

Un garde-fou est apparu en v4

La v4 préserve explicitement le compte qui lance l'installation, et le dit :

 [!] SAFEGUARD: Preserving current admin 'operateur' in 'wheel' group

C'est une correction bienvenue par rapport à la génération précédente, où la purge pouvait retirer l'opérateur lui-même. Le garde-fou ne couvre que le compte courant : les autres administrateurs de la machine sont toujours retirés, et doivent être remis ensuite.

Les paramètres noyau sont posés dans quatre fichiers, ce qui permet de les lire et de les auditer indépendamment de l'outil.

/etc/modprobe.d/syswarden-cis-fs.conf
/etc/modprobe.d/syswarden-cis-net.conf
/etc/sysctl.d/99-syswarden-cis-level2.conf
/etc/security/limits.d/99-syswarden-cis.conf

Mettre à jour

La commande update interroge l'API GitHub, compare les versions et, le cas échéant, installe une release vérifiée par un manifeste signé.

sudo syswarden update

[INFO] Checking for SYSWARDEN updates via GitHub API...
Current Version : v4.04.3
Latest Version  : v4.04.3
[SUCCESS] You are already using the latest version of SYSWARDEN!

La release publie les éléments qui rendent cette vérification possible : syswarden-update-manifest-v1.json, qui porte la taille et l'empreinte SHA-256 de chaque artefact ainsi qu'un identifiant de clé, sa signature détachée .sig, et un SBOM au format SPDX, syswarden-sbom.spdx.json.

Ne confondez pas ce que chacun prouve. Le manifeste signé authentifie les métadonnées des paquets, et lui seul. Le SBOM est un inventaire de dépendances, utile à une revue, mais il n'est pas authentifié par cette signature et ne constitue aucune promesse d'absence de vulnérabilité. Une vérification de manifeste réussie ne dit donc rien du SBOM.

Désinstaller

La désinstallation retire le produit, ses services, ses règles et ses fichiers de politique CIS.

sudo syswarden uninstall

Elle annonce clairement ce qu'elle ne touche pas, ce qui vaut mieux qu'un nettoyage silencieux et approximatif :

[WARN] Preserved ambiguous legacy hardening, rsyslog, shell-completion, legacy
       config, and root-crontab artifacts for manual recovery.
[SUCCESS] Verified SysWarden-owned host removal is complete.

Après son passage, /opt/syswarden, /etc/syswarden, /var/lib/syswarden et /var/log/syswarden ont disparu, ainsi que les deux unités systemd, les trois tables nftables, la tâche cron et les fichiers rsyslog. Deux gestes terminent le nettoyage.

1. Le paquet reste installé

   syswarden uninstall supprime les fichiers du produit, pas l'entrée du gestionnaire de paquets. Après la désinstallation, dpkg -l syswarden rend toujours ii syswarden 4.04.3. Terminez le travail :

   sudo apt-get remove --purge syswarden

2. Le noyau en cours n'est pas rétabli

   Les fichiers de politique sont retirés, mais les valeurs déjà appliquées restent en mémoire. Mesuré sur kernel.kptr_restrict : la valeur est 2 juste après la désinstallation, et revient à 0 seulement après redémarrage.

   sudo sysctl -n kernel.kptr_restrict   # 2 avant reboot, 0 après

   Si vous désinstallez pour lever un durcissement qui gêne, prévoyez le redémarrage : sans lui, la machine reste durcie sans plus rien pour l'expliquer.

Dépannage

Symptôme	Cause probable	Correction
sudo syswarden : command not found sur RHEL	secure_path exclut /usr/local/bin	Utiliser sudo /usr/local/bin/syswarden
systemctl status syswarden-firewall : could not be found	Seconde passe non jouée sur un RPM	sudo syswarden install
semodule: Failed! à l'installation	Politique SELinux absente de l'hôte	Installer selinux-policy-targeted
Aucun pays bloqué malgré le géoblocage actif	blocked_countries = [] en v4	Remplir la liste dans 99-user.toml
honeyports vide après migration	Réglage sans équivalent v3	Le repositionner à la main
x509: certificate signed by unknown authority	Certificat du pair non distribué	Le déposer dans /etc/syswarden/ha-ca.pem, sans redémarrage
ha-sync rend 400	Une adresse du lot est à usage spécial	La retirer de la liste locale
Rejecting log input: /var/log/secure sur Debian	Ce chemin appartient à la famille RHEL	Message d'information, aucune action nécessaire
Machine toujours durcie après désinstallation	Noyau non rétabli	Redémarrer

Glissez pour voir

Ce qui a changé depuis la v3

Si vous connaissiez la génération précédente, quatre changements demandent de désapprendre.

Sujet	v3	v4.04.3
Tableau de bord	Service web HTTPS sur le port 62027, jeton	Supprimé. TUI locale, aucun port ouvert
Configuration	/opt/syswarden/syswarden-auto.conf, variables	TOML modulaire sous /etc/syswarden/config/
Géoblocage	77 pays actifs par défaut	Mécanisme actif, liste vide
Plateformes	amd64, arm64, Debian à FreeBSD	amd64 uniquement, six distributions qualifiées

Glissez pour voir

La disparition du service web retire une surface d'attaque de la machine. Si vous migrez une installation v3, profitez-en pour vérifier qu'aucune règle de votre pare-feu amont n'ouvre encore le 62027 vers ce serveur.

À retenir

• SysWarden n'est pas un pare-feu applicatif en coupure. Il analyse des journaux hors bande et applique ses décisions dans nftables, par adresse et après coup.
• La version de référence de cette page est v4.04.3, publiée le 7 septembre 2026, amd64 uniquement.
• La configuration est en TOML modulaire sous /etc/syswarden/config/. Vos réglages vont dans 99-user.toml, qui prime sur tous les autres.
• Le géoblocage ne bloque rien par défaut en v4 : le mécanisme est actif, la liste de pays est vide.
• Un pare-feu existant est préservé. UFW et firewalld survivent, leurs tables cohabitent avec les trois tables SysWarden.
• Sur la famille RHEL, appelez sudo /usr/local/bin/syswarden : /usr/local/bin n'est pas dans le secure_path de sudo.
• La synchronisation entre nœuds exige de distribuer les certificats auto-signés, et échoue en bloc si une seule adresse du lot est à usage spécial. Posez-les dans /etc/syswarden/ha-ca.pem plutôt que dans le magasin système : la confiance reste cantonnée à SysWarden, et aucun redémarrage n'est nécessaire.
• Après syswarden uninstall, retirez le paquet et redémarrez : les fichiers partent, l'entrée du gestionnaire de paquets et les réglages noyau en cours restent.
• En v4.04.3, la détection SSH ne lit pas les journaux de Debian 13 : elle attend un horodatage classique et le processus sshd, là où Debian écrit de l'ISO et sshd-session. Cherchez SHADOW-ALERT pour vérifier chez vous.
• Ce n'est pas le mot de passe désactivé qui coupe la détection, c'est le format du journal. Invalid user est un motif reconnu à part entière, émis même quand PasswordAuthentication no empêche tout Failed password.
• sha256sum prouve l'intégrité, pas la provenance. Pour un téléchargement manuel, authentifiez le manifeste signé Ed25519 : un paquet substitué dont la somme a été réécrite passe le premier contrôle et échoue au second.

Prochaines étapes

nftables Comprendre les tables et les hooks qui permettent à deux pare-feu de cohabiter.

Fail2ban L'outil que SysWarden prétend remplacer, pour comparer les deux approches.

BunkerWeb Un vrai pare-feu applicatif en coupure, complémentaire et non concurrent.

CrowdSec Une autre approche de l'analyse de journaux, avec renseignement communautaire.

×

📖 Voir la documentation →