SysWarden : protéger rapidement un serveur Linux exposé

SysWarden réduit très vite l'exposition d'un serveur Linux connecté à Internet. La version 3 se présente comme un HIDS/HIPS doublé d'un WAAP (pare-feu applicatif orienté API), écrit intégralement en Go : il combine un pare-feu nftables, un moteur de détection L7 natif, des blocklists, du blocage ASN, du géoblocage, WireGuard pour masquer l'administration et une synchronisation haute disponibilité. Ce n'est ni un SIEM ni un IDS réseau complet, c'est un bouclier périmétrique qui filtre tôt le bruit d'Internet.

Une installation par paquet sur Debian 13 applique le pare-feu et charge environ 69 500 adresses en blocklist dès la commande apt-get install, sans attendre la moindre configuration. Ce comportement, mesuré en lab sur la version 3.76.8, change complètement la façon d'aborder le déploiement.

Ce que vous allez apprendre

Comprendre à quoi sert SysWarden v3 et ce qu'il ne fait pas
Installer SysWarden via son paquet .deb, .rpm ou .apk
Configurer les options clés avec syswarden config : whitelist, blocklists, ASN, géoblocage, WireGuard, HA
Gérer les IP au quotidien avec le CLI unifié
Vérifier le déploiement et choisir un profil adapté : VPS, bastion, hôte Docker

Dans quel contexte ?

Sur un serveur exposé, une grande partie du trafic reçu n'a aucune valeur :

Scans automatisés sur tous les ports, toutes les minutes
Tentatives de brute force SSH par centaines chaque heure
Bots opportunistes qui cherchent des failles connues
Trafic issu d'infrastructures déjà connues pour des activités hostiles

SysWarden cherche à bloquer ce trafic avant qu'il n'atteigne vos services. L'intérêt est simple : moins de bruit dans les logs, moins de surface d'exposition, une mise en place plus rapide qu'un empilement manuel de scripts.

Ce que fait SysWarden v3

SysWarden (licence GPL-3.0) se décrit comme un système de détection et de prévention d'intrusion hôte (HIDS/HIPS). Il s'articule autour de trois binaires Go déposés dans /opt/syswarden/bin/ :

Composant	Rôle
`syswarden-cli`	Orchestration : installation, configuration, gestion des IP, audit, serveur Web-TUI
`syswarden-core`	Moteur WAAP L7 (algorithme Aho-Corasick), tourne en daemon systemd
`syswarden-tui`	Tableau de bord terminal temps réel

Le CLI est accessible par le lien symbolique /usr/local/bin/syswarden, posé par le paquet. Sur la VM de test, le daemon syswarden-core occupe 12,7 Mo de mémoire résidente au repos, ce qui reste négligeable sur un VPS d'entrée de gamme.

Il agrège plusieurs mécanismes :

Mécanisme	Rôle
Pare-feu nftables	Filtrage kernel, backend détecté automatiquement
Moteur WAAP natif	Détection L7 et brute force en Go, remplace Fail2ban
Blocklists	Dizaines de milliers d'IP malveillantes injectées dans le kernel
Blocage GeoIP	Filtrage par pays, activé par défaut, liste paramétrable
Blocage ASN	Listes d'AS à risque, Spamhaus ASN-DROP en option
Protection L2	Limitation du débit de requêtes ARP contre le spoofing
WireGuard	Tunnel VPN pour isoler l'administration
Haute disponibilité	Synchronisation chiffrée de la blocklist entre nœuds
Durcissement CIS	Hardening kernel/OS niveau CIS Benchmark L2
Web-TUI	Tableau de bord HTTPS protégé par jeton, actif par défaut

Le backend pare-feu est choisi selon la distribution. Le tableau ci-dessous reprend les plateformes que le projet déclare prendre en charge :

Plateforme	Backend pare-feu
Debian 12 / 13	nftables, iptables
Ubuntu 24.04+	ufw, nftables, iptables
RHEL 9+, Rocky, AlmaLinux 9+	firewalld, nftables, iptables
Oracle Linux 10+, Fedora 40+	firewalld, nftables, iptables
Alpine Linux 3.21+	nftables
FreeBSD 14+	pf

