Aller au contenu principal
SYSTEMS OPERATIONAL

Sécuriser Votre Serveur Dédié : Avant Que Quelqu'un Ne Le Fasse à Votre Place

Votre serveur a été scanné 12 000 fois cette nuit. Ports ouverts, versions exposées, failles connues, tout est catalogué. La seule question : est-ce qu'un attaquant passera à l'action avant vous ?

120+
Serveurs durcis
50+
Points de contrôle
0
Compromission post-hardening
48h
Sécurisation complète

Votre serveur est une cible. Pas une possibilité , une certitude.

Vous avez un serveur dédié. Il tourne chez OVH, Hetzner ou Scaleway. Les applications répondent, les clients ne se plaignent pas. Vous pensez que tout va bien.

Sauf qu'un serveur exposé sur Internet reçoit en moyenne 13 000 tentatives de bruteforce SSH par semaine. Les bots ne dorment pas. Ils scannent chaque port, testent chaque CVE connue, cherchent chaque configuration par défaut. Et votre serveur leur répond, poliment, avec son numéro de version Apache en clair dans les headers.

On récupère des serveurs chaque mois. Le constat est toujours le même : SSH sur le port 22 avec mot de passe root, firewall désactivé, paquets critiques non patchés depuis 6 mois, aucune détection d'intrusion. Le serveur fonctionne, oui. Comme une maison avec la porte grande ouverte fonctionne, jusqu'au jour où quelqu'un entre.

Si vous ne pouvez pas répondre à la question "quand a été appliquée la dernière mise à jour de sécurité ?", votre serveur est probablement vulnérable. Un audit de sécurité serveur permet d'en avoir le coeur net , avant qu'un attaquant ne fasse le diagnostic à votre place.

$ grep "Failed password" /var/log/auth.log | wc -l

47,832 tentatives de connexion échouées ce mois-ci

$ apt list --upgradable 2>/dev/null | grep -i security | wc -l

23 mises à jour de sécurité en attente, dont 7 critiques

$ curl -sI votre-site.fr | grep Server

Server: Apache/2.4.52 (Ubuntu), version exposée publiquement

$ ss -tlnp | wc -l

14 ports ouverts, dont 6 inutiles et non surveillés

Ce que l'inaction coûte vraiment à votre entreprise

On ne parle pas de risques théoriques. On parle de chiffres que des dirigeants de PME découvrent chaque semaine, quand il est trop tard pour négocier.

130 000 €

Coût moyen d'un ransomware pour une PME en France (rançon + arrêt + restauration)

3 à 7 jours

Durée moyenne de paralysie totale après une compromission serveur

4% du CA

Amende RGPD maximale en cas de fuite de données personnelles

60%

Des PME ferment dans les 18 mois suivant une cyberattaque majeure

Le scénario qu'on voit le plus souvent : un serveur mal sécurisé, une faille exploitée un vendredi soir, des fichiers chiffrés dimanche matin, et lundi à 8h une équipe entière qui ne peut plus travailler. La rançon demandée : 2 Bitcoin. Les sauvegardes ? Sur le même serveur, chiffrées elles aussi.

Et ce n'est que la partie visible. Ajoutez la perte de confiance des clients, le temps du dirigeant mobilisé sur la gestion de crise au lieu du développement commercial, les notifications CNIL obligatoires, et les mois de reconstruction. Le coût réel dépasse systématiquement le coût visible.

Un Plan de Reprise d'Activité (PRA) couplé à un serveur durci transforme ce scénario catastrophe en un incident maîtrisé de quelques heures. La question n'est pas "est-ce que ça va arriver ?" mais "est-ce que vous serez prêt quand ça arrivera ?"

Ce qu'on déploie sur votre serveur : 8 couches de défense

Sécuriser un serveur, ce n'est pas cocher une case. C'est une architecture de défense en profondeur où chaque couche compense les failles de la précédente. Ce qu'on met en place, point par point.

