Durcissement des nodes

Ce que l'agent applique tout seul : anti-DDoS, force brute, ports fermés.

Chaque node applique un durcissement réseau sans que personne ait à le régler. Cette page décrit ce qui est fait, à quel niveau, et ce qu'il faut savoir avant de le modifier. Tout est actif à partir de l'agent 2.34.

Anti-DDoS#

Deux étages, et il faut les deux : le pare-feu décide quels paquets entrent, les réglages du noyau décident de ce que la pile fait de ceux qui passent.

Au niveau du pare-feu

Protection	Seuil	Ce que ça arrête
Nouvelles connexions par adresse (web)	200/s, rafale 60	Flood SYN sur 80/443
Nouvelles connexions par adresse (jeu)	60/s, rafale 20	Flood sur la plage 25566-25999
Connexions simultanées par adresse	300	Connexions lentes (slowloris)
Drapeaux TCP impossibles	—	Scans NULL, FIN, XMAS de nmap
Paquets d'état invalide	—	Paquets hors session
Ping	5/s	Flood ICMP

Le web n'était pas protégé avant la 2.34

Le limiteur ne portait que sur la plage de ports de jeu. Autrement dit 80 et 443 — les deux ports qui reçoivent réellement du trafic — n'avaient aucune protection de niveau 4 : un flood passait entièrement, et seul le bouclier applicatif le voyait, c'est-à-dire trop tard.

Les seuils du web sont volontairement plus larges que ceux du jeu : un navigateur ouvre facilement une trentaine de connexions pour une seule page, et un réseau d'entreprise multiplie ça par ses postes. Brider au même niveau couperait des visiteurs normaux.

Au niveau du noyau

Écrits dans /etc/sysctl.d/99-ecloud-ddos.conf, donc conservés au redémarrage — sans fichier, un node se retrouverait nu juste après l'incident qui l'a fait redémarrer.

SYN cookies — le plus important de la liste. Sous flood, le noyau répond sans réserver d'entrée dans la file d'attente. Sans eux, la file sature et le serveur refuse les connexions légitimes : l'attaque réussit alors même que le pare-feu jette l'essentiel du trafic ;
file d'attente et table d'état agrandies, entrées mortes évacuées plus tôt ;
filtrage par chemin de retour — jette les paquets dont l'adresse source est usurpée ;
redirections ICMP, routage par la source et ping diffusé désactivés (ce dernier est l'amplificateur « smurf »).

Force brute#

fail2ban est installé et configuré par l'agent. Cinq prisons sont actives par défaut : SSH, authentification nginx, robots, dépassements de débit, et recidive.

La récidive est la seule qui traite le vrai problème

Les autres prisons voient des tentatives isolées et bannissent une heure. Un attaquant patient revient simplement à l'expiration, indéfiniment. recidive, elle, surveille le journal de fail2ban lui-même : trois bannissements en vingt-quatre heures, et l'adresse est écartée une semaine.

S'y ajoute le bannissement à durée croissante : chaque récidive double la durée précédente, jusqu'à une semaine. C'est ce qui fait passer d'une attaque ralentie à une attaque non rentable. Le plafond d'une semaine n'est pas de la timidité — au-delà, on finit par bannir une adresse recyclée par un opérateur mobile, donc quelqu'un qui n'a rien fait.

En parallèle, l'agent applique sa propre détection à partir des journaux nginx : une adresse qui accumule les 400/403/404 ou le volume brut est écartée au niveau du pare-feu, sans dépendre de fail2ban.

Ports fermés#

Une liste de ports est fermée à l'internet même en mode « tout ouvert »— c'est justement le mode où tout le reste répond.

text

21   FTP           mots de passe en clair
23   Telnet        idem
69   TFTP
111  rpcbind       porte des vers Unix
135  137-139  445  RPC / NetBIOS / SMB
512-514           rexec / rlogin / rsh
873  rsync         en démon
1433 1521          SQL Server, Oracle
2049 NFS
3306 MySQL   5432 PostgreSQL   6379 Redis   27017 MongoDB
3389 RDP     5900 VNC
9200 9300  Elasticsearch
11211 memcached    amplificateur de DDoS

Aucun n'a de raison d'être servi publiquement par un serveur d'hébergement. Un port explicitement ouvert à quelques adresses (une base jointe par un pool applicatif, par exemple) reste accessible : l'autorisation est évaluée avant la fermeture.

SSH#

Le port 22 n'est plus ouvert à l'internet. Il n'accepte que les adresses déclarées dans Administration → Pare-feu → Accès SSH, plus les réseaux privés, ajoutés d'office.

À faire avant la mise à jour de l'agent

Si tu te connectes en SSH depuis chez toi, ajoute ton adresse dans cet écran avant que le node n'applique la nouvelle configuration. L'écran propose « Autoriser mon adresse » en un clic. Sans ça, il te restera la console de ton hébergeur — le node continuera de fonctionner, mais tu ne pourras plus y entrer par SSH.

Les réseaux privés (10/8, 172.16/12, 192.168/16) sont toujours ajoutés à la liste. C'est le filet : même avec une liste ne contenant qu'une adresse résidentielle périmée, une console d'hyperviseur ou un autre conteneur du même hôte garde une porte.

Le durcissement reste réversible : « Rouvrir à tous » remet le port 22 dans son état d'origine. Un réglage de sécurité qu'on ne peut pas défaire n'est pas un réglage.

Ce qui n'est jamais fermé#

80 et 443 restent ouverts sans condition, quelle que soit la politique. Ils servent le panel et le renouvellement des certificats : sans eux, plus rien ne se répare à distance. Une politique qui les fermerait ne dégraderait pas le service, elle rendrait la machine injoignable — et en silence, puisque les paquets sont jetés et non refusés : le node répond au ping et paraît vivant.

Les adresses déclarées comme exemptions du bouclier traversent tout, y compris les ports fermés. Voir Sécurité.