Quand l'utiliser

SysWarden est surtout pertinent pour :

un VPS public qui reçoit du trafic non sollicité en permanence
un bastion dont l'accès doit être restreint au maximum
un petit serveur web que vous ne pouvez pas mettre derrière un WAF cloud
un hôte Docker exposé, où l'outil ajoute une chaîne docker_protect sur le hook forward
un cluster de deux nœuds où il faut synchroniser les bannissements

Quand ne pas en attendre trop

SysWarden ne remplace pas :

une supervision centralisée (Wazuh, Grafana, Prometheus)
un moteur de détection comportementale avancée multi-sources
une stratégie IAM solide
la gestion des vulnérabilités et des correctifs
la sécurisation applicative (authentification, injection, chiffrement)

Il faut le voir comme une première couche réseau et L7, pas comme une réponse complète à tous les risques.

Prérequis

Un serveur Debian 12 ou 13, Ubuntu 24.04+, RHEL/AlmaLinux/Rocky 9+, Alpine 3.21+ ou FreeBSD 14+
Accès root (ou sudo)
La commande wget (ou curl) pour récupérer le paquet
Connaître l'IP publique autorisée à administrer le serveur
Prévoir une fenêtre de test pour éviter de se bloquer soi-même

Le paquet Debian tire les dépendances nftables, ipset, curl, wget, rsyslog, cron et bash-completion. Sur une image minimale, comptez une trentaine de paquets supplémentaires installés par apt.

Installer SysWarden

SysWarden est exclusivement distribué par paquets, nommés par version et architecture :

Plateforme	Nom du paquet
Debian / Ubuntu	`syswarden_<version>_amd64.deb`, `syswarden_<version>_arm64.deb`
RHEL / AlmaLinux / Rocky	`syswarden-<version>-1.x86_64.rpm`, `syswarden-<version>-1.aarch64.rpm`
Alpine	`syswarden_<version>_x86_64.apk`, `syswarden_<version>_aarch64.apk`
FreeBSD	`syswarden-<version>.txz`

Récupérer la dernière version publiée

VERSION=$(curl -s https://api.github.com/repos/duggytuxy/syswarden/releases/latest \
  | grep '"tag_name":' | cut -d '"' -f 4)
