Héberger ASP.NET Core sur Linux avec Nginx

De Sourabh Shirhatti

Ce guide explique comment configurer un environnement ASP.NET Core prêt pour la production sur un serveur Ubuntu 16.04. Ces instructions fonctionnent normalement avec les versions d’Ubuntu plus récentes, mais elles n’ont pas fait l’objet de tests avec ces versions.

Pour plus d’informations sur les autres distributions Linux prises en charge par ASP.NET Core, consultez Prérequis pour .NET Core sur Linux.

Notes

Pour Ubuntu 14,04, supervisord est recommandé en tant que solution pour la surveillance du Kestrel processus. systemd n’est pas disponible sur Ubuntu 14,04. Pour obtenir des instructions pour Ubuntu 14.04, consultez la version précédente de cette rubrique.

Ce guide montre comment effectuer les opérations suivantes :

  • Placer une application ASP.NET Core existante derrière un serveur proxy inverse.
  • Configure le serveur proxy inverse pour transférer les demandes au Kestrel serveur Web.
  • S’assurer que l’application web s’exécute au démarrage en tant que démon.
  • Configurer un outil de gestion des processus pour aider à redémarrer l’application web.

Prérequis

  • Accédez à un serveur Ubuntu 16.04 avec un compte d’utilisateur standard disposant de privilèges sudo.
  • Le Runtime .net non-preview le plus récent installé sur le serveur.
  • Une application ASP.NET Core existante.

À tout moment après la mise à niveau de l’infrastructure partagée, redémarrez le ASP.NET Core les applications hébergées par le serveur.

Publier et copier sur l’application

Configurez l’application pour un déploiement dépendant du framework.

Si l’application est exécutée localement et n’est pas configurée pour établir des connexions sécurisées (HTTPS), adoptez l’une des approches suivantes :

  • Configurez l’application pour gérer les connexions locales sécurisées. Pour plus d’informations, consultez la section Configuration HTTPS.
  • Supprimez https://localhost:5001 (le cas échéant) de la applicationUrl propriété dans le Properties/launchSettings.json fichier.

Exécutez dotnet Publish à partir de l’environnement de développement pour empaqueter une application dans un répertoire (par exemple, bin/Release/{TARGET FRAMEWORK MONIKER}/publish , où l’espace réservé {TARGET FRAMEWORK MONIKER} est le moniker du Framework cible/TFM) qui peut s’exécuter sur le serveur :

dotnet publish --configuration Release

L’application peut également être publiée en tant que déploiement autonome si vous préférez ne pas gérer le runtime .NET Core sur le serveur.

Copiez l’application ASP.NET Core sur le serveur à l’aide d’un outil qui s’intègre dans le flux de travail de l’organisation (par exemple, SCP SFTP ). Il est courant de rechercher des applications Web dans le var répertoire (par exemple, var/www/helloapp ).

Notes

Dans un scénario de déploiement en production, un workflow d’intégration continue effectue le travail de publication de l’application et de copie des composants sur le serveur.

Testez l’application :

  1. À partir de la ligne de commande, exécutez l’application : dotnet <app_assembly>.dll.
  2. Dans un navigateur, accédez à http://<serveraddress>:<port> pour vérifier que l’application fonctionne sur Linux localement.

Configurer un serveur proxy inverse

Un proxy inverse est une configuration courante pour traiter les applications web dynamiques. Un proxy inverse met fin à la requête HTTP et la transfère à l’application ASP.NET Core.

Utiliser un serveur proxy inverse

Kestrel est idéal pour traiter le contenu dynamique de ASP.NET Core. Toutefois, les fonctionnalités de service web ne sont pas aussi complètes que les serveurs tels qu’IIS, Apache ou Nginx. Un serveur proxy inverse peut décharger du travail tel que le traitement du contenu statique, la mise en cache des requêtes, la compression des requêtes et l’arrêt HTTPS à partir du serveur HTTP. Un serveur proxy inverse peut résider sur un ordinateur dédié ou peut être déployé à côté d’un serveur HTTP.

Pour les besoins de ce guide, nous utilisons une seule instance de Nginx. Elle s’exécute sur le même serveur, en plus du serveur HTTP. Selon les exigences, un paramétrage différent peut être choisi.

