Configuration de Nginx pour les performances et la sécurité

Dans ce didacticiel, nous verrons comment configurer le serveur Web Nginx pour un environnement de production.


Un serveur Web dans un environnement de production est différent d’un serveur Web dans un environnement de test en termes de performances, de sécurité, etc..

Par défaut, il existe toujours un paramètre de configuration prêt à l’emploi pour un serveur Web Nginx une fois que vous l’avez installé avec succès. Cependant, la configuration par défaut n’est pas assez bonne pour un environnement de production. Par conséquent, nous nous concentrerons sur la façon de configurer Nginx pour qu’il fonctionne mieux pendant les pics de trafic lourds et normaux, et comment le protéger des utilisateurs qui ont l’intention d’en abuser.

Si vous n’avez pas installé Nginx sur votre machine, vous pouvez vérifier comment le faire ici. Il vous montre comment installer Nginx sur une plate-forme Unix. Choisissez d’installer Nginx via les fichiers source car les Nginx pré-construits ne sont pas fournis avec certains des modules utilisés dans ce tutoriel.

Exigences

Vous devez avoir les éléments suivants installés sur votre machine et assurez-vous d’exécuter ce tutoriel sur n’importe quelle plate-forme basée sur Debian telle que Ubuntu.

  • Ubuntu ou toute autre plate-forme basée sur Debian
  • wget
  • Vim (éditeur de texte)

De plus, vous devez exécuter ou exécuter certaines commandes dans ce didacticiel en tant qu’utilisateur root via la commande sudo.

Comprendre la structure de configuration de Nginx

Dans cette section, nous examinerons les éléments suivants:

  • Structure de Nginx
  • Sections telles qu’un événement, HTTP et le courrier
  • Syntaxe valide de Nginx

À la fin de cette section, vous comprendrez la structure de la configuration Nginx, le but ou les rôles des sections ainsi que la façon de définir des directives valides à l’intérieur des sections.

Le fichier de configuration Nginx complet a une structure logique composée de directives regroupées en un certain nombre de sections telles que la section événement, la section http, la section courrier, etc..

Le fichier de configuration principal se trouve dans /etc/nginx/nginx.conf tandis que les autres fichiers de configuration se trouvent dans / etc / nginx.

Contexte principal

Cette section ou ce contexte contient des directives en dehors de sections spécifiques telles que la section courrier.

Toutes autres directives telles que l’utilisateur nginx; , Worker_processes 1; , Error_log /var/log/nginx/error.log warn; et pid /var/run/nginx.pid peut être placé dans la section principale ou le contexte.

Mais certaines de ces directives telles que les processus de travail peuvent également exister dans la section des événements.

Sections

Les sections de Nginx définissent la configuration des modules Nginx.

Par exemple, la section http définit la configuration du module ngx_http_core, la section event définit la configuration du ngx_event_module tandis que la section mail définit la configuration du ngx_mail_module.

Tu peux vérifier ici pour une liste complète des sections dans Nginx.

Directives

Les directives dans Nginx sont composées d’un nom de variable et d’un certain nombre d’arguments tels que les suivants:

Le worker_processes est un nom de variable tandis que l’auto sert d’argument.

worker_processes auto;

Les directives se terminent par un point-virgule comme indiqué ci-dessus.

Enfin, le fichier de configuration Nginx doit respecter un ensemble particulier de règles. Voici la syntaxe valide de la configuration Nginx:

  • Les directives valides commencent par un nom de variable puis sont suivies d’un ou de plusieurs arguments
  • Toutes les directives valides se terminent par un point-virgule;
  • Les sections sont définies avec des accolades {}
  • Une section peut être intégrée dans une autre section
  • La configuration en dehors de toute section fait partie de la configuration globale de Nginx.
  • Les lignes commençant par le signe de hachage # sont des commentaires.

Optimisation de Nginx pour les performances

Dans cette section, nous allons configurer Nginx pour qu’il fonctionne mieux en cas de trafic intense et de pics de trafic.

Nous verrons comment configurer:

  • Ouvriers
  • Activité d’E / S disque
  • Activité réseau
  • Tampons
  • Compression
  • Mise en cache
  • Temps libre

Pourtant, à l’intérieur de l’environnement virtuel activé, tapez les commandes suivantes pour passer au répertoire Nginx et répertorier son contenu.

cd nginx && ls

Recherchez le dossier conf. À l’intérieur de ce dossier se trouve le fichier nginx.conf.

