Delen via


Draai ASP.NET Core op Linux met Nginx

Door Sourabh Shirhatti

Notitie

Dit is niet de nieuwste versie van dit artikel. Zie de .NET 9-versie van dit artikelvoor de huidige release.

Waarschuwing

Deze versie van ASP.NET Core wordt niet meer ondersteund. Zie de .NET- en .NET Core-ondersteuningsbeleidvoor meer informatie. Zie de .NET 9-versie van dit artikelvoor de huidige release.

Belangrijk

Deze informatie heeft betrekking op een pre-releaseproduct dat aanzienlijk kan worden gewijzigd voordat het commercieel wordt uitgebracht. Microsoft geeft geen garanties, uitdrukkelijk of impliciet, met betrekking tot de informatie die hier wordt verstrekt.

Zie de .NET 9-versie van dit artikelvoor de huidige release.

In deze handleiding wordt uitgelegd hoe u een productieklare ASP.NET Core-omgeving instelt voor Ubuntu, Red Hat Enterprise (RHEL) en SUSE Linux Enterprise Server.

Zie Vereisten voor .NET Core op Linuxvoor informatie over andere Linux-distributies die worden ondersteund door ASP.NET Core.

Deze handleiding:

  • Hiermee plaatst u een bestaande ASP.NET Core-app achter een omgekeerde proxyserver.
  • Hiermee stelt u de omgekeerde proxyserver in om aanvragen door te sturen naar de Kestrel webserver.
  • Zorgt ervoor dat de web-app wordt uitgevoerd bij het opstarten als een daemon.
  • Hiermee configureert u een hulpprogramma voor procesbeheer om de web-app opnieuw op te starten.

Voorwaarden

  • Toegang tot Ubuntu 20.04 met een standaardgebruikersaccount met sudo-bevoegdheid.
  • De meest recente stabiele .NET-runtime geïnstalleerd op de server.
  • Een bestaande ASP.NET Core-app.

Start de ASP.NET Core-apps die worden gehost door de server, opnieuw op elk moment in de toekomst na het upgraden van het gedeelde framework.

De app publiceren en kopiëren

Configureer de app voor een frameworkafhankelijke implementatie.

Als de app lokaal wordt uitgevoerd in de Ontwikkelomgeving en niet is geconfigureerd door de server om beveiligde HTTPS-verbindingen te maken, gaat u op een van de volgende manieren te werk:

  • Configureer de app voor het afhandelen van beveiligde lokale verbindingen. Zie de sectie HTTPS-configuratie voor meer informatie.

  • Configureer de app die moet worden uitgevoerd op het onveilige eindpunt:

    • HTTPS Redirection Middleware deactiveren in de ontwikkelomgeving (Program.cs):

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

      Zie Meerdere omgevingen gebruiken in ASP.NET Corevoor meer informatie.

    • Verwijder https://localhost:5001 (indien aanwezig) uit de eigenschap applicationUrl in het bestand Properties/launchSettings.json.

Zie Meerdere omgevingen gebruiken in ASP.NET Corevoor meer informatie over configuratie per omgeving.

Voer dotnet uit vanuit de ontwikkelomgeving om een app in een map te verpakken (bijvoorbeeld bin/Release/{TARGET FRAMEWORK MONIKER}/publish, waarbij de tijdelijke aanduiding {TARGET FRAMEWORK MONIKER} de Target Framework Moniker (TFM)is) zodat deze op de server kan worden uitgevoerd.

dotnet publish --configuration Release

De app kan ook worden gepubliceerd als een zelfstandige implementatie als u de .NET Core-runtime liever niet op de server onderhoudt.

Kopieer de ASP.NET Core-app naar de server met behulp van een hulpprogramma dat is geïntegreerd in de werkstroom van de organisatie (bijvoorbeeld SCP, SFTP). Het is gebruikelijk om web-apps te vinden in de map var (bijvoorbeeld var/www/helloapp).

Notitie

Onder een productie-implementatiescenario voert een werkstroom voor continue integratie het publiceren van de app uit en het kopiëren van de assets naar de server.

De app testen:

  1. Voer vanaf de opdrachtregel de app uit: dotnet <app_assembly>.dll.
  2. Navigeer in een browser naar http://<serveraddress>:<port> om te controleren of de app lokaal werkt op Linux.

Een omgekeerde proxyserver configureren

Een omgekeerde proxy is een algemene installatie voor het leveren van dynamische web-apps. Een omgekeerde proxy beëindigt de HTTP-aanvraag en stuurt deze door naar de ASP.NET Core-app.

Een omgekeerde proxyserver gebruiken

Kestrel is ideaal voor het leveren van dynamische inhoud van ASP.NET Core. De webservicemogelijkheden zijn echter niet zo uitgebreid als servers zoals IIS, Apache of Nginx. Een omgekeerde proxyserver kan werk offloaden, zoals het leveren van statische inhoud, het in de cache opslaan van aanvragen, comprimeren van aanvragen en HTTPS-beëindiging vanaf de HTTP-server. Een omgekeerde proxyserver kan zich op een toegewezen computer bevinden of naast een HTTP-server worden geïmplementeerd.

Voor deze handleiding wordt één exemplaar van Nginx gebruikt. Deze wordt uitgevoerd op dezelfde server, naast de HTTP-server. Op basis van vereisten kan een andere installatie worden gekozen.

Omdat aanvragen worden doorgestuurd via omgekeerde proxy, gebruikt u de Forwarded Headers Middleware uit het Microsoft.AspNetCore.HttpOverrides-pakket, dat automatisch wordt opgenomen in ASP.NET Core-apps via de Microsoft.AspNetCore.App metapackagevan het gedeelde framework. De middleware werkt de Request.Schemebij met behulp van de X-Forwarded-Proto-header, zodat omleidings-URI's en ander beveiligingsbeleid correct werken.

Headers middleware moet worden uitgevoerd voordat andere middleware worden uitgevoerd. Deze volgorde zorgt ervoor dat de middleware die afhankelijk is van informatie over doorgestuurde headers de headerwaarden kan gebruiken voor verwerking. Zie voor de volgorde van de Middleware voor doorgestuurde headersom deze uit te voeren na diagnose en foutafhandeling van middleware.

Roep de methode UseForwardedHeaders aan voordat u andere middleware aanroept. Configureer de middleware om de X-Forwarded-For en X-Forwarded-Proto headers door te sturen:

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();

Als er geen ForwardedHeadersOptions zijn opgegeven voor de middleware, worden de standaardheaders die moeten worden doorgestuurd None.

Proxy's die worden uitgevoerd op loopback-adressen (127.0.0.0/8, [::1]), inclusief het standaard localhost-adres (127.0.0.1), worden standaard vertrouwd. Als andere vertrouwde proxy's of netwerken binnen de organisatie aanvragen verwerken tussen internet en de webserver, voegt u deze toe aan de lijst met KnownProxies of KnownNetworks met ForwardedHeadersOptions. In het volgende voorbeeld wordt een betrouwbare proxyserver bij het IP-adres 10.0.0.100 aan de Forwarded Headers middleware KnownProxiestoegevoegd.

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();

Zie ASP.NET Core configureren voor gebruik met proxyservers en load balancersvoor meer informatie.

Nginx installeren

Gebruik apt-get om Nginx te installeren. Het installatieprogramma maakt een systemd init-script dat Nginx uitvoert als daemon bij het opstarten van het systeem. Volg de installatie-instructies voor Ubuntu op Nginx: Officiële Debian/Ubuntu-pakketten.

Notitie

Als optionele Nginx-modules vereist zijn, is het bouwen van Nginx vanuit de bron mogelijk vereist.

Omdat Nginx voor het eerst is geïnstalleerd, start u deze expliciet door het volgende uit te voeren:

sudo service nginx start

Controleer of in een browser de standaardlandingspagina voor Nginx wordt weergegeven. De landingspagina is bereikbaar op http://<server_IP_address>/index.nginx-debian.html.

Nginx configureren

Als u Nginx wilt configureren als een omgekeerde proxy om HTTP-aanvragen door te sturen naar de ASP.NET Core-app, wijzigt u /etc/nginx/sites-available/default en maakt u de symlink opnieuw. Nadat u het /etc/nginx/sites-available/default-bestand hebt gemaakt, gebruikt u de volgende opdracht om de symlink te maken:

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

Open /etc/nginx/sites-available/default in een teksteditor en vervang de inhoud door het volgende fragment:

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

Als de app een SignalR- of Blazor Server-app is, raadpleegt u ASP.NET Core SignalR productiehosting en schaalaanpassing van en Host en implementeert u ASP.NET Core Blazor apps respectievelijk voor meer informatie.