Étant donné que les demandes sont transférées par le proxy inverse, utilisez l' intergiciel d’en-têtes transmis à partir du Microsoft.AspNetCore.HttpOverrides Package. Le middleware met à jour le Request.Scheme, à l’aide de l’en-tête X-Forwarded-Proto, afin que les URI de redirection et d’autres stratégies de sécurité fonctionnent correctement.

L’intergiciel (middleware) d’en-têtes transférés doit s’exécuter avant tout autre intergiciel. Cet ordre permet au middleware qui repose sur les informations des en-têtes transférés d’utiliser les valeurs d’en-tête pour le traitement. Pour exécuter l’intergiciel (middleware) d’en-têtes transférés après les diagnostics et l’intergiciel (middleware) de gestion des erreurs, consultez ordre des intergiciels en-têtes transférés.

Appelez la UseForwardedHeaders méthode en haut de Startup.Configure avant d’appeler un autre intergiciel. Configurez le middleware pour transférer les en-têtes X-Forwarded-For et X-Forwarded-Proto :

using Microsoft.AspNetCore.HttpOverrides;

...

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

Si aucune option ForwardedHeadersOptions n’est spécifiée au middleware, les en-têtes par défaut à transférer sont None.

Les proxies s’exécutant sur des adresses de bouclage ( 127.0.0.0/8 , [::1] ), y compris l’adresse localhost standard ( 127.0.0.1 ), sont approuvés par défaut. Si d’autres proxys ou réseaux approuvés au sein de l’organisation gèrent les requêtes entre Internet et le serveur web, ajoutez-les à la liste des KnownProxies ou des KnownNetworks avec ForwardedHeadersOptions. L’exemple suivant ajoute un serveur proxy approuvé avec l’adresse IP 10.0.0.100 au middleware des en-têtes transférés KnownProxies dans Startup.ConfigureServices :

using System.Net;

...

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

Pour plus d’informations, consultez Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge.

Installer Nginx

Utilisez apt-get pour installer Nginx. Le programme d’installation crée un systemd script init qui exécute Nginx en tant que démon au démarrage du système. Suivez les instructions d’installation pour Ubuntu sur le site Nginx : Les packages officiels Debian/Ubuntu.

Notes

Si des modules Nginx facultatifs sont requis, il peut s’avérer nécessaire de configurer Nginx à partir de la source.

Comme il s’agit de l’installation initiale de Nginx, vous devez le démarrer explicitement en exécutant :

sudo service nginx start

Vérifiez qu’un navigateur affiche la page d’accueil par défaut de Nginx. La page d’accueil est accessible à l’adresse http://<server_IP_address>/index.nginx-debian.html.

Configurer Nginx

Pour configurer Nginx en tant que proxy inverse pour transférer les requêtes HTTP à votre application ASP.NET Core, modifiez /etc/nginx/sites-available/default . Ouvrez-le dans un éditeur de texte et remplacez le contenu par l’extrait de code suivant :

