Hosta ASP.NET Core på Linux med Nginx

Av Sourabh Shirhatti

Den här guiden beskriver hur du konfigurerar en produktionsklar ASP.NET Core-miljö för Ubuntu, Red Hat Enterprise (RHEL) och SUSE Linux Enterprise Server.

Information om andra Linux-distributioner som stöds av ASP.NET Core finns i Krav för .NET Core på Linux.

Den här guiden:

• Placerar en befintlig ASP.NET Core-app bakom en omvänd proxyserver.
• Konfigurerar den omvända proxyservern för att vidarebefordra begäranden till Kestrel-webbservern.
• Ser till att webbappen körs vid start som en daemon.
• Konfigurerar ett processhanteringsverktyg för att starta om webbappen.

Förutsättningar

Ubuntu

• Åtkomst till Ubuntu 20.04 med ett standardanvändarkonto med sudo-behörighet.
• Den senaste stabila .NET-körningsmiljön är installerad på servern.
• En befintlig ASP.NET Core-app.

Red Hat Enterprise Linux

• Åtkomst till Red Hat Enterprise (RHEL) 8.0 eller senare med ett standardanvändarkonto med sudo-behörighet.
• Den senaste stabila .NET-körtiden installerad på servern.
• En befintlig ASP.NET Core-app.

SUSE Linux Enterprise Server

• Åtkomst till SLES 12 eller 15 med ett standardanvändarkonto med sudo-behörighet.
• Den senaste stabila .NET-körmiljön installerad på servern.
• En befintlig ASP.NET Core-app.

När som helst i framtiden efter uppgradering av det delade ramverket startar du om ASP.NET Core-appar som hanteras av servern.

Publicera och kopiera över appen

Konfigurera appen för en ramverksberoende distribution.

Om appen körs lokalt i Utvecklingsmiljö och inte har konfigurerats av servern för att göra säkra HTTPS-anslutningar använder du någon av följande metoder:

• Konfigurera appen för att hantera säkra lokala anslutningar. Mer information finns i avsnittet HTTPS-konfiguration.

• Konfigurera appen så att den körs på den osäkra slutpunkten:

  • Inaktivera HTTPS Redirection Middleware i utvecklingsmiljön (Program.cs):

    if (!app.Environment.IsDevelopment())
    {
        app.UseHttpsRedirection();
    }
    

    Mer information finns i Använda flera miljöer i ASP.NET Core.

  • Ta bort https://localhost:5001 (om det finns) från egenskapen applicationUrl i filen Properties/launchSettings.json.

Mer information om konfiguration efter miljö finns i Använda flera miljöer i ASP.NET Core.

Kör dotnet publish från utvecklingsmiljön för att paketera en app i en katalog (till exempel bin/Release/{TARGET FRAMEWORK MONIKER}/publish, där platshållaren {TARGET FRAMEWORK MONIKER} är Target Framework Moniker (TFM)) som kan köras på servern:

dotnet publish --configuration Release

Appen kan också publiceras som en fristående distribution om du föredrar att inte underhålla .NET Core-runtime på servern.

Kopiera ASP.NET Core-appen till servern med hjälp av ett verktyg som integreras i organisationens arbetsflöde (till exempel SCP, SFTP). Det är vanligt att hitta webbappar under katalogen var (till exempel var/www/helloapp).

Notera

I ett produktionsdistributionsscenario utför ett arbetsflöde för kontinuerlig integrering arbetet med att publicera appen och kopiera tillgångarna till servern.

Testa appen:

1. Kör appen från kommandoraden: dotnet <app_assembly>.dll.
2. I en webbläsare navigerar du till http://<serveraddress>:<port> för att verifiera att appen fungerar lokalt i Linux.

Konfigurera en omvänd proxyserver

En omvänd proxy är en vanlig konfiguration för att hantera dynamiska webbappar. En omvänd proxy avslutar HTTP-begäran och vidarebefordrar den till ASP.NET Core-appen.

Använda en omvänd proxyserver