01

SSH blindé

Authentification par clé ED25519 uniquement. Port personnalisé. Désactivation root login. AllowUsers restrictif. Le SSH est la porte d'entrée n°1 , on la verrouille en premier.

$ sshd -T | grep -E "permit|pubkey|port"

PermitRootLogin no / PubkeyAuth yes / Port 2222

02

Firewall nftables

Politique DROP par défaut. Seuls les ports strictement nécessaires sont ouverts. Rate limiting sur les connexions entrantes. Le serveur devient invisible aux scanners.

$ nft list ruleset | grep "policy drop"

chain input { policy drop; }, tout est fermé par défaut

03

Fail2ban multi-services

Bannissement automatique des IP malveillantes. Pas uniquement SSH , on protège aussi Apache, Nginx, Postfix, les API et tout service exposé. Jails personnalisées par service.

$ fail2ban-client status sshd

Currently banned: 847. Total banned: 23,491

04

Détection d'intrusion

OSSEC pour la surveillance temps réel des fichiers système. Rkhunter pour la détection de rootkits. Audits Lynis réguliers pour le scoring de sécurité global. Si quelqu'un entre, on le sait en minutes.

05

WAF ModSecurity

Pare-feu applicatif devant Apache ou Nginx. Règles OWASP CRS contre les injections SQL, XSS, traversées de répertoires. La dernière ligne de défense avant votre application.

06

Mises à jour automatiques

Unattended-upgrades pour les patchs de sécurité critiques, appliqués automatiquement sans intervention. Mises à jour majeures testées et déployées lors de fenêtres de maintenance planifiées.

07

Conformité CIS Benchmarks

Application des recommandations CIS (Center for Internet Security) pour Debian/Ubuntu. Chaque paramètre système vérifié, documenté et corrigé. Le standard utilisé par les entreprises du CAC 40.

08

Monitoring & SIEM

Logs centralisés, corrélés et analysés en temps réel. Alertes sur comportements suspects. Rapports mensuels de sécurité. Le socle de notre supervision 24/7.

Ces 8 couches constituent notre prestation standard de sécurisation. Chaque serveur que nous prenons en infogérance passe par ce processus complet avant d'être considéré comme opérationnel.

Serveur par défaut vs. serveur durci : la différence concrète

