Recherche de site Web

Le guide ultime pour sécuriser, renforcer et améliorer les performances du serveur Web Nginx

Sur la base des choses merveilleuses que vous avez entendues sur Nginx, vous avez peut-être décidé de l'essayer. Vous l'avez peut-être tellement aimé que vous envisagez de remplacer vos installations Apache par Nginx après avoir parcouru certains des articles sur le sujet que nous avons publiés sur ce site.

Si tel est le cas, je suis sûr que vous accueillerez ce guide à bras ouverts puisque nous allons aborder 12 conseils pour augmenter la sécurité de vos serveurs Nginx (allant de la mise à jour de Nginx jusqu'à en utilisant TLS et en redirigeant HTTP vers HTTPS), et vous remarquerez que certains d'entre eux sont très similaires à ce que vous feriez avec Apache.

Ne manquez pas :

13 Conseils de sécurité et de renforcement du serveur Web Apache

25 astuces Apache Htaccess pour sécuriser le serveur Web Apache

Environnement de test Nginx

Nous utiliserons l’environnement suivant dans ce guide :

  1. Debian GNU/Linux 8.1 (jessie).

  2. Adresse IP : 192.168.0.25 (tecmintlovesnginx.com) et 192.168.0.26 (nginxmeanspower.com), comme décrit dans le document virtuel basé sur IP. section des hôtes sur

    1. "Comment configurer des hôtes virtuels basés sur le nom et basés sur IP (blocs de serveur) avec Nginx"
  3. Version Nginx : nginx/1.6.2.
  4. Pour votre commodité, voici le fichier de configuration final (lien Pastebin).

En gardant cela à l’esprit, commençons.

CONSEIL N°1 : Gardez Nginx à jour

Au moment d'écrire ces lignes, les dernières versions de Nginx dans les référentiels CentOS (en EPEL) et Debian sont 1.6.3 et 1.6.2-5, respectivement.

Ne manquez pas : Installez la dernière version stable de Nginx à partir des référentiels et de la source

Bien qu'installer un logiciel à partir des référentiels soit plus facile que compiler le programme à partir du code source, cette dernière option présente deux avantages : 1) elle vous permet de créer des modules supplémentaires dans Nginx (comme mod_security), et 2) elle fournira toujours une version plus récente. que les référentiels (1.9.9 à ce jour). Les notes de version sont toujours disponibles sur le site Web de Nginx.

Ne manquez pas :

Protégez Apache contre les attaques par force brute et DDoS à l'aide de Mod_Security et Mod_Evasive

CONSEIL N°2 : Supprimez les modules inutiles dans Nginx

Pour supprimer explicitement des modules de Nginx lors de l'installation à partir des sources, procédez :

./configure --without-module1 --without-module2 --without-module3

Par exemple:

./configure  --without-http_dav_module --withouthttp_spdy_module

Comme vous l'aurez probablement deviné, supprimer des modules d'une installation précédente de Nginx à partir des sources nécessite de refaire la compilation.

Un mot d'avertissement : les directives de configuration sont fournies par les modules. Assurez-vous de ne pas désactiver un module contenant une directive dont vous aurez besoin plus tard ! Vous devriez consulter la documentation nginx pour la liste des directives disponibles dans chaque module avant de prendre une décision sur la désactivation des modules.

CONSEIL N°3 : Désactivez la directive server_tokens dans Nginx

La directive server_tokens indique à Nginx d'afficher sa version actuelle sur les pages d'erreur. Cela n'est pas souhaitable puisque vous ne souhaitez pas partager ces informations avec le monde afin d'empêcher les attaques sur votre serveur Web causées par des vulnérabilités connues dans cette version spécifique.

Pour désactiver la directive server_tokens, définissez if sur off dans un bloc serveur :

server {
    listen       192.168.0.25:80;
    server_tokens        off;
    server_name  tecmintlovesnginx.com www.tecmintlovesnginx.com;
    access_log  /var/www/logs/tecmintlovesnginx.access.log;
    error_log  /var/www/logs/tecmintlovesnginx.error.log error;
        root   /var/www/tecmintlovesnginx.com/public_html;
        index  index.html index.htm;
}

Redémarrez nginx et vérifiez les modifications :

CONSEIL N°4 : Refuser les agents utilisateurs HTTP dans Nginx

Un agent utilisateur HTTP est un logiciel utilisé pour la négociation de contenu avec un serveur Web. Cela inclut également les robots malveillants et les robots d’exploration qui peuvent finir par avoir un impact sur les performances de votre serveur Web en gaspillant les ressources système.

Afin de maintenir plus facilement la liste des agents utilisateurs indésirables, créez un fichier (/etc/nginx/blockuseragents.rules par exemple) avec le contenu suivant :

map $http_user_agent $blockedagent {
        default         0;
        ~*malicious     1;
        ~*bot           1;
        ~*backdoor      1;
        ~*crawler       1;
        ~*bandit        1;
}

Ensuite, placez la ligne suivante avant la définition du bloc serveur :

include /etc/nginx/blockuseragents.rules;

Et une instruction if pour renvoyer une réponse 403 si la chaîne de l'agent utilisateur est dans la liste noire définie ci-dessus :

Redémarrez nginx et tous les agents utilisateurs dont la chaîne correspond à ce qui précède ne pourront pas accéder à votre serveur Web. Remplacez 192.168.0.25 par l'adresse IP de votre serveur et n'hésitez pas à choisir une chaîne différente pour le commutateur --user-agent de wget :

wget http://192.168.0.25/index.html
wget --user-agent "I am a bandit haha" http://192.168.0.25/index.html

CONSEIL N°5 : Désactivez les méthodes HTTP indésirables dans Nginx

Également connues sous le nom de verbes, les méthodes HTTP indiquent l'action souhaitée à entreprendre sur une ressource servie par Nginx. Pour les sites Web et les applications courants, vous devez uniquement autoriser GET, POST et HEAD et désactiver tous les autres.

Pour ce faire, placez les lignes suivantes à l’intérieur d’un bloc serveur. Une réponse HTTP 444 signifie une réponse vide et est souvent utilisée dans Nginx pour tromper les attaques de logiciels malveillants :

if ($request_method !~ ^(GET|HEAD|POST)$) {
   return 444;
}

Pour tester, utilisez curl pour envoyer une requête DELETE et comparez le résultat à celui obtenu lorsque vous envoyez un GET :

curl -X DELETE http://192.168.0.25/index.html
curl -X POST http://192.168.0.25/index.html

CONSEIL N°6 : Définir les limites de taille du tampon dans Nginx

Pour empêcher les attaques par débordement de tampon contre votre serveur Web Nginx, définissez les directives suivantes dans un fichier séparé (créez un nouveau fichier nommé /etc/nginx/conf.d/buffer.conf, par exemple) :

client_body_buffer_size  1k;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 1k;

Les directives ci-dessus garantiront que les requêtes adressées à votre serveur Web ne provoqueront pas de débordement de tampon dans votre système. Encore une fois, reportez-vous à la documentation pour plus de détails sur ce que chacun d'eux fait.

Ajoutez ensuite une directive include dans le fichier de configuration :

include /etc/nginx/conf.d/*.conf;

CONSEIL N°7 : Limiter le nombre de connexions par IP dans Nginx

Afin de limiter les connexions par IP, utilisez les directives limit_conn_zone (dans un contexte http ou au moins en dehors du bloc serveur) et limit_conn (dans un contexte http, bloc serveur ou localisation).

Cependant, gardez à l’esprit que toutes les connexions ne sont pas comptées – mais seulement celles pour lesquelles une requête a été traitée par le serveur et dont l’intégralité de l’en-tête de requête a été lue.

Par exemple, fixons le nombre maximum de connexions à 1 (oui, c'est une exagération, mais cela fera très bien l'affaire dans ce cas) dans une zone nommée addr (vous pouvez définir ceci sur n'importe quelle valeur nom que vous souhaitez) :

limit_conn_zone $binary_remote_addr zone=addr:5m;
limit_conn addr 1;

Un simple test avec Apache Benchmark (Perform Nginx Load) où 10 connexions au total sont établies avec 2 requêtes simultanées nous aidera à démontrer notre point :

ab -n 10 -c 2 http://192.168.0.25/index.html

Voir le conseil suivant pour plus de détails.

CONSEIL N°8 : Configurer les journaux de surveillance pour Nginx

Une fois que vous avez effectué le test décrit dans le conseil précédent, vérifiez le journal des erreurs défini pour le bloc serveur :

Vous souhaiterez peut-être utiliser grep pour filtrer les journaux pour les demandes ayant échoué adressées à la zone addr définie dans le CONSEIL n°7 :

grep addr /var/www/logs/tecmintlovesnginx.error.log --color=auto

De même, vous pouvez filtrer le journal d'accès pour les informations qui vous intéressent, telles que :

  1. IP du client
  2. Type de navigateur
  3. Type de requête HTTP
  4. Ressource demandée
  5. Blocage du serveur répondant à la requête (utile si plusieurs hôtes virtuels se connectent au même fichier).

Et prenez les mesures appropriées si vous détectez une activité inhabituelle ou indésirable.

CONSEIL N°9 : Empêcher le hotlinking d'images dans Nginx

Le hotlinking d’images se produit lorsqu’une personne affiche sur un autre site une image hébergée sur le vôtre. Cela entraîne une augmentation de votre utilisation de la bande passante (pour laquelle vous payez) tandis que l'autre personne affiche joyeusement l'image comme si elle lui appartenait. Autrement dit, c’est une double perte pour vous.

Par exemple, disons que vous avez un sous-répertoire nommé img dans votre bloc serveur où vous stockez toutes les images utilisées dans cet hôte virtuel. Pour empêcher d'autres sites d'utiliser vos images, vous devrez insérer le bloc d'emplacement suivant dans la définition de votre hôte virtuel :

location /img/ {
  valid_referers none blocked 192.168.0.25;
   if ($invalid_referer) {
     return   403;
   }
}

Modifiez ensuite le fichier index.html dans chaque hôte virtuel comme suit :






192.168.0.26


192.168.0.25





<!DOCTYPE html>

<html>

<head>

<meta charset=”utf-8″>

<title>Nginx means power</title>

</head>

<body>

<h1>Nginx means power!</h1>

<img src=”http://192.168.0.25/img/nginx.png” />

</body>

</html>		
<!DOCTYPE html>

<html>

<head>

<meta charset=”utf-8″>

<title>Tecmint loves Nginx</title>

</head>

<body>

<h1>Tecmint loves Nginx!</h1>

<img src=”img/nginx.png” />

</body>

</html>

Parcourez maintenant chaque site et comme vous pouvez le constater, l'image s'affiche correctement dans 192.168.0.25 mais est remplacée par une réponse 403 dans 192.168.0.26. fort> :

Notez que cette astuce dépend du navigateur distant qui envoie le champ Referer.

CONSEIL N°10 : Désactivez SSL et activez uniquement TLS dans Nginx

Dans la mesure du possible, faites tout ce qui est en votre pouvoir pour éviter SSL dans l'une de ses versions et utilisez plutôt TLS. Les ssl_protocols suivants doivent être placés dans un contexte de serveur ou http dans votre fichier d'hôte virtuel ou constituent un fichier séparé via une directive d'inclusion (certaines personnes utilisent un fichier nommé ssl.conf , mais c'est entièrement à vous de décider) :

ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;

Par exemple:

CONSEIL N°11 : Créez des certificats dans Nginx

Tout d’abord, générez une clé et un certificat. N'hésitez pas à utiliser un autre type de cryptage si vous le souhaitez :

openssl genrsa -aes256 -out tecmintlovesnginx.key 1024
openssl req -new -key tecmintlovesnginx.key -out tecmintlovesnginx.csr
cp tecmintlovesnginx.key tecmintlovesnginx.key.org
openssl rsa -in tecmintlovesnginx.key.org -out tecmintlovesnginx.key
openssl x509 -req -days 365 -in tecmintlovesnginx.csr -signkey tecmintlovesnginx.key -out tecmintlovesnginx.crt

Ajoutez ensuite les lignes suivantes dans un bloc serveur séparé en préparation pour le prochain conseil (redirection http --> https) et déplacez également les directives liées à SSL vers le nouveau bloc :

server {
    listen 192.168.0.25:443 ssl;
    server_tokens off;
    server_name  tecmintlovesnginx.com www.tecmintlovesnginx.com;
    root   /var/www/tecmintlovesnginx.com/public_html;
    ssl_certificate /etc/nginx/sites-enabled/certs/tecmintlovesnginx.crt;
    ssl_certificate_key /etc/nginx/sites-enabled/certs/tecmintlovesnginx.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
}

Dans le prochain conseil, nous vérifierons comment notre site utilise désormais un certificat auto-signé et TLS.

CONSEIL N°12 : Rediriger le trafic HTTP vers HTTPS dans Nginx

Ajoutez la ligne suivante au premier bloc serveur :

return 301 https://$server_name$request_uri;

La directive ci-dessus renverra une réponse 301 (Déplacée de façon permanente), qui est utilisée pour la redirection d'URL permanente chaque fois qu'une demande est faite vers le port 80 de votre hôte virtuel, et redirigera la demande vers le serveur bloqué que nous ajouté dans le conseil précédent.

L'image ci-dessous montre la redirection et confirme le fait que nous utilisons TLS 1.2 et AES-256 pour le chiffrement :

Résumé

Dans cet article, nous avons partagé quelques conseils pour sécuriser votre serveur Web Nginx. Nous serions ravis de connaître votre avis et, si vous avez d'autres conseils que vous aimeriez partager avec le reste de la communauté, n'hésitez pas à nous le faire savoir en nous envoyant une note en utilisant le formulaire de commentaires ci-dessous.