Als er geen server_name overeenkomsten zijn, gebruikt Nginx de standaardserver. Als er geen standaardserver is gedefinieerd, is de eerste server in het configuratiebestand de standaardserver. Voeg als best practice een specifieke standaardserver toe die een statuscode van 444 in uw configuratiebestand retourneert. Een voorbeeld van een standaardserverconfiguratie is:

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

Met het voorgaande configuratiebestand en de standaardserver accepteert Nginx openbaar verkeer op poort 80 met hostheader example.com of *.example.com. Aanvragen die niet overeenkomen met deze hosts, worden niet doorgestuurd naar Kestrel. Nginx stuurt de overeenkomende aanvragen door naar Kestrel op http://127.0.0.1:5000/. Zie Hoe nginx een aanvraag verwerktvoor meer informatie. Zie Kestrel: Eindpuntconfiguratieals u het IP-adres/de poort van Kestrelwilt wijzigen.

Waarschuwing

Als u geen juiste server_name directive opgeeft, leidt dit ertoe dat uw app wordt blootgesteld aan beveiligingsproblemen. Subdomein-jokertekenbinding (bijvoorbeeld *.example.com) vormt dit beveiligingsrisico niet als u het hele bovenliggende domein bepaalt (in tegenstelling tot *.com, wat kwetsbaar is). Zie RFC 9110: HTTP-semantiek (sectie 7.2: Host en :authority)voor meer informatie.

Zodra de Nginx-configuratie tot stand is gebracht, voert u sudo nginx -t uit om de syntaxis van de configuratiebestanden te controleren. Als de test van het configuratiebestand is geslaagd, dwingt u Nginx af om de wijzigingen op te halen door sudo nginx -s reloaduit te voeren.

De app rechtstreeks uitvoeren op de server:

  1. Navigeer naar de map van de app.
  2. Voer de app uit: dotnet <app_assembly.dll>, waarbij app_assembly.dll de assemblybestandsnaam van de app is.

Als de app wordt uitgevoerd op de server, maar niet via internet reageert, controleert u de firewall van de server en controleert u of poort 80 is geopend. Als u een Virtuele Azure Ubuntu-machine gebruikt, voegt u een NSG-regel (Network Security Group) toe waarmee binnenkomend poort 80-verkeer wordt ingeschakeld. U hoeft geen regel voor uitgaande poort 80 in te schakelen, omdat het uitgaande verkeer automatisch wordt verleend wanneer de regel voor binnenkomend verkeer is ingeschakeld.

Wanneer u klaar bent met het testen van de app, sluit u de app af met Ctrl+C- in de opdrachtshell.

Keepalive_requests verhogen

keepalive_requests kan worden verhoogd voor hogere prestaties, zie dit GitHub-probleemvoor meer informatie.

De app bewaken

De server is ingesteld voor het doorsturen van aanvragen naar http://<serveraddress>:80 naar de ASP.NET Core-app die wordt uitgevoerd op Kestrel op http://127.0.0.1:5000. Nginx is echter niet ingesteld voor het beheren van het Kestrel proces. systemd kan worden gebruikt om een servicebestand te maken om de onderliggende web-app te starten en te bewaken. systemd is een init-systeem dat veel krachtige functies biedt voor het starten, stoppen en beheren van processen.

Het servicebestand maken

Maak het servicedefinitiebestand:

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

Het volgende voorbeeld is een .ini servicebestand voor de app:

