Comment sécuriser un serveur web contre les attaques : le guide essentiel

Un serveur web mal configuré, c'est comme une porte d'entrée dont la serrure tient avec du ruban adhésif. Ça tient. Jusqu'au jour où ça tient plus.

La question revient sans cesse dans ma boîte mail : comment sécuriser un serveur web contre les attaques ? Franchement, après avoir vu passer quelques centaines de logs d'attaque sur mes propres machines, je peux vous dire une chose : la plupart des intrusions ne sont pas spectaculaires. Elles passent par des portes qu'on a oublié de fermer. Un service qui traîne, un mot de passe réutilisé, une version de PHP vieille de deux ans.

Dans cet article, je vais vous montrer ce qui fonctionne réellement, dans quel ordre, et ce qui relève du folklore.

Pourquoi votre serveur web est une cible, même s'il est petit

J'ai hébergé un projet perso il y a quelques années, un simple site de recettes avec 40 visiteurs par jour. En trois semaines, j'ai compté plus de 12 000 tentatives de connexion SSH échouées. Douze mille. Pour un site de cuisine.

Le point que beaucoup de gens ratent : les attaquants ne vous ciblent pas personnellement. Ils scannent des plages IP entières, à la recherche de ports ouverts, de bannières de service obsolètes, de formulaires mal protégés. C'est industriel. Automatisé. Et ça ne coûte rien à celui qui le fait.

Ce qui se passe réellement quand on vous attaque

Trois scénarios reviennent constamment :

• Force brute sur SSH ou l'interface d'admin — des milliers de combinaisons login/mot de passe testées en continu.
• Injection SQL ou XSS — l'attaquant cherche à faire parler votre base de données ou à injecter du code dans vos pages.
• Exploitation d'une faille connue — un plugin WordPress non mis à jour, un framework avec un CVE publié il y a six mois. Vous ne l'avez pas patché. Il le sait.

Le troisième cas est le plus meurtrier. Et paradoxalement, le plus simple à éviter.

Durcir SSH : la première action à fort rendement

Si vous ne faites qu'une seule chose après avoir lu cet article, faites celle-ci.

Par défaut, SSH accepte l'authentification par mot de passe. C'est pratique. C'est aussi une invitation ouverte au bruteforce. La solution : passer à l'authentification par clé, et désactiver complètement les mots de passe.

Les réglages concrets dans sshd_config

Voici ce que j'ai fini par mettre en place, après avoir tâtonné :

• PasswordAuthentication no — une fois vos clés en place, plus aucun mot de passe ne passe.
• PermitRootLogin no — on se connecte avec un utilisateur normal, puis on utilise sudo. Toujours.
• Port personnalisé — je sais, c'est de la sécurité par obscurité. Mais ça élimine 95 % du bruit automatique dans les logs. Je l'assume.
• AllowUsers — une liste blanche stricte. Si votre nom n'y est pas, vous ne rentrez pas, même avec la bonne clé.

Et puis il y a Fail2ban. Ce petit outil lit vos logs, repère les IP qui échouent trop souvent, et les bannit temporairement via iptables. Sur mon serveur de recettes, ça a fait chuter les tentatives visibles de 80 % en une semaine.

Un détail que j'ai mis du temps à comprendre : bannir une IP ne sert à rien si vous ne vérifiez jamais pourquoi elle a été bannie. Les logs Fail2ban sont une mine d'informations sur ce qu'on essaie de vous faire.

Le WAF, le truc qui manque à 90 % des tutoriels

Franchement, je ne comprends pas pourquoi on en parle si peu. Un WAF — Web Application Firewall — analyse le trafic HTTP avant qu'il n'atteigne votre application. Il filtre les requêtes qui ressemblent à des injections SQL, à du XSS, à du path traversal.

Vous n'avez pas besoin d'une solution payante à cinq chiffres. Un ModSecurity avec le ruleset OWASP Core Rule Set, c'est gratuit, ça se configure en une après-midi, et ça bloque une quantité déprimante d'attaques basiques.

Oui, ça peut générer des faux positifs. Oui, il faut ajuster les règles. Mais le rapport effort/protection est imbattable. J'ai vu un WAF mal réglé bloquer une tentative d'injection SQL que mon code aurait laissée passer — j'avais oublié une requête préparée dans un vieux formulaire de contact.

Protection DDoS : ne confondez pas tout

Un WAF ne vous sauvera pas d'une attaque par déni de service volumétrique. Pour ça, il faut soit un CDN avec protection intégrée (Cloudflare, Fastly, ce genre), soit un service anti-DDoS chez votre hébergeur. Si votre serveur tombe dès qu'on lui envoie 50 000 requêtes par seconde, aucune règle ModSecurity ne changera la donne.

Mises à jour et réduction de surface d'attaque