Nous utiliserons ce fichier pour configurer Nginx

Exécutez maintenant les commandes suivantes pour accéder au dossier conf et ouvrez le fichier nginx.conf avec l’éditeur vim

cd conf
sudo vim nginx.conf

Ci-dessous, une capture d’écran de l’apparence par défaut du fichier nginx.conf.

Ouvriers

Pour permettre à Nginx de mieux fonctionner, nous devons configurer les travailleurs dans la section des événements. La configuration des travailleurs Nginx vous permet de traiter efficacement les connexions des clients.

En supposant que vous n’avez pas fermé l’éditeur vim, appuyez sur le bouton i du clavier pour modifier le fichier nginx.conf.

Copiez et collez les éléments suivants dans la section des événements, comme indiqué ci-dessous:

événements {
worker_processes auto;
travailleurs_connexions 1024;
worker_rlimit_nofile 20960;
multi_accept on;
mutex_accept on;
mutex_accept_delay 500ms;
utilisez epoll;
epoll_events 512;
}

worker_processes: cette directive contrôle le nombre de travailleurs dans Nginx. La valeur de cette directive est définie sur auto pour permettre à Nginx de déterminer le nombre de cœurs disponibles, les disques, la charge du serveur et le sous-système réseau. Cependant, vous pouvez découvrir le nombre de cœurs en exécutant la commande lscpu sur le terminal.

worker_connections: cette directive définit la valeur du nombre de connexions simultanées pouvant être ouvertes par un travailleur. La valeur par défaut est 512, mais nous l’avons définie sur 1 024 pour permettre à un travailleur d’accepter une connexion très simultanée d’un client.

worker_rlimit_nofile: Cette directive est en quelque sorte liée à worker_connections. Afin de gérer une grande connexion simultanée, nous la définissons sur une grande valeur.

multi_accept: cette directive permet à un travailleur d’accepter plusieurs connexions dans la file d’attente à la fois. Une file d’attente dans ce contexte signifie simplement une séquence d’objets de données en attente de traitement.

mutex_accept: cette directive est désactivée par défaut. Mais parce que nous avons configuré de nombreux travailleurs dans Nginx, nous devons l’activer comme indiqué dans le code ci-dessus pour permettre aux travailleurs d’accepter les nouvelles connexions une par une..

mutex_accept_delay: cette directive détermine le temps qu’un travailleur doit attendre avant d’accepter une nouvelle connexion. Une fois que accept_mutex est activé, un verrou mutex est attribué à un travailleur pour une période spécifiée par accept_mutex_delay. Lorsque le délai est écoulé, le prochain travailleur en ligne est prêt à accepter de nouvelles connexions.

use: Cette directive spécifie la méthode pour traiter une connexion à partir du client. Dans ce didacticiel, nous avons décidé de définir la valeur sur epoll car nous travaillons sur une plate-forme Ubuntu. La méthode epoll est la méthode de traitement la plus efficace pour les plateformes Linux.

epoll_events: La valeur de cette directive spécifie le nombre d’événements que Nginx transférera au noyau.

E / S disque

Dans cette section, nous allons configurer l’activité d’E / S asynchrone dans Nginx pour lui permettre d’effectuer un transfert de données efficace et d’améliorer l’efficacité du cache.

Les E / S disque se réfèrent simplement aux opérations d’écriture et de lecture entre le disque dur et la RAM. Nous utiliserons envoyer le fichier() fonction à l’intérieur du noyau pour envoyer de petits fichiers.

Vous pouvez utiliser la section http, la section location et la section server pour les directives dans ce domaine.

La section emplacement, la section serveur peut être intégrée ou placée dans la section http pour rendre la configuration lisible.

Copiez et collez le code suivant dans la section emplacement incorporée dans la section HTTP.

emplacement / pdf / {
sendfile on;
aio on;
}

emplacement / audio / {
directio 4m
directio_alignment 512
}

sendfile: pour utiliser les ressources du système d’exploitation, définissez la valeur de cette directive sur on. sendfile transfère les données entre les descripteurs de fichiers dans l’espace du noyau du système d’exploitation sans les envoyer aux tampons d’application. Cette directive sera utilisée pour servir de petits fichiers.

directio: cette directive améliore l’efficacité du cache en permettant d’envoyer en lecture et en écriture directement à l’application. directio est une fonctionnalité de système de fichiers de tous les systèmes d’exploitation modernes. Cette directive sera utilisée pour servir des fichiers plus volumineux comme des vidéos.