V_NUM=${VERSION#v}
echo "Version : ${V_NUM}"

Version : 3.76.8

Télécharger le paquet et sa somme de contrôle

wget "https://github.com/duggytuxy/syswarden/releases/download/${VERSION}/syswarden_${V_NUM}_amd64.deb"
wget "https://github.com/duggytuxy/syswarden/releases/download/${VERSION}/SHA256SUMS.txt"

Vérifier l'intégrité
Fenêtre de terminal
```
sha256sum -c SHA256SUMS.txt --ignore-missing
```
```
syswarden_3.76.8_amd64.deb: OK
```
La ligne doit porter le nom du paquet téléchargé, suivi de OK. N'installez jamais un paquet dont la somme ne correspond pas.
Installer le paquet
Fenêtre de terminal
sudo apt-get install -y "./syswarden_${V_NUM}_amd64.deb"
Fenêtre de terminal
sudo dnf install -y "./syswarden-${V_NUM}-1.x86_64.rpm"
Fenêtre de terminal
sudo apk add --allow-untrusted "./syswarden_${V_NUM}_x86_64.apk"
Adapter la configuration

Le script post-installation a déjà appliqué une politique par défaut (voir la section suivante). Ouvrez maintenant l'éditeur pour la personnaliser :
Fenêtre de terminal
```
sudo syswarden config
```
```
[*] Opening configuration with /usr/bin/nano...
[*] Validating configuration...
[SUCCESS] Configuration is valid.
[INFO] To apply the new configuration, please run: sudo syswarden install
```
Renseignez au minimum votre IP d'administration dans SYSWARDEN_WHITELIST_IPS et relisez SYSWARDEN_GEO_CODES.
Appliquer réellement les politiques
Fenêtre de terminal
```
sudo syswarden install
```
Cette seconde exécution est obligatoire : c'est elle qui applique le géoblocage, le blocage ASN et le durcissement, sautés au premier passage.

Pourquoi une seconde passe est indispensable

Le script post-installation du paquet lance lui-même syswarden-cli install. Autrement dit, le pare-feu est déjà actif à la fin de apt-get install, avant toute configuration de votre part. Le journal d'installation le montre sans ambiguïté :

Setting up syswarden (3.76.8) ...
[SYSWARDEN] Starting v3.76.8 Installation Pipeline...
[INFO] Selected Mirror: https://codeberg.org/
Downloading Threat Intel IPv4 Blocklist... OK
[INFO] Applying Firewall Rules (nftables atomic transaction)...
[INFO] Nftables applied successfully.
[SYSWARDEN] Starting OS & CIS Hardening...
[SYSWARDEN] v3.76.8 Native Installation Complete.

Ce premier passage a une limite décisive : le fichier de configuration n'existe pas encore quand le pipeline démarre, il est écrit pendant l'exécution. Le moteur travaille donc avec des valeurs vides, et trois modules sont silencieusement ignorés : le géoblocage, le blocage ASN et le durcissement OS/CIS. La ligne Starting OS & CIS Hardening... s'affiche sans qu'aucune règle ne suive.

La seconde exécution, elle, lit le fichier et fait le travail complet. Les flux GeoIP et ASN sont téléchargés pays par pays, puis le durcissement s'applique :

[SYSWARDEN] Starting OS & CIS Hardening...
[INFO] Applying CIS Level 2 System Hardening...
 -> 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)
 -> Applying CIS Level 2 SSH Hardening (CIS 5.2)
 -> Configuring automatic security updates (Zero-Day defense)

Retenez la règle : installer le paquet ne suffit pas, et lancer syswarden config sans relancer syswarden install ne sert à rien. Le CLI vous le rappelle d'ailleurs à chaque sortie de l'éditeur.

Vérifier l'installation

SysWarden crée trois tables nftables, pas une seule :

sudo nft list tables

table netdev syswarden_hw_drop
table inet syswarden
table arp syswarden_arp

La table inet syswarden porte le filtrage L3/L4, netdev syswarden_hw_drop réalise un rejet au plus près de la carte réseau, et arp syswarden_arp couvre la protection de niveau 2. Vérifiez ensuite les trois services déployés :

systemctl list-units --type=service | grep syswarden

syswarden-core.service      loaded active running SYSWARDEN WAF and Core Engine
syswarden-firewall.service  loaded active exited  SYSWARDEN Firewall Persistence & Engine Loader
syswarden-webtui.service    loaded active running SYSWARDEN Web-TUI (WebTTY)

Le service syswarden-firewall est de type oneshot : l'état exited est normal, il recharge simplement les règles au démarrage. Si les trois tables et les trois services sont présents, le déploiement est fonctionnel.

Pour contrôler le volume réellement chargé dans le kernel, comptez les entrées des sets :

sudo nft list set inet syswarden syswarden_blacklist | grep -c ','

Sur la VM de test après la seconde passe : environ 69 500 adresses en blocklist, 28 800 en GeoIP et 8 100 en ASN.

Configurer SysWarden

La configuration vit dans /opt/syswarden/syswarden-auto.conf, en permissions 0600 réservées à root. Deux manières de l'éditer :

Interactive : sudo syswarden config ouvre votre $EDITOR, valide la syntaxe en sortie, puis rappelle de lancer syswarden install.
Non interactive (CI/CD, Ansible, cloud-init) : éditer directement le fichier, puis sudo syswarden install.

Paramètres importants

