Avant de détecter quoi que ce soit, il te faut un endroit où installer ton SIEM. Une machine. Pas n’importe laquelle, pas configurée n’importe comment.

Dans l’épisode d’ouverture, on a posé le pourquoi. RGPD t’oblige déjà à détecter une violation et à la notifier en 72 heures, NIS2 a élargi le filet, et ce n’est pas fini. Le SaaS américain fait le boulot mais livre tes journaux les plus sensibles, sur simple demande administrative du gouvernement US. Tout cela est extrêmement défavorable à tes intérêts, tu en conviendras.

Alors comment résoudre ce dilemme ? La conclusion est simple, tu montes ton propre SIEM, conforme RGPD et NIS2, sur une infrastructure que tu contrôles totalement.

Cet article-là, c’est la première brique. Le socle.

Tout le reste de la série va s’empiler dessus. Wazuh à l’épisode 2, les agents à l’épisode 3, la défense réseau, le filtre mail, le contrôle d’exécution. Si le socle est bancal, toute la pile est bancale. Un SIEM qui surveille ton parc mais qui tourne sur une machine elle-même percée, c’est une caméra de surveillance branchée sur une porte grande ouverte.

Cette stack que je te recommande, je l’utilise au quotidien. Je vais te montrer comment monter ton socle, dans l’ordre, avec les commandes réelles. Tu peux le reproduire aujourd’hui.

Choisir l’hébergeur, la juridiction avant le reste

Première décision, et c’est la plus structurante. Où va vivre ta machine.

La tentation, c’est d’aller au moins cher ou au plus connu. AWS, Google Cloud, Azure. Ils sont excellents techniquement. Et ils sont tous de nationalité américaine, donc soumis au CLOUD Act, cette magnifique loi de 2018 qui permet aux autorités US de réquisitionner les données d’un fournisseur américain, où qu’elles soient stockées dans le monde, datacenter européen compris.

Mettre les journaux de sécurité de ton SI là-dedans, c’est exactement le problème qu’on essaie de résoudre depuis le départ. Pour être raccord, ce qu’on cherche, c’est donc un hébergeur dont le siège, les serveurs et le capital échappent à cette exception US.

Trois critères à vraiment considérer, je te les donne.

• La juridiction du siège social. Une entreprise européenne sans société mère américaine n’est pas soumise au CLOUD Act. Suisse, Allemagne, France, etc. La nuance, c’est la filiale, un hébergeur européen qui a ouvert une entité aux États-Unis expose au CLOUD Act les ressources hébergées dans cette filiale. Le siège ne suffit pas, il faut regarder où vivent physiquement tes données.

• La localisation des datacenters. Tes logs doivent rester sur des serveurs européens, point. Pas de réplication transatlantique « pour ta disponibilité ».

• Le prix, en dernier. Un VPS pour démarrer un SIEM PME coûte entre 5 et 25 euros par mois. À ce niveau, l’écart de prix entre les opérateurs souverains est marginal. Tu ne choisis pas ton hébergeur de sécurité au centime près.

Concrètement, deux noms reviennent quand on croise ces critères.

Infomaniak, hébergeur suisse basé à Genève, détenu à 100 % par ses fondateurs et ses salariés, sans fonds d’investissement extérieur. Serveurs exclusivement en Suisse, sous nLPD, la loi fédérale suisse de protection des données entrée en vigueur en septembre 2023, alignée sur le RGPD et reconnue par décision d’adéquation européenne.

Pas de filiale américaine, hors CLOUD Act par construction, hors 5eyes, donc sans coopération étendue avec les renseignements US. En Suisse toutes les demandes de communication doivent passer par la Justice, une des juridictions les plus protectrices au monde.

Leurs datacenters sont certifiés ISO 27001 et ISO 50001. C’est l’opérateur que j’utilise, sur leur gamme VPS Cloud, mais l’entrée de gamme VPS Lite peut largement suffire pour démarrer.