aio: cette directive active le multithread lorsqu’elle est activée pour les opérations d’écriture et de lecture. Le multi-threading est un modèle d’exécution qui permet à plusieurs threads de s’exécuter séparément les uns des autres tout en partageant leurs ressources de processus d’hébergement.

directio_alignment: cette directive attribue une valeur de taille de bloc au transfert de données. Elle concernait la directive directio.

Couche réseau

Dans cette section, nous utiliserons des directives telles que tcp_nodelay et tcp_nopush pour empêcher les petits paquets d’attendre un délai spécifié d’environ 200 millisecondes avant d’être envoyés simultanément.

Habituellement, lorsque les paquets sont transférés en «morceaux», ils ont tendance à saturer le réseau très chargé. John Nagle a donc construit un algorithme de mise en mémoire tampon pour résoudre ce problème. Le but de l’algorithme de mise en mémoire tampon de Nagle est d’empêcher les petits paquets de saturer le réseau très chargé.

Copiez et collez le code suivant dans la section HTTP.

http {

tcp_nopush on;
tcp_nodelay on;

}

tcp_nodelay: Cette directive, par défaut, est désactivée pour permettre aux petits paquets d’attendre une période spécifiée avant d’être envoyés simultanément. Pour autoriser l’envoi simultané de toutes les données, cette directive est activée.

tcp_nopush: Parce que nous avons activé la directive tcp_nodelay, de petits paquets sont envoyés à la fois. Cependant, si vous souhaitez toujours utiliser l’algorithme de mise en mémoire tampon de John Nagle, nous pouvons également permettre à tcp_nopush de s’ajouter des paquets et de les envoyer tous en même temps.

Tampons

Voyons comment configurer les tampons de demande dans Nginx pour gérer efficacement les demandes. Un tampon est un stockage temporaire où les données sont conservées pendant un certain temps et traitées.

Vous pouvez copier ce qui suit dans la section serveur.

serveur {

client_body_buffer_size 8k;
client_max_body_size 2m;
client_body_in_single_buffer on;
client_body_temp_pathtemp_files 1 2;
client_header_buffer_size 1m;
large_client_header_buffers 4 8k;

}

Il est important de comprendre ce que font ces lignes tampons.

client_body_buffer_size: cette directive définit la taille du tampon pour le corps de la demande. Si vous prévoyez d’exécuter le serveur Web sur des systèmes 64 bits, vous devez définir la valeur sur 16k. Si vous souhaitez exécuter le serveur Web sur le système 32 bits, définissez la valeur sur 8k.

client_max_body_size: Si vous avez l’intention de gérer des téléchargements de fichiers volumineux, vous devez définir cette directive sur au moins 2 m ou plus. Par défaut, il est réglé sur 1 m.

client_body_in_file_only: Si vous avez désactivé la directive client_body_buffer_size avec le symbole de hashtag # et que cette directive client_body_in_file_only est définie, Nginx enregistrera alors les tampons de demande dans un fichier temporaire. Ceci n’est pas recommandé pour un environnement de production.

client_body_in_single_buffer: Parfois, tout le corps de la demande n’est pas stocké dans un tampon. Le reste est enregistré ou écrit dans un fichier temporaire. Cependant, si vous avez l’intention d’enregistrer ou de stocker le tampon de demande complet dans un seul tampon, vous devez activer cette directive.

client_header_buffer_size: vous pouvez utiliser cette directive pour définir ou allouer un tampon pour les en-têtes de demande. Vous pouvez définir cette valeur sur 1 m.

large_client_header_buffers: Cette directive est utilisée pour définir le nombre et la taille maximum pour la lecture des en-têtes de requête volumineux. Vous pouvez définir le nombre maximal et la taille du tampon sur 4 et 8 Ko avec précision.

Compression

La compression de la quantité de données transférées sur le réseau est un autre moyen de garantir que votre serveur Web fonctionne mieux. Dans cette section, nous utiliserons des directives telles que gzip, gzip_comp_level et gzip_min_length pour compresser les données.

Collez le code suivant dans la section http comme indiqué ci-dessous:

http {

gzip on;
gzip_comp_level 2;
gzip_min_length 1000;
gzip_types text / xml text / css;
gzip_http_version 1.1;
gzip_vary on;
gzip_disable "MSIE [4-6] \.";

}

gzip: Si vous souhaitez activer la compression, définissez la valeur de cette directive sur on. Par défaut, c’est désactivé.