Paramètre	Description
`SYSWARDEN_WHITELIST_IPS`	IP à ne jamais bloquer, le plus important
`SYSWARDEN_WHITELIST_INFRA`	Auto-whitelist passerelle, DNS, métadonnées cloud, `y` par défaut
`SYSWARDEN_LAN_SUBNETS`	Sous-réseaux internes de confiance, RFC1918 par défaut
`SYSWARDEN_SSH_PORT`	Port SSH, détecté automatiquement si vide
`SYSWARDEN_FIREWALL_BACKEND`	`nftables`, `iptables` ou `keep` (ne pas toucher Firewalld)
`SYSWARDEN_LIST_CHOICE`	Blocklist : `1` Standard, `2` Critical, `3` Custom, `4` aucune
`SYSWARDEN_ENABLE_GEO` / `SYSWARDEN_GEO_CODES`	Blocage par pays et liste des codes
`SYSWARDEN_GEO_ALLOWED`	Mode zero-trust : si rempli, tout le reste du monde est rejeté
`SYSWARDEN_ENABLE_ASN` / `SYSWARDEN_ASN_LIST`	Blocage par numéro d'AS
`SYSWARDEN_ALLOW_SAAS_MONITORS`	Laisse passer les sondes de supervision externes, `y` par défaut
`SYSWARDEN_HARDENING`	Durcissement OS : cron, groupes privilégiés, journaux
`APPLY_CIS_L2_HARDENING`	Durcissement CIS Benchmark L2 du noyau, paramètre distinct
`SYSWARDEN_ENABLE_L2` / `SYSWARDEN_ARP_PROTECT`	Protection ARP de niveau 2
`SYSWARDEN_ENABLE_WG`	Activer WireGuard pour masquer SSH, `n` par défaut
`SYSWARDEN_HA_ENABLED` / `SYSWARDEN_HA_PEER_IP`	Haute disponibilité, activée par défaut mais sans pair
`SYSWARDEN_SIEM_ENABLED` / `SYSWARDEN_SIEM_IP`	Export des événements vers un SIEM (syslog TLS)
`SYSWARDEN_ENABLE_WEBHOOK`	Notifications Discord, Teams ou Slack
`SYSWARDEN_SECURE_WIPE_CONF`	Efface le fichier de configuration après installation
`SYSWARDEN_ENTERPRISE_MODE`	`y` désactive toute télémétrie tierce (conformité interne)

Deux pièges méritent d'être signalés. D'abord, SYSWARDEN_HARDENING et APPLY_CIS_L2_HARDENING sont deux paramètres différents, tous deux à y par défaut : le premier touche au système (cron, groupes, journaux), le second au noyau et à SSH. Ensuite, SYSWARDEN_HA_ENABLED vaut y d'origine alors qu'aucun pair n'est configuré, ce qui produit un avertissement à chaque rechargement.

Ce que le durcissement modifie sur le système

Avec SYSWARDEN_HARDENING="y", l'outil ne se contente pas de poser des règles de pare-feu : il retire les comptes non-root des groupes sudo, wheel et adm, réserve cron à root via /etc/cron.allow, et rend immuables les profils shell des autres utilisateurs. C'est cohérent avec l'objectif « moindre privilège » d'un CIS Benchmark, mais il faut le savoir avant de l'activer. Sur la VM de test, le journal est explicite :

[INFO] Applying strict OS hardening (Crontab, Sudo/Wheel, Profiles)...
 -> Locking down Crontab to root only
 -> Purging non-root users from privileged groups
 [-] Removed user 'student' from 'sudo' group
 [!] SAFEGUARD: Preserving current admin 'ansible' in 'sudo' group

Le garde-fou préserve le compte qui lance la commande, lu depuis SUDO_USER. Les autres administrateurs de la machine perdent en revanche leurs privilèges, et la désinstallation ne les rétablit pas. Sur un serveur partagé entre plusieurs équipes, ou géré par un compte de service Ansible distinct de vos comptes humains, cela peut couper l'accès à des personnes légitimes. La précaution est simple : inventoriez les membres de sudo avant d'activer le durcissement, ou laissez SYSWARDEN_HARDENING="n" sur ces machines et durcissez le système par ailleurs.