Hetzner, hébergeur allemand familial fondé en 1997, rapport performance/prix imbattable en Europe, avec une gamme cloud ARM à 4,49 euros HT par mois, environ 5,40 euros TTC, au tarif du jour où j’écris ces lignes. Excellent choix, à une condition. Hetzner a ouvert des datacenters aux États-Unis en 2021, puis à Singapour en 2023. Tu dois donc provisionner ta machine exclusivement sur leurs sites européens, Falkenstein, Nuremberg ou Helsinki, pour rester hors CLOUD Act.

Deux réserves honnêtes en plus, l’interface et le support sont en anglais et en allemand uniquement, et Hetzner suspend parfois les comptes jugés à risque, sans avertissement. Rien de bloquant pour un usage SIEM légitime, mais autant le savoir.

Pour ce guide, je pars sur Infomaniak. La logique est identique chez Hetzner, seuls les noms d’interface changent.

À lire bientôt : choisir son hébergeur souverain, le comparatif complet

Dimensionner la machine, ni trop, ni trop peu

Wazuh, qu’on installera à l’épisode 2, n’est pas léger. Il embarque un manager, un indexeur de logs et un tableau de bord. L’indexeur, en particulier, aime la mémoire vive.

Pour une PME jusqu’à une cinquantaine de machines surveillées, le bon point de départ tient en trois chiffres.

• 4 vCPU, pour absorber l’indexation et les corrélations de règles sans saturer.
• 8 Go de RAM, le minimum sérieux pour l’indexeur Wazuh. En dessous, il rame ou s’arrête. C’est le critère qui compte le plus. Je recommande 12 Go.
• 100 à 250 Go de SSD, selon la rétention de logs que tu veux. Plus tu gardes de mois d’historique, plus il te faut d’espace. NIS2 et RGPD raisonnent en mois, prévois large.

Un VPS de ce calibre tourne autour de 15 à 30 euros par mois chez un opérateur souverain. Tu peux démarrer plus petit pour tester, mais ne descends pas sous 8 Go de RAM si tu comptes faire tourner Wazuh dessus pour de vrai.

Côté système, prends une distribution Linux à support long. Ubuntu Server LTS ou Debian stable. Les deux sont documentées partout, supportées des années, et c’est ce sur quoi la communauté Wazuh teste en priorité. J’utilise Ubuntu Server LTS, c’est ce que j’emploierai dans les commandes qui suivent.

Le premier contact, et le premier durcissement

Tu viens de commander ta machine. L’hébergeur t’envoie une adresse IP, un identifiant root et un mot de passe. C’est le moment le plus exposé de toute la vie du serveur, un root accessible par mot de passe sur une IP publique, c’est précisément ce que les bots scannent en permanence.

Une précision avant de plonger. Un serveur, ça s’administre en ligne de commande, pas d’interface graphique ni de souris, le Terminal est ton seul cockpit. Rien d’intimidant, chaque commande de ce guide est courte et expliquée ligne à ligne.

La première session de connexion sert à fermer cette porte. Dans l’ordre.

Créer un utilisateur non-root

Travailler en root au quotidien, c’est conduire sans ceinture. La moindre erreur de commande s’exécute avec les pleins pouvoirs. On crée un utilisateur dédié, à qui on donne le droit d’élever ses privilèges quand c’est nécessaire, via sudo.

adduser mack
usermod -aG sudo mack

Le premier adduser crée le compte et demande un mot de passe. Le second l’ajoute au groupe sudo, ce qui l’autorise à exécuter des commandes administrateur en les préfixant de sudo. À partir de maintenant, tu te connectes avec ce compte, plus jamais en root directement.

Passer à l’authentification par clé

Un mot de passe se devine, se force par dictionnaire, se vole. Une clé cryptographique, non. On génère une paire de clés sur ta machine locale, on installe la partie publique sur le serveur, et on désactive complètement la connexion par mot de passe.

Sur ton Mac, dans le Terminal :

ssh-keygen -t ed25519 -C "ton-commentaire"
ssh-copy-id mack@IP_DU_SERVEUR