Kestrel är bra för att hantera dynamiskt innehåll från ASP.NET Core. Webbtjänstfunktionerna är dock inte lika funktionsrika som servrar som IIS, Apache eller Nginx. En omvänd proxyserver kan avlasta arbete som att hantera statiskt innehåll, cachelagringsbegäranden, komprimera begäranden och HTTPS-avslutning från HTTP-servern. En omvänd proxyserver kan finnas på en dedikerad dator eller distribueras tillsammans med en HTTP-server.

I den här guiden används en enda instans av Nginx. Den körs på samma server, tillsammans med HTTP-servern. Baserat på kraven kan en annan konfiguration väljas.

Eftersom begäranden vidarebefordras med omvänd proxy använder du Vidarebefordrade huvudmellanprogram från Microsoft.AspNetCore.HttpOverrides-paketet, som automatiskt ingår i ASP.NET Core-appar via delade ramverkets Microsoft.AspNetCore.App metapaket. Mellanprogrammet uppdaterar Request.Scheme, med hjälp av X-Forwarded-Proto-huvudet, så att omdirigerings-URI:er och andra säkerhetsprinciper fungerar korrekt.

Mellanprogram för vidarebefordrade rubriker ska köras före andra mellanprogram. Den här ordningen säkerställer att mellanprogrammet som förlitar sig på vidarebefordrad rubrikinformation kan använda huvudvärdena för bearbetning. För att köra vidarebefordrade headers-mellanprogram efter diagnostik och felhantering av mellanprogram, se ordning för vidarebefordringshuvudmellanprogram.

Anropa metoden UseForwardedHeaders innan du anropar andra mellanprogram. Konfigurera mellanprogrammet för att vidarebefordra X-Forwarded-For- och X-Forwarded-Proto-huvuden:

using Microsoft.AspNetCore.HttpOverrides;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication();

var app = builder.Build();

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

app.UseAuthentication();

app.MapGet("/", () => "Hello ForwardedHeadersOptions!");

app.Run();

Om inga ForwardedHeadersOptions anges för mellanprogrammet är standardrubrikerna som ska vidarebefordras None.

Proxyservrar som körs på loopback-adresser (127.0.0.0/8, [::1]), inklusive standardadressen localhost (127.0.0.1), är betrodda som standard. Om andra betrodda proxyservrar eller nätverk i organisationen hanterar begäranden mellan Internet och webbservern lägger du till dem i listan över KnownProxies eller KnownNetworks med ForwardedHeadersOptions. I följande exempel läggs en betrodd proxyserver till med IP-adressen 10.0.0.100 i mellanprogrammet för vidarebefordrade headers KnownProxies:

using Microsoft.AspNetCore.HttpOverrides;
using System.Net;

var builder = WebApplication.CreateBuilder(args);

// Configure forwarded headers
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

builder.Services.AddAuthentication();

var app = builder.Build();

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

app.UseAuthentication();

app.MapGet("/", () => "10.0.0.100");

app.Run();

Mer information finns i Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare.

Installera Nginx

Ubuntu

Använd apt-get för att installera Nginx. Installationsprogrammet skapar ett systemd init-skript som kör Nginx som daemon vid systemstart. Följ installationsanvisningarna för Ubuntu på Nginx: Officiella Debian/Ubuntu-paket.

Red Hat Enterprise Linux

Använd yum-utils för att välja och installera en Nginx-modulström. Följ installationsanvisningarna för RHEL på Nginx: Linux-paket – RHEL.

SUSE Linux Enterprise Server

Använd yum-utils för att välja och installera en Nginx-modulström. Följ installationsanvisningarna för SLES på Nginx: Linux-paket – SLES.

Anteckning

Om valfria Nginx-moduler krävs kan det krävas att du skapar Nginx från källan.

Eftersom Nginx installerades för första gången startar du det explicit genom att köra:

sudo service nginx start

Kontrollera att en webbläsare visar standardlandningssidan för Nginx. Landningssidan kan nås på http://<server_IP_address>/index.nginx-debian.html.

Konfigurera Nginx

Ubuntu

Om du vill konfigurera Nginx som en omvänd proxy för att vidarebefordra HTTP-begäranden till ASP.NET Core-appen ändrar du /etc/nginx/sites-available/default och återskapar symlänken. När du har skapat /etc/nginx/sites-available/default-filen använder du följande kommando för att skapa symlinken:

sudo ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default

Öppna /etc/nginx/sites-available/default i en textredigerare och ersätt innehållet med följande kodfragment:

Red Hat Enterprise Linux

Om du vill konfigurera Nginx som en omvänd proxy för att vidarebefordra HTTP-begäranden till en ASP.NET Core-app ändrar du /etc/nginx.conf. Uppdatera http{} kodblocket med följande kodfragment:

SUSE Linux Enterprise Server

Om du vill konfigurera Nginx som en omvänd proxy för att vidarebefordra HTTP-begäranden till en ASP.NET Core-app ändrar du /etc/nginx.conf. Uppdatera http{} kodblocket med följande kodfragment:

map $http_connection $connection_upgrade {
  "~*Upgrade" $http_connection;
  default keep-alive;
}

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 $connection_upgrade;
      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;
  }
}

Om appen är en SignalR- eller Blazor Server-app kan du läsa ASP.NET Core SignalR produktionsvärdskap och skalning och Värdskap och distribution av ASP.NET Core-Blazor appar på serversidan för mer information.

När inga server_name matchar använder Nginx standardservern. Om ingen standardserver har definierats är den första servern i konfigurationsfilen standardservern. Vi rekommenderar att du lägger till en specifik standardserver som returnerar statuskoden 444 i konfigurationsfilen. Ett exempel på standardserverkonfiguration är:

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

Med den föregående konfigurationsfilen och standardservern accepterar Nginx offentlig trafik på port 80 med värdhuvudet example.com eller *.example.com. Begäranden som inte matchar dessa värdar vidarebefordras inte till Kestrel. Nginx vidarebefordrar matchande begäranden till Kestrel på http://127.0.0.1:5000/. Mer information finns i Hur nginx bearbetar en begäran. Information om hur du ändrar IP/port för Kestrelfinns i Kestrel: Slutpunktskonfiguration.

Varning

Att inte ange en korrekt server_name-direktiv utsätter din app för säkerhetsrisker. Jokerteckenbindning för underdomäner (till exempel *.example.com) utgör inte den här säkerhetsrisken om du kontrollerar hela den överordnade domänen (till skillnad från *.com, som är sårbar). Mer information finns i RFC 9110: HTTP-semantik (avsnitt 7.2: Värd och :auktoritet).

När Nginx-konfigurationen har upprättats kör du sudo nginx -t för att verifiera syntaxen för konfigurationsfilerna. Om konfigurationsfiltestet lyckas tvingar du Nginx att hämta ändringarna genom att köra sudo nginx -s reload.

Så här kör du appen direkt på servern:

1. Gå till appens katalog.
2. Kör appen: dotnet <app_assembly.dll>, där app_assembly.dll är appens sammansättningsfilnamn.

Ubuntu

Om appen körs på servern men inte svarar via Internet kontrollerar du serverns brandvägg och bekräftar att port 80 är öppen. Om du använder en virtuell Azure Ubuntu-dator lägger du till en NSG-regel (Network Security Group) som aktiverar inkommande port 80-trafik. Du behöver inte aktivera en regel för utgående port 80 eftersom utgående trafik beviljas automatiskt när regeln för inkommande trafik är aktiverad.

Red Hat Enterprise Linux

Om appen körs på servern men inte svarar via Internet kontrollerar du serverns brandvägg och bekräftar att port 80 är öppen.

SUSE Linux Enterprise Server

Om appen körs på servern men inte svarar via Internet kontrollerar du serverns brandvägg och bekräftar att port 80 är öppen.

När du är klar med att testa appen stänger du av appen med Ctrl+C (Windows) eller ⌘+C (macOS) i kommandotolken.

Öka keepalive_requests

keepalive_requests kan ökas för högre prestanda. För mer information, se det här GitHub-ärendet.

Övervaka appen

Servern har konfigurerats för att vidarebefordra begäranden som görs till http://<serveraddress>:80 till ASP.NET Core-appen som körs på Kestrel vid http://127.0.0.1:5000. Nginx är dock inte konfigurerat för att hantera Kestrel processen. systemd kan användas för att skapa en tjänstfil för att starta och övervaka den underliggande webbappen. systemd är ett init-system som innehåller många kraftfulla funktioner för att starta, stoppa och hantera processer.