Un serveur qui tourne avec des logiciels à jour, c'est un serveur qui ferme les portes que les attaquants connaissent. C'est bête, mais c'est la réalité.

Le problème, c'est que personne ne fait ses mises à jour manuellement de façon régulière. Moi le premier — j'ai laissé tourner une version de Nginx pendant huit mois sans y toucher. Huit mois, c'est une éternité en termes de CVE publiées.

Ce qui marche vraiment :

1. Activer les mises à jour de sécurité automatiques pour le système d'exploitation (unattended-upgrades sous Debian/Ubuntu).
2. Mettre en place une alerte quand une mise à jour critique est disponible pour votre stack applicative.
3. Désinstaller tout ce qui ne sert pas. Un service que vous n'utilisez plus, c'est une porte que vous avez oubliée.

Sur la surface d'attaque, un exemple concret : j'avais laissé phpMyAdmin accessible sur un sous-domaine. Pratique pour gérer la base. Sauf que phpMyAdmin, c'est une cible connue, avec ses propres CVE. Je l'ai déplacé derrière une restriction IP. Le jour où une faille sort, je ne suis plus dans la liste des victimes potentielles.

Surveillance et réponse à incident : ce que personne ne vous dit

Vous pouvez avoir la meilleure configuration du monde. Si vous ne regardez jamais vos logs, vous êtes aveugle.

La surveillance, c'est trois niveaux :

• Les logs d'accès — qui vient, quand, avec quel code de réponse. Une pic de 404 ou de 403, c'est souvent un scan.
• Les logs système — connexions SSH, erreurs kernel, redémarrages de services.
• Les alertes — pas besoin d'un SIEM à 40 000 euros. Un simple fail2ban qui envoie un mail, ou un script cron qui grep les motifs suspects, ça suffit pour commencer.

J'ai mis six mois à implémenter une alerte basique sur les tentatives d'authentification. Six mois pendant lesquels je n'aurais pas su qu'on me testait. C'est absurde, et pourtant c'est le cas de la majorité des serveurs que je croise.

Faut-il faire des tests d'intrusion ?

Si vous hébergez des données sensibles, oui. Un scan automatisé (OpenVAS, Nikto) vous donnera déjà une idée. Un vrai pentest, c'est autre chose — plus cher, plus long, mais ça trouve des failles que les scanners ratent. Pour un site vitrine, un scan régulier suffit. Pour une application avec des comptes utilisateurs, investissez.

HTTPS : faut-il tout crypter ?

Oui. Et si vous ne l'avez pas encore fait, c'est probablement la chose la plus simple de cette liste.

Let's Encrypt délivre des certificats gratuits, valables 90 jours, renouvelables automatiquement. Certbot fait ça en trois commandes. Il n'y a plus aucune excuse technique ou financière.

Ce que HTTPS fait : il chiffre le transport entre le navigateur et votre serveur. Il empêche l'interception du trafic, les attaques de l'homme du milieu, et il est devenu un critère de référencement.

Ce que HTTPS ne fait pas : il ne protège pas votre application. Une injection SQL passe très bien en HTTPS. Un formulaire mal validé aussi. C'est une couche de transport, pas une couche de sécurité applicative.

Récapitulatif : ce qui protège contre quoi

Mesure	Protège contre	Effort	Impact
Clés SSH + Fail2ban	Bruteforce, accès non autorisé	Faible	Très élevé
WAF (ModSecurity + OWASP CRS)	Injections SQL, XSS, path traversal	Moyen	Élevé
Mises à jour automatiques	Exploitation de CVE connues	Faible	Très élevé
HTTPS / TLS	Interception, homme du milieu	Faible	Moyen (transport uniquement)
Surveillance des logs	Détection tardive, angles morts	Moyen	Élevé (permet de réagir)

Par où commencer concrètement

Si vous partez de zéro, voici l'ordre que je recommande, et que j'aurais aimé qu'on me donne :

1. Passez SSH en clés, désactivez les mots de passe, installez Fail2ban. Aujourd'hui.
2. Activez les mises à jour automatiques de sécurité.
3. Mettez en place HTTPS si ce n'est pas fait.
4. Installez un WAF et ajustez-le pendant une semaine avant de le passer en mode bloquant.
5. Configurez au moins une alerte sur les tentatives d'authentification échouées.

Le reste — audits, pentests, durcissement applicatif — viendra après. Mais ces cinq étapes couvrent l'essentiel des attaques automatisées que vous subirez.

La sécurité d'un serveur web n'est pas un projet qu'on termine. C'est un état qu'on maintient. Et la vérité inconfortable, c'est que la plupart des serveurs compromis ne l'ont pas été par une attaque sophistiquée. Ils l'ont été parce que quelqu'un, quelque part, n'a pas appliqué un patch qui existait depuis des mois.

La question n'est pas de savoir si on va tester votre serveur. C'est de savoir si vous le saurez quand ça arrivera.