La première commande crée la paire de clés, en Ed25519, l’algorithme moderne, court et solide. La seconde copie ta clé publique dans le serveur. Teste ensuite que tu te connectes bien sans mot de passe, ssh mack@IP_DU_SERVEUR. Si ça marche, on peut couper le reste.

Verrouiller SSH

C’est ici que la surface d’attaque se referme vraiment. On édite la configuration du démon SSH.

sudo nano /etc/ssh/sshd_config

Trois lignes à fixer, ce sont les trois qui comptent.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

PermitRootLogin no interdit toute connexion directe en root. PasswordAuthentication no désactive les mots de passe, seule ta clé ouvre la porte désormais. PubkeyAuthentication yes confirme qu’on accepte les clés.

Garde ta session actuelle ouverte, redémarre le service, puis teste une nouvelle connexion dans une seconde fenêtre. Une erreur de configuration SSH, et tu te retrouves verrouillé hors de ta propre machine.

sudo systemctl restart ssh

Un piège connu des images cloud, Ubuntu y dépose souvent un fichier /etc/ssh/sshd_config.d/50-cloud-init.conf contenant PasswordAuthentication yes, qui écrase ta configuration. Vérifie la valeur réellement appliquée avec sudo sshd -T | grep -i passwordauthentication, et si elle ressort à yes, corrige ce fichier-là aussi.

Trois commandes, trois lignes de config. Tu viens d’éliminer la quasi-totalité des attaques automatisées qui visent SSH. Les bots qui tentent root par mot de passe frappent maintenant contre un mur.

Activer les mises à jour de sécurité automatiques

Un serveur qu’on n’a pas patché est un serveur vulnérable, et personne ne se connecte tous les matins pour lancer les mises à jour à la main. On automatise les correctifs de sécurité.

sudo apt update && sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Le paquet unattended-upgrades installe automatiquement les correctifs de sécurité publiés pour ta distribution, sans toucher au reste. Tes failles connues se referment toutes seules, pendant que tu dors.

La surface d’attaque minimale, le vrai sujet souverain

Le durcissement SSH, c’est le b.a.-ba. Le saut de niveau, il est ici.

Le principe directeur tient en une phrase. Un port qui n’écoute pas ne peut pas être attaqué. Chaque service exposé sur une IP publique est une porte, et chaque porte est une cible. La sécurité maximale, ce n’est pas le meilleur cadenas sur chaque porte, c’est de ne pas avoir de porte du tout.

C’est exactement la logique qu’on a vue pour la Secure Enclave. Le composant le plus sûr est celui qui refuse de donner accès, pas celui qui le défend bien.

Le pare-feu, fermer par défaut

Sur Ubuntu, le pare-feu se gère avec ufw. La bonne posture, c’est l’inversion, on bloque tout, puis on ouvre seulement ce qui doit l’être.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable

default deny incoming refuse par principe toute connexion entrante. default allow outgoing laisse ta machine joindre l’extérieur, pour les mises à jour notamment. On n’ouvre que le port 22, SSH, le strict nécessaire pour administrer la machine. Et on active.

À ce stade, ton serveur ne présente plus qu’une seule porte SSH par clé. C’est déjà un profil radicalement plus discret que 90 % des VPS en production.

Tailscale, et l’IP publique disparaît

On peut faire mieux. Bien mieux. Plutôt que d’ouvrir SSH sur l’IP publique, même par clé, on le retire complètement de la vue d’internet et on l’expose uniquement sur un réseau privé chiffré.

C’est le rôle de Tailscale. Tailscale crée un maillage privé entre tes appareils, par-dessus WireGuard, le protocole de tunnel moderne. Tes machines se voient entre elles via des adresses privées, comme si elles étaient sur le même réseau local, alors qu’elles sont éparpillées entre un datacenter suisse, ton bureau et chez toi. Le reste d’internet, lui, ne voit rien.