Skapa tjänstfilen

Skapa tjänstdefinitionsfilen:

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

Följande exempel är en .ini tjänstfil för appen:

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

[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_NOLOGO=true

[Install]
WantedBy=multi-user.target

I föregående exempel anges den användare som hanterar tjänsten med alternativet User. Användaren (www-data) måste finnas och ha rätt ägarskap för appens filer.

Använd TimeoutStopSec för att konfigurera hur lång tid det tar att vänta tills appen stängs av när den tar emot den första avbrottssignalen. Om appen inte stängs av under den här perioden utfärdas SIGKILL för att avsluta appen. Ange värdet som enhetslösa sekunder (till exempel 150), ett tidsintervallvärde (till exempel 2min 30s) eller infinity för att inaktivera tidsgränsen. TimeoutStopSec tilldelas standardvärdet för DefaultTimeoutStopSec i hanterarens konfigurationsfil (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). Standardtimeouten för de flesta distributioner är 90 sekunder.

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

Linux har ett skiftlägeskänsligt filsystem. Om du anger ASPNETCORE_ENVIRONMENT till Production resulterar det i att du söker efter konfigurationsfilen appsettings.Production.json, inte appsettings.production.json.

Vissa värden (till exempel SQL-anslutningssträngar) måste vara undantagna för att konfigurationsprovidrar ska kunna läsa miljövariablerna. Använd följande kommando för att generera ett korrekt escaperat värde för användning i konfigurationsfilen:

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

Kolonavgränsare (:) stöds inte i miljövariabelnamn. Använd ett dubbelt understreck (__) i stället för ett kolon. Konfigurationsleverantören Miljövariabler konverterar dubbla understreck till kolon när miljövariabler läses in i konfigureringen. I följande exempel anges anslutningssträngsnyckeln ConnectionStrings:DefaultConnection i tjänstdefinitionsfilen som ConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Spara filen och aktivera tjänsten.

sudo systemctl enable kestrel-helloapp.service

Starta tjänsten och kontrollera att den körs.

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

◝ kestrel-helloapp.service - Example .NET Web API App running on Linux
    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

Med den omvända proxyn konfigurerad och Kestrel hanteras via systemdär webbappen helt konfigurerad och kan nås från en webbläsare på den lokala datorn på http://localhost. Det är också tillgängligt från en fjärrdator, såvida det inte blockeras av en brandvägg. Genom att inspektera svarsrubrikerna visar Server-huvudet att ASP.NET Core-appen tillhandahålls av 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

Visa loggar

Eftersom webbappen som använder Kestrel hanteras med systemdloggas alla händelser och processer i en centraliserad journal. Den här journalen innehåller dock alla poster för alla tjänster och processer som hanteras av systemd. Om du vill visa kestrel-helloapp.service-specifika objekt använder du följande kommando:

sudo journalctl -fu kestrel-helloapp.service

För ytterligare filtrering kan tidsalternativ som --since today, --until 1 hour agoeller en kombination av dessa minska antalet returnerade poster.

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

Dataskydd

ASP.NET Core Data Protection-stacken används av flera ASP.NET Core mellanprogram, inklusive mellanprogram för autentisering (till exempel cookie mellanprogram) och csrf-skydd (request forgery) mellan webbplatser. Även om dataskydds-API:er inte anropas av användarkod bör dataskydd konfigureras för att skapa en beständig kryptografisk nyckelarkiv. Om dataskyddet inte har konfigurerats lagras nycklarna i minnet och tas bort när appen startas om.

Om nyckelringen lagras i minnet när appen startas om:

• Alla cookie-baserade autentiseringstoken är ogiltiga.
• Användarna måste logga in igen på nästa begäran.
• Data som skyddas med nyckelringen kan inte längre dekrypteras. Detta kan omfatta CSRF-token och ASP.NET Core MVC TempData-cookies.

Information om hur du konfigurerar dataskydd för att bevara och kryptera nyckelringen finns i:

• Nyckellagringsproviders i ASP.NET Core
• Nyckelkryptering i vila i Windows och Azure med hjälp av ASP.NET Core

Fält för långa begäranshuvuden

Standardinställningarna för proxyservern begränsar vanligtvis begärandehuvudfält till 4 K eller 8 K beroende på plattform. En app kan kräva fält som är längre än standardvärdet (till exempel appar som använder Microsoft Entra-ID). Om längre fält krävs måste standardinställningarna för proxyservern justeras. Vilka värden som ska tillämpas beror på scenariot. Mer information finns i serverns dokumentation.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Varning

Öka inte standardvärdena för proxybuffertar om det inte behövs. Om du ökar dessa värden ökar risken för buffertöverskridningar (spill) och DoS-attacker (Denial of Service) av skadliga användare.

Skydda appen

Aktivera AppArmor

Linux Security Modules (LSM) är ett ramverk som ingår i Linux-kerneln sedan Linux 2.6. LSM stöder olika implementeringar av säkerhetsmoduler. AppArmor är en LSM som implementerar ett obligatoriskt åtkomstkontrollsystem, vilket gör det möjligt att begränsa programmet till en begränsad uppsättning resurser. Kontrollera att AppArmor är aktiverat och korrekt konfigurerat.

Konfigurera brandväggen

Stäng alla externa portar som inte används. Okomplicerad brandvägg (ufw) tillhandahåller en klientdel för iptables genom att tillhandahålla ett CLI för att konfigurera brandväggen.

Ubuntu

Varning

En brandvägg förhindrar åtkomst till hela systemet om den inte är korrekt konfigurerad. Om du inte anger rätt SSH-port låss du ut ur systemet om du använder SSH för att ansluta till den. Standardporten är 22. För mer information, se introduktion av ufw och manualen.

Installera ufw och konfigurera den så att den tillåter trafik på alla portar som behövs.

sudo apt-get install ufw

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

sudo ufw enable

Red Hat Enterprise Linux

Varning

En brandvägg förhindrar åtkomst till hela systemet om den inte är korrekt konfigurerad. Om du inte anger rätt SSH-port låss du ut ur systemet om du använder SSH för att ansluta till den. Standardporten är 22. Mer information finns i introduktion till ufw.

Installera ufw och konfigurera den så att den tillåter trafik på alla portar som behövs.

sudo yum -y install ufw

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

sudo ufw enable

SUSE Linux Enterprise Server

Varning

En brandvägg förhindrar åtkomst till hela systemet om den inte är korrekt konfigurerad. Om du inte anger rätt SSH-port låss du ut ur systemet om du använder SSH för att ansluta till den. Standardporten är 22. Mer information finns i introduktion till ufw.

Installera ufw och konfigurera den så att den tillåter trafik på alla portar som behövs.

sudo yum -y install ufw

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

sudo ufw enable

Säker Nginx

Ändra Nginx-svarsnamnet

Redigera 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;

Konfigurera alternativ

Konfigurera servern med ytterligare nödvändiga moduler. Överväg att använda en brandvägg för webbappar, till exempel ModSecurity, för att härda appen.

HTTPS-konfiguration

Konfigurera appen för säkra lokala anslutningar (HTTPS)

Kommandot dotnet run använder appens Properties/launchSettings.json-fil, som konfigurerar appen att lyssna på url:erna som tillhandahålls av egenskapen applicationUrl. Till exempel https://localhost:5001;http://localhost:5000.

Konfigurera appen så att den använder ett certifikat under utveckling för dotnet run-kommandot eller utvecklingsmiljön (F5 eller Ctrl+F5 i Visual Studio Code) med någon av följande metoder:

• Ersätt standardcertifikatet från konfigurationen (rekommenderas)
• KestrelServerOptions.ConfigureHttpsDefaults

Konfigurera omvänd proxy för säkra (HTTPS) klientanslutningar

Varning

Säkerhetskonfigurationen i det här avsnittet är en allmän konfiguration som ska användas som utgångspunkt för ytterligare anpassning. Vi kan inte ge stöd för verktyg, servrar och operativsystem från tredje part. Använd konfigurationen i det här avsnittet på egen risk. Mer information finns i följande resurser:

• Konfigurera HTTPS-servrar (Nginx-dokumentation)
• mozilla.org SSL-konfigurationsgenerator

• Konfigurera servern att lyssna på HTTPS-trafik på port 443 genom att ange ett giltigt certifikat utfärdat av en betrodd certifikatutfärdare (CA).

• Härda säkerheten genom att använda några av de metoder som beskrivs i följande /etc/nginx/nginx.conf fil.

• I följande exempel konfigureras inte servern för omdirigering av osäkra begäranden. Vi rekommenderar att du använder HTTPS Redirection Middleware. Mer information finns i Framtvinga HTTPS i ASP.NET Core.

  Not

  För utvecklingsmiljöer där serverkonfigurationen hanterar säker omdirigering i stället för HTTPS Redirection Middleware rekommenderar vi att du använder tillfälliga omdirigeringar (302) i stället för permanenta omdirigeringar (301). Länkcachelagring kan orsaka instabilt beteende i utvecklingsmiljöer.

• Genom att lägga till ett Strict-Transport-Security-huvud (HSTS) ser du till att alla efterföljande begäranden som görs av klienten är över HTTPS. Mer information om hur du anger Strict-Transport-Security-huvudet finns i Framtvinga HTTPS i ASP.NET Core.

• Om HTTPS kommer att inaktiveras i framtiden använder du någon av följande metoder:

  • Lägg inte till HSTS-huvudet.
  • Välj ett kort max-age värde.

Lägg till konfigurationsfilen /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;

Ubuntu

Ersätt innehållet i konfigurationsfilen /etc/nginx/nginx.conf med följande fil. Exemplet innehåller både http och server avsnitt i en konfigurationsfil.

Red Hat Enterprise Linux

Ändra /etc/nginx/nginx.conf. Öppna den i en textredigerare och ersätt kodblocken http{} och server{} med innehållet med följande kodfragment:

SUSE Linux Enterprise Server

Ändra /etc/nginx/nginx.conf. Öppna den i en textredigerare och ersätt kodblocken http{} och server{} med innehållet med följande kodfragment:

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;
        }
    }
}