gzip_comp_level: Vous pouvez utiliser cette directive pour définir le niveau de compression. Afin de ne pas gaspiller les ressources CPU, vous n’avez pas besoin de définir un niveau de compression trop élevé. Entre 1 et 9, vous pouvez régler le niveau de compression sur 2 ou 3.

gzip_min_length: définissez la longueur de réponse minimale pour la compression via le champ d’en-tête de réponse de longueur de contenu. Vous pouvez le définir sur plus de 20 octets.

gzip_types: Cette directive vous permet de choisir le type de réponse que vous souhaitez compresser. Par défaut, le type de réponse text / html est toujours compressé. Vous pouvez ajouter un autre type de réponse tel que text / css comme indiqué dans le code ci-dessus.

gzip_http_version: Cette directive vous permet de choisir la version HTTP minimale d’une demande de réponse compressée. Vous pouvez utiliser la valeur par défaut qui est 1,1.

gzip_vary: lorsque la directive gzip est activée, cette directive ajoute le champ d’en-tête Vary: accepte l’encodage à la réponse.

gzip_disabled: certains navigateurs tels qu’Internet Explorer 6 ne prennent pas en charge la compression gzip. Cette directive utilise le champ d’en-tête de demande User-Agent pour désactiver la compression pour certains navigateurs.

Mise en cache

Tirez parti des fonctionnalités de mise en cache pour réduire le nombre de fois où les mêmes données doivent être chargées plusieurs fois. Nginx fournit des fonctionnalités pour mettre en cache les métadonnées de contenu statique via la directive open_file_cache.

Vous pouvez placer cette directive à l’intérieur du serveur, de l’emplacement et de la section http.

http {

open_file_cache max = 1000 inactif = 30s;
open_file_cache_valid 30s;
open_file_cache_min_uses 4;
open_file_cache_errors sur;

}

open_file_cache: Cette directive est désactivée par défaut. Activez-le si vous souhaitez implémenter la mise en cache dans Nginx. Cette directive stocke les métadonnées des fichiers et répertoires couramment demandés par les utilisateurs.

open_file_cache_valid: Cette directive contient des informations de sauvegarde à l’intérieur de la directive open_file_cache. Vous pouvez utiliser cette directive pour définir une période valide généralement en secondes après laquelle les informations relatives aux fichiers et répertoires sont à nouveau validées.

open_file_cache_min_uses: Nginx efface généralement les informations à l’intérieur de la directive open_file_cache après une période d’inactivité basée sur open_file_cache_min_uses. Vous pouvez utiliser cette directive pour définir un nombre minimum d’accès pour identifier les fichiers et répertoires auxquels vous accédez activement..

open_file_cache_errors: vous pouvez utiliser cette directive pour autoriser Nginx à mettre en cache des erreurs telles que “autorisation refusée” ou “ne peut pas accéder à ce fichier” lors de l’accès aux fichiers. Ainsi, chaque fois qu’une ressource est accédée par un utilisateur qui n’a pas le droit de le faire, Nginx affiche le même rapport d’erreur «permission refusée».

Temps libre

Configurer le délai d’expiration à l’aide de directives telles que keepalive_timeout et keepalive_requests pour éviter que les connexions à longue attente ne gaspillent les ressources.

Dans la section HTTP, copiez et collez le code suivant:

http {

keepalive_timeout 30s;
keepalive_requests 30;
send_timeout 30s;

}

keepalive_timeout: maintient les connexions actives pendant environ 30 secondes. La valeur par défaut est 75 secondes.

keepalive_requests: configurez un certain nombre de demandes pour qu’elles restent actives pendant une période de temps spécifique. Vous pouvez définir le nombre de demandes à 20 ou 30.

keepalive_disable: si vous souhaitez désactiver la connexion keepalive pour un groupe spécifique de navigateurs, utilisez cette directive.

send_timeout: définir un délai d’expiration pour la transmission de données au client.

Configuration de la sécurité pour Nginx

Les éléments suivants se concentrent uniquement sur la façon de configurer en toute sécurité un Nginx au lieu d’une application Web. Ainsi, nous ne regarderons pas les attaques basées sur le Web comme l’injection SQL, etc..

Dans cette section, nous verrons comment configurer les éléments suivants:

  • Restreindre l’accès aux fichiers et répertoires
  • Configurer les journaux pour surveiller les activités malveillantes
  • Empêcher les DDoS
  • Désactiver la liste des répertoires

Restreindre l’accès aux fichiers et répertoires

