Sécurité et hardening de serveurs : fermez la porte avant qu’on la force

La plupart des failles de sécurité n’exploitent pas des vulnérabilités sophistiquées. Elles exploitent des configurations par défaut, des services exposés inutilement et des systèmes qui n’ont pas été mis à jour depuis des mois. Un serveur mal configuré est une porte ouverte : personne ne la forcera peut-être aujourd’hui, mais les bots ne se reposent jamais.

Je m’occupe de fermer cette porte avant qu’il y ait un problème. Audit de l’état actuel, réduction de la surface d’attaque et configuration des couches de défense adaptées à chaque service. Sans installer de suites lourdes ni de solutions boîtes noires : votre infrastructure, bien configurée, avec tout documenté.

Je travaille avec des agences et des développeurs qui ont besoin de laisser les serveurs de leurs clients en bon état avant la livraison, et avec des responsables e-commerce et des entreprises qui veulent connaître leur niveau d’exposition réel.

Symptômes courants

  • Serveur fraîchement installé, jamais vérifié. Accès SSH root par mot de passe, ports ouverts inutilisés, services par défaut encore actifs. Un hébergement ou un VPS par défaut n’est pas un serveur sécurisé.
  • Attaques par force brute continues. SSH, wp-login, xmlrpc, panneaux d’administration… les logs sont remplis de tentatives et personne n’a configuré quoi que ce soit pour les bloquer.
  • Personne ne sait quels ports ou services sont exposés. Le pare-feu est « activé » mais personne n’a revu les règles ni vérifié ce qui écoute sur quel port depuis longtemps.
  • Mises à jour de sécurité en attente. Le système d’exploitation, le noyau ou les services du stack n’ont pas été mis à jour depuis des mois. Chaque semaine qui passe, il y a davantage de CVE connus et exploitables.
  • Audit nécessaire avant une livraison ou une certification. Un client demande des preuves de sécurité, un audit externe est prévu, ou vous voulez simplement connaître l’état réel avant de livrer.

Comment je l’aborde

Le point de départ est toujours le même : connaître l’état réel avant de toucher quoi que ce soit. Pas question d’appliquer une checklist générique sans comprendre l’environnement. D’abord j’audite, ensuite je priorise par impact réel, puis j’applique les modifications avec une documentation pour chaque décision.

L’objectif n’est pas un serveur « parfait » sur le papier, mais un serveur avec une surface d’attaque raisonnable, avec des couches de défense actives là où elles comptent et un logging suffisant pour détecter les anomalies.

Ce que couvre ce service

Audit de sécurité du système

  • Revue des ports exposés, des services actifs et des utilisateurs système.
  • Analyse des configurations par défaut, des permissions de fichiers et des répertoires sensibles.
  • Revue des logs à la recherche d’indices d’accès suspects ou de tentatives antérieures.
  • Rapport avec les résultats classés par sévérité et des recommandations concrètes.

Hardening du système

  • Configuration de SSH : authentification par clé, désactiver root, changement de port si applicable, restrictions d’accès.
  • Configuration du pare-feu (iptables, nftables, pf sur BSD) : politique restrictive, seul le nécessaire ouvert.
  • Réduction de la surface d’attaque : supprimer les services inutiles, revoir les crons et les utilisateurs.
  • Configuration de fail2ban ou équivalent pour le blocage automatique de la force brute (SSH, HTTP, services spécifiques).
  • En-têtes de sécurité HTTP, TLS bien configuré et renouvellement automatique des certificats.
  • Mises à jour de sécurité du système d’exploitation, du noyau et des paquets du stack.

Protection au niveau de l’application web

  • Protection des endpoints sensibles : wp-login, xmlrpc, panneaux d’administration, APIs.
  • Filtrage des bots et scrapers au niveau du serveur web avant qu’ils atteignent votre application.
  • WAF au niveau serveur (ModSecurity) ou périmétrique (Cloudflare) selon le cas.
  • Permissions correctes de fichiers et répertoires dans le docroot.

Sécurité continue

  • Gestion périodique des mises à jour de sécurité du système.
  • Revue des logs et alertes en cas d’anomalies.
  • Nouvel audit après des modifications importantes de l’infrastructure.

Parlons de la sécurité de votre infrastructure