Utiliser le code 444 avec nginx

Si tu héberges tes sites et applications web sur un serveur dédié sous nginx et que comme moi, tu en as marre qu'il se fasse manger des ressources par des scripts kiddies et des scanners réseaux à la noix, j'ai un truc pour toi : le code 444 !

Le contexte

Comme tu le sais probablement déjà, lorqu'on expose un truc sur internet, il ne faut pas attendre longtemps avant que des bots ou des idiots tombent sur ta plage d'adresse IP et se mettent à tout scanner pour trouver une faille à exploiter.

On ne va pas parler ici de sécurité mais plutôt de performance. Il y a d'autres outils dédiés de pour faire la sécu.

Cela étant dit, chaque fois qu'un serveur reçoit une requête, il doit l'interpréter, traiter la demande, éventuellement faire de la redirection et réécriture d'URL, chercher les fichiers sur le disque et faire une réponse en bonne et due forme. Tout ceci à pour conséquence de consommer des ressources en CPU, RAM, et temps d'acces disque. Ce n'est pas un problème quand ce sont des visiteuses et visiteurs amicaux mais c'est franchement inutile lorqu'il s'agit d'un blaireau qui cherche à nuire à ta machine.

La méthode

On va simplement configurer nginx pour couper avec dedain toutes les connexions entrantes qui ne sont pas à destination d'un nom de domaine déclaré (ex : https://site-qui-rox.net/). Ca parait basique, mais ca permet de ne pas traiter une proportion assez élevée de requêtes inutiles.

Chose importante, on va partir du principe que personne n'a besoin de venir se connecter sur ton site web via son ip (ex : https://10.10.0.8/). Ceux qui font ça ne méritent pas de lire le contenu de ton site de toute façon.

Précision quand même : si tu veux pouvoir acceder à ton site malgré tout par son IP (sur un LAN sans DNS par exemple), tu peux toujours utiliser ton fichier hosts pour déclarer un nom local.

Configuration de Nginx

Sous debian, il suffit de créer (ou de remplacer) le fichier /etc/nginx/sites-enabled/default.conf et de le configurer comme ceci :

server {
  # On écoute sur les ports HTTP et HTTPS
  # default_server permet d'aspirer les requetes vers des server_name non déclarés
  listen 80 default_server; ## ecoute en ipv4, port 80
  listen [::]:80 default_server; ## ecoute en ipv6, port 80
  listen 443 default_server; ## ecoute en ipv4, port 443 sans ssl
  listen [::]:443 default_server; ## ecoute en ipv6, port 443 sans ssl

  # Rejet des connexions SSL. On n'est pas pas pour servir un café !
  # Ce paramètre est impératif pour pouvoir traiter le port 443
  # dans le même bloc "serveur" que le port 80.
  ssl_reject_handshake on;

  server_name "";
  # Les petits fichiers de logs qui permettent de voir tout ce qui est drop
  access_log /var/log/nginx/default-access.log;
  error_log /var/log/nginx/default-error.log error;

  # Le mot magique. 
  # return 444 indique à nginx de couper la connexion TCP
  # sans autre forme de procès
  return 444;
}

Je donne ci dessous un exemple de config d'un site qui serait accessible via l'adresse https://sitequirox.net et hébergé sur le même serveur :

# Ce bloc sert à rediriger le traffic http vers https
server {
  listen   80;
  listen   [::]:80;

  server_name sitequirox.net;

  access_log /var/log/nginx/sitequirox-access.log;
  error_log /var/log/nginx/sitequirox-error.log error;

  return 301 https://$host$request_uri;
}

# bloc HTTPS
server {
  listen  443 ssl; 
  listen [::]:443 ssl;
	
  server_name sitequirox.net;
  
  access_log /var/log/nginx/sitequirox-access.log;
  error_log /var/log/nginx/sitequirox-error.log error;

  ssl_certificate /etc/letsencrypt/live/sitequirox.net/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/sitequirox.net/privkey.pem;

  root /srv/www/sitequirox.net/;
  index index.html;

  location / {
    # First attempt to serve request as file, then
    # as directory, then fall back to displaying a 404.
    try_files $uri $uri/ =404;	
  }

}

Et n'oublie pas de recharger la conf de nginx après l'avoir modifié.

systemctl reload nginx

Conclusion

Cette méthode permet, de manière très simple, d'économiser les ressources du serveur en ne traitant pas les requêtes inutiles.

Le second avantage avec la configuration que j'ai donné est que tu pourras voir toutes les requêtes non légitimes dans un fichier de log dédié. La récupération des IP malveillantes provenant d'attaques non ciblées en devient simplifiée.