Aspect Serveur par défaut Serveur durci
Accès SSH Port 22, root + mot de passe Port custom, clé ED25519, root interdit
Firewall Désactivé ou ACCEPT par défaut nftables, policy DROP, rate limiting
Bruteforce Aucune protection, tentatives illimitées Fail2ban multi-jails, ban automatique
Mises à jour Manuelles (si quelqu'un y pense) Automatiques (sécurité) + planifiées (majeures)
Intrusion Aucune détection, découverte trop tard OSSEC + rkhunter + alertes temps réel
Application web Aucun WAF, injections SQL possibles ModSecurity + OWASP CRS actif
Logs Locaux, non surveillés, rotation par défaut Centralisés, corrélés, alertes automatiques

La colonne de gauche, c'est l'état dans lequel on récupère 90% des serveurs. La colonne de droite, c'est l'état dans lequel on les rend. La différence entre les deux, c'est la différence entre un serveur qui attend d'être compromis et un serveur qui résiste activement.

Interventions sécurité : retours terrain

Ransomware Restauration 4h + hardening 48h

Cabinet comptable, 2 serveurs dédiés OVH. Appel un lundi matin : impossible d'accéder aux fichiers. Ransomware déployé via un PHPMyAdmin exposé sans authentification. Aucune sauvegarde exploitable sur site. On a restauré depuis notre backup offsite chiffré AES-256, resécurisé l'intégralité de l'infrastructure. SSH durci, nftables, OSSEC , et mis en place un monitoring temps réel. Le cabinet a repris son activité le jour même.

Données restaurées en 4h. zéro perte, 8 couches de défense déployées
Sécurité 3 jours de hardening complet

Startup SaaS B2B, 3 serveurs Hetzner. Le développeur principal utilisait root pour tout, même mot de passe partout, SSH sur le port 22 sans fail2ban. 84 000 tentatives de bruteforce par semaine dans les logs. On a déployé l'authentification ED25519, segmenté les accès par utilisateur, configuré fail2ban sur SSH + API + Nginx, et installé OSSEC. Résultat : de 12 000 tentatives/jour à zéro connexion non autorisée.

Bruteforce éliminé. surface d'attaque réduite de 94%
Compromission 24h nettoyage + 5 jours durcissement

E-commerce, 8 000 commandes/mois sur Scaleway. Alerte ANSSI : le serveur figurait sur une liste d'IP compromises utilisées comme relai de spam. Cause : un plugin WordPress vulnérable exploité pour injecter un webshell en PHP. Nettoyage complet, déploiement WAF ModSecurity avec règles OWASP CRS, mise à jour de toute la stack, surveillance des modifications de fichiers par OSSEC. Serveur retiré des blacklists en 24h.

Serveur nettoyé, blacklists levées, WAF + détection d'intrusion actifs

Questions fréquentes : sécurisation serveur

Mon hébergeur ne gère pas déjà la sécurité de mon serveur ?

Non. Sur un serveur dédié ou VPS, l'hébergeur (OVH, Hetzner, Scaleway) fournit le matériel, le réseau et éventuellement un anti-DDoS basique. Tout le reste, système d'exploitation, firewall, SSH, mises à jour, sauvegardes, détection d'intrusion, est sous votre responsabilité. C'est exactement le périmètre qu'on couvre. Leur responsabilité s'arrête au hardware. La vôtre commence au kernel.

Combien coûte la sécurisation d'un serveur dédié ?

Comparez le coût de la sécurisation (quelques centaines d'euros pour le hardening initial + maintenance mensuelle) avec le coût moyen d'un ransomware pour une PME : 130 000€. Sans compter l'arrêt d'activité, la perte de clients et les amendes RGPD. La sécurisation n'est pas une dépense, c'est l'assurance la moins chère que vous puissiez souscrire pour votre infrastructure.

Est-ce que la sécurisation va impacter les performances de mon serveur ?

Au contraire. Un serveur durci est souvent plus performant qu'un serveur par défaut. On ferme les services inutiles qui consomment de la RAM, on élimine les processus parasites (mineurs crypto installés par des attaquants, par exemple), on optimise les règles firewall. Le monitoring qu'on met en place identifie aussi les goulets d'étranglement. Moins de bruit, plus de signal.

Que se passe-t-il si mon serveur est déjà compromis ?

On intervient en urgence. D'abord, isolation du serveur pour stopper la propagation. Ensuite, analyse forensique pour identifier le vecteur d'attaque. Puis restauration depuis une sauvegarde saine ou nettoyage manuel. Enfin, hardening complet des 8 couches pour que ça ne se reproduise pas. Temps de réaction moyen : 15 minutes après alerte. Et si vous n'avez pas encore de sauvegardes offsite, c'est la première chose qu'on met en place.

Est-ce que je garde l'accès root à mon serveur après sécurisation ?

Oui. C'est votre serveur, vous gardez un accès complet via votre propre clé SSH. On travaille avec des comptes dédiés et tracés. Chaque intervention est documentée. Si vous arrêtez notre collaboration, votre serveur reste fonctionnel et vous conservez toute la documentation technique. Zéro vendor lock-in, c'est un principe non négociable.

Audit gratuit , on vous montre les failles avant les hackers

Rapport détaillé avec les vulnérabilités critiques de votre serveur, scoring de sécurité et plan d'action concret. Gratuit, sans engagement. Parce que découvrir ses failles soi-même coûte beaucoup moins cher que de laisser un attaquant les trouver.

Réponse sous 24h · Diagnostic offert · Sans engagement