Attaques sur la machine : ce que nous faisons et ce que vous pouvez faire

Le mot « attaque » désigne deux situations totalement différentes : lorsque votre canal est saturé de trafic indésirable et lorsqu'une quelques centaines de requêtes par seconde font tomber votre application. Elles se traitent différemment, et la première chose à faire est de déterminer à laquelle vous êtes confronté.

Distinguer l'une de l'autre

Consultez les graphiques du processeur, de la mémoire et du trafic dans « Aperçu » à l'adresse /hosting/vds/m/<id> pour les dernières 24 heures. Si le trafic est normal mais que le processeur est à son maximum, il s'agit d'une charge applicative, et c'est de votre côté qu'il faut la traiter.

Ce que vous pouvez faire

Limiter le débit des requêtes dans nginx :

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

server {
    limit_req zone=perip burst=20 nodelay;
    limit_conn conn 20;
    client_body_timeout 10s;
    client_header_timeout 10s;
}

Limiter les connexions dans le pare-feu :

ufw limit 22/tcp

Des règles plus souples figurent dans l'article nftables : vous pouvez y limiter également le débit des nouvelles connexions et tenir une liste d'adresses bloquées avec une durée de vie.

Identifier la source dans les journaux :

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

Bloquer une adresse ou un réseau une fois pour toutes :

ufw deny from 203.0.113.0/24

fail2ban peut automatiser le blocage à partir des journaux.

Ce que nous faisons

Notre infrastructure filtre le trafic indésirable en amont vers le nœud — avant qu'il ne consomme votre bande passante. Cela fonctionne contre les attaques volumétriques sur le canal et ne demande aucune configuration de votre part.

Ce que la protection au niveau du nœud ne fait pas : elle n'analyse pas la logique de votre application. Les requêtes qui semblent normales de l'extérieur atteignent votre machine, et seule votre propre configuration vous en protège.

Si votre machine devient la source d'une attaque — par exemple, si elle a été compromise et participe à une campagne de spam menée par un tiers — l'accès sera restreint conformément à la politique d'utilisation acceptable. Vérifiez votre machine à l'aune des signes de compromission.

Mise en cache et fichiers statiques

La technique la plus efficace contre un afflux de requêtes consiste à ne pas calculer deux fois la même chose :

location /static/ {
    expires 30d;
    add_header Cache-Control "public";
}

Mettez en cache les pages lourdes côté application. Une requête servie depuis le cache coûte des centaines de fois moins cher.

Erreurs courantes

• Définir limit_req sans burst — les utilisateurs ordinaires dont la page charge deux douzaines de fichiers se font couper.
• Bloquer les adresses une par une à la main pendant une attaque distribuée : il y en a des milliers, et vous ne tiendrez pas le rythme.
• Bloquer entièrement ICMP — cela casse la négociation de la taille des paquets, voir MTU.
• Confondre votre propre bug avec une attaque : une boucle dans le code, un robot d'indexation qui parcourt un répertoire que vous avez oublié d'exclure, des tentatives sans fin côté client.

Définissez vos limites à l'avance, sur une machine au repos. Pendant un afflux de requêtes, vous ne pourrez pas ajuster les valeurs rate et burst : vous modifierez la configuration à l'aveugle et par petits bouts.