server {
    listen        80;
    server_name   example.com *.example.com;
    location / {
        proxy_pass         http://127.0.0.1:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

Si l’application est une SignalR Blazor Server application ou, consultez ASP.NET Core SignalR de l’hébergement et de la mise à l’échelle de production et, respectivement, Héberger et déployer des ASP.NET Core Blazor Server pour plus d’informations.

Si aucun server_name ne correspond, Nginx utilise le serveur par défaut. Si aucun serveur par défaut n’est défini, le premier serveur dans le fichier de configuration est le serveur par défaut. Il est recommandé d’ajouter un serveur par défaut spécifique qui retourne le code d’État 444 dans votre fichier de configuration. Voici un exemple de configuration de serveur par défaut :

server {
    listen   80 default_server;
    # listen [::]:80 default_server deferred;
    return   444;
}

Avec les fichier de configuration et le serveur par défaut précédents, Nginx accepte le trafic public sur le port 80 avec un en-tête d’hôte example.com ou *.example.com. Les demandes qui ne correspondent pas à ces hôtes ne sont pas transférées à Kestrel . Nginx transfère les demandes correspondantes à Kestrel à http://127.0.0.1:5000 . Pour plus d’informations, consultez How Nginx traite une demande. Pour modifier Kestrel l’adresse IP/le port de, voir Kestrel : configuration du point de terminaison.

Avec les fichier de configuration et le serveur par défaut précédents, Nginx accepte le trafic public sur le port 80 avec un en-tête d’hôte example.com ou *.example.com. Les demandes qui ne correspondent pas à ces hôtes ne sont pas transférées à Kestrel . Nginx transfère les demandes correspondantes à Kestrel à http://127.0.0.1:5000 . Pour plus d’informations, consultez How Nginx traite une demande. Pour modifier Kestrel l’adresse IP/le port de, voir Kestrel : configuration du point de terminaison.

Avertissement

La spécification d’une directive server_name incorrecte expose votre application à des failles de sécurité. Une liaison générique de sous-domaine (par exemple, *.example.com) ne présente pas ce risque de sécurité si vous contrôlez le domaine parent en entier (par opposition à *.com, qui est vulnérable). Pour plus d’informations, consultez la section rfc7230-5,4.

Une fois la configuration de Nginx établie, exécutez sudo nginx -t pour vérifier la syntaxe des fichiers de configuration. Si le test de fichier de configuration réussit, forcez Nginx à appliquer les modifications en exécutant sudo nginx -s reload.

Pour exécuter directement l’application sur le serveur :

  1. Accédez au répertoire de l’application.
  2. Exécutez l’application : dotnet <app_assembly.dll>, où app_assembly.dll est le nom de fichier d’assembly de l’application.

Si l’application s’exécute sur le serveur mais ne répond pas sur Internet, vérifiez le pare-feu du serveur et vérifiez que le port 80 est ouvert. Si vous utilisez une machine virtuelle Azure Ubuntu, ajoutez une règle de groupe de sécurité réseau (NSG) qui autorise le trafic entrant sur le port 80. Il est inutile d’activer une règle de trafic sortant sur le port 80, car le trafic sortant est accordé automatiquement quand la règle de trafic entrant est activée.

Lorsque vous avez terminé de tester l’application, arrêtez l’application en appuyant sur CTRL + C à l’invite de commandes.

Surveiller l’application

Le serveur est configuré pour transférer les demandes effectuées à http://<serveraddress>:80 sur l’application ASP.net Core s’exécutant sur Kestrel http://127.0.0.1:5000 . Toutefois, Nginx n’est pas configuré pour gérer le Kestrel processus. systemd peut être utilisé pour créer un fichier de service pour démarrer et surveiller l’application Web sous-jacente. systemd est un système init qui fournit de nombreuses fonctionnalités puissantes pour le démarrage, l’arrêt et la gestion des processus.

Créer le fichier de service

Créez le fichier de définition de service :

sudo nano /etc/systemd/system/kestrel-helloapp.service

L’exemple suivant est un fichier de service pour l’application :

[Unit]
Description=Example .NET Web API App running on Ubuntu

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

Dans l’exemple précédent, l’utilisateur qui gère le service est spécifié par l' User option. L’utilisateur ( www-data ) doit exister et avoir la propriété correcte des fichiers de l’application.

Utilisez TimeoutStopSec pour configurer la durée d’attente de l’arrêt de l’application après la réception du signal d’interruption initial. Si l’application ne s’arrête pas pendant cette période, le signal SIGKILL est émis pour mettre fin à l’application. Indiquez la valeur en secondes sans unité (par exemple, 150), une valeur d’intervalle de temps (par exemple, 2min 30s) ou infinity pour désactiver le délai d’attente. TimeoutStopSec la valeur par défaut est la valeur de DefaultTimeoutStopSec dans le fichier de configuration du gestionnaire ( systemd-system.conf , system.conf.d , systemd-user.conf , user.conf.d ). Le délai d’expiration par défaut pour la plupart des distributions est de 90 secondes.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Linux possède un système de fichiers respectant la casse. Si ASPNETCORE_ENVIRONMENT la valeur est Production , la recherche du fichier de configuration appsettings.Production.json n’a pas lieu appsettings.production.json .

Certaines valeurs (par exemple, les chaînes de connexion SQL) doivent être placées dans une séquence d’échappement afin que les fournisseurs de configuration puissent lire les variables d’environnement. Utilisez la commande suivante pour générer une valeur correctement placée dans une séquence d’échappement en vue de son utilisation dans le fichier de configuration :

systemd-escape "<value-to-escape>"

Les séparateurs : (signe deux-points) ne sont pas pris en charge dans les noms de variables d’environnement. Utilisez un double trait de soulignement (__) à la place d’un signe deux-points. Le fournisseur de configuration de variables d’environnement convertit les doubles traits de soulignement en signes deux-points quand les variables d’environnement sont lues dans la configuration. Dans l’exemple suivant, la clé de chaîne de connexion ConnectionStrings:DefaultConnection est définie dans le fichier de définition de service en tant que ConnectionStrings__DefaultConnection :

Les séparateurs : (signe deux-points) ne sont pas pris en charge dans les noms de variables d’environnement. Utilisez un double trait de soulignement (__) à la place d’un signe deux-points. Le fournisseur de configuration de variables d’environnement convertit les doubles traits de soulignement en signes deux-points quand les variables d’environnement sont lues dans la configuration. Dans l’exemple suivant, la clé de chaîne de connexion ConnectionStrings:DefaultConnection est définie dans le fichier de définition de service en tant que ConnectionStrings__DefaultConnection :

Environment=ConnectionStrings__DefaultConnection={Connection String}

Enregistrez le fichier et activez le service.

sudo systemctl enable kestrel-helloapp.service

Démarrez le service et vérifiez qu’il s’exécute.

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on Ubuntu
    Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
    Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
    CGroup: /system.slice/kestrel-helloapp.service
            └─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.dll

Une fois le proxy inverse configuré et Kestrel géré via systemd , l’application Web est entièrement configurée et accessible à partir d’un navigateur sur l’ordinateur local à l’adresse http://localhost . Elle est également accessible à partir d’un ordinateur distant, sauf en cas de blocage par un pare-feu. En examinant les en-têtes de réponse, l' Server en-tête indique le ASP.net Core application servi par Kestrel .

HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked

Afficher les journaux d’activité

Étant donné que l’application Web utilisant Kestrel est gérée à l’aide de systemd , tous les événements et processus sont consignés dans un journal centralisé. Toutefois, ce journal inclut toutes les entrées pour tous les services et les processus gérés par systemd. Pour afficher les éléments propres à kestrel-helloapp.service, utilisez la commande suivante :

sudo journalctl -fu kestrel-helloapp.service

Pour un filtrage approfondi, les options d’heure telles que --since today , --until 1 hour ago ou une combinaison de ces options peuvent réduire le nombre d’entrées retournées.

sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"

Protection des données

La pile de protection des données ASP.net Core est utilisée par plusieurs ASP.net Core intergiciels, y compris l’intergiciel (middleware) d’authentification (par exemple, cookie intergiciel) et les protections CSRF (cross-site request falsification). Même si les API de protection des données ne sont pas appelées par le code de l’utilisateur, la protection des données doit être configurée pour créer un magasin de clés de chiffrement persistantes. Si la protection des données n’est pas configurée, les clés sont conservées en mémoire et ignorées au redémarrage de l’application.

Si le Key Ring est stocké en mémoire, au redémarrage de l’application :

  • Tous les cookie jetons d’authentification de base sont invalidés.
  • Les utilisateurs doivent se reconnecter pour envoyer leur prochaine demande.
  • toutes les données protégées par le Key Ring ne peuvent plus être déchiffrées. Cela peut inclure des jetons CSRF et des ASP.NET Core les de la MVC cookie .

Pour configurer la protection des données de façon à conserver et chiffrer le porte-clés (Key Ring), consultez :

Longs champs d'en-tête de demande

Les paramètres par défaut du serveur proxy limitent généralement les champs d’en-tête de demande à 4 K ou 8 K en fonction de la plateforme. Une application peut nécessiter des champs plus longs que la valeur par défaut (par exemple, les applications qui utilisent Azure Active Directory). Si des champs plus longs sont requis, les paramètres par défaut du serveur proxy doivent être ajustés. Les valeurs à appliquer dépendent du scénario. Pour plus d'informations, voir la documentation du serveur.

Avertissement

N’augmentez pas les valeurs par défaut des mémoires tampons de proxy à moins que ce ne soit nécessaire. Leur augmentation augmente le risque de dépassement de mémoire tampon (dépassement de capacité) et d’attaques par déni de service (DoS) par des utilisateurs malveillants.

Sécuriser l’application

Activer AppArmor

Linux Security Modules (LSM) est un framework qui fait partie du noyau Linux depuis Linux 2.6. LSM prend en charge différentes implémentations de modules de sécurité. AppArmor est un LSM qui implémente un système Access Control obligatoire, ce qui permet de limiter le programme à un ensemble limité de ressources. Vérifiez qu’AppArmor est activé et configuré correctement.

Configurer le pare-feu

Fermez tous les ports externes qui ne sont pas en cours d’utilisation. Le pare-feu UFW fournit une interface de commande pour iptables la configuration du pare-feu.

Avertissement

Un pare-feu mal configuré bloque l’accès à l’ensemble du système. Faute d’avoir spécifié le port SSH approprié, vous ne pourrez pas accéder au système si vous utilisez SSH pour vous y connecter. Le numéro de port par défaut est 22. Pour plus d’informations, consultez la présentation d’ufw et le manuel.

Installez ufw et configurez-le de façon à autoriser le trafic sur les ports nécessaires.

sudo apt-get install ufw

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable

Sécuriser Nginx

Changer le nom de la réponse Nginx

Modifiez src/http/ngx_http_header_filter_module.c:

static char ngx_http_server_string[] = "Server: Web Server" CRLF;
static char ngx_http_server_full_string[] = "Server: Web Server" CRLF;

Configurer les options

Configurez le serveur avec les modules nécessaires supplémentaires. Pour renforcer l’application, vous pouvez utiliser un pare-feu d’application web tel que ModSecurity.

Configuration HTTPS

Configurer l’application pour les connexions locales sécurisées (HTTPS)

La commande dotnet Run utilise les Propriétés/launchSettings.js de l’application sur le fichier, ce qui configure l’application pour qu’elle écoute les URL fournies par la applicationUrl propriété. Par exemple : https://localhost:5001;http://localhost:5000.

Configurez l’application pour qu’elle utilise un certificat en développement pour la dotnet run commande ou l’environnement de développement (F5 ou CTRL + F5 dans Visual Studio code) à l’aide de l’une des approches suivantes :

Configurer le proxy inverse pour les connexions clientes sécurisées (HTTPS)

Avertissement

La configuration de la sécurité de cette section est une configuration générale à utiliser comme point de départ pour une personnalisation plus poussée. Nous ne pouvons pas assurer la prise en charge des outils tiers, des serveurs et des systèmes d’exploitation. Utilisez la configuration de cette section à vos propres risques. Pour plus d’informations, accédez aux ressources suivantes :

  • Configurez le serveur pour écouter le trafic HTTPs sur le port 443 en spécifiant un certificat valide émis par une autorité de certification approuvée.

  • Renforcez la sécurité en appliquant certaines des pratiques mentionnées dans le fichier /etc/nginx/nginx.conf suivant.

  • L’exemple suivant ne configure pas le serveur de façon à rediriger les demandes non sécurisées. Nous vous recommandons d’utiliser l’intergiciel (middleware) de redirection HTTPs. Pour plus d’informations, consultez Appliquer le protocole HTTPs en ASP.NET Core.

    Notes

    Pour les environnements de développement où la configuration du serveur gère la redirection sécurisée au lieu de l’intergiciel (middleware) de redirection HTTPs, nous vous recommandons d’utiliser des redirections temporaires (302) plutôt que des redirections permanentes (301). La mise en cache des liens peut provoquer un comportement instable dans les environnements de développement.

  • L’ajout d’un Strict-Transport-Security en-tête (HSTS) garantit que toutes les demandes ultérieures effectuées par le client sont sur HTTPS. Pour obtenir des conseils sur la définition de l' Strict-Transport-Security en-tête, consultez Appliquer le protocole HTTPs en ASP.NET Core .

  • Si le protocole HTTPs est désactivé à l’avenir, utilisez l’une des approches suivantes :

    • N’ajoutez pas l’en-tête HSTS.
    • Choisissez une valeur abrégée max-age .

Ajoutez le fichier de configuration /etc/nginx/proxy.conf :

proxy_redirect          off;
proxy_set_header        Host $host;
proxy_set_header        X-Real-IP $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header        X-Forwarded-Proto $scheme;
client_max_body_size    10m;
client_body_buffer_size 128k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffers           32 4k;

Remplacez le contenu du fichier de configuration /etc/nginx/nginx.conf par le fichier suivant. Dans l’exemple, les sections http et server figurent dans un même fichier de configuration.

http {
    include        /etc/nginx/proxy.conf;
    limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
    server_tokens  off;

    sendfile on;
    # Adjust keepalive_timeout to the lowest possible value that makes sense 
    # for your use case.
    keepalive_timeout   29;
    client_body_timeout 10; client_header_timeout 10; send_timeout 10;

    upstream helloapp{
        server 127.0.0.1:5000;
    }

    server {
        listen                    443 ssl http2;
        listen                    [::]:443 ssl http2;
        server_name               example.com *.example.com;
        ssl_certificate           /etc/ssl/certs/testCert.crt;
        ssl_certificate_key       /etc/ssl/certs/testCert.key;
        ssl_session_timeout       1d;
        ssl_protocols             TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers off;
        ssl_ciphers               ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
        ssl_session_cache         shared:SSL:10m;
        ssl_session_tickets       off;
        ssl_stapling              off;

        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;

        #Redirects all traffic
        location / {
            proxy_pass http://helloapp;
            limit_req  zone=one burst=10 nodelay;
        }
    }
}

Notes

Blazor WebAssembly les applications requièrent une plus grande burst valeur de paramètre pour prendre en charge le plus grand nombre de requêtes effectuées par une application. Pour plus d’informations, consultez Héberger et déployer des ASP.NET Core Blazor WebAssembly.

Notes

L’exemple précédent désactive l’agrafage du protocole OCSP (Online Certificate Status Protocol). S’il est activé, vérifiez que le certificat prend en charge la fonctionnalité. Pour plus d’informations et de conseils sur l’activation du protocole OCSP, consultez les propriétés suivantes dans l’article du Module ngx_http_ssl_module (documentation Nginx) :

  • ssl_stapling
  • ssl_stapling_file
  • ssl_stapling_responder
  • ssl_stapling_verify

Sécuriser Nginx contre le détournement de clic

Le détournement de clic, également appelé UI redress attack, est une attaque malveillante qui amène le visiteur d’un site web à cliquer sur un lien ou un bouton sur une page différente de celle qu’il est en train de visiter. Utilisez X-FRAME-OPTIONS pour sécuriser le site.

Pour atténuer les attaques par détournement de clic :

  1. Modifiez le fichier nginx.conf :

    sudo nano /etc/nginx/nginx.conf
    

    Ajoutez la ligne : add_header X-Frame-Options "SAMEORIGIN";

  2. Enregistrez le fichier .

  3. Redémarrez Nginx.

Détection de type MIME

Cet en-tête empêche la plupart des navigateurs de détourner le type MIME d’une réponse et de remplacer le type de contenu déclaré, car l’en-tête indique au navigateur qu’il ne doit pas substituer le type de contenu de la réponse. Avec l' nosniff option, si le serveur indique que le contenu est text/html , le navigateur le restitue sous la forme text/html .

  1. Modifiez le fichier nginx.conf :

    sudo nano /etc/nginx/nginx.conf
    

    Ajoutez la ligne : add_header X-Content-Type-Options "nosniff";

  2. Enregistrez le fichier .

  3. Redémarrez Nginx.

Suggestions supplémentaires pour Nginx

Après la mise à niveau de l’infrastructure partagée sur le serveur, redémarrez le ASP.NET Core les applications hébergées par le serveur.

Ressources supplémentaires