Le Web-TUI est exposé par défaut

La v3 démarre un service syswarden-webtui qui écoute en HTTPS sur le port 62027, sur toutes les interfaces, et affiche son URL d'accès en fin d'installation :

[+] Web-TUI Client Access URL: https://10.10.40.14:62027/?token=ed7da8e1d86d0e79f34e69aa916b19f0

Cette console reprend, dans le navigateur, le tableau de bord du terminal : posture système, compteurs de blocage L3, vecteurs de risque L7 et registre des IP autorisées ou bannies.

Tableau de bord Web-TUI de SysWarden 3.76.8 sur Debian 13

Le jeton est stocké en clair dans SYSWARDEN_WEB_TOKEN au sein du fichier de configuration et transmis en paramètre d'URL, donc susceptible de finir dans un historique de navigateur ou un journal de proxy. Sans jeton, le serveur répond 403. C'est une console d'administration accessible depuis le réseau si rien ne la filtre : pensez à la restreindre à votre IP d'administration ou à la placer derrière le tunnel WireGuard.

# Faire tourner le jeton
sudo syswarden web-token --rotate

Si vous n'en avez pas l'usage, coupez le service et gardez le tableau de bord en mode terminal, qui offre les mêmes informations sans ouvrir de port.

sudo systemctl disable --now syswarden-webtui.service

Gérer les IP au quotidien

Tout passe par le CLI syswarden, qui agit sur les trois couches : fichiers de persistance, sets kernel et moteur WAAP. Chaque commande de blocage déclenche une transaction nftables atomique, visible dans la sortie.

Diagnostiquer une IP

sudo syswarden check 1.0.164.165

=== SYSWARDEN Global Search: 1.0.164.165 ===
[Storage] Global Whitelist (v4) : Not Found
[Storage] SSH Bypass            : Not Found
[Storage] Global Blocklist (v4) : Not Found
[Kernel]  Active Nftables       : FOUND in active memory

La distinction est utile : Storage indique vos décisions manuelles, Kernel dit si l'adresse est effectivement bloquée, y compris par une blocklist externe. Dans l'exemple, l'IP n'a jamais été bannie à la main mais figure bien dans un flux de threat intelligence.

Bloquer, débloquer, whitelister

Les commandes acceptent plusieurs IP à la fois :

# Bloquer une ou plusieurs IP (kernel + persistance)
sudo syswarden block 203.0.113.66 203.0.113.67

# Débloquer
sudo syswarden unblock 203.0.113.66

# Whitelister (bypass global, port optionnel)
sudo syswarden whitelist 10.0.0.42

# Lister les IP gérées manuellement
sudo syswarden list

La sortie de list sépare whitelist IPv4 et IPv6, exemptions SSH et blocages manuels. Elle inclut les adresses ajoutées automatiquement à l'installation, ce qui permet de contrôler d'un coup d'œil que votre passerelle et vos DNS sont bien protégés.

Commandes disponibles

Commande	Action
`check <IP>`	Diagnostic complet (persistance + kernel)
`block <IP>...`	Blocage kernel + fichier persistant
`unblock <IP>...`	Suppression de toutes les couches
`whitelist <IP>... [PORT]`	Bypass global (accès VIP)
`unwhitelist <IP>...`	Révoque le bypass global
`allow-ssh <IP> [PORT]`	Exemption SSH (contourne WireGuard)
`revoke-ssh <IP>`	Révoque l'exemption SSH
`whitelist-infra`	Auto-détecte et whiteliste les IP d'infrastructure
`list`	Affiche toutes les IP gérées
`reload`	Resynchronisation complète sans coupure
`audit`	Audit de posture en sept phases
`manual`	Manuel administrateur embarqué
`tui` / `alerts`	Tableau de bord et flux d'alertes
`web-tui` / `web-token`	Console HTTPS et gestion de son jeton

Le moteur WAAP et la détection brute force