[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

In het voorgaande voorbeeld wordt de gebruiker die de service beheert, opgegeven door de optie User. De gebruiker (www-data) moet bestaan en de juiste eigenaar zijn van de bestanden van de app.

Gebruik TimeoutStopSec om de tijdsduur te configureren die moet worden gewacht totdat de app wordt afgesloten nadat het eerste interruptsignaal is ontvangen. Als de app in deze periode niet wordt afgesloten, wordt SIGKILL gebruikt om de app te beëindigen. Geef de waarde op als seconden zonder eenheid (bijvoorbeeld 150), een tijdspannewaarde (bijvoorbeeld 2min 30s) of infinity om de time-out uit te schakelen. TimeoutStopSec neemt standaard de waarde van DefaultTimeoutStopSec aan in het configuratiebestand van de manager (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). De standaardtime-out voor de meeste distributies is 90 seconden.

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

Linux heeft een hoofdlettergevoelig bestandssysteem. Bij het instellen van ASPNETCORE_ENVIRONMENT op Production, zult u zoeken naar het configuratiebestand appsettings.Production.jsonin plaats van appsettings.production.json.

Sommige waarden (bijvoorbeeld SQL-verbindingsreeksen) moeten worden ontsnapt zodat de configuratieproviders de omgevingsvariabelen kunnen lezen. Gebruik de volgende opdracht om een correct escape-waarde te genereren voor gebruik in het configuratiebestand:

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

Dubbele puntscheidingstekens (:) worden niet ondersteund in namen van omgevingsvariabelen. Gebruik een dubbele onderstrepingsteken (__) in plaats van een dubbele punt. De configuratieprovider voor omgevingsvariabelen converteert dubbele onderstrepingstekens in dubbele punten wanneer de omgevingsvariabelen in de configuratie worden gelezen. In het volgende voorbeeld wordt de verbindingsreekssleutel ConnectionStrings:DefaultConnection ingesteld in het servicedefinitiebestand als ConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Sla het bestand op en schakel de service in.

sudo systemctl enable kestrel-helloapp.service

Start de service en controleer of deze wordt uitgevoerd.

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

Wanneer de omgekeerde proxy is geconfigureerd en Kestrel beheerd via systemd, is de web-app volledig geconfigureerd en kan deze worden geopend vanuit een browser op de lokale computer op http://localhost. Het is ook toegankelijk vanaf een externe computer, tenzij er een firewall is die de toegang blokkeert. Bij het inspecteren van de response headers toont de Server header de ASP.NET Core-app die wordt geleverd door 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

Logboeken weergeven

Omdat de web-app die gebruikmaakt van Kestrel wordt beheerd met systemd, worden alle gebeurtenissen en processen vastgelegd in een gecentraliseerd logboek. Dit logboek bevat echter alle vermeldingen voor alle services en processen die worden beheerd door systemd. Gebruik de volgende opdracht om de kestrel-helloapp.service-specifieke items weer te geven:

sudo journalctl -fu kestrel-helloapp.service

Voor verdere filtering kunnen tijdsopties zoals --since today, --until 1 hour agoof een combinatie hiervan het aantal geretourneerde items verminderen.

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

Gegevensbescherming

De ASP.NET Core Data Protection-stack wordt gebruikt door verschillende ASP.NET Core middleware, waaronder authenticatie-middleware (zoals cookie middleware) en CSRF-beveiligingen (cross-site request forgery). Zelfs als gegevensbeveiligings-API's niet worden aangeroepen door gebruikerscode, moet gegevensbeveiliging worden geconfigureerd voor het maken van een permanente cryptografische sleutelarchief. Als gegevensbeveiliging niet is geconfigureerd, worden de sleutels in het geheugen bewaard en verwijderd wanneer de app opnieuw wordt opgestart.

Als de sleutelring wordt opgeslagen in het geheugen wanneer de app opnieuw wordt opgestart:

  • Alle op cookiegebaseerde verificatietokens zijn ongeldig.
  • Gebruikers moeten zich opnieuw aanmelden bij hun volgende aanvraag.
  • Gegevens die met de sleutelring zijn beveiligd, kunnen niet meer worden ontsleuteld. Dit kan CSRF-tokens en ASP.NET Core MVC TempData-cookieszijn.

Als u gegevensbeveiliging wilt configureren om de sleutelring te behouden en te versleutelen, raadpleegt u:

Velden van lange verzoekheader

Standaardinstellingen voor de proxyserver beperken de aanvraagheadervelden doorgaans tot 4 K of 8 K, afhankelijk van het platform. Een app vereist mogelijk velden die langer zijn dan de standaardwaarde (bijvoorbeeld apps die gebruikmaken van Microsoft Entra ID). Als langere velden vereist zijn, moeten de standaardinstellingen van de proxyserver worden aangepast. De waarden die moeten worden toegepast, zijn afhankelijk van het scenario. Zie de documentatie van uw server voor meer informatie.

Waarschuwing

Verhoog de standaardwaarden van proxybuffers niet, tenzij dit nodig is. Door deze waarden te verhogen, wordt het risico van bufferoverschrijding (overloop) en DoS-aanvallen (Denial of Service) door kwaadwillende gebruikers verhoogd.

De app beveiligen

AppArmor inschakelen

Linux Security Modules (LSM) is een framework dat deel uitmaakt van de Linux-kernel sinds Linux 2.6. LSM ondersteunt verschillende implementaties van beveiligingsmodules. AppArmor- is een LSM waarmee een verplicht toegangsbeheersysteem wordt geïmplementeerd, waarmee het programma kan worden beperkt tot een beperkt aantal resources. Zorg ervoor dat AppArmor is ingeschakeld en juist is geconfigureerd.

De firewall configureren

Sluit alle externe poorten die niet in gebruik zijn. Niet-gecompliceerde firewall (ufw) biedt een front-end voor iptables door een CLI te bieden voor het configureren van de firewall.

Waarschuwing

Een firewall voorkomt toegang tot het hele systeem als deze niet juist is geconfigureerd. Als u de juiste SSH-poort niet opgeeft, wordt het systeem vergrendeld als u SSH gebruikt om er verbinding mee te maken. De standaardpoort is 22. Zie de inleiding tot ufw en de handleidingvoor meer informatie.

Installeer ufw en configureer deze zo dat verkeer op de benodigde poorten is toegestaan.

sudo apt-get install ufw

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

sudo ufw enable

Nginx beveiligen

De naam van het Nginx-antwoord wijzigen

src/http/ngx_http_header_filter_module.cbewerken:

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

Opties configureren

Configureer de server met aanvullende vereiste modules. Overweeg om een web-app-firewall, zoals ModSecurity, te gebruiken om de app te beveiligen.

HTTPS-configuratie

de app configureren voor beveiligde (HTTPS) lokale verbindingen

Het dotnet run-commando gebruikt het Properties/launchSettings.json-bestand van de app, waarmee de app wordt geconfigureerd om te luisteren naar de URL's die zijn gegeven door de eigenschap applicationUrl. Bijvoorbeeld https://localhost:5001;http://localhost:5000.

Configureer de app voor het gebruik van een certificaat in ontwikkeling voor de dotnet run opdracht of ontwikkelomgeving (F5- of Ctrl+F5- in Visual Studio Code) met behulp van een van de volgende methoden:

de omgekeerde proxy configureren voor beveiligde (HTTPS)-clientverbindingen

Waarschuwing

De beveiligingsconfiguratie in deze sectie is een algemene configuratie die moet worden gebruikt als uitgangspunt voor verdere aanpassing. We kunnen geen ondersteuning bieden voor hulpprogramma's, servers en besturingssystemen van derden. Gebruik de configuratie in deze sectie op eigen risico. Ga voor meer informatie naar de volgende bronnen:

  • Configureer de server om te luisteren naar HTTPS-verkeer op poort 443 door een geldig certificaat op te geven dat is uitgegeven door een vertrouwde certificeringsinstantie (CA).

  • Beveilig de beveiliging door enkele van de procedures te gebruiken die worden weergegeven in het volgende /etc/nginx/nginx.conf bestand.

  • In het volgende voorbeeld wordt de server niet geconfigureerd om onveilige aanvragen om te leiden. U wordt aangeraden middleware voor HTTPS-omleiding te gebruiken. Zie HTTPS afdwingen in ASP.NET Corevoor meer informatie.

    Notitie

    Voor ontwikkelomgevingen waarbij de serverconfiguratie beveiligde omleiding afhandelt in plaats van HTTPS Redirection Middleware, raden we u aan tijdelijke omleidingen (302) te gebruiken in plaats van permanente omleidingen (301). Het opslaan van koppelingen kan onstabiel gedrag veroorzaken in ontwikkelomgevingen.

  • Door een Strict-Transport-Security -header (HSTS) toe te voegen, zorgt u ervoor dat alle volgende aanvragen van de client via HTTPS worden uitgevoerd. Zie HTTPS afdwingen in ASP.NET Corevoor hulp bij het instellen van de Strict-Transport-Security-header.

  • Als HTTPS in de toekomst wordt uitgeschakeld, gebruikt u een van de volgende methoden:

    • Voeg de HSTS-header niet toe.
    • Kies een korte max-age-waarde.

Voeg het configuratiebestand /etc/nginx/proxy.conf toe:

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;

Vervang de inhoud van het /etc/nginx/nginx.conf configuratiebestand door het volgende bestand. Het voorbeeld bevat zowel http als server secties in één configuratiebestand.

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

Notitie

Blazor WebAssembly-apps een grotere parameterwaarde van burst vereisen om het grotere aantal aanvragen van een app te kunnen verwerken. Zie Host en implementeer ASP.NET Core Blazor WebAssemblyvoor meer informatie.

Notitie

In het voorgaande voorbeeld wordt Online Certificate Status Protocol (OCSP)-koppeling uitgeschakeld. Als dit is ingeschakeld, controleert u of het certificaat de functie ondersteunt. Zie voor meer informatie en richtlijnen over het inschakelen van OCSP de volgende eigenschappen in de Module ngx_http_ssl_module (Nginx-documentatie) artikel:

  • ssl_stapling
  • ssl_stapling_file
  • ssl_stapling_responder
  • ssl_stapling_verify

Nginx beveiligen tegen clickjacking

nl-NL: Clickjacking, ook wel bekend als een UI-verschuivingsaanval, is een kwaadaardige aanval waarbij een websitebezoeker wordt misleid om op een link of knop op een andere pagina te klikken dan ze op dat moment bezoeken. Gebruik X-FRAME-OPTIONS om de site te beveiligen.

Om klikjacking-aanvallen te beperken:

  1. Bewerk het bestand nginx.conf:

    sudo nano /etc/nginx/nginx.conf
    

    Voeg in het codeblok http{} de regel toe: add_header X-Frame-Options "SAMEORIGIN";

  2. Sla het bestand op.

  3. Start Nginx opnieuw.

MIME-type sniffing (het vaststellen van het MIME-type)

Deze header voorkomt dat de meeste browsers het gedeclareerde contenttype van een reactie wijzigen, omdat de header de browser instrueert om het contenttype van de reactie niet te overschrijven. Als de server met de optie nosniff aangeeft dat de inhoud is text/html, wordt deze door de browser weergegeven als text/html.

  1. Bewerk het bestand nginx.conf:

    sudo nano /etc/nginx/nginx.conf
    

    Voeg in het codeblok http{} de regel toe: add_header X-Content-Type-Options "nosniff";

  2. Sla het bestand op.

  3. Start Nginx opnieuw.

Aanvullende Nginx-suggesties

Nadat u het gedeelde framework op de server hebt bijgewerkt, start u de ASP.NET Core-apps die worden gehost door de server opnieuw op.

Aanvullende informatiebronnen

In deze handleiding wordt uitgelegd hoe u een productieklare ASP.NET Core-omgeving instelt op een Ubuntu 16.04-server. Deze instructies werken waarschijnlijk met nieuwere versies van Ubuntu, maar de instructies zijn niet getest met nieuwere versies.

Zie Vereisten voor .NET Core op Linuxvoor informatie over andere Linux-distributies die worden ondersteund door ASP.NET Core.

Notitie

Voor Ubuntu 14.04 wordt supervisord aanbevolen als een oplossing voor het bewaken van het Kestrel proces. systemd is niet beschikbaar op Ubuntu 14.04. Zie de vorige versie van dit onderwerpvoor instructies voor Ubuntu 14.04.

Deze handleiding:

  • Hiermee plaatst u een bestaande ASP.NET Core-app achter een omgekeerde proxyserver.
  • Hiermee stelt u de omgekeerde proxyserver in om aanvragen door te sturen naar de Kestrel webserver.
  • Zorgt ervoor dat de web-app wordt uitgevoerd bij het opstarten als een daemon.
  • Hiermee configureert u een hulpprogramma voor procesbeheer om de web-app opnieuw op te starten.

Voorwaarden

  • Toegang tot een Ubuntu 16.04-server met een standaardgebruikersaccount met sudo-bevoegdheden.
  • De meest recente niet-preview .NET Runtime is geïnstalleerd op de server.
  • Een bestaande ASP.NET Core-app.

Start de ASP.NET Core-apps die worden gehost door de server, opnieuw op elk moment in de toekomst na het upgraden van het gedeelde framework.

De app publiceren en kopiëren

Configureer de app voor een frameworkafhankelijke implementatie.

Als de app lokaal wordt uitgevoerd in de Ontwikkelomgeving en niet is geconfigureerd door de server om beveiligde HTTPS-verbindingen te maken, gaat u op een van de volgende manieren te werk:

  • Configureer de app voor het afhandelen van beveiligde lokale verbindingen. Zie de sectie HTTPS-configuratie voor meer informatie.

  • Configureer de app die moet worden uitgevoerd op het onveilige eindpunt:

    • HTTPS Redirection Middleware deactiveren in de ontwikkelomgeving (Program.cs):

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

      Zie Meerdere omgevingen gebruiken in ASP.NET Corevoor meer informatie.

    • Verwijder https://localhost:5001 (indien aanwezig) uit de eigenschap applicationUrl in het bestand Properties/launchSettings.json.

Zie Meerdere omgevingen gebruiken in ASP.NET Corevoor meer informatie over configuratie per omgeving.

Voer dotnet publish uit vanuit de ontwikkelomgeving om een app in een map te verpakken (bijvoorbeeld bin/Release/{TARGET FRAMEWORK MONIKER}/publish, waarbij de placeholder {TARGET FRAMEWORK MONIKER} de Target Framework Moniker/TFM is) die op de server kan worden uitgevoerd.

dotnet publish --configuration Release

De app kan ook worden gepubliceerd als een zelfstandige implementatie als u de .NET Core-runtime liever niet op de server onderhoudt.

Kopieer de ASP.NET Core-app naar de server met behulp van een hulpprogramma dat is geïntegreerd in de werkstroom van de organisatie (bijvoorbeeld SCP, SFTP). Het is gebruikelijk om web-apps te vinden in de map var (bijvoorbeeld var/www/helloapp).

Notitie

Onder een productie-implementatiescenario voert een werkstroom voor continue integratie het publiceren van de app uit en het kopiëren van de assets naar de server.

De app testen:

  1. Voer vanaf de opdrachtregel de app uit: dotnet <app_assembly>.dll.
  2. Navigeer in een browser naar http://<serveraddress>:<port> om te controleren of de app lokaal werkt op Linux.

Een omgekeerde proxyserver configureren

Een omgekeerde proxy is een algemene installatie voor het leveren van dynamische web-apps. Een omgekeerde proxy beëindigt de HTTP-aanvraag en stuurt deze door naar de ASP.NET Core-app.

Een omgekeerde proxyserver gebruiken

Kestrel is ideaal voor het leveren van dynamische inhoud van ASP.NET Core. De webservicemogelijkheden zijn echter niet zo uitgebreid als servers zoals IIS, Apache of Nginx. Een omgekeerde proxyserver kan werk offloaden, zoals het leveren van statische inhoud, het in de cache opslaan van aanvragen, comprimeren van aanvragen en HTTPS-beëindiging vanaf de HTTP-server. Een omgekeerde proxyserver kan zich op een toegewezen computer bevinden of naast een HTTP-server worden geïmplementeerd.

Voor deze handleiding wordt één exemplaar van Nginx gebruikt. Deze wordt uitgevoerd op dezelfde server, naast de HTTP-server. Op basis van vereisten kan een andere installatie worden gekozen.

Omdat aanvragen worden doorgestuurd via omgekeerde proxy, gebruikt u de Forwarded Headers Middleware uit het Microsoft.AspNetCore.HttpOverrides-pakket. De middleware werkt de Request.Schemebij met behulp van de X-Forwarded-Proto-header, zodat omleidings-URI's en ander beveiligingsbeleid correct werken.

Forwarded Headers Middleware moet worden uitgevoerd voordat andere middleware. Deze volgorde zorgt ervoor dat de middleware die afhankelijk is van informatie over doorgestuurde headers de headerwaarden kan gebruiken voor verwerking. Zie Doorgeschakelde headers Middlewareom Middleware voor doorgestuurde headers uit te voeren na diagnose en foutafhandeling van middleware.

Roep de methode UseForwardedHeaders boven aan Program.cs aan voordat u andere middleware aanroept. Configureer de middleware om de X-Forwarded-For en X-Forwarded-Proto headers door te sturen:

// requires using Microsoft.AspNetCore.HttpOverrides;
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

Als er geen ForwardedHeadersOptions zijn opgegeven voor de middleware, worden de standaardheaders die moeten worden doorgestuurd None.

Proxy's die worden uitgevoerd op loopback-adressen (127.0.0.0/8, [::1]), inclusief het standaard localhost-adres (127.0.0.1), worden standaard vertrouwd. Als andere vertrouwde proxy's of netwerken binnen de organisatie aanvragen verwerken tussen internet en de webserver, voegt u deze toe aan de lijst met KnownProxies of KnownNetworks met ForwardedHeadersOptions. In het volgende voorbeeld wordt een vertrouwde proxyserver op IP-adres 10.0.0.100 toegevoegd aan de Forwarded Headers Middleware KnownProxies in Program.cs.

using System.Net;

var builder = WebApplication.CreateBuilder(args);

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

Zie ASP.NET Core configureren voor gebruik met proxyservers en load balancersvoor meer informatie.

Nginx installeren

Gebruik apt-get om Nginx te installeren. Het installatieprogramma maakt een systemd init-script dat Nginx uitvoert als daemon bij het opstarten van het systeem. Volg de installatie-instructies voor Ubuntu op Nginx: Officiële Debian/Ubuntu-pakketten.

Notitie

Als optionele Nginx-modules vereist zijn, is het bouwen van Nginx vanuit de bron mogelijk vereist.

Omdat Nginx voor het eerst is geïnstalleerd, start u deze expliciet door het volgende uit te voeren:

sudo service nginx start

Controleer of in een browser de standaardlandingspagina voor Nginx wordt weergegeven. De landingspagina is bereikbaar op http://<server_IP_address>/index.nginx-debian.html.

Nginx configureren

Als u Nginx wilt configureren als een omgekeerde proxy om HTTP-aanvragen door te sturen naar uw ASP.NET Core-app, wijzigt u /etc/nginx/sites-available/default. Open deze in een teksteditor en vervang de inhoud door het volgende fragment:

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

Als de app een SignalR- of Blazor Server-app is, raadpleeg dan voor meer informatie ASP.NET Core SignalR producthosting en schaalvergroting van en Host en implementeer ASP.NET Core server-side Blazor apps.

Als er geen server_name overeenkomsten zijn, gebruikt Nginx de standaardserver. Als er geen standaardserver is gedefinieerd, is de eerste server in het configuratiebestand de standaardserver. Voeg als best practice een specifieke standaardserver toe die een statuscode van 444 in uw configuratiebestand retourneert. Een voorbeeld van een standaardserverconfiguratie is:

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

Met het voorgaande configuratiebestand en de standaardserver accepteert Nginx openbaar verkeer op poort 80 met hostheader example.com of *.example.com. Aanvragen die niet overeenkomen met deze hosts, worden niet doorgestuurd naar Kestrel. Nginx stuurt de overeenkomende aanvragen door naar Kestrel op http://127.0.0.1:5000. Zie Hoe nginx een aanvraag verwerktvoor meer informatie. Zie Kestrel: Eindpuntconfiguratieals u het IP-adres/de poort van Kestrelwilt wijzigen.

Waarschuwing

Als u geen juiste server_name instructie opgeeft uw app blootstelt aan beveiligingsproblemen. Subdomein-jokertekenbinding (bijvoorbeeld *.example.com) vormt dit beveiligingsrisico niet als u het hele bovenliggende domein bepaalt (in tegenstelling tot *.com, wat kwetsbaar is). Zie RFC 9110: HTTP-semantiek (sectie 7.2: Host en :authority)voor meer informatie.

Zodra de Nginx-configuratie tot stand is gebracht, voert u sudo nginx -t uit om de syntaxis van de configuratiebestanden te controleren. Als de test van het configuratiebestand is geslaagd, dwingt u Nginx af om de wijzigingen op te halen door sudo nginx -s reloaduit te voeren.

De app rechtstreeks uitvoeren op de server:

  1. Navigeer naar de map van de app.
  2. Voer de app uit: dotnet <app_assembly.dll>, waarbij app_assembly.dll de assemblybestandsnaam van de app is.

Als de app wordt uitgevoerd op de server, maar niet via internet reageert, controleert u de firewall van de server en controleert u of poort 80 is geopend. Als u een Virtuele Azure Ubuntu-machine gebruikt, voegt u een NSG-regel (Network Security Group) toe waarmee binnenkomend poort 80-verkeer wordt ingeschakeld. U hoeft geen regel voor uitgaande poort 80 in te schakelen, omdat het uitgaande verkeer automatisch wordt verleend wanneer de regel voor binnenkomend verkeer is ingeschakeld.

Wanneer u klaar bent met het testen van de app, sluit u de app af met Ctrl+C- in de opdrachtshell.

De app bewaken

De server is ingesteld voor het doorsturen van aanvragen naar http://<serveraddress>:80 naar de ASP.NET Core-app die wordt uitgevoerd op Kestrel op http://127.0.0.1:5000. Nginx is echter niet ingesteld voor het beheren van het Kestrel proces. systemd kan worden gebruikt om een servicebestand te maken om de onderliggende web-app te starten en te bewaken. systemd is een init-systeem dat veel krachtige functies biedt voor het starten, stoppen en beheren van processen.

Het servicebestand maken

Maak het servicedefinitiebestand:

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

Het volgende voorbeeld is een servicebestand voor de app:

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

[Install]
WantedBy=multi-user.target

In het voorgaande voorbeeld wordt de gebruiker die de service beheert, opgegeven door de optie User. De gebruiker (www-data) moet aanwezig zijn en over het juiste eigendom van de bestanden van de app beschikken.

Gebruik TimeoutStopSec om de tijdsduur te configureren die moet worden gewacht totdat de app wordt afgesloten nadat het eerste interruptsignaal is ontvangen. Als de app in deze periode niet wordt afgesloten, zal SIGKILL worden ingezet om de app te beëindigen. Geef de waarde op als seconden zonder eenheid (bijvoorbeeld 150), een tijdspannewaarde (bijvoorbeeld 2min 30s) of infinity om de time-out uit te schakelen. TimeoutStopSec stelt zich standaard in op de waarde van DefaultTimeoutStopSec in het configuratiebestand van de manager (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). De standaardtime-out voor de meeste distributies is 90 seconden.

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

Linux heeft een hoofdlettergevoelig bestandssysteem. Het instellen van ASPNETCORE_ENVIRONMENT op Production leidt ertoe dat wordt gezocht naar het configuratiebestand appsettings.Production.json, niet appsettings.production.json.

Sommige waarden (bijvoorbeeld SQL-verbindingsreeksen) moeten zijn geëscaped zodat de configuratieproviders de omgevingsvariabelen kunnen lezen. Gebruik de volgende opdracht om een correct escape-waarde te genereren voor gebruik in het configuratiebestand:

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

Dubbele puntscheidingstekens (:) worden niet ondersteund in namen van omgevingsvariabelen. Gebruik een dubbele onderstrepingsteken (__) in plaats van een dubbele punt. De configuratieprovider voor omgevingsvariabelen converteert dubbele onderstrepingstekens naar dubbele punten wanneer omgevingsvariabelen worden gelezen in de configuratie. In het volgende voorbeeld wordt de verbindingsreekssleutel ConnectionStrings:DefaultConnection ingesteld in het servicedefinitiebestand als ConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Sla het bestand op en schakel de service in.

sudo systemctl enable kestrel-helloapp.service

Start de service en controleer of deze wordt uitgevoerd.

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

Wanneer de omgekeerde proxy is geconfigureerd en Kestrel beheerd via systemd, is de web-app volledig geconfigureerd en kan deze worden geopend vanuit een browser op de lokale computer op http://localhost. Het is ook toegankelijk vanaf een afstandscomputer, tenzij een firewall die mogelijk de toegang blokkeert. Als je de response-headers inspecteert, toont de Server-header dat de ASP.NET Core-app wordt geleverd door 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

Logboeken weergeven

Omdat de web-app die gebruikmaakt van Kestrel wordt beheerd met systemd, worden alle gebeurtenissen en processen vastgelegd in een gecentraliseerd logboek. Dit logboek bevat echter alle vermeldingen voor alle services en processen die worden beheerd door systemd. Gebruik de volgende opdracht om de kestrel-helloapp.service-specifieke items weer te geven:

sudo journalctl -fu kestrel-helloapp.service

Voor verdere filtering kunnen tijdsopties zoals --since today, --until 1 hour agoof een combinatie hiervan het aantal geretourneerde items verminderen.

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

Gegevensbescherming

De ASP.NET Core Data Protection-stack wordt gebruikt door verschillende ASP.NET Core middleware, waaronder authenticatie-middleware (bijvoorbeeld cookie middleware) en beveiliging tegen cross-site request forgery (CSRF). Zelfs als gegevensbeveiligings-API's niet worden aangeroepen door gebruikerscode, moet gegevensbeveiliging worden geconfigureerd voor het maken van een permanente cryptografische sleutelarchief. Als gegevensbeveiliging niet is geconfigureerd, worden de sleutels in het geheugen bewaard en verwijderd wanneer de app opnieuw wordt opgestart.

Als de sleutelring wordt opgeslagen in het geheugen wanneer de app opnieuw wordt opgestart:

  • Alle op cookiegebaseerde verificatietokens zijn ongeldig.
  • Gebruikers moeten zich opnieuw aanmelden bij hun volgende aanvraag.
  • Gegevens die met de sleutelring zijn beveiligd, kunnen niet meer worden ontsleuteld. Dit kan CSRF-tokens en ASP.NET Core MVC TempData-cookieszijn.

Als u gegevensbeveiliging wilt configureren om de sleutelring te behouden en te versleutelen, raadpleegt u:

Lange velden voor verzoekkoptekst

Standaardinstellingen voor de proxyserver beperken de aanvraagheadervelden doorgaans tot 4 K of 8 K, afhankelijk van het platform. Een app vereist mogelijk velden die langer zijn dan de standaardwaarde (bijvoorbeeld apps die gebruikmaken van Azure Active Directory-). Als langere velden vereist zijn, moeten de standaardinstellingen van de proxyserver worden aangepast. De waarden die moeten worden toegepast, zijn afhankelijk van het scenario. Zie de documentatie van uw server voor meer informatie.

Waarschuwing

Verhoog de standaardwaarden van proxybuffers niet, tenzij dit nodig is. Door deze waarden te verhogen, wordt het risico van bufferoverschrijding (overloop) en DoS-aanvallen (Denial of Service) door kwaadwillende gebruikers verhoogd.

De app beveiligen

AppArmor inschakelen

Linux Security Modules (LSM) is een framework dat deel uitmaakt van de Linux-kernel sinds Linux 2.6. LSM ondersteunt verschillende implementaties van beveiligingsmodules. AppArmor- is een LSM waarmee een verplicht toegangsbeheersysteem wordt geïmplementeerd, waarmee het programma kan worden beperkt tot een beperkt aantal resources. Zorg ervoor dat AppArmor is ingeschakeld en juist is geconfigureerd.

De firewall configureren

Sluit alle externe poorten die niet in gebruik zijn. Niet-gecompliceerde firewall (ufw) biedt een front-end voor iptables door een CLI te bieden voor het configureren van de firewall.

Waarschuwing

Een firewall voorkomt toegang tot het hele systeem als deze niet juist is geconfigureerd. Als u niet de juiste SSH-poort opgeeft, wordt het systeem vergrendeld als u SSH gebruikt om er verbinding mee te maken. De standaardpoort is 22. Zie de inleiding tot ufw en de handleidingvoor meer informatie.

Installeer ufw en configureer deze zo dat verkeer op de benodigde poorten is toegestaan.

sudo apt-get install ufw

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

sudo ufw enable

Nginx beveiligen

De naam van het Nginx-antwoord wijzigen

src/http/ngx_http_header_filter_module.cbewerken:

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

Opties configureren

Configureer de server met aanvullende vereiste modules. Overweeg om een web-app-firewall, zoals ModSecurity, te gebruiken om de app te beveiligen.

HTTPS-configuratie

de app configureren voor beveiligde (HTTPS) lokale verbindingen

De dotnet run-commando maakt gebruik van het Properties/launchSettings.json-bestand van de app, waarmee de app wordt geconfigureerd om te luisteren naar de URL's die door de eigenschap applicationUrl worden opgegeven. Bijvoorbeeld https://localhost:5001;http://localhost:5000.

Configureer de app voor het gebruik van een certificaat in ontwikkeling voor de dotnet run opdracht of ontwikkelomgeving (F5- of Ctrl+F5- in Visual Studio Code) met behulp van een van de volgende methoden:

de omgekeerde proxy configureren voor beveiligde (HTTPS)-clientverbindingen

Waarschuwing

De beveiligingsconfiguratie in deze sectie is een algemene configuratie die moet worden gebruikt als uitgangspunt voor verdere aanpassing. We kunnen geen ondersteuning bieden voor hulpprogramma's, servers en besturingssystemen van derden. Gebruik de configuratie in deze sectie op eigen risico. Ga voor meer informatie naar de volgende bronnen:

  • Configureer de server om te luisteren naar HTTPS-verkeer op poort 443 door een geldig certificaat op te geven dat is uitgegeven door een vertrouwde certificeringsinstantie (CA).

  • Beveilig de beveiliging door enkele van de procedures te gebruiken die worden weergegeven in het volgende /etc/nginx/nginx.conf bestand.

  • In het volgende voorbeeld wordt de server niet geconfigureerd om onveilige aanvragen om te leiden. U wordt aangeraden middleware voor HTTPS-omleiding te gebruiken. Zie HTTPS afdwingen in ASP.NET Corevoor meer informatie.

    Notitie

    Voor ontwikkelomgevingen waarbij de serverconfiguratie beveiligde omleiding afhandelt in plaats van HTTPS Redirection Middleware, raden we u aan tijdelijke omleidingen (302) te gebruiken in plaats van permanente omleidingen (301). Het opslaan van koppelingen kan onstabiel gedrag veroorzaken in ontwikkelomgevingen.

  • Door een Strict-Transport-Security -header (HSTS) toe te voegen, zorgt u ervoor dat alle volgende aanvragen van de client via HTTPS worden uitgevoerd. Zie HTTPS afdwingen in ASP.NET Corevoor hulp bij het instellen van de Strict-Transport-Security-header.

  • Als HTTPS in de toekomst wordt uitgeschakeld, gebruikt u een van de volgende methoden:

    • Voeg de HSTS-header niet toe.
    • Kies een korte max-age-waarde.

Voeg het configuratiebestand /etc/nginx/proxy.conf toe:

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;

Vervang de inhoud van het /etc/nginx/nginx.conf configuratiebestand door het volgende bestand. Het voorbeeld bevat zowel http als server secties in één configuratiebestand.

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

Notitie

Blazor WebAssembly-apps een grotere parameterwaarde van burst vereisen om het grotere aantal aanvragen van een app te kunnen verwerken. Zie Host en implementeer ASP.NET Core Blazor WebAssemblyvoor meer informatie.

Notitie

In het voorgaande voorbeeld wordt OCSP-koppeling (Online Certificate Status Protocol) uitgeschakeld. Als dit is ingeschakeld, controleert u of het certificaat de functie ondersteunt. Zie voor meer informatie en richtlijnen over het inschakelen van OCSP de volgende eigenschappen in de Module ngx_http_ssl_module (Nginx-documentatie) artikel:

  • ssl_stapling
  • ssl_stapling_file
  • ssl_stapling_responder
  • ssl_stapling_verify

Nginx beveiligen tegen clickjacking

Clickjacking, ook wel bekend als een UI-misleiding aanval, is een kwaadaardige aanval waarbij een websitebezoeker wordt misleid om op een andere pagina op een koppeling of knop te klikken dan de pagina die ze momenteel bezoeken. Gebruik X-FRAME-OPTIONS om de site te beveiligen.

Klikjackingaanvallen beperken:

  1. Bewerk het bestand nginx.conf:

    sudo nano /etc/nginx/nginx.conf
    

    Voeg de regel toe: add_header X-Frame-Options "SAMEORIGIN";

  2. Sla het bestand op.

  3. Start Nginx opnieuw.

MIME-type sniffing (het herkennen van MIME-typen)

Deze header voorkomt dat de meeste browsers een antwoord van het gedeclareerde inhoudstype verwijderen, omdat de header de browser instrueert om het inhoudstype van het antwoord niet te overschrijven. Als de server met de optie nosniff aangeeft dat de inhoud is text/html, wordt deze door de browser weergegeven als text/html.

  1. Bewerk het bestand nginx.conf:

    sudo nano /etc/nginx/nginx.conf
    

    Voeg de regel toe: add_header X-Content-Type-Options "nosniff";

  2. Sla het bestand op.

  3. Start Nginx opnieuw.

Aanvullende Nginx-suggesties

Nadat u het gedeelde framework op de server hebt bijgewerkt, start u de ASP.NET Core-apps die worden gehost door de server opnieuw op.

Aanvullende informatiebronnen

In deze handleiding wordt uitgelegd hoe u een productieklare ASP.NET Core-omgeving instelt op een Ubuntu 16.04-server. Deze instructies werken waarschijnlijk met nieuwere versies van Ubuntu, maar de instructies zijn niet getest met nieuwere versies.

Zie Vereisten voor .NET Core op Linuxvoor informatie over andere Linux-distributies die worden ondersteund door ASP.NET Core.

Notitie

Voor Ubuntu 14.04 wordt supervisord aanbevolen als een oplossing voor het bewaken van het Kestrel proces. systemd is niet beschikbaar op Ubuntu 14.04. Zie de vorige versie van dit onderwerpvoor instructies voor Ubuntu 14.04.

Deze handleiding:

  • Hiermee plaatst u een bestaande ASP.NET Core-app achter een omgekeerde proxyserver.
  • Hiermee stelt u de omgekeerde proxyserver in om aanvragen door te sturen naar de Kestrel webserver.
  • Zorgt ervoor dat de web-app wordt uitgevoerd bij het opstarten als een daemon.
  • Hiermee configureert u een hulpprogramma voor procesbeheer om de web-app opnieuw op te starten.

Voorwaarden

  • Toegang tot een Ubuntu 16.04-server met een standaardgebruikersaccount met sudo-bevoegdheden.
  • De nieuwste niet-previewversie van de .NET-Runtime is op de server geïnstalleerd.
  • Een bestaande ASP.NET Core-app.

Start de ASP.NET Core-apps die worden gehost door de server, opnieuw op elk moment in de toekomst na het upgraden van het gedeelde framework.

De app publiceren en kopiëren

Configureer de app voor een frameworkafhankelijke implementatie.

Als de app lokaal wordt uitgevoerd in de Ontwikkelomgeving en niet is geconfigureerd door de server om beveiligde HTTPS-verbindingen te maken, gaat u op een van de volgende manieren te werk:

  • Configureer de app voor het afhandelen van beveiligde lokale verbindingen. Zie de sectie HTTPS-configuratie voor meer informatie.

  • Configureer de app die moet worden uitgevoerd op het onveilige eindpunt:

    • HTTPS Redirection Middleware deactiveren in de ontwikkelomgeving (Program.cs):

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

      Zie Meerdere omgevingen gebruiken in ASP.NET Corevoor meer informatie.

    • Verwijder https://localhost:5001 (indien aanwezig) uit de eigenschap applicationUrl in het bestand Properties/launchSettings.json.

Zie Meerdere omgevingen gebruiken in ASP.NET Corevoor meer informatie over configuratie per omgeving.

Voer het commando dotnet publish uit vanuit de ontwikkelomgeving om een app te verpakken in een map (bijvoorbeeld bin/Release/{TARGET FRAMEWORK MONIKER}/publish), waarbij de tijdelijke aanduiding {TARGET FRAMEWORK MONIKER} staat voor het Target Framework Moniker/TFM, zodat deze op de server kan draaien.

dotnet publish --configuration Release

De app kan ook worden gepubliceerd als een zelfstandige implementatie als u de .NET Core-runtime liever niet op de server onderhoudt.

Kopieer de ASP.NET Core-app naar de server met behulp van een hulpprogramma dat is geïntegreerd in de werkstroom van de organisatie (bijvoorbeeld SCP, SFTP). Het is gebruikelijk om web-apps te vinden in de map var (bijvoorbeeld var/www/helloapp).

Notitie

Onder een productie-implementatiescenario voert een werkstroom voor continue integratie het publiceren van de app uit en het kopiëren van de assets naar de server.

De app testen:

  1. Voer vanaf de opdrachtregel de app uit: dotnet <app_assembly>.dll.
  2. Navigeer in een browser naar http://<serveraddress>:<port> om te controleren of de app lokaal werkt op Linux.

Een omgekeerde proxyserver configureren

Een omgekeerde proxy is een algemene installatie voor het leveren van dynamische web-apps. Een omgekeerde proxy beëindigt de HTTP-aanvraag en stuurt deze door naar de ASP.NET Core-app.

Een omgekeerde proxyserver gebruiken

Kestrel is ideaal voor het leveren van dynamische inhoud van ASP.NET Core. De webservicemogelijkheden zijn echter niet zo uitgebreid als servers zoals IIS, Apache of Nginx. Een omgekeerde proxyserver kan werk offloaden, zoals het leveren van statische inhoud, het in de cache opslaan van aanvragen, comprimeren van aanvragen en HTTPS-beëindiging vanaf de HTTP-server. Een omgekeerde proxyserver kan zich op een toegewezen computer bevinden of naast een HTTP-server worden geïmplementeerd.

Voor deze handleiding wordt één exemplaar van Nginx gebruikt. Deze wordt uitgevoerd op dezelfde server, naast de HTTP-server. Op basis van vereisten kan een andere installatie worden gekozen.

Omdat aanvragen worden doorgestuurd via omgekeerde proxy, gebruikt u de Forwarded Headers Middleware uit het Microsoft.AspNetCore.HttpOverrides-pakket. De middleware werkt de Request.Schemebij met behulp van de X-Forwarded-Proto-header, zodat omleidings-URI's en ander beveiligingsbeleid correct werken.

"Forwarded Headers Middleware" moet worden uitgevoerd voordat andere middleware. Deze volgorde zorgt ervoor dat de middleware die afhankelijk is van informatie over doorgestuurde headers de headerwaarden kan gebruiken voor verwerking. Zie Doorgeschakelde Headers Middlewareom de middleware voor doorgeschakelde headers na de diagnostische en foutafhandelende middleware uit te voeren.

Roep de methode UseForwardedHeaders boven aan Startup.Configure aan voordat u andere middleware aanroept. Configureer de middleware om de X-Forwarded-For en X-Forwarded-Proto headers door te sturen:

using Microsoft.AspNetCore.HttpOverrides;

...

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

app.UseAuthentication();

Als er geen ForwardedHeadersOptions zijn opgegeven voor de middleware, worden de standaardheaders die moeten worden doorgestuurd None.

Proxy's die worden uitgevoerd op loopback-adressen (127.0.0.0/8, [::1]), inclusief het standaard localhost-adres (127.0.0.1), worden standaard vertrouwd. Als andere vertrouwde proxy's of netwerken binnen de organisatie aanvragen verwerken tussen internet en de webserver, voegt u deze toe aan de lijst met KnownProxies of KnownNetworks met ForwardedHeadersOptions. In het volgende voorbeeld wordt een vertrouwde proxyserver op IP-adres 10.0.0.100 toegevoegd aan de doorstuurkoppenmiddleware KnownProxies in Startup.ConfigureServices.

using System.Net;

...

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

Zie ASP.NET Core configureren voor gebruik met proxyservers en load balancersvoor meer informatie.

Nginx installeren

Gebruik apt-get om Nginx te installeren. Het installatieprogramma maakt een systemd init-script dat Nginx uitvoert als daemon bij het opstarten van het systeem. Volg de installatie-instructies voor Ubuntu op Nginx: Officiële Debian/Ubuntu-pakketten.

Notitie

Als optionele Nginx-modules vereist zijn, is het bouwen van Nginx vanuit de bron mogelijk vereist.

Omdat Nginx voor het eerst is geïnstalleerd, start u deze expliciet door het volgende uit te voeren:

sudo service nginx start

Controleer of in een browser de standaardlandingspagina voor Nginx wordt weergegeven. De landingspagina is bereikbaar op http://<server_IP_address>/index.nginx-debian.html.

Nginx configureren

Als u Nginx wilt configureren als een omgekeerde proxy om HTTP-aanvragen door te sturen naar uw ASP.NET Core-app, wijzigt u /etc/nginx/sites-available/default. Open deze in een teksteditor en vervang de inhoud door het volgende fragment:

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

Als de app een SignalR- of Blazor Server-app is, raadpleeg dan ASP.NET Core SignalR productiehosting en schaalvergroting en Hosten en implementeren van ASP.NET Core server-side Blazor apps voor meer informatie.

Als er geen server_name overeenkomsten zijn, gebruikt Nginx de standaardserver. Als er geen standaardserver is gedefinieerd, is de eerste server in het configuratiebestand de standaardserver. Voeg als best practice een specifieke standaardserver toe die een statuscode van 444 in uw configuratiebestand retourneert. Een voorbeeld van een standaardserverconfiguratie is:

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

Met het voorgaande configuratiebestand en de standaardserver accepteert Nginx openbaar verkeer op poort 80 met hostheader example.com of *.example.com. Aanvragen die niet overeenkomen met deze hosts, worden niet doorgestuurd naar Kestrel. Nginx stuurt de overeenkomende aanvragen door naar Kestrel op http://127.0.0.1:5000. Zie Hoe nginx een aanvraag verwerktvoor meer informatie. Zie Kestrel: Eindpuntconfiguratieals u het IP-adres/de poort van Kestrelwilt wijzigen.

Waarschuwing

Als u geen juiste richtlijn voor server_name opgeeft, kan uw app worden blootgesteld aan beveiligingsproblemen. Subdomein-jokertekenbinding (bijvoorbeeld *.example.com) vormt dit beveiligingsrisico niet als u het hele bovenliggende domein bepaalt (in tegenstelling tot *.com, wat kwetsbaar is). Zie RFC 9110: HTTP-semantiek (sectie 7.2: Host en :authority)voor meer informatie.

Zodra de Nginx-configuratie tot stand is gebracht, voert u sudo nginx -t uit om de syntaxis van de configuratiebestanden te controleren. Als de test van het configuratiebestand is geslaagd, dwingt u Nginx af om de wijzigingen op te halen door sudo nginx -s reloaduit te voeren.

De app rechtstreeks uitvoeren op de server:

  1. Navigeer naar de map van de app.
  2. Voer de app uit: dotnet <app_assembly.dll>, waarbij app_assembly.dll de assemblybestandsnaam van de app is.

Als de app wordt uitgevoerd op de server, maar niet via internet reageert, controleert u de firewall van de server en controleert u of poort 80 is geopend. Als u een Virtuele Azure Ubuntu-machine gebruikt, voegt u een NSG-regel (Network Security Group) toe waarmee binnenkomend poort 80-verkeer wordt ingeschakeld. U hoeft geen regel voor uitgaande poort 80 in te schakelen, omdat het uitgaande verkeer automatisch wordt verleend wanneer de regel voor binnenkomend verkeer is ingeschakeld.

Wanneer u klaar bent met het testen van de app, sluit u de app af met Ctrl+C- in de opdrachtshell.

De app bewaken

De server is ingesteld voor het doorsturen van aanvragen naar http://<serveraddress>:80 naar de ASP.NET Core-app die wordt uitgevoerd op Kestrel op http://127.0.0.1:5000. Nginx is echter niet ingesteld voor het beheren van het Kestrel proces. systemd kan worden gebruikt om een servicebestand te maken om de onderliggende web-app te starten en te bewaken. systemd is een init-systeem dat veel krachtige functies biedt voor het starten, stoppen en beheren van processen.

Het servicebestand maken

Maak het servicedefinitiebestand:

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

Het volgende voorbeeld is een servicebestand voor de app:

[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

In het voorgaande voorbeeld wordt de gebruiker die de service beheert, opgegeven door de optie User. De gebruiker (www-data) moet bestaan en over de correcte eigendomsrechten van de bestanden van de app beschikken.

Gebruik TimeoutStopSec om de tijdsduur te configureren die moet worden gewacht totdat de app wordt afgesloten nadat het eerste interruptsignaal is ontvangen. Als de app in deze periode niet wordt afgesloten, wordt SIGKILL verzonden om de app af te sluiten. Geef de waarde op als seconden zonder eenheid (bijvoorbeeld 150), een tijdspannewaarde (bijvoorbeeld 2min 30s) of infinity om de time-out uit te schakelen. TimeoutStopSec heeft standaard de waarde van DefaultTimeoutStopSec in het manager-configuratiebestand (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). De standaardtime-out voor de meeste distributies is 90 seconden.

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

Linux heeft een hoofdlettergevoelig bestandssysteem. Als u ASPNETCORE_ENVIRONMENT instelt op Production, leidt dit ertoe dat er wordt gezocht naar het configuratiebestand appsettings.Production.jsonin plaats van appsettings.production.json.

Sommige waarden (bijvoorbeeld SQL-verbindingsreeksen) moeten worden aangepast zodat configuratieproviders de omgevingsvariabelen kunnen lezen. Gebruik de volgende opdracht om een correct escape-waarde te genereren voor gebruik in het configuratiebestand:

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

Dubbele puntscheidingstekens (:) worden niet ondersteund in namen van omgevingsvariabelen. Gebruik een dubbele onderstrepingsteken (__) in plaats van een dubbele punt. De configuratieprovider voor omgevingsvariabelen converteert dubbele onderstrepingstekens naar dubbele punten wanneer omgevingsvariabelen worden gelezen in de configuratie. In het volgende voorbeeld wordt de verbindingsreekssleutel ConnectionStrings:DefaultConnection ingesteld in het servicedefinitiebestand als ConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Sla het bestand op en schakel de service in.

sudo systemctl enable kestrel-helloapp.service

Start de service en controleer of deze wordt uitgevoerd.

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

Wanneer de omgekeerde proxy is geconfigureerd en Kestrel beheerd via systemd, is de web-app volledig geconfigureerd en kan deze worden geopend vanuit een browser op de lokale computer op http://localhost. Het is ook toegankelijk vanaf een externe computer, tenzij een firewall dit verhindert. Als je de antwoordheaders inspecteert, toont de Server koptekst de ASP.NET Core-app die door Kestrelwordt gehost.

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

Logboeken weergeven

Omdat de web-app die gebruikmaakt van Kestrel wordt beheerd met systemd, worden alle gebeurtenissen en processen vastgelegd in een gecentraliseerd logboek. Dit logboek bevat echter alle vermeldingen voor alle services en processen die worden beheerd door systemd. Gebruik de volgende opdracht om de kestrel-helloapp.service-specifieke items weer te geven:

sudo journalctl -fu kestrel-helloapp.service

Voor verdere filtering kunnen tijdsopties zoals --since today, --until 1 hour agoof een combinatie hiervan het aantal geretourneerde items verminderen.

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

Gegevensbescherming

De ASP.NET Core Data Protection-stack wordt gebruikt door verschillende ASP.NET Core middlewares, waaronder verificatie-middleware (bijvoorbeeld cookie middleware) en CSRF-beveiliging (cross-site request forgery). Zelfs als gegevensbeveiligings-API's niet worden aangeroepen door gebruikerscode, moet gegevensbeveiliging worden geconfigureerd voor het maken van een permanente cryptografische sleutelarchief. Als gegevensbeveiliging niet is geconfigureerd, worden de sleutels in het geheugen bewaard en verwijderd wanneer de app opnieuw wordt opgestart.

Als de sleutelring wordt opgeslagen in het geheugen wanneer de app opnieuw wordt opgestart:

  • Alle op cookiegebaseerde verificatietokens zijn ongeldig.
  • Gebruikers moeten zich opnieuw aanmelden bij hun volgende aanvraag.
  • Gegevens die met de sleutelring zijn beveiligd, kunnen niet meer worden ontsleuteld. Dit kan CSRF-tokens en ASP.NET Core MVC TempData-cookieszijn.

Als u gegevensbeveiliging wilt configureren om de sleutelring te behouden en te versleutelen, raadpleegt u:

Lange velden voor aanvraagheaders

Standaardinstellingen voor de proxyserver beperken de aanvraagheadervelden doorgaans tot 4 K of 8 K, afhankelijk van het platform. Een app vereist mogelijk velden die langer zijn dan de standaardwaarde (bijvoorbeeld apps die gebruikmaken van Azure Active Directory-). Als langere velden vereist zijn, moeten de standaardinstellingen van de proxyserver worden aangepast. De waarden die moeten worden toegepast, zijn afhankelijk van het scenario. Zie de documentatie van uw server voor meer informatie.

Waarschuwing

Verhoog de standaardwaarden van proxybuffers niet, tenzij dit nodig is. Door deze waarden te verhogen, wordt het risico van bufferoverschrijding (overloop) en DoS-aanvallen (Denial of Service) door kwaadwillende gebruikers verhoogd.

De app beveiligen

AppArmor inschakelen

Linux Security Modules (LSM) is een framework dat deel uitmaakt van de Linux-kernel sinds Linux 2.6. LSM ondersteunt verschillende implementaties van beveiligingsmodules. AppArmor- is een LSM waarmee een verplicht toegangsbeheersysteem wordt geïmplementeerd, waarmee het programma kan worden beperkt tot een beperkt aantal resources. Zorg ervoor dat AppArmor is ingeschakeld en juist is geconfigureerd.

De firewall configureren

Sluit alle externe poorten die niet in gebruik zijn. Niet-gecompliceerde firewall (ufw) biedt een front-end voor iptables door een CLI te bieden voor het configureren van de firewall.

Waarschuwing

Een firewall voorkomt toegang tot het hele systeem als deze niet juist is geconfigureerd. Als u niet de juiste SSH-poort opgeeft, wordt het systeem vergrendeld als u SSH gebruikt om er verbinding mee te maken. De standaardpoort is 22. Zie voor meer informatie de inleiding tot ufw en de handleiding.

Installeer ufw en configureer deze zo dat verkeer op de benodigde poorten is toegestaan.

sudo apt-get install ufw

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

sudo ufw enable

Nginx beveiligen

De naam van het Nginx-antwoord wijzigen

src/http/ngx_http_header_filter_module.cbewerken:

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

Opties configureren

Configureer de server met aanvullende vereiste modules. Overweeg om een web-app-firewall, zoals ModSecurity, te gebruiken om de app te beveiligen.

HTTPS-configuratie

de app configureren voor beveiligde (HTTPS) lokale verbindingen

De dotnet run opdracht gebruikt het Properties/launchSettings.json-bestand van de app, die de app configureert om te luisteren naar de URL's die zijn opgegeven door de eigenschap applicationUrl. Bijvoorbeeld https://localhost:5001;http://localhost:5000.

Configureer de app voor het gebruik van een certificaat in ontwikkeling voor de dotnet run opdracht of ontwikkelomgeving (F5- of Ctrl+F5- in Visual Studio Code) met behulp van een van de volgende methoden:

de omgekeerde proxy configureren voor beveiligde (HTTPS)-clientverbindingen

Waarschuwing

De beveiligingsconfiguratie in deze sectie is een algemene configuratie die moet worden gebruikt als uitgangspunt voor verdere aanpassing. We kunnen geen ondersteuning bieden voor hulpprogramma's, servers en besturingssystemen van derden. Gebruik de configuratie in deze sectie op eigen risico. Ga voor meer informatie naar de volgende bronnen:

  • Configureer de server om te luisteren naar HTTPS-verkeer op poort 443 door een geldig certificaat op te geven dat is uitgegeven door een vertrouwde certificeringsinstantie (CA).

  • Beveilig de beveiliging door enkele van de procedures te gebruiken die worden weergegeven in het volgende /etc/nginx/nginx.conf bestand.

  • In het volgende voorbeeld wordt de server niet geconfigureerd om onveilige aanvragen om te leiden. U wordt aangeraden middleware voor HTTPS-omleiding te gebruiken. Zie HTTPS afdwingen in ASP.NET Corevoor meer informatie.

    Notitie

    Voor ontwikkelomgevingen waarbij de serverconfiguratie beveiligde omleiding afhandelt in plaats van HTTPS Redirection Middleware, raden we u aan tijdelijke omleidingen (302) te gebruiken in plaats van permanente omleidingen (301). Het opslaan van koppelingen kan onstabiel gedrag veroorzaken in ontwikkelomgevingen.

  • Door een Strict-Transport-Security -header (HSTS) toe te voegen, zorgt u ervoor dat alle volgende aanvragen van de client via HTTPS worden uitgevoerd. Zie HTTPS afdwingen in ASP.NET Corevoor hulp bij het instellen van de Strict-Transport-Security-header.

  • Als HTTPS in de toekomst wordt uitgeschakeld, gebruikt u een van de volgende methoden:

    • Voeg de HSTS-header niet toe.
    • Kies een korte max-age waarde.

Voeg het configuratiebestand /etc/nginx/proxy.conf toe:

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;

Vervang de inhoud van het /etc/nginx/nginx.conf configuratiebestand door het volgende bestand. Het voorbeeld bevat zowel http als server secties in één configuratiebestand.

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

Notitie

Blazor WebAssembly-apps een grotere parameterwaarde van burst vereisen om het grotere aantal aanvragen van een app te kunnen verwerken. Zie Host en implementeer ASP.NET Core Blazor WebAssemblyvoor meer informatie.

Notitie

In het voorgaande voorbeeld wordt OCSP-koppeling (Online Certificate Status Protocol) uitgeschakeld. Als dit is ingeschakeld, controleert u of het certificaat de functie ondersteunt. Zie voor meer informatie en richtlijnen over het inschakelen van OCSP de volgende eigenschappen in de Module ngx_http_ssl_module (Nginx-documentatie) artikel:

  • ssl_stapling
  • ssl_stapling_file
  • ssl_stapling_responder
  • ssl_stapling_verify

Nginx beveiligen tegen clickjacking

Clickjacking, ook wel bekend als een UI-bedrog aanval, is een kwaadaardige aanval waarbij een websitebezoeker wordt misleid om op een link of knop op een andere pagina te klikken dan die ze op dat moment bezoeken. Gebruik X-FRAME-OPTIONS om de site te beveiligen.

Om klikjacking-aanvallen te voorkomen:

  1. Bewerk het bestand nginx.conf:

    sudo nano /etc/nginx/nginx.conf
    

    Voeg de regel toe: add_header X-Frame-Options "SAMEORIGIN";

  2. Sla het bestand op.

  3. Start Nginx opnieuw.

MIME-type sniffing

Deze header voorkomt dat de meeste browsers door MIME-sniffing het antwoord van het gedeclareerde inhoudstype afleiden, omdat de header de browser instrueert het inhoudstype van de reactie niet te wijzigen. Als de server met de optie nosniff aangeeft dat de inhoud is text/html, wordt deze door de browser weergegeven als text/html.

  1. Bewerk het bestand nginx.conf:

    sudo nano /etc/nginx/nginx.conf
    

    Voeg de regel toe: add_header X-Content-Type-Options "nosniff";

  2. Sla het bestand op.

  3. Start Nginx opnieuw.

Aanvullende Nginx-suggesties

Nadat u het gedeelde framework op de server hebt bijgewerkt, start u de ASP.NET Core-apps die worden gehost door de server opnieuw op.

Aanvullende informatiebronnen