freedzhost.cloud

Avant d'ouvrir un site web à internet : un audit de sécurité en dix contrôles

Niveau IntermédiaireTemps estimé 2 hÀ lire avant Homelab 2 : une seule entrée HTTPS pour tous vos services, Homelab 18 : bannir les scanners avec fail2ban, et le piège Docker qui rend les bannissements inutilesUn mot inconnu ? Lexique

Un site web à la maison se fait rarement pirater par le site lui-même. Il se fait pirater par ce qui partage sa porte : une console d'administration publiée par habitude, un outil qui tourne en root, une défense installée mais qui ne marche pas. Nous avons audité l'un des nôtres avec rien d'autre que de la lecture et de la mesure, sans aucune attaque. Le site a passé l'examen. Trois choses à côté de lui, non, et nous les avons refermées la nuit même.

Ce que vous y gagnez. Un audit non destructif que vous pouvez mener sur votre propre site en deux heures, la commande de chaque contrôle, et le correctif de chaque constat classique. Appliqué ici, il a fait apparaître un éditeur de code à distance tournant en root et ouvert à internet, et un outil de bannissement qui avait reconnu 0 ligne de journal sur 67 079. Les deux sont corrigés : les consoles d'administration répondent désormais 403 depuis l'extérieur, et le filtre réparé a banni son premier scanner en quelques minutes.

1. Regarder comme un visiteur : les en-têtes

curl -s -o /dev/null -D - https://votre-site.example/
Content-Security-Policy: default-src 'self'; img-src 'self' data:; script-src 'self';
  style-src 'self'; frame-ancestors 'none'; base-uri 'none'; form-action 'self'

Dans nginx, un add_header placé dans un bloc location annule tous les add_header du bloc serveur pour cet emplacement. Notre dossier /media/ a perdu ainsi ses en-têtes de sécurité, sans bruit. Mettez les en-têtes dans un fichier et incluez-le partout.

2. Le chiffrement

for v in tls1 tls1_1 tls1_2 tls1_3; do echo | openssl s_client -connect votre-site.example:443 -$v 2>&1 | grep -m1 Protocol; done

Seuls TLS 1.2 et 1.3 doivent répondre. Vérifiez aussi les noms des certificats : l'un des hôtes examinés servait un certificat fait pour un autre nom, que tout navigateur refuse.

3. Le DNS

curl -s -H 'accept: application/dns-json' "https://cloudflare-dns.com/dns-query?name=votre-site.example&type=CAA"

4. Les voisins : tout ce qui est derrière la même porte

Listez chaque nom publié par votre proxy inverse, et demandez-vous pour chacun : qui, à part moi, en a besoin depuis internet ? Les consoles d'administration (le panneau du proxy lui-même, un filtre DNS, un hyperviseur, un éditeur de code web) jamais. Placez-les derrière une liste d'accès qui n'autorise que votre réseau local et votre réseau privé, en un clic dans Nginx Proxy Manager.

Le pire cas rencontré : un éditeur de code web tournant en root sur la machine qui héberge la forge de code, protégé par un simple mot de passe. Un terminal web ne doit jamais tourner en root, et jamais être sur internet.

5. L'outil de bannissement bannit-il vraiment ?

Une prison fail2ban peut être activée, en marche, et aveugle. Testez le filtre contre votre vrai journal :

fail2ban-regex /var/log/npm/proxy-host-1_access.log /etc/fail2ban/filter.d/npm.conf
# Lines: 67079 lines, 0 ignored, 0 matched   <- aveugle

Deux pièges expliquaient notre zéro. D'abord, fail2ban retire la date de chaque ligne avant d'appliquer le filtre : un motif qui commence par la date ne correspond donc jamais. Ensuite, Nginx Proxy Manager écrit l'adresse du client à la fin, pas au début. Un filtre qui marche sur son format :

[Definition]
failregex = \] - (?:401|403|404|429) \d+ - \S+ \S+ \S+ "[^"]*" \[Client <HOST>\]

[npm]
ignoreip = 127.0.0.1/8 YOUR-LAN/24 YOUR-TAILNET-RANGE

La ligne ignoreip compte : une fois réparé, le filtre reconnaissait des milliers de lignes, et beaucoup venaient de nos propres machines (un exécutant de CI qui recevait des 404). Sans elle, la prison réparée bannirait votre propre infrastructure. Avec Docker, bannissez dans la chaîne DOCKER-USER (voir fail2ban).

6. Lire les journaux une fois

Comptez ce qui vous arrive. Sur le site audité : 9 901 requêtes répondues en 401, 403 ou 404 sur environ 76 000, et des centaines de recherches de /.env et /.git/config, venues de serveurs cloud. Ce sont des robots qui cherchent des secrets oubliés : vérifiez que ces chemins n'existent pas dans ce que vous publiez, et bannissez dès la première sonde.

7. Le reste de la liste

  1. Le moindre privilège : aucun service web en root ; les ports des conteneurs liés à 127.0.0.1 derrière le proxy.
  2. Un pare-feu d'hôte sur la machine du proxy : 80 et 443 pour tous, le reste pour votre réseau privé seulement.
  3. Regarder de l'extérieur : depuis un téléphone en données mobiles, scannez votre adresse publique. Des ports qui semblent ouverts depuis la maison peuvent n'être que votre box qui se répond à elle-même.
  4. Des limites de débit et des délais courts au proxy, contre le devinage de mots de passe et les inondations (voir résister aux DDoS à la maison).

Pièges

Auditez sans attaquer : lire les en-têtes, le DNS et votre propre configuration trouve la plupart des problèmes. Ne scannez ni ne testez jamais le site de quelqu'un d'autre sans autorisation écrite.

Écrivez l'audit, et gardez le rapport privé tant que les correctifs ne sont pas en place : c'est une carte pour qui le lit.

Sources

Utile ? Dites-nous ce qu'il faut mesurer ensuite.