C'est syswarden-core qui détecte les comportements hostiles, sans Fail2ban. Il lit les journaux des services et applique l'algorithme Aho-Corasick pour la mitigation L7 en temps réel : injections SQL, XSS, inclusion de fichiers, exécution de code, plus le suivi des codes HTTP 401, 403 et 404 en rafale. Le seuil de brute force se règle dans la configuration :

Paramètre	Description
`SYSWARDEN_BRUTEFORCE_LOGS`	Journaux à surveiller, `auto` pour la découverte automatique
`SYSWARDEN_BRUTEFORCE_THRESHOLD`	Nombre d'échecs avant bannissement (défaut `5`)
`SYSWARDEN_BRUTEFORCE_WINDOW`	Fenêtre d'observation en secondes (défaut `60`)
`SYSWARDEN_MODSEC_LOGS`	Logs ModSecurity à corréler, utile en multi-tenant

La valeur auto déclenche la découverte des journaux Nginx, Apache, Caddy et Traefik. Une chaîne vide désactive complètement le moteur L7, ce qui peut se justifier sur un serveur sans service web.

Visualiser en temps réel : TUI et alertes

SysWarden embarque un tableau de bord terminal et un flux d'alertes. Les deux détectent l'absence de terminal interactif et basculent alors en mode texte, ce qui les rend utilisables dans un script ou une session non interactive.

sudo syswarden tui

=== SYSWARDEN ENTERPRISE DASHBOARD (SNAPSHOT) ===
[SYSTEM] NODE: srv-web-01 | Uptime: 66h34m31s | Load: 0.28 0.16 0.07
[L3 FIREWALL] Global Blocks: 91069 (GeoIP: 129245 | ASN: 27653)
[WAAP L7] Active Bans: 1

Pour suivre uniquement les alertes en flux continu :

sudo syswarden alerts

[2026-07-29 09:16:42] [SYSWARDEN L7] [ALLOWED] 10.10.40.1 -> SERVICE: sshd | ansible

Chaque connexion acceptée ou rejetée apparaît avec son service et son compte. C'est le moyen le plus rapide de vérifier qu'une règle produit l'effet attendu, sans fouiller les journaux système.

Dans un vrai terminal, le tableau de bord devient interactif : depuis le registre des IP, la touche b bannit l'adresse sélectionnée en L7 puis en L3, et la touche u lève le bannissement sur les deux couches. C'est plus rapide que d'enchaîner syswarden block et syswarden unblock quand vous triez une série d'adresses en direct.

Haute disponibilité

Sur un cluster de deux nœuds, SysWarden synchronise la blocklist par une API TLS point à point sur le port 62026. Le module est activé d'origine, mais tant que SYSWARDEN_HA_PEER_IP reste vide, la synchronisation échoue proprement :

sudo syswarden ha-sync

[ERROR] HA Sync failed: HA Cluster enabled but no Peer IPs configured

Renseignez l'adresse du second nœud, relancez syswarden install, puis forcez une synchronisation. L'IP du pair est automatiquement whitelistée pour que le canal TLS reste joignable. Si vous n'exploitez qu'un seul serveur, passez SYSWARDEN_HA_ENABLED à n pour supprimer l'avertissement à chaque rechargement.

Vérifier le déploiement avec syswarden audit

L'audit intégré contrôle la posture de la machine en sept phases et signale ce qui manque. Il ne modifie rien, vous pouvez le lancer à tout moment.

sudo syswarden audit

Phase	Ce qui est contrôlé
1. Cron Orchestration	La tâche planifiée de rafraîchissement des flux existe
2. Log Routing	Permissions des journaux, rsyslog actif, pont vers la socket
3. Kernel Shield	Blocklist peuplée, GeoIP et ASN déployés, accélération L2
4. Layer 7 Active Defense	Daemon WAAP en marche, découverte des journaux, télémétrie
5. Telemetry & Dashboard	Génération des données du tableau de bord
6. Zero Trust Remote Access	État de WireGuard et du masquage SSH
7. CSPM / Persistence	Persistance des règles nftables après redémarrage