Voyons comment restreindre l’accès aux fichiers et répertoires sensibles via les méthodes suivantes.

En utilisant l’authentification HTTP

Nous pouvons restreindre l’accès aux fichiers sensibles ou aux zones non destinées à un affichage public en demandant une authentification des utilisateurs ou même des administrateurs. Exécutez la commande suivante pour installer un utilitaire de création de fichier de mot de passe si vous ne l’avez pas installé.

apt-get install -y apache-utils

Ensuite, créez un fichier de mot de passe et un utilisateur à l’aide de l’outil htpasswd comme indiqué ci-dessous. L’outil htpasswd est fourni par l’utilitaire apache2-utils.

sudo htpasswd -c / etc / apache2 / .htpasswd micro

Vous pouvez confirmer si vous avez réussi à créer un utilisateur et un mot de passe aléatoire via la commande suivante

chat etc / apache2 / .htpasswd

Dans la section emplacement, vous pouvez coller le code suivant pour inviter les utilisateurs à s’authentifier à l’aide de la directive auth_basic.

location / admin {

basic_auth "Zone d’administration";
fichier_utilisateur_auth_basic / etc / apache2 / .htpasswd;

}

En utilisant la directive Allow

En plus de la directive basic_auth, nous pouvons utiliser la directive allow pour restreindre l’accès.

Dans la section emplacement, vous pouvez utiliser le code suivant pour autoriser les adresses IP spécifiées à accéder à la zone sensible.

location / admin {
autoriser 192.168.34.12;
autoriser 192.168.12.34;
}

Configurer les journaux pour surveiller les activités malveillantes

Dans cette section, nous allons configurer les journaux d’erreurs et d’accès pour surveiller spécifiquement les demandes valides et non valides. Vous pouvez examiner ces journaux pour savoir qui s’est connecté à un moment donné, ou quel utilisateur a accédé à un fichier particulier, etc..

error_log: permet de configurer la journalisation dans un fichier particulier tel que syslog ou stderr. Vous pouvez également spécifier le niveau des messages d’erreur que vous souhaitez enregistrer.

access_log: permet d’écrire la demande des utilisateurs dans le fichier access.log

Dans la section HTTP, vous pouvez utiliser les éléments suivants.

http {

access_log logs / access.log combinés;
error_log logs / warn.log warn;

}

Empêcher DDOS

Vous pouvez protéger le Nginx contre une attaque DDOS par les méthodes suivantes:

Limiter les demandes des utilisateurs 

Vous pouvez utiliser les directives limit_req_zone et limit_req pour limiter le taux d’une demande envoyée par les utilisateurs en quelques minutes.

Ajoutez le code suivant dans la section emplacement incorporée dans la section serveur.

limit_req_zone $ binary_remote_addr zone = one: 10m rate = 30r / m;

serveur {
emplacement /admin.html {
zone limit_req = un;
}

}

Limitez le nombre de connexions 

Vous pouvez utiliser les directives limit_conn et limit_conn_zone pour limiter la connexion à certains emplacements ou zones. Par exemple, le code ci-dessous reçoit 15 connexions de clients pour une période spécifique.

Le code suivant ira à la section emplacement.

limit_conn_zone $ binary_remote_addr zone = addr: 10m;

serveur {

emplacement / produits / {
limit_conn addr 10;

}
}

Mettre fin aux connexions lentes   

Vous pouvez utiliser des directives de temporisation telles que client_body_timeout et client_header_timeout pour contrôler la durée pendant laquelle Nginx attendra les écritures du corps du client et de l’en-tête du client.

Ajoutez ce qui suit dans la section serveur.

serveur {
client_body_timeout 5s;
client_header_timeout 5s;
}

Ce serait également une bonne idée d’arrêter les attaques DDoS en périphérie en tirant parti des solutions basées sur le cloud, comme mentionné ici.

Désactiver la liste des répertoires

Vous pouvez utiliser la directive auto_index pour empêcher la liste des répertoires comme indiqué dans le code ci-dessous. Vous devez le régler sur la valeur off pour désactiver la liste des répertoires.

emplacement / {
auto_index off;
}

Conclusion

Nous avons configuré le serveur Web Nginx pour qu’il fonctionne efficacement et le protège contre les abus excessifs dans un environnement de production. Si vous utilisez Nginx pour des applications Web accessibles sur Internet, vous devriez également envisager d’utiliser un CDN et une sécurité basée sur le cloud pour de meilleures performances et sécurité.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map