Voici le flux concret. Tu installes Tailscale sur le serveur et sur ton Mac. Les deux rejoignent ton réseau privé. Ton Mac obtient une adresse Tailscale, le serveur aussi. Tu te connectes en SSH au serveur via son adresse Tailscale, pas via son IP publique. Et tu refermes le port 22 sur l’IP publique. Désormais, pour atteindre SSH, il faut déjà être membre de ton réseau privé. Un attaquant sur internet ne voit même plus que le port existe.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

La commande affiche un lien, tu l’ouvres dans ton navigateur, tu authentifies la machine, elle rejoint ton réseau. Répète sur ton Mac. Récupère l’adresse Tailscale du serveur :

tailscale ip -4

Teste la connexion SSH via cette adresse privée. Une fois que ça marche, on referme le port 22 public :

sudo ufw delete allow 22/tcp
sudo ufw allow in on tailscale0 to any port 22 proto tcp

La première ligne retire l’ouverture de SSH sur toutes les interfaces. La seconde le rouvre uniquement sur l’interface tailscale0, ton réseau privé. SSH n’écoute plus que sur le maillage chiffré.

Le résultat, c’est une machine dont la seule porte d’administration est invisible depuis internet. Pas verrouillée, invisible. Un scan de ports sur ton IP publique ne révèle rien d’exploitable.

Pour la suite de la série, c’est aussi par ce maillage que tes agents Wazuh remonteront leurs logs vers le serveur, sans jamais transiter par l’internet ouvert. Le socle réseau qu’on pose aujourd’hui sert toute la pile.

Et les services qui doivent rester publics ?

Tout ne peut pas vivre derrière le réseau privé. Si ton serveur héberge un site web ou un service qui doit être joignable par n’importe qui, ce service-là doit écouter sur l’IP publique. C’est inévitable.

La règle, alors, n’est pas « zéro port public » mais « zéro port public inutile ». Tu ouvres exactement ce que le service exige, ni plus. Un site web, c’est le port 443 en HTTPS, et le port 80 le temps de renouveler les certificats. Rien d’autre. Tout le reste, administration, bases de données, tableaux de bord internes, reste sur Tailscale.

Pour notre socle SIEM, à ce stade, la bonne réponse est simple. Aucun service public. Le serveur n’expose rien au monde. Wazuh, qu’on installera ensuite, vit entièrement derrière Tailscale, accessible à toi seul.

Les sauvegardes, chiffrées hors-site

Un serveur durci n’est pas un serveur immortel. Un datacenter peut prendre feu, on l’a vu avec OVH Strasbourg en mars 2021, des clients sans sauvegarde ont tout perdu. Un ransomware peut malgré tout passer sur une de tes machines de prod. Un doigt qui glisse sur une mauvaise commande peut effacer une base.

La règle est non négociable. Tes sauvegardes vivent ailleurs que sur la machine qu’elles protègent, et elles sont chiffrées avant de partir. Chiffrées par toi, sur ta machine, avant l’envoi. Pas chiffrées par le fournisseur de stockage, par toi. Comme ça, même l’hébergeur du backup ne peut pas lire ce qu’il stocke.

L’outil que j’utilise, c’est Kopia. Open source, rapide, et il fait exactement ce qu’on veut, chiffrement côté client avant transfert, déduplication pour ne pas exploser ton volume de stockage, et envoi vers un stockage compatible S3.

Et le stockage hors-site, je le prends chez Swiss Backup, l’offre de sauvegarde d’Infomaniak. Même logique de souveraineté que pour le VPS, serveurs suisses, hors CLOUD Act, et un endpoint S3 standard que Kopia consomme directement.

Le flux, concrètement. Kopia tourne sur ton serveur. Une fois par jour, ou plusieurs, il prend un instantané des dossiers qui comptent, ta configuration système, tes données Wazuh, tes logs.

Il chiffre cet instantané localement, avec une clé que toi seul détiens. Puis il l’envoie chez Swiss Backup. Le jour où le serveur meurt, tu provisionnes une nouvelle machine, tu réinstalles Kopia, tu pointes vers le dépôt distant avec ta clé, et tu restaures.