Sur une installation neuve en 3.76.8, les sept phases passent au vert. Le dernier contrôle du bouclier confirme la persistance des règles nftables :

[PASS] /var/lib/syswarden/ui/data.json permissions VERIFIED (0600).
[✔] SYSWARDEN Audit Sequence Completed.

Mettre à jour

# Comparer la version installée à la version publiée
sudo syswarden update

# Rafraîchir uniquement les flux de Threat Intelligence
sudo syswarden update-feeds

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

Le rafraîchissement des blocklists est en outre planifié par une entrée dans la crontab de root, à une minute tirée au hasard pour étaler la charge sur les miroirs :

sudo crontab -l | grep syswarden

8 * * * * /opt/syswarden/bin/syswarden-cli update-feeds >/dev/null 2>&1

Compte tenu du rythme de publication du projet, ne branchez pas syswarden update sur une tâche automatique : vous installeriez plusieurs versions par semaine sans les avoir relues.

Ce que je configure sur mes serveurs

Voici les profils que je recommande selon le cas d'usage. Dans les trois cas, la configuration s'édite puis s'applique avec sudo syswarden install.

Profil VPS public (premier déploiement)

Le but : réduire le bruit sans prendre de risques.

SYSWARDEN_WHITELIST_IPS="<votre-IP>"
SYSWARDEN_WHITELIST_INFRA="y"
SYSWARDEN_LIST_CHOICE="1"          # Standard
SYSWARDEN_ENABLE_ASN="y"
SYSWARDEN_ENABLE_GEO="n"           # désactivé au départ, audience large
SYSWARDEN_ENABLE_WG="y"            # WireGuard si possible
SYSWARDEN_HARDENING="n"            # à activer après inventaire des comptes sudo

Je désactive le géoblocage le temps d'observer le trafic réel, et je laisse le durcissement de côté tant que je n'ai pas vérifié qui utilise sudo sur la machine. Après syswarden install, je lance syswarden audit puis j'observe syswarden alerts pendant quelques jours avant de durcir.

Profil bastion (accès restreint)

Le but : exposer le strict minimum.

SYSWARDEN_WHITELIST_IPS="<IP-admin>"
SYSWARDEN_LIST_CHOICE="1"
SYSWARDEN_ENABLE_ASN="y"
SYSWARDEN_ENABLE_GEO="y"
SYSWARDEN_GEO_ALLOWED="fr"         # zero-trust : tout le reste est rejeté
SYSWARDEN_ENABLE_WG="y"
SYSWARDEN_SSH_PORT="<port-non-standard>"
SYSWARDEN_HARDENING="y"

Sur un bastion, la liste d'autorisation vaut mieux que la liste de blocage : SYSWARDEN_GEO_ALLOWED inverse la logique et rejette tout ce qui ne vient pas des pays cités. SSH n'est pas exposé publiquement, tout passe par WireGuard, et le durcissement CIS est en place puisque la machine n'a qu'un seul administrateur.

Profil cluster (haute disponibilité)

SYSWARDEN_WHITELIST_IPS="<IP-admin>"
SYSWARDEN_HA_ENABLED="y"
SYSWARDEN_HA_PEER_IP="<IP-du-second-noeud>"
SYSWARDEN_HA_PEER_PORT="62026"

Chaque bannissement décidé sur un nœud est propagé à l'autre, ce qui évite qu'une IP bloquée d'un côté reste joignable de l'autre. Pensez à autoriser le port 62026 entre les deux machines.

Fichiers importants

Chemin	Rôle
`/opt/syswarden/bin/`	Binaires Go (CLI, core, TUI)
`/opt/syswarden/syswarden-auto.conf`	Configuration principale, permissions `0600`
`/opt/syswarden/signatures.json`	Base de signatures du moteur WAAP
`/etc/syswarden/lists/`	Whitelists et blocklists persistées
`/etc/systemd/system/syswarden-*.service`	Les trois unités systemd