Obs

Blazor WebAssembly appar kräver ett större burst parametervärde för att hantera det större antalet begäranden som görs av en app. Mer information finns i Värd och distribuera ASP.NET Core Blazor WebAssembly.

Obs.

Exemplet ovan inaktiverar OCSP-stapling (Online Certificate Status Protocol). Bekräfta att certifikatet stöder funktionen om det är aktiverat. Mer information och vägledning om hur du aktiverar OCSP finns i följande egenskaper i artikeln Module ngx_http_ssl_module (Nginx-dokumentation):

• ssl_stapling
• ssl_stapling_file
• ssl_stapling_responder
• ssl_stapling_verify

Skydda Nginx från clickjacking

Clickjacking, även känd som en UI redress attack, är en skadlig attack där en webbplatsbesökare luras att klicka på en länk eller knapp på en annan sida än de för närvarande besöker. Använd X-FRAME-OPTIONS för att skydda webbplatsen.

Så här åtgärdar du klickkapningsattacker:

1. Redigera filen nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

   Lägg till raden i http{}-kodblocket: add_header X-Frame-Options "SAMEORIGIN";

2. Spara filen.

3. Starta om Nginx.

MIME-typ av sniffning

Det här huvud förhindrar de flesta webbläsare från att MIME-sniffa bort ett svar från den deklarerade innehållstypen, eftersom det instruerar webbläsaren att inte åsidosätta innehållstypen i svaret. Med alternativet nosniff, om servern säger att innehållet är text/html, renderar webbläsaren det som text/html.

1. Redigera filen nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

   Lägg till raden i http{}-kodblocket: add_header X-Content-Type-Options "nosniff";

2. Spara filen.

3. Starta om Nginx.

Ytterligare Nginx-förslag

När du har uppgraderat det delade ramverket på servern startar du om ASP.NET Core-appar som hanteras av servern.

Ytterligare resurser

• förutsättningar för .NET Core i Linux
• Nginx: Binära versioner: Officiella Debian-/Ubuntu-paket
• Avhjälpa problem och debugga ASP.NET Core-projekt
• Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare
• NGINX: Använda den vidarebefordrade rubriken