curl -s https://kopia.io/signing-key | sudo gpg --dearmor -o /usr/share/keyrings/kopia-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/kopia-keyring.gpg] http://packages.kopia.io/apt/ stable main" | sudo tee /etc/apt/sources.list.d/kopia.list
sudo apt update && sudo apt install kopia
kopia repository create s3 \
  --bucket=TON_BUCKET \
  --endpoint=s3.swiss-backup.infomaniak.com \
  --access-key=TA_CLE \
  --secret-access-key=TON_SECRET

Les trois premières lignes installent Kopia depuis son dépôt officiel. La dernière commande crée le dépôt chiffré sur le stockage distant, en reprenant l’endpoint exact affiché dans ta console Swiss Backup, il varie selon le cluster qui t’est attribué. Kopia te demande une phrase de passe au moment de la création, c’est la clé de chiffrement de tout ton dépôt. Note-la ailleurs que sur le serveur. Si tu la perds, tes sauvegardes sont définitivement illisibles, y compris pour toi. C’est le prix du chiffrement côté client, et c’est exactement ce qu’on veut.

Reste à automatiser. On crée un instantané quotidien des dossiers critiques, puis on planifie le tout avec une tâche cron.

kopia snapshot create /etc /home /var/log

Cette commande capture l’instant présent des trois dossiers. Tu la planifies pour qu’elle s’exécute chaque nuit, et tu vérifies de temps en temps que tes instantanés sont bien là avec kopia snapshot list. Une sauvegarde qu’on ne teste jamais n’est pas une sauvegarde, c’est un espoir. Il faudra donc prévoir trimestriellement une restauration test de tes données.

Ce socle de sauvegarde servira tout le reste de la série. Chaque brique qu’on ajoutera, Wazuh et ses données, les règles que tu calibreras, sera capturée dans le même instantané chiffré, hors-site, le jour où tu en auras besoin.

En résumé

Le socle, c’est quatre gestes qui se tiennent.

Tu as choisi un hébergeur dont la juridiction te protège, pas seulement dont le datacenter est en Europe. Tu as durci l’accès, utilisateur non-root, clé à la place du mot de passe, root interdit, correctifs automatiques. Tu as réduit la surface d’attaque à rien, pare-feu fermé par défaut, administration repliée derrière un réseau privé chiffré, plus aucune porte inutile face à internet. Et tu as posé des sauvegardes chiffrées hors-site, illisibles pour quiconque n’a pas ta clé, prêtes pour le jour où.

Aucune de ces étapes n’est compliquée. Prises ensemble, elles transforment une machine de location en un coffre-fort que tu contrôles. C’est l’inverse exact de ce que tu signes chez un SaaS américain, où la donnée est à toi mais l’infrastructure et la juridiction sont à un autre.

Un après-midi de travail. Pas un week-end.

Le socle est en place. À l’épisode 2, on remplit le coffre. Wazuh en mode tout-en-un, le manager, l’indexeur et le tableau de bord sur ce seul nœud. L’équivalent fonctionnel d’un Splunk, pour le prix du VPS que tu viens de monter. Ton SIEM commence à exister.

Rappel de la série

Sept épisodes pour monter ta plomberie de sécurité souveraine, brique par brique.

• Épisode 0, le fondement de la série. Pourquoi une PME a besoin d’un SIEM souverain, NIS2, RGPD, et le coût du statu quo.
• Épisode 1, le socle. Le VPS durci hors CLOUD Act. Tu viens de le lire.
• Épisode 2, Wazuh en tout-en-un. Manager, indexeur et tableau de bord sur un seul nœud.
• Épisode 3, les agents partout. Déploiement sur tes serveurs, Mac et Windows.
• Épisode 4, la défense réseau communautaire. Bloquer les attaquants connus avant qu’ils n’arrivent.
• Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ton serveur de messagerie.
• Épisode 6, le contrôle d’exécution sur les Mac. Décider quelles applications ont le droit de démarrer.
• Épisode 7, alerting et coût total. Notifications calibrées et bilan financier honnête face au SaaS.

Des termes techniques ? Consulte le glossaire.