Désinstallation

sudo syswarden uninstall

[WARN] Starting Deep Clean Uninstallation (Scorched Earth)...
 -> Cleaning Firewall Rules (nftables & iptables)...
 -> Reverting CIS Hardening...
[SUCCESS] Uninstallation complete. A reboot is recommended.

En 3.76.8, la désinstallation est bien plus complète que dans les versions précédentes. Elle retire les règles nftables, les trois services (y compris syswarden-webtui, qui libère le port 62027), la tâche cron, les fichiers /etc/sysctl.d/99-syswarden-cis-level2.conf et /etc/modprobe.d/syswarden-cis-*.conf, supprime /etc/cron.allow et déverrouille les profils utilisateurs (chattr -i). Sur la VM de test, ni le port 62027 ni un processus résiduel ne subsistent après la commande.

Deux effets du durcissement ne sont pas annulés, par prudence, et se corrigent à la main si besoin :

Les comptes retirés des groupes sudo, wheel et adm n'y sont pas remis automatiquement.
Le fichier sshd_config garde son durcissement : AllowTcpForwarding no, MaxAuthTries 4 et ClientAliveInterval 300 restent actifs.

# Rendre sudo à un compte administrateur qui l'avait perdu
sudo usermod -aG sudo <compte-retire>

# Puis retirer le paquet
sudo apt-get purge -y syswarden

Dépannage

Symptôme	Cause probable	Solution
Impossible de se connecter en SSH	Votre IP n'est pas whitelistée	Console KVM/IPMI puis `syswarden whitelist <IP>`
Le géoblocage ne s'applique pas	Seul le passage post-installation a tourné	Relancer `sudo syswarden install` après `syswarden config`
Le moteur ne démarre pas	`syswarden-core.service` en échec	`systemctl status syswarden-core` puis `journalctl -u syswarden-core`
`nft list tables` ne montre pas `syswarden`	Pipeline interrompu	Relancer `sudo syswarden install` et lire la sortie
Un administrateur a perdu `sudo`	Purge des groupes privilégiés par le durcissement	`sudo usermod -aG sudo <compte>`
Vrais visiteurs bloqués	Liste de pays par défaut trop large	Ajuster `SYSWARDEN_GEO_CODES` ou passer `SYSWARDEN_ENABLE_GEO` à `n`
`HA Cluster enabled but no Peer IP`	HA active sans second nœud	Renseigner `SYSWARDEN_HA_PEER_IP` ou désactiver `SYSWARDEN_HA_ENABLED`
Web-TUI accessible depuis le réseau	Service actif sur `62027` toutes interfaces	Restreindre à l'IP d'admin ou `systemctl disable --now syswarden-webtui.service`

À retenir

SysWarden v3 est un HIPS/WAAP écrit en Go : il filtre tôt, il ne protège pas tout
Il orchestre nftables, un moteur L7 natif (qui remplace Fail2ban), blocklists, ASN, GeoIP, WireGuard et la haute disponibilité
L'installation du paquet applique déjà une politique : la machine est filtrée dès apt-get install
Une seconde exécution de syswarden install après syswarden config est obligatoire pour le géoblocage, l'ASN et le durcissement
Le durcissement retire les comptes non-root des groupes privilégiés : inventoriez sudo avant de l'activer
Le Web-TUI écoute en HTTPS sur le port 62027 sur toutes les interfaces : filtrez-le ou coupez-le
SysWarden publie souvent : conservez le paquet installé pour pouvoir réinstaller la même version

Prochaines étapes

CrowdSec : IDS collaboratif Combinez SysWarden avec CrowdSec pour une détection enrichie par la threat intelligence communautaire.

Firewalld : pare-feu dynamique Comprendre les zones et les règles du pare-feu natif des distributions RHEL.

UFW : pare-feu simplifié Le frontend iptables pour Debian/Ubuntu : idéal pour les serveurs simples.

BunkerWeb : WAF applicatif Un pare-feu applicatif complet pour protéger vos services web exposés.