• Assurez la sécurité des applications de la bonne manière! Détectez, protégez, surveillez, accélérez et plus encore…
  • Dans ce tutoriel, nous verrons comment nous pouvons 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 suffisante 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 faire ici. Il vous montre comment installer Nginx sur une plate-forme Unix. Choisissez d'installer Nginx via les fichiers source car le Nginx pré-construit n'est pas fourni avec certains des modules utilisés dans ce didacticiel.

    Nos Exigences

    Vous devez installer les éléments suivants sur votre machine et vous assurer d'exécuter ce didacticiel sur n'importe quelle plate-forme basée sur Debian telle qu'Ubuntu.

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

    De plus, vous devez exécuter ou exécuter certaines commandes de ce didacticiel en tant qu'utilisateur root via le sudo commander.

    Understanding Nginx Config Structure

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

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

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

    Le fichier de configuration Nginx complet a une structure logique qui est composée de directives regroupées en un certain nombre de sections telles que le event section, http sectionmail section etc.

    Le fichier de configuration principal se trouve sur  /etc/nginx/nginx.conf  tandis que d'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 mail section.

    Toute autre directive telle que user  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 le worker_processes peut également exister dans le event section.

    sections

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

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

    Vous pouvez vérifier ici pour une liste complète des sections dans Nginx.

    Directives

    Les directives dans Nginx sont constitué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 le 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 adhérer à un ensemble particulier de règles. Voici la syntaxe valide de la configuration Nginx:

    • Les directives valides commencent par un nom de variable suivi d'un ou 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.

    Tuning Nginx for Performance

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

    Nous verrons comment configurer:

    • Ouvriers
    • Activité d'E / S disque
    • Activité de réseau
    • Buffers
    • Compression
    • La mise en cache
    • Temps mort

    Pourtant, dans 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. Dans ce dossier se trouve le nginx.conf fichier.

    Nous utiliserons ce fichier pour configurer Nginx

    Exécutez maintenant les commandes suivantes pour accéder au conf dossier et ouvrez le fichier nginx.conf des vim editor

    cd conf
    sudo vim nginx.conf

    Vous trouverez ci-dessous une capture d'écran de la façon dont nginx.conf le fichier ressemble par défaut.

    Ouvriers

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

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

    Copiez et collez ce qui suit dans le events section comme indiqué ci-dessous:

    events { 
        worker_processes    auto;
        worker_connections  1024;
        worker_rlimit_nofile 20960;
        multi_accept        on;  
        mutex_accept        on; 
        mutex_accept_delay  500ms; 
        use                 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 worker. La valeur par défaut est 512 mais nous l'avons mis à 1,024 pour permettre à un travailleur d'accepter une connexion beaucoup plus 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 valeur élevée.

    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 comme nous avons configuré de nombreux nœuds de calcul dans Nginx, nous devons l'activer comme indiqué dans le code ci-dessus pour permettre aux collaborateurs d'accepter les nouvelles connexions une par une.

    mutex_accept_delay:  Cette directive détermine combien de temps un travailleur doit attendre avant d'accepter une nouvelle connexion. Une fois la accept_mutex est activé, un verrou mutex est attribué à un travailleur pendant une période spécifiée par le 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 tutoriel, nous avons décidé de définir la valeur sur epoll parce que nous travaillons sur un Ubuntu Plate-forme. le epoll est la méthode de traitement la plus efficace pour les plates-formes Linux.

    epoll_events:  La valeur de cette directive spécifie le nombre d'événements que Nginx transférera vers le 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 de disque se réfèrent simplement aux opérations d'écriture et de lecture entre le disque dur et la RAM. Nous utiliserons <a href="https://linux.die.net/man/2/sendfile">sendfile(</a>) fonction à l'intérieur du noyau pour envoyer de petits fichiers.

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

    Le location section, server section peut être intégré ou placé dans le http section pour rendre la configuration lisible.

    Copiez et collez le code suivant dans la section d'emplacement intégrée dans la section HTTP.

    location /pdf/  {
       sendfile on; 
       aio      on; 
      }  
    
    location /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 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 l'envoi direct de lecture et d'écriture à l'application.  directio est une fonctionnalité de système de fichiers de chaque système d'exploitation moderne. Cette directive sera utilisée pour servir des fichiers plus volumineux comme des vidéos.

    aio:  Cette directive active le multi-threading lorsqu'elle est définie sur on 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. Il était lié à la directio  Directive.

    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 pendant un laps de temps spécifié d'environ 200 millisecondes avant d'être envoyés en même temps.

    Habituellement, lorsque les paquets sont transférés en «morceaux», ils ont tendance à saturer le réseau fortement chargé. Alors John Nagle a 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 fortement 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 pendant une période spécifiée avant d'être envoyés en même temps. Pour permettre à toutes les données d'être envoyées en même temps, cette directive est activée.

    tcp_nopush:   Parce que nous avons activé tcp_nodelay directive, les 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 activer le tcp_nopush pour ajouter des paquets les uns aux autres et les envoyer tous en même temps.

    Buffers

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

    Vous pouvez copier ce qui suit dans la section serveur.

    server { 
    
       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 de tampon.

    client_body_buffer_size:  Cette directive définit la taille de la mémoire tampon pour le corps de la requête. Si vous prévoyez d'exécuter le serveur Web sur des systèmes 64 bits, vous devez définir la valeur sur 16 Ko. 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 2m ou plus. Par défaut, il est défini sur 1m.

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

    client_body_in_single_buffer:  Parfois, tout le corps de la requête 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 requête 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 1m.

    large_client_header_buffers: Cette directive est utilisée pour définir le nombre et la taille maximum pour la lecture d'en-têtes de requête volumineux. Vous pouvez définir le nombre maximum et la taille de la mémoire tampon sur et 8k précisément.

    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_levelainsi que gzip_min_length pour compresser les données.

    Collez le code suivant dans le http section 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 du processeur, 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 or 3.

    gzip_min_length:  Définissez la longueur de réponse minimale pour la compression via le content-length response header field. 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 requête pour une réponse compressée. Vous pouvez utiliser la valeur par défaut qui est 1.1.

    gzip_vary:  Quand gzip directive est activée, cette directive ajoute le champ d'en-tête Vary:Accept Encoding  à la réponse.

    gzip_disabled:  Certains navigateurs tels que Internet Explorer 6 je n'ai pas de support pour gzip compression. Cette directive utilise User-Agent champ d'en-tête de demande pour désactiver la compression pour certains navigateurs.

    La mise en cache

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

    Vous pouvez placer cette directive dans le server, location et http .

    http {  
    
    open_file_cache max=1,000 inactive=30s; 
    open_file_cache_valid 30s; 
    open_file_cache_min_uses 4; 
    open_file_cache_errors on; 
    
     }

    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 dans le open_file_cache directif. Vous pouvez utiliser cette directive pour définir une période de validité 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 du open_file_cache directive après une période d'inactivité basée sur la open_file_cache_min_uses. Vous pouvez utiliser cette directive pour définir un nombre minimum d'accès afin d'identifier les fichiers et répertoires auxquels l'accès est actif.

    open_file_cache_errors:  Vous pouvez utiliser cette directive pour permettre à Nginx de mettre en cache des erreurs telles que «permission refusée» ou «impossible d'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 mort

    Configurez le délai d'expiration à l'aide de directives telles que keepalive_timeout et keepalive_requests pour éviter que les connexions en attente ne gaspillent des ressources.

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

    http {  
    
     keepalive_timeout  30s; 
     keepalive_requests 30;
     send_timeout      30s;
    
    }

    keepalive_timeout: Gardez les connexions actives pendant environ 30 secondes. La valeur par défaut est de 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 sur 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éfinissez un délai d'expiration pour la transmission des données au client.

    Security Configuration for Nginx

    Ce qui suit se concentre uniquement sur la façon de configurer en toute sécurité un Nginx au lieu d'une application Web. Ainsi, nous ne nous intéresserons pas aux attaques Web comme SQL injection 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 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 au public en demandant l'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 mots de passe et un utilisateur à l'aide du htpasswd outil comme indiqué ci-dessous. le htpasswd l'outil est fourni par le apache2-utils utilitaire.

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

    Vous pouvez confirmer si vous avez créé avec succès un utilisateur et un mot de passe aléatoire via la commande suivante

    cat  etc/apache2/ .htpasswd

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

    location /admin {  
    
     basic_auth "Admin Area"; 
     auth_basic_user_file /etc/apache2/ .htpasswd; 
    
    }

    En utilisant la directive Allow

    En plus de la basic_auth directive, nous pouvons utiliser la allow directive 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 {  
     allow 192.168.34.12; 
     allow 192.168.12.34; 
    }

    Configurer les journaux pour surveiller les activités malveillantes

    Dans cette section, nous allons configurer error et access journaux 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: Vous permet de configurer la journalisation dans un fichier particulier tel que syslog or stderr. Vous pouvez également spécifier le niveau des messages d'erreur que vous souhaitez consigner.

    access_log:  Permet d'écrire la demande des utilisateurs dans le fichier access.log

    Dans la section HTTP, vous pouvez utiliser ce qui suit.

    http {  
    
      access_log  logs/access.log   combined; 
      error_log   logs/warn.log     warn;
    
    }

    Empêcher DDOS

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

    Limiter les demandes des utilisateurs 

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

    Ajoutez le code suivant dans le location section intégrée dans la section serveur.

    limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;  
    
    server {
     location /admin.html { 
       limit_req zone=one;
           }
    
    }

    Limiter le nombre de connexions 

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

    Le code suivant ira à la location .

    limit_conn_zone $binary_remote_addr zone=addr:10m;
    
    server {
       
        location /products/ {
            limit_conn addr 10;
           
        }
    }

    Mettre fin aux connexions lentes   

    Vous pouvez utiliser des directives d'expiration telles que client_body_timeout et client_header_timeout pour contrôler combien de temps Nginx attendra les écritures du client body et client header.

    Ajoutez ce qui suit dans le server .

    server {
        client_body_timeout 5s;
        client_header_timeout 5s;
    }

    Il serait également judicieux d'arrêter les attaques DDoS à la périphérie en exploitant des solutions basées sur le cloud comme mentionné ici.

    Désactiver la liste des répertoires

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

    location / {  
     auto_index  off;
    }

    Conclusion

    Nous avons configuré le serveur Web Nginx pour fonctionner efficacement et le protéger contre les abus excessifs dans un environnement de production. Si vous utilisez Nginx pour des applications Web accessibles sur Internet, vous devez également envisager d'utiliser un CAN et sécurité basée sur le cloud pour de meilleures performances et une meilleure sécurité.