Hostování ASP.NET Core v Linuxu s Nginx

Tato příručka vysvětluje nastavení produkčního prostředí ASP.NET Core pro Ubuntu, Red Hat Enterprise (RHEL) a SUSE Linux Enterprise Server.

Informace o dalších distribucích Linuxu podporovaných službou ASP.NET Core najdete v tématu Požadavky pro .NET Core v Linuxu.

Tento průvodce:

• Umístí existující aplikaci ASP.NET Core za reverzní proxy server.
• Nastaví reverzní proxy server tak, aby předával požadavky na Kestrel webový server.
• Zajišťuje, aby webová aplikace běžela při spuštění jako proces démon.
• Nakonfiguruje nástroj pro správu procesů, který pomáhá restartovat webovou aplikaci.

Požadavky

Kdykoli v budoucnu po upgradu sdílené architektury restartujte aplikace ASP.NET Core hostované serverem.

Publikování a kopírování přes aplikaci

Nakonfigurujte aplikaci pro nasazení závislé na rozhraní.

Pokud je aplikace spuštěná místně ve vývojovém prostředí a server ji nenakonfiguruje pro zajištění zabezpečených připojení HTTPS, použijte některý z následujících přístupů:

• Nakonfigurujte aplikaci tak, aby zpracovávala zabezpečená místní připojení. Další informace najdete v části Konfigurace HTTPS.

• Nakonfigurujte aplikaci tak, aby běžela v nezabezpečeném koncovém bodu:

  • Deaktivace middlewaru přesměrování HTTPS ve vývojovém prostředí (Program.cs):

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

    Další informace viz Použití více prostředí v ASP.NET Core.

  • Odeberte https://localhost:5001 (pokud je k dispozici) z applicationUrl vlastnosti v Properties/launchSettings.json souboru.

Další informace o konfiguraci podle prostředí najdete v tématu Použití více prostředí v ASP.NET Core.

Spuštěním příkazu dotnet publish from the development environment zabalte aplikaci do adresáře (například bin/Release/{TARGET FRAMEWORK MONIKER}/publish, kde {TARGET FRAMEWORK MONIKER} zástupný symbol je cílový moniker (TFM)), který může běžet na serveru:

dotnet publish --configuration Release

Pokud nechcete udržovat modul runtime .NET Core na serveru, můžete aplikaci publikovat také jako samostatné nasazení .

Zkopírujte aplikaci ASP.NET Core na server pomocí nástroje, který se integruje do pracovního postupu organizace (například SCP, SFTP). V adresáři je běžné vyhledat webové aplikace var (například var/www/helloapp).

Otestujte aplikaci:

1. Z příkazového řádku spusťte aplikaci: dotnet <app_assembly>.dll.
2. V prohlížeči přejděte a http://<serveraddress>:<port> ověřte, že aplikace funguje místně v Linuxu.

Konfigurace reverzního proxy serveru

Reverzní proxy server je běžným nastavením pro obsluhu dynamických webových aplikací. Reverzní proxy server ukončí požadavek HTTP a předá ho do aplikace ASP.NET Core.

Použití reverzního proxy serveru

Kestrel je skvělá pro obsluhu dynamického obsahu z ASP.NET Core. Funkce webové obsluhy ale nejsou tak bohaté jako servery, jako je služba IIS, Apache nebo Nginx. Reverzní proxy server může přesměrovat práci, jako je obsluha statického obsahu, ukládání požadavků do mezipaměti, komprimace požadavků a ukončení protokolu HTTPS ze serveru HTTP. Reverzní proxy server se může nacházet na vyhrazeném počítači nebo může být nasazen společně se serverem HTTP.

Pro účely této příručky se používá jedna instance Nginx. Běží na stejném serveru společně se serverem HTTP. Na základě požadavků může být zvoleno jiné nastavení.

Vzhledem k tomu, že požadavky se předávají reverzním proxy serverem, použijte middleware Forwarded Headers z Microsoft.AspNetCore.HttpOverrides balíčku, který se automaticky zahrne do aplikací ASP.NET Core prostřednictvím metabalíku sdílené architekturyMicrosoft.AspNetCore.App. Middleware aktualizuje hlavičku Request.SchemeX-Forwarded-Proto pomocí hlavičky, aby identifikátory URI a další zásady zabezpečení správně fungovaly.

Middleware Forwarded Headers by měl běžet před ostatním middlewarem. Toto řazení zajišťuje, že middleware, který spoléhá na informace předávaných hlaviček, může využívat hodnoty hlaviček ke zpracování. Pokud chcete middleware Forwarded Headers spustit po diagnostice a middlewaru pro zpracování chyb, přečtěte si téma Middleware Ordered Headers.

Před voláním jiného middlewaru vyvoláte metodu UseForwardedHeaders . Nakonfigurujte middleware tak, aby předával X-Forwarded-For hlavičky a X-Forwarded-Proto předával je:

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

Pokud není pro middleware zadáno žádné ForwardedHeadersOptions , výchozí hlavičky, které se mají předat, jsou None.

Proxy servery spuštěné na adresách zpětné smyčky (127.0.0.0/8, [::1]včetně standardní adresy localhost (127.0.0.1) jsou ve výchozím nastavení důvěryhodné. Pokud jiné důvěryhodné proxy servery nebo sítě v rámci organizace zpracovávají požadavky mezi internetem a webovým serverem, přidejte je do seznamu KnownProxies nebo KnownNetworks pomocí ForwardedHeadersOptions. Následující příklad přidá důvěryhodný proxy server na IP adresu 10.0.0.100 do middlewaru KnownProxiesForwarded Headers:

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

Další informace najdete v tématu Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení.

Instalace serveru Nginx

Vzhledem k tomu, že se Nginx nainstaloval poprvé, explicitně ho spusťte spuštěním následujícího příkazu:

sudo service nginx start

Ověřte, že prohlížeč zobrazuje výchozí cílovou stránku pro Nginx. Cílová stránka je dostupná na adrese http://<server_IP_address>/index.nginx-debian.html.

Konfigurace služby Nginx

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

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

Pokud se jedná o SignalR aplikaci nebo Blazor Server aplikaci, další informace najdete v tématu ASP.NET SignalR hostování a škálování jádra a škálování a hostování a nasazení aplikací na straně Blazor serveru ASP.NET Core.

Pokud žádné shody nejsou server_name , Nginx používá výchozí server. Pokud není definován žádný výchozí server, je prvním serverem v konfiguračním souboru výchozí server. Osvědčeným postupem je přidat do konfiguračního souboru konkrétní výchozí server, který vrátí stavový kód 444. Výchozí příklad konfigurace serveru je:

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

S předchozím konfiguračním souborem a výchozím serverem Nginx přijímá veřejný provoz na portu 80 s hlavičkou example.com hostitele nebo *.example.com. Žádosti, které neodpovídají těmto hostitelům, se nepřesměrují na Kestrel. Nginx předá odpovídající požadavky na Kestrel adrese http://127.0.0.1:5000/. Další informace naleznete v tématu Jak nginx zpracovává požadavek. Pokud chcete změnit KestrelIP adresu nebo port, přečtěte si téma Kestrel: Konfigurace koncového bodu.

Po vytvoření konfigurace Nginx spusťte sudo nginx -t ověření syntaxe konfiguračních souborů. Pokud je test konfiguračního souboru úspěšný, vynuťte Nginx, aby změny vyzvedli spuštěním sudo nginx -s reload.

Přímé spuštění aplikace na serveru:

1. Přejděte do adresáře aplikace.
2. Spusťte aplikaci: dotnet <app_assembly.dll>, kde app_assembly.dll je název souboru sestavení aplikace.

Po otestování aplikace vypněte aplikaci pomocí ctrl+C (Windows) nebo ⌘+C (macOS) na příkazovém řádku.

Zvýšení keepalive_requests

keepalive_requestspokud chcete zvýšit výkon, další informace najdete v tomto problému na GitHubu.

Monitorování aplikace

Server je nastavený tak, aby předával požadavky předávané na http://<serveraddress>:80 aplikaci ASP.NET Core spuštěné na adrese Kestrel http://127.0.0.1:5000. Nginx ale není nastavený pro správu Kestrel procesu. systemd lze použít k vytvoření souboru služby pro spuštění a monitorování podkladové webové aplikace. systemd je inicializační systém, který poskytuje mnoho výkonných funkcí pro spouštění, zastavování a správu procesů.

Vytvoření souboru služby

Vytvořte definiční soubor služby:

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

Následující příklad je .ini soubor služby pro aplikaci:

[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

V předchozím příkladu je uživatel, který spravuje službu, určen možností User . Uživatel (www-data) musí existovat a mít správné vlastnictví souborů aplikace.

Slouží TimeoutStopSec ke konfiguraci doby trvání čekání na vypnutí aplikace po přijetí počátečního signálu přerušení. Pokud se aplikace v tomto období nevypíná, služba SIGKILL se vydá za účelem ukončení aplikace. Zadejte hodnotu jako jednotkové sekundy (například 150), hodnotu časového rozsahu (například 2min 30s) nebo infinity pokud chcete časový limit zakázat. TimeoutStopSec výchozí hodnota v konfiguračním DefaultTimeoutStopSec souboru správce (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). Výchozí časový limit většiny distribucí je 90 sekund.

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

Linux má systém souborů rozlišující malá a velká písmena. Nastavení ASPNETCORE_ENVIRONMENT výsledků Production hledání konfiguračního souboru appsettings.Production.json, nikoli appsettings.production.json.

Některé hodnoty (například SQL připojovací řetězec) musí být uchycené, aby zprostředkovatelé konfigurace mohli číst proměnné prostředí. Pomocí následujícího příkazu vygenerujte správně řídicí hodnotu pro použití v konfiguračním souboru:

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

Oddělovače dvojtečky (:) nejsou podporovány v názvech proměnných prostředí. Místo dvojtečky použijte dvojité podtržítko (__). Zprostředkovatel konfigurace proměnných prostředí převede dvojtržítka na dvojtečky, když se proměnné prostředí načtou do konfigurace. V následujícím příkladu je klíč ConnectionStrings:DefaultConnection připojovací řetězec nastaven do definičního souboru služby taktoConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Uložte soubor a povolte službu.

sudo systemctl enable kestrel-helloapp.service

Spusťte službu a ověřte, že je spuštěná.

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

S nakonfigurovaným a Kestrel spravovaným reverzním proxy serverem systemdje webová aplikace plně nakonfigurovaná a je přístupná z prohlížeče na místním počítači na http://localhostadrese . Je také přístupný ze vzdáleného počítače a blokuje všechny brány firewall, které by mohly blokovat. Při kontrole hlaviček odpovědí se v hlavičce Server zobrazí aplikace ASP.NET Core, kterou obsluhuje 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

Zobrazení protokolů

Vzhledem k tomu, že se webová aplikace spravuje Kestrel pomocí systemd, všechny události a procesy se protokolují do centralizovaného deníku. Tento deník však zahrnuje všechny položky pro všechny služby a procesy spravované systemd. Pokud chcete zobrazit kestrel-helloapp.servicekonkrétní položky, použijte následující příkaz:

sudo journalctl -fu kestrel-helloapp.service

Pro další filtrování můžou časové možnosti, jako --since todayje , --until 1 hour agonebo jejich kombinace snížit počet vrácených položek.

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

Ochrana dat

Zásobník ASP.NET Core Data Protection používá několik middlewarů ASP.NET Core, včetně middlewaru ověřování (například cookie middleware) a ochrany proti padělání žádostí mezi weby (CSRF). I když rozhraní API ochrany dat nejsou volána uživatelským kódem, ochrana dat by měla být nakonfigurovaná tak, aby vytvořila trvalé úložiště kryptografických klíčů. Pokud ochrana dat není nakonfigurovaná, klíče se uchovávají v paměti a při restartování aplikace se zahodí.

Pokud se svazek klíčů uchovává v paměti, při restartování aplikace se stane následující:

• Všechny ověřovací tokeny založené na souborech cookie se zneplatní.
• Uživatelé se při dalším požadavku musí přihlásit znovu.
• Veškerá data chráněná daným svazkem klíčů již není možné dešifrovat. To může zahrnovat tokeny CSRF a soubory cookie ASP.NET Core MVC TempData.

Informace o konfiguraci ochrany dat pro zachování a šifrování okruhu klíčů najdete tady:

• Poskytovatelé úložiště klíčů v ASP.NET Core
• Šifrování rest klíčů ve Windows a Azure pomocí ASP.NET Core

Pole s dlouhou hlavičkou požadavku

Výchozí nastavení proxy serveru obvykle omezují pole hlaviček požadavků na 4 K nebo 8 K v závislosti na platformě. Aplikace může vyžadovat pole delší než výchozí (například aplikace, které používají ID Microsoft Entra). Pokud jsou požadována delší pole, výchozí nastavení proxy serveru vyžadují úpravy. Hodnoty, které se mají použít, závisí na scénáři. Další informace najdete v dokumentaci k serveru.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Zabezpečení aplikace

Povolení AppArmoru

Moduly zabezpečení Linuxu (LSM) je architektura, která je součástí jádra Linuxu od Linuxu 2.6. LSM podporuje různé implementace modulů zabezpečení. AppArmor je LSM, který implementuje povinný systém řízení přístupu, který umožňuje připojit program k omezené sadě prostředků. Ujistěte se, že je služba AppArmor povolená a správně nakonfigurovaná.

Konfigurace brány firewall

Zavřete všechny externí porty, které se nepoužívají. Nekomplikovaná brána firewall (ufw) poskytuje front-end iptables pro poskytnutí rozhraní příkazového řádku pro konfiguraci brány firewall.

sudo apt-get install ufw

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

sudo ufw enable

sudo yum -y install ufw

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

sudo ufw enable

sudo yum -y install ufw

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

sudo ufw enable

Zabezpečení serveru Nginx

Změna názvu odpovědi Nginx

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

Konfigurace možností

Nakonfigurujte server s dalšími požadovanými moduly. Zvažte použití firewallu webových aplikací, jako je ModSecurity, k posílení zabezpečení aplikace.

Konfigurace HTTPS

Konfigurace aplikace pro zabezpečená místní připojení (HTTPS)

Příkaz dotnet run používá soubor aplikace Properties/launchSettings.json , který nakonfiguruje aplikaci tak, aby naslouchala adresám URL poskytovaných applicationUrl vlastností. Například https://localhost:5001;http://localhost:5000.

Nakonfigurujte aplikaci tak, aby ve vývoji používala certifikát pro dotnet run příkaz nebo vývojové prostředí (F5 nebo Ctrl+F5 v editoru Visual Studio Code) pomocí jednoho z následujících přístupů:

• Nahrazení výchozího certifikátu z konfigurace (doporučeno)
• KestrelServerOptions.ConfigureHttpsDefaults

Konfigurace reverzního proxy serveru pro zabezpečená připojení klienta (HTTPS)

• Nakonfigurujte server tak, aby naslouchal provozu HTTPS na portu 443 zadáním platného certifikátu vydaného důvěryhodnou certifikační autoritou (CA).

• Posílení zabezpečení pomocí některých postupů zobrazených v následujícím souboru /etc/nginx/nginx.conf .

• Následující příklad nenakonfiguruje server tak, aby přesměrovává nezabezpečené požadavky. Doporučujeme použít middleware přesměrování HTTPS. Další informace najdete v tématu Vynucení HTTPS v ASP.NET Core.

  Poznámka:

  Pro vývojová prostředí, ve kterých konfigurace serveru zpracovává zabezpečené přesměrování místo middlewaru přesměrování HTTPS, doporučujeme místo trvalých přesměrování (301) používat dočasné přesměrování (302). Ukládání odkazů do mezipaměti může způsobit nestabilní chování ve vývojových prostředích.

• Strict-Transport-Security Přidání hlavičky (HSTS) zajišťuje, že všechny následné požadavky provedené klientem budou přes PROTOKOL HTTPS. Pokyny k nastavení hlavičky Strict-Transport-Security najdete v tématu Vynucení HTTPS v ASP.NET Core.

• Pokud bude protokol HTTPS v budoucnu zakázaný, použijte jeden z následujících přístupů:

  • Nepřidávejte hlavičku HSTS.
  • Zvolte krátkou max-age hodnotu.

Přidejte konfigurační soubor /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;

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

Zabezpečení Nginx z clickjackingu

Clickjacking, označovaný také jako útok na nápravu uživatelského rozhraní, je škodlivý útok, při kterém je návštěvník webu zklamaný kliknutím na odkaz nebo tlačítko na jiné stránce, než který právě navštěvuje. Slouží X-FRAME-OPTIONS k zabezpečení webu.

Zmírnění útoků clickjacking:

1. Upravte soubor nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

   http{} V bloku kódu přidejte řádek:add_header X-Frame-Options "SAMEORIGIN";

2. Uložte soubor.

3. Restartujte Nginx.

Šifrování typu MIME

Tato hlavička zabraňuje většině prohlížečů v zašifrování odpovědi mimo deklarovaný typ obsahu, protože hlavička dává prohlížeči pokyn, aby nepřepsal typ obsahu odpovědi. nosniff S možností, pokud server říká, že obsah je text/html, prohlížeč ho vykreslí jako text/html.

1. Upravte soubor nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

   http{} V bloku kódu přidejte řádek:add_header X-Content-Type-Options "nosniff";

2. Uložte soubor.

3. Restartujte Nginx.

Další návrhy Nginx

Po upgradu sdílené architektury na serveru restartujte aplikace ASP.NET Core hostované serverem.

Další materiály

• Požadavky pro .NET Core v Linuxu
• Nginx: Binární vydání: Oficiální balíčky Debian/Ubuntu
• Řešení potíží s projekty ASP.NET Core a jejich ladění
• Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení
• NGINX: Použití předávané hlavičky

Tato příručka vysvětluje nastavení produkčního prostředí ASP.NET Core na serveru Ubuntu 16.04. Tyto pokyny pravděpodobně fungují s novějšími verzemi Ubuntu, ale pokyny nebyly testovány s novějšími verzemi.

Informace o dalších distribucích Linuxu podporovaných službou ASP.NET Core najdete v tématu Požadavky pro .NET Core v Linuxu.

Tento průvodce:

• Umístí existující aplikaci ASP.NET Core za reverzní proxy server.
• Nastaví reverzní proxy server tak, aby předával požadavky na Kestrel webový server.
• Zajišťuje, aby webová aplikace běžela při spuštění jako proces démon.
• Nakonfiguruje nástroj pro správu procesů, který pomáhá restartovat webovou aplikaci.

Požadavky

• Přístup k serveru Ubuntu 16.04 se standardním uživatelským účtem s oprávněním sudo.
• Nejnovější modul runtime .NET, který není ve verzi Preview , je nainstalovaný na serveru.
• Existující aplikace ASP.NET Core.

Kdykoli v budoucnu po upgradu sdílené architektury restartujte aplikace ASP.NET Core hostované serverem.

Publikování a kopírování přes aplikaci

Nakonfigurujte aplikaci pro nasazení závislé na rozhraní.

Pokud je aplikace spuštěná místně ve vývojovém prostředí a server ji nenakonfiguruje pro zajištění zabezpečených připojení HTTPS, použijte některý z následujících přístupů:

• Nakonfigurujte aplikaci tak, aby zpracovávala zabezpečená místní připojení. Další informace najdete v části Konfigurace HTTPS.

• Nakonfigurujte aplikaci tak, aby běžela v nezabezpečeném koncovém bodu:

  • Deaktivace middlewaru přesměrování HTTPS ve vývojovém prostředí (Program.cs):

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

    Další informace viz Použití více prostředí v ASP.NET Core.

  • Odeberte https://localhost:5001 (pokud je k dispozici) z applicationUrl vlastnosti v Properties/launchSettings.json souboru.

Další informace o konfiguraci podle prostředí najdete v tématu Použití více prostředí v ASP.NET Core.

Spuštěním příkazu dotnet publish from the development environment zabalte aplikaci do adresáře (například bin/Release/{TARGET FRAMEWORK MONIKER}/publish, kde zástupný symbol {TARGET FRAMEWORK MONIKER} je Cílový framework Moniker/TFM), který může běžet na serveru:

dotnet publish --configuration Release

Pokud nechcete udržovat modul runtime .NET Core na serveru, můžete aplikaci publikovat také jako samostatné nasazení .

Zkopírujte aplikaci ASP.NET Core na server pomocí nástroje, který se integruje do pracovního postupu organizace (například SCP, SFTP). V adresáři je běžné vyhledat webové aplikace var (například var/www/helloapp).

Otestujte aplikaci:

1. Z příkazového řádku spusťte aplikaci: dotnet <app_assembly>.dll.
2. V prohlížeči přejděte a http://<serveraddress>:<port> ověřte, že aplikace funguje místně v Linuxu.

Konfigurace reverzního proxy serveru

Reverzní proxy server je běžným nastavením pro obsluhu dynamických webových aplikací. Reverzní proxy server ukončí požadavek HTTP a předá ho do aplikace ASP.NET Core.

Použití reverzního proxy serveru

Kestrel je skvělá pro obsluhu dynamického obsahu z ASP.NET Core. Funkce webové obsluhy ale nejsou tak bohaté jako servery, jako je služba IIS, Apache nebo Nginx. Reverzní proxy server může přesměrovat práci, jako je obsluha statického obsahu, ukládání požadavků do mezipaměti, komprimace požadavků a ukončení protokolu HTTPS ze serveru HTTP. Reverzní proxy server se může nacházet na vyhrazeném počítači nebo může být nasazen společně se serverem HTTP.

Pro účely této příručky se používá jedna instance Nginx. Běží na stejném serveru společně se serverem HTTP. Na základě požadavků může být zvoleno jiné nastavení.

Vzhledem k tomu, že požadavky se předávají reverzním proxy serverem, použijte middleware Forwarded Headers z Microsoft.AspNetCore.HttpOverrides balíčku. Middleware aktualizuje hlavičku Request.SchemeX-Forwarded-Proto pomocí hlavičky, aby identifikátory URI a další zásady zabezpečení správně fungovaly.

Middleware Forwarded Headers by měl běžet před ostatním middlewarem. Toto řazení zajišťuje, že middleware, který spoléhá na informace předávaných hlaviček, může využívat hodnoty hlaviček ke zpracování. Pokud chcete middleware Forwarded Headers spustit po diagnostice a middlewaru pro zpracování chyb, přečtěte si téma Middleware Ordered Headers.

Vyvoláním UseForwardedHeaders metody v horní části před voláním jiného Program.cs middlewaru. Nakonfigurujte middleware tak, aby předával X-Forwarded-For hlavičky a X-Forwarded-Proto předával je:

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

app.UseAuthentication();

Pokud není pro middleware zadáno žádné ForwardedHeadersOptions , výchozí hlavičky, které se mají předat, jsou None.

Proxy servery spuštěné na adresách zpětné smyčky (127.0.0.0/8, [::1]včetně standardní adresy localhost (127.0.0.1) jsou ve výchozím nastavení důvěryhodné. Pokud jiné důvěryhodné proxy servery nebo sítě v rámci organizace zpracovávají požadavky mezi internetem a webovým serverem, přidejte je do seznamu KnownProxies nebo KnownNetworks pomocí ForwardedHeadersOptions. Následující příklad přidá důvěryhodný proxy server na IP adresu 10.0.0.100 do middlewaru KnownProxies Forwarded Headers v Program.cs:

using System.Net;

var builder = WebApplication.CreateBuilder(args);

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

Další informace najdete v tématu Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení.

Instalace serveru Nginx

Slouží apt-get k instalaci serveru Nginx. Instalační program vytvoří systemd inicializační skript, který spustí Nginx jako démon při spuštění systému. Postupujte podle pokynů k instalaci Ubuntu v Nginx: Oficiální balíčky Debian/Ubuntu.

Vzhledem k tomu, že se Nginx nainstaloval poprvé, explicitně ho spusťte spuštěním následujícího příkazu:

sudo service nginx start

Ověřte, že prohlížeč zobrazuje výchozí cílovou stránku pro Nginx. Cílová stránka je dostupná na adrese http://<server_IP_address>/index.nginx-debian.html.

Konfigurace služby Nginx

Pokud chcete nakonfigurovat Nginx jako reverzní proxy pro předávání požadavků HTTP do aplikace ASP.NET Core, upravte /etc/nginx/sites-available/default. Otevřete ho v textovém editoru a nahraďte jeho obsah následujícím fragmentem kódu:

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

Pokud se jedná o SignalR aplikaci nebo Blazor Server aplikaci, další informace najdete v tématu ASP.NET SignalR hostování a škálování jádra a škálování a hostování a nasazení aplikací na straně Blazor serveru ASP.NET Core.

Pokud žádné shody nejsou server_name , Nginx používá výchozí server. Pokud není definován žádný výchozí server, je prvním serverem v konfiguračním souboru výchozí server. Osvědčeným postupem je přidat do konfiguračního souboru konkrétní výchozí server, který vrátí stavový kód 444. Výchozí příklad konfigurace serveru je:

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

S předchozím konfiguračním souborem a výchozím serverem Nginx přijímá veřejný provoz na portu 80 s hlavičkou example.com hostitele nebo *.example.com. Žádosti, které neodpovídají těmto hostitelům, se nepřesměrují na Kestrel. Nginx předá odpovídající požadavky na Kestrel adrese http://127.0.0.1:5000. Další informace naleznete v tématu Jak nginx zpracovává požadavek. Pokud chcete změnit KestrelIP adresu nebo port, přečtěte si téma Kestrel: Konfigurace koncového bodu.

Po vytvoření konfigurace Nginx spusťte sudo nginx -t ověření syntaxe konfiguračních souborů. Pokud je test konfiguračního souboru úspěšný, vynuťte Nginx, aby změny vyzvedli spuštěním sudo nginx -s reload.

Přímé spuštění aplikace na serveru:

1. Přejděte do adresáře aplikace.
2. Spusťte aplikaci: dotnet <app_assembly.dll>, kde app_assembly.dll je název souboru sestavení aplikace.

Pokud aplikace běží na serveru, ale nereaguje přes internet, zkontrolujte bránu firewall serveru a ověřte, že je otevřený port 80. Pokud používáte virtuální počítač Azure Ubuntu, přidejte pravidlo skupiny zabezpečení sítě (NSG), které povoluje příchozí provoz na portu 80. Není potřeba povolit pravidlo odchozího portu 80, protože odchozí provoz se automaticky udělí, když je povolené příchozí pravidlo.

Po otestování aplikace vypněte aplikaci pomocí ctrl+C (Windows) nebo ⌘+C (macOS) na příkazovém řádku.

Monitorování aplikace

Server je nastavený tak, aby předával požadavky předávané na http://<serveraddress>:80 aplikaci ASP.NET Core spuštěné na adrese Kestrel http://127.0.0.1:5000. Nginx ale není nastavený pro správu Kestrel procesu. systemd lze použít k vytvoření souboru služby pro spuštění a monitorování podkladové webové aplikace. systemd je inicializační systém, který poskytuje mnoho výkonných funkcí pro spouštění, zastavování a správu procesů.

Vytvoření souboru služby

Vytvořte definiční soubor služby:

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

Následující příklad je soubor služby pro aplikaci:

[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

V předchozím příkladu je uživatel, který spravuje službu, určen možností User . Uživatel (www-data) musí existovat a mít správné vlastnictví souborů aplikace.

Slouží TimeoutStopSec ke konfiguraci doby trvání čekání na vypnutí aplikace po přijetí počátečního signálu přerušení. Pokud se aplikace v tomto období nevypíná, služba SIGKILL se vydá za účelem ukončení aplikace. Zadejte hodnotu jako jednotkové sekundy (například 150), hodnotu časového rozsahu (například 2min 30s) nebo infinity pokud chcete časový limit zakázat. TimeoutStopSec výchozí hodnota v konfiguračním DefaultTimeoutStopSec souboru správce (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). Výchozí časový limit většiny distribucí je 90 sekund.

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

Linux má systém souborů rozlišující malá a velká písmena. Nastavení ASPNETCORE_ENVIRONMENT výsledků Production hledání konfiguračního souboru appsettings.Production.json, nikoli appsettings.production.json.

Některé hodnoty (například SQL připojovací řetězec) musí být uchycené, aby zprostředkovatelé konfigurace mohli číst proměnné prostředí. Pomocí následujícího příkazu vygenerujte správně řídicí hodnotu pro použití v konfiguračním souboru:

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

Oddělovače dvojtečky (:) nejsou podporovány v názvech proměnných prostředí. Místo dvojtečky použijte dvojité podtržítko (__). Zprostředkovatel konfigurace proměnných prostředí převede dvojtržítka na dvojtečky, když se proměnné prostředí načtou do konfigurace. V následujícím příkladu je klíč ConnectionStrings:DefaultConnection připojovací řetězec nastaven do definičního souboru služby taktoConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Uložte soubor a povolte službu.

sudo systemctl enable kestrel-helloapp.service

Spusťte službu a ověřte, že je spuštěná.

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

S nakonfigurovaným a Kestrel spravovaným reverzním proxy serverem systemdje webová aplikace plně nakonfigurovaná a je přístupná z prohlížeče na místním počítači na http://localhostadrese . Je také přístupný ze vzdáleného počítače a blokuje všechny brány firewall, které by mohly blokovat. Při kontrole hlaviček odpovědí se v hlavičce Server zobrazí aplikace ASP.NET Core, kterou obsluhuje 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

Zobrazení protokolů

Vzhledem k tomu, že se webová aplikace spravuje Kestrel pomocí systemd, všechny události a procesy se protokolují do centralizovaného deníku. Tento deník však zahrnuje všechny položky pro všechny služby a procesy spravované systemd. Pokud chcete zobrazit kestrel-helloapp.servicekonkrétní položky, použijte následující příkaz:

sudo journalctl -fu kestrel-helloapp.service

Pro další filtrování můžou časové možnosti, jako --since todayje , --until 1 hour agonebo jejich kombinace snížit počet vrácených položek.

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

Ochrana dat

Zásobník ASP.NET Core Data Protection používá několik middlewarů ASP.NET Core, včetně middlewaru ověřování (například cookie middleware) a ochrany proti padělání žádostí mezi weby (CSRF). I když rozhraní API ochrany dat nejsou volána uživatelským kódem, ochrana dat by měla být nakonfigurovaná tak, aby vytvořila trvalé úložiště kryptografických klíčů. Pokud ochrana dat není nakonfigurovaná, klíče se uchovávají v paměti a při restartování aplikace se zahodí.

Pokud se svazek klíčů uchovává v paměti, při restartování aplikace se stane následující:

• Všechny ověřovací tokeny založené na souborech cookie se zneplatní.
• Uživatelé se při dalším požadavku musí přihlásit znovu.
• Veškerá data chráněná daným svazkem klíčů již není možné dešifrovat. To může zahrnovat tokeny CSRF a soubory cookie ASP.NET Core MVC TempData.

Informace o konfiguraci ochrany dat pro zachování a šifrování okruhu klíčů najdete tady:

• Poskytovatelé úložiště klíčů v ASP.NET Core
• Šifrování rest klíčů ve Windows a Azure pomocí ASP.NET Core

Pole s dlouhou hlavičkou požadavku

Výchozí nastavení proxy serveru obvykle omezují pole hlaviček požadavků na 4 K nebo 8 K v závislosti na platformě. Aplikace může vyžadovat pole delší než výchozí (například aplikace, které používají Azure Active Directory). Pokud jsou požadována delší pole, výchozí nastavení proxy serveru vyžadují úpravy. Hodnoty, které se mají použít, závisí na scénáři. Další informace najdete v dokumentaci k serveru.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Zabezpečení aplikace

Povolení AppArmoru

Moduly zabezpečení Linuxu (LSM) je architektura, která je součástí jádra Linuxu od Linuxu 2.6. LSM podporuje různé implementace modulů zabezpečení. AppArmor je LSM, který implementuje povinný systém řízení přístupu, který umožňuje připojit program k omezené sadě prostředků. Ujistěte se, že je služba AppArmor povolená a správně nakonfigurovaná.

Konfigurace brány firewall

Zavřete všechny externí porty, které se nepoužívají. Nekomplikovaná brána firewall (ufw) poskytuje front-end iptables pro poskytnutí rozhraní příkazového řádku pro konfiguraci brány firewall.

Nainstalujte ho a nakonfigurujte ufw tak, aby umožňoval provoz na všech potřebných portech.

sudo apt-get install ufw

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

sudo ufw enable

Zabezpečení serveru Nginx

Změna názvu odpovědi Nginx

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

Konfigurace možností

Nakonfigurujte server s dalšími požadovanými moduly. Zvažte použití firewallu webových aplikací, jako je ModSecurity, k posílení zabezpečení aplikace.

Konfigurace HTTPS

Konfigurace aplikace pro zabezpečená místní připojení (HTTPS)

Příkaz dotnet run používá soubor aplikace Properties/launchSettings.json , který nakonfiguruje aplikaci tak, aby naslouchala adresám URL poskytovaných applicationUrl vlastností. Například https://localhost:5001;http://localhost:5000.

Nakonfigurujte aplikaci tak, aby ve vývoji používala certifikát pro dotnet run příkaz nebo vývojové prostředí (F5 nebo Ctrl+F5 v editoru Visual Studio Code) pomocí jednoho z následujících přístupů:

• Nahrazení výchozího certifikátu z konfigurace (doporučeno)
• KestrelServerOptions.ConfigureHttpsDefaults

Konfigurace reverzního proxy serveru pro zabezpečená připojení klienta (HTTPS)

• Nakonfigurujte server tak, aby naslouchal provozu HTTPS na portu 443 zadáním platného certifikátu vydaného důvěryhodnou certifikační autoritou (CA).

• Posílení zabezpečení pomocí některých postupů zobrazených v následujícím souboru /etc/nginx/nginx.conf .

• Následující příklad nenakonfiguruje server tak, aby přesměrovává nezabezpečené požadavky. Doporučujeme použít middleware přesměrování HTTPS. Další informace najdete v tématu Vynucení HTTPS v ASP.NET Core.

  Poznámka:

  Pro vývojová prostředí, ve kterých konfigurace serveru zpracovává zabezpečené přesměrování místo middlewaru přesměrování HTTPS, doporučujeme místo trvalých přesměrování (301) používat dočasné přesměrování (302). Ukládání odkazů do mezipaměti může způsobit nestabilní chování ve vývojových prostředích.

• Strict-Transport-Security Přidání hlavičky (HSTS) zajišťuje, že všechny následné požadavky provedené klientem budou přes PROTOKOL HTTPS. Pokyny k nastavení hlavičky Strict-Transport-Security najdete v tématu Vynucení HTTPS v ASP.NET Core.

• Pokud bude protokol HTTPS v budoucnu zakázaný, použijte jeden z následujících přístupů:

  • Nepřidávejte hlavičku HSTS.
  • Zvolte krátkou max-age hodnotu.

Přidejte konfigurační soubor /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;

Nahraďte obsah konfiguračního souboru /etc/nginx/nginx.conf následujícím souborem. Příklad obsahuje oba http server oddíly v jednom konfiguračním souboru.

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

Zabezpečení Nginx z clickjackingu

Clickjacking, označovaný také jako útok na nápravu uživatelského rozhraní, je škodlivý útok, při kterém je návštěvník webu zklamaný kliknutím na odkaz nebo tlačítko na jiné stránce, než který právě navštěvuje. Slouží X-FRAME-OPTIONS k zabezpečení webu.

Zmírnění útoků clickjacking:

1. Upravte soubor nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

   Přidejte řádek: add_header X-Frame-Options "SAMEORIGIN";

2. Uložte soubor.

3. Restartujte Nginx.

Šifrování typu MIME

Tato hlavička zabraňuje většině prohlížečů v zašifrování odpovědi mimo deklarovaný typ obsahu, protože hlavička dává prohlížeči pokyn, aby nepřepsal typ obsahu odpovědi. nosniff S možností, pokud server říká, že obsah je text/html, prohlížeč ho vykreslí jako text/html.

1. Upravte soubor nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

   Přidejte řádek: add_header X-Content-Type-Options "nosniff";

2. Uložte soubor.

3. Restartujte Nginx.

Další návrhy Nginx

Po upgradu sdílené architektury na serveru restartujte aplikace ASP.NET Core hostované serverem.

Další materiály

• Požadavky pro .NET Core v Linuxu
• Nginx: Binární vydání: Oficiální balíčky Debian/Ubuntu
• Řešení potíží s projekty ASP.NET Core a jejich ladění
• Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení
• NGINX: Použití předávané hlavičky

Tato příručka vysvětluje nastavení produkčního prostředí ASP.NET Core na serveru Ubuntu 16.04. Tyto pokyny pravděpodobně fungují s novějšími verzemi Ubuntu, ale pokyny nebyly testovány s novějšími verzemi.

Informace o dalších distribucích Linuxu podporovaných službou ASP.NET Core najdete v tématu Požadavky pro .NET Core v Linuxu.

Tento průvodce:

• Umístí existující aplikaci ASP.NET Core za reverzní proxy server.
• Nastaví reverzní proxy server tak, aby předával požadavky na Kestrel webový server.
• Zajišťuje, aby webová aplikace běžela při spuštění jako proces démon.
• Nakonfiguruje nástroj pro správu procesů, který pomáhá restartovat webovou aplikaci.

Požadavky

• Přístup k serveru Ubuntu 16.04 se standardním uživatelským účtem s oprávněním sudo.
• Nejnovější modul runtime .NET, který není ve verzi Preview , je nainstalovaný na serveru.
• Existující aplikace ASP.NET Core.

Kdykoli v budoucnu po upgradu sdílené architektury restartujte aplikace ASP.NET Core hostované serverem.

Publikování a kopírování přes aplikaci

Nakonfigurujte aplikaci pro nasazení závislé na rozhraní.

Pokud je aplikace spuštěná místně ve vývojovém prostředí a server ji nenakonfiguruje pro zajištění zabezpečených připojení HTTPS, použijte některý z následujících přístupů:

• Nakonfigurujte aplikaci tak, aby zpracovávala zabezpečená místní připojení. Další informace najdete v části Konfigurace HTTPS.

• Nakonfigurujte aplikaci tak, aby běžela v nezabezpečeném koncovém bodu:

  • Deaktivace middlewaru přesměrování HTTPS ve vývojovém prostředí (Program.cs):

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

    Další informace viz Použití více prostředí v ASP.NET Core.

  • Odeberte https://localhost:5001 (pokud je k dispozici) z applicationUrl vlastnosti v Properties/launchSettings.json souboru.

Další informace o konfiguraci podle prostředí najdete v tématu Použití více prostředí v ASP.NET Core.

Spuštěním příkazu dotnet publish from the development environment zabalte aplikaci do adresáře (například bin/Release/{TARGET FRAMEWORK MONIKER}/publish, kde zástupný symbol {TARGET FRAMEWORK MONIKER} je Cílový framework Moniker/TFM), který může běžet na serveru:

dotnet publish --configuration Release

Pokud nechcete udržovat modul runtime .NET Core na serveru, můžete aplikaci publikovat také jako samostatné nasazení .

Zkopírujte aplikaci ASP.NET Core na server pomocí nástroje, který se integruje do pracovního postupu organizace (například SCP, SFTP). V adresáři je běžné vyhledat webové aplikace var (například var/www/helloapp).

Otestujte aplikaci:

1. Z příkazového řádku spusťte aplikaci: dotnet <app_assembly>.dll.
2. V prohlížeči přejděte a http://<serveraddress>:<port> ověřte, že aplikace funguje místně v Linuxu.

Konfigurace reverzního proxy serveru

Reverzní proxy server je běžným nastavením pro obsluhu dynamických webových aplikací. Reverzní proxy server ukončí požadavek HTTP a předá ho do aplikace ASP.NET Core.

Použití reverzního proxy serveru

Kestrel je skvělá pro obsluhu dynamického obsahu z ASP.NET Core. Funkce webové obsluhy ale nejsou tak bohaté jako servery, jako je služba IIS, Apache nebo Nginx. Reverzní proxy server může přesměrovat práci, jako je obsluha statického obsahu, ukládání požadavků do mezipaměti, komprimace požadavků a ukončení protokolu HTTPS ze serveru HTTP. Reverzní proxy server se může nacházet na vyhrazeném počítači nebo může být nasazen společně se serverem HTTP.

Pro účely této příručky se používá jedna instance Nginx. Běží na stejném serveru společně se serverem HTTP. Na základě požadavků může být zvoleno jiné nastavení.

Vzhledem k tomu, že požadavky se předávají reverzním proxy serverem, použijte middleware Forwarded Headers z Microsoft.AspNetCore.HttpOverrides balíčku. Middleware aktualizuje hlavičku Request.SchemeX-Forwarded-Proto pomocí hlavičky, aby identifikátory URI a další zásady zabezpečení správně fungovaly.

Middleware Forwarded Headers by měl běžet před ostatním middlewarem. Toto řazení zajišťuje, že middleware, který spoléhá na informace předávaných hlaviček, může využívat hodnoty hlaviček ke zpracování. Pokud chcete middleware Forwarded Headers spustit po diagnostice a middlewaru pro zpracování chyb, přečtěte si téma Middleware Ordered Headers.

Vyvoláním UseForwardedHeaders metody v horní části před voláním jiného Startup.Configure middlewaru. Nakonfigurujte middleware tak, aby předával X-Forwarded-For hlavičky a X-Forwarded-Proto předával je:

using Microsoft.AspNetCore.HttpOverrides;

...

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

app.UseAuthentication();

Pokud není pro middleware zadáno žádné ForwardedHeadersOptions , výchozí hlavičky, které se mají předat, jsou None.

Proxy servery spuštěné na adresách zpětné smyčky (127.0.0.0/8, [::1]včetně standardní adresy localhost (127.0.0.1) jsou ve výchozím nastavení důvěryhodné. Pokud jiné důvěryhodné proxy servery nebo sítě v rámci organizace zpracovávají požadavky mezi internetem a webovým serverem, přidejte je do seznamu KnownProxies nebo KnownNetworks pomocí ForwardedHeadersOptions. Následující příklad přidá důvěryhodný proxy server na IP adresu 10.0.0.100 do middlewaru KnownProxies Forwarded Headers v Startup.ConfigureServices:

using System.Net;

...

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

Další informace najdete v tématu Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení.

Instalace serveru Nginx

Slouží apt-get k instalaci serveru Nginx. Instalační program vytvoří systemd inicializační skript, který spustí Nginx jako démon při spuštění systému. Postupujte podle pokynů k instalaci Ubuntu v Nginx: Oficiální balíčky Debian/Ubuntu.

Vzhledem k tomu, že se Nginx nainstaloval poprvé, explicitně ho spusťte spuštěním následujícího příkazu:

sudo service nginx start

Ověřte, že prohlížeč zobrazuje výchozí cílovou stránku pro Nginx. Cílová stránka je dostupná na adrese http://<server_IP_address>/index.nginx-debian.html.

Konfigurace služby Nginx

Pokud chcete nakonfigurovat Nginx jako reverzní proxy pro předávání požadavků HTTP do aplikace ASP.NET Core, upravte /etc/nginx/sites-available/default. Otevřete ho v textovém editoru a nahraďte jeho obsah následujícím fragmentem kódu:

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

Pokud se jedná o SignalR aplikaci nebo Blazor Server aplikaci, další informace najdete v tématu ASP.NET SignalR hostování a škálování jádra a škálování a hostování a nasazení aplikací na straně Blazor serveru ASP.NET Core.

Pokud žádné shody nejsou server_name , Nginx používá výchozí server. Pokud není definován žádný výchozí server, je prvním serverem v konfiguračním souboru výchozí server. Osvědčeným postupem je přidat do konfiguračního souboru konkrétní výchozí server, který vrátí stavový kód 444. Výchozí příklad konfigurace serveru je:

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

S předchozím konfiguračním souborem a výchozím serverem Nginx přijímá veřejný provoz na portu 80 s hlavičkou example.com hostitele nebo *.example.com. Žádosti, které neodpovídají těmto hostitelům, se nepřesměrují na Kestrel. Nginx předá odpovídající požadavky na Kestrel adrese http://127.0.0.1:5000. Další informace naleznete v tématu Jak nginx zpracovává požadavek. Pokud chcete změnit KestrelIP adresu nebo port, přečtěte si téma Kestrel: Konfigurace koncového bodu.

Po vytvoření konfigurace Nginx spusťte sudo nginx -t ověření syntaxe konfiguračních souborů. Pokud je test konfiguračního souboru úspěšný, vynuťte Nginx, aby změny vyzvedli spuštěním sudo nginx -s reload.

Přímé spuštění aplikace na serveru:

1. Přejděte do adresáře aplikace.
2. Spusťte aplikaci: dotnet <app_assembly.dll>, kde app_assembly.dll je název souboru sestavení aplikace.

Pokud aplikace běží na serveru, ale nereaguje přes internet, zkontrolujte bránu firewall serveru a ověřte, že je otevřený port 80. Pokud používáte virtuální počítač Azure Ubuntu, přidejte pravidlo skupiny zabezpečení sítě (NSG), které povoluje příchozí provoz na portu 80. Není potřeba povolit pravidlo odchozího portu 80, protože odchozí provoz se automaticky udělí, když je povolené příchozí pravidlo.

Po otestování aplikace vypněte aplikaci pomocí ctrl+C (Windows) nebo ⌘+C (macOS) na příkazovém řádku.

Monitorování aplikace

Server je nastavený tak, aby předával požadavky předávané na http://<serveraddress>:80 aplikaci ASP.NET Core spuštěné na adrese Kestrel http://127.0.0.1:5000. Nginx ale není nastavený pro správu Kestrel procesu. systemd lze použít k vytvoření souboru služby pro spuštění a monitorování podkladové webové aplikace. systemd je inicializační systém, který poskytuje mnoho výkonných funkcí pro spouštění, zastavování a správu procesů.

Vytvoření souboru služby

Vytvořte definiční soubor služby:

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

Následující příklad je soubor služby pro aplikaci:

[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

V předchozím příkladu je uživatel, který spravuje službu, určen možností User . Uživatel (www-data) musí existovat a mít správné vlastnictví souborů aplikace.

Slouží TimeoutStopSec ke konfiguraci doby trvání čekání na vypnutí aplikace po přijetí počátečního signálu přerušení. Pokud se aplikace v tomto období nevypíná, služba SIGKILL se vydá za účelem ukončení aplikace. Zadejte hodnotu jako jednotkové sekundy (například 150), hodnotu časového rozsahu (například 2min 30s) nebo infinity pokud chcete časový limit zakázat. TimeoutStopSec výchozí hodnota v konfiguračním DefaultTimeoutStopSec souboru správce (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). Výchozí časový limit většiny distribucí je 90 sekund.

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

Linux má systém souborů rozlišující malá a velká písmena. Nastavení ASPNETCORE_ENVIRONMENT výsledků Production hledání konfiguračního souboru appsettings.Production.json, nikoli appsettings.production.json.

Některé hodnoty (například SQL připojovací řetězec) musí být uchycené, aby zprostředkovatelé konfigurace mohli číst proměnné prostředí. Pomocí následujícího příkazu vygenerujte správně řídicí hodnotu pro použití v konfiguračním souboru:

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

Oddělovače dvojtečky (:) nejsou podporovány v názvech proměnných prostředí. Místo dvojtečky použijte dvojité podtržítko (__). Zprostředkovatel konfigurace proměnných prostředí převede dvojtržítka na dvojtečky, když se proměnné prostředí načtou do konfigurace. V následujícím příkladu je klíč ConnectionStrings:DefaultConnection připojovací řetězec nastaven do definičního souboru služby taktoConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Uložte soubor a povolte službu.

sudo systemctl enable kestrel-helloapp.service

Spusťte službu a ověřte, že je spuštěná.

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

S nakonfigurovaným a Kestrel spravovaným reverzním proxy serverem systemdje webová aplikace plně nakonfigurovaná a je přístupná z prohlížeče na místním počítači na http://localhostadrese . Je také přístupný ze vzdáleného počítače a blokuje všechny brány firewall, které by mohly blokovat. Při kontrole hlaviček odpovědí se v hlavičce Server zobrazí aplikace ASP.NET Core, kterou obsluhuje 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

Zobrazení protokolů

Vzhledem k tomu, že se webová aplikace spravuje Kestrel pomocí systemd, všechny události a procesy se protokolují do centralizovaného deníku. Tento deník však zahrnuje všechny položky pro všechny služby a procesy spravované systemd. Pokud chcete zobrazit kestrel-helloapp.servicekonkrétní položky, použijte následující příkaz:

sudo journalctl -fu kestrel-helloapp.service

Pro další filtrování můžou časové možnosti, jako --since todayje , --until 1 hour agonebo jejich kombinace snížit počet vrácených položek.

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

Ochrana dat

Zásobník ASP.NET Core Data Protection používá několik middlewarů ASP.NET Core, včetně middlewaru ověřování (například cookie middleware) a ochrany proti padělání žádostí mezi weby (CSRF). I když rozhraní API ochrany dat nejsou volána uživatelským kódem, ochrana dat by měla být nakonfigurovaná tak, aby vytvořila trvalé úložiště kryptografických klíčů. Pokud ochrana dat není nakonfigurovaná, klíče se uchovávají v paměti a při restartování aplikace se zahodí.

Pokud se svazek klíčů uchovává v paměti, při restartování aplikace se stane následující:

• Všechny ověřovací tokeny založené na souborech cookie se zneplatní.
• Uživatelé se při dalším požadavku musí přihlásit znovu.
• Veškerá data chráněná daným svazkem klíčů již není možné dešifrovat. To může zahrnovat tokeny CSRF a soubory cookie ASP.NET Core MVC TempData.

Informace o konfiguraci ochrany dat pro zachování a šifrování okruhu klíčů najdete tady:

• Poskytovatelé úložiště klíčů v ASP.NET Core
• Šifrování rest klíčů ve Windows a Azure pomocí ASP.NET Core

Pole s dlouhou hlavičkou požadavku

Výchozí nastavení proxy serveru obvykle omezují pole hlaviček požadavků na 4 K nebo 8 K v závislosti na platformě. Aplikace může vyžadovat pole delší než výchozí (například aplikace, které používají Azure Active Directory). Pokud jsou požadována delší pole, výchozí nastavení proxy serveru vyžadují úpravy. Hodnoty, které se mají použít, závisí na scénáři. Další informace najdete v dokumentaci k serveru.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Zabezpečení aplikace

Povolení AppArmoru

Moduly zabezpečení Linuxu (LSM) je architektura, která je součástí jádra Linuxu od Linuxu 2.6. LSM podporuje různé implementace modulů zabezpečení. AppArmor je LSM, který implementuje povinný systém řízení přístupu, který umožňuje připojit program k omezené sadě prostředků. Ujistěte se, že je služba AppArmor povolená a správně nakonfigurovaná.

Konfigurace brány firewall

Zavřete všechny externí porty, které se nepoužívají. Nekomplikovaná brána firewall (ufw) poskytuje front-end iptables pro poskytnutí rozhraní příkazového řádku pro konfiguraci brány firewall.

Nainstalujte ho a nakonfigurujte ufw tak, aby umožňoval provoz na všech potřebných portech.

sudo apt-get install ufw

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

sudo ufw enable

Zabezpečení serveru Nginx

Změna názvu odpovědi Nginx

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

Konfigurace možností

Nakonfigurujte server s dalšími požadovanými moduly. Zvažte použití firewallu webových aplikací, jako je ModSecurity, k posílení zabezpečení aplikace.

Konfigurace HTTPS

Konfigurace aplikace pro zabezpečená místní připojení (HTTPS)

Příkaz dotnet run používá soubor aplikace Properties/launchSettings.json , který nakonfiguruje aplikaci tak, aby naslouchala adresám URL poskytovaných applicationUrl vlastností. Například https://localhost:5001;http://localhost:5000.

Nakonfigurujte aplikaci tak, aby ve vývoji používala certifikát pro dotnet run příkaz nebo vývojové prostředí (F5 nebo Ctrl+F5 v editoru Visual Studio Code) pomocí jednoho z následujících přístupů:

• Nahrazení výchozího certifikátu z konfigurace (doporučeno)
• KestrelServerOptions.ConfigureHttpsDefaults

Konfigurace reverzního proxy serveru pro zabezpečená připojení klienta (HTTPS)

• Nakonfigurujte server tak, aby naslouchal provozu HTTPS na portu 443 zadáním platného certifikátu vydaného důvěryhodnou certifikační autoritou (CA).

• Posílení zabezpečení pomocí některých postupů zobrazených v následujícím souboru /etc/nginx/nginx.conf .

• Následující příklad nenakonfiguruje server tak, aby přesměrovává nezabezpečené požadavky. Doporučujeme použít middleware přesměrování HTTPS. Další informace najdete v tématu Vynucení HTTPS v ASP.NET Core.

  Poznámka:

  Pro vývojová prostředí, ve kterých konfigurace serveru zpracovává zabezpečené přesměrování místo middlewaru přesměrování HTTPS, doporučujeme místo trvalých přesměrování (301) používat dočasné přesměrování (302). Ukládání odkazů do mezipaměti může způsobit nestabilní chování ve vývojových prostředích.

• Strict-Transport-Security Přidání hlavičky (HSTS) zajišťuje, že všechny následné požadavky provedené klientem budou přes PROTOKOL HTTPS. Pokyny k nastavení hlavičky Strict-Transport-Security najdete v tématu Vynucení HTTPS v ASP.NET Core.

• Pokud bude protokol HTTPS v budoucnu zakázaný, použijte jeden z následujících přístupů:

  • Nepřidávejte hlavičku HSTS.
  • Zvolte krátkou max-age hodnotu.

Přidejte konfigurační soubor /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;

Nahraďte obsah konfiguračního souboru /etc/nginx/nginx.conf následujícím souborem. Příklad obsahuje oba http server oddíly v jednom konfiguračním souboru.

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

Zabezpečení Nginx z clickjackingu

Clickjacking, označovaný také jako útok na nápravu uživatelského rozhraní, je škodlivý útok, při kterém je návštěvník webu zklamaný kliknutím na odkaz nebo tlačítko na jiné stránce, než který právě navštěvuje. Slouží X-FRAME-OPTIONS k zabezpečení webu.

Zmírnění útoků clickjacking:

1. Upravte soubor nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

   Přidejte řádek: add_header X-Frame-Options "SAMEORIGIN";

2. Uložte soubor.

3. Restartujte Nginx.

Šifrování typu MIME

Tato hlavička zabraňuje většině prohlížečů v zašifrování odpovědi mimo deklarovaný typ obsahu, protože hlavička dává prohlížeči pokyn, aby nepřepsal typ obsahu odpovědi. nosniff S možností, pokud server říká, že obsah je text/html, prohlížeč ho vykreslí jako text/html.

1. Upravte soubor nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

   Přidejte řádek: add_header X-Content-Type-Options "nosniff";

2. Uložte soubor.

3. Restartujte Nginx.

Další návrhy Nginx

Po upgradu sdílené architektury na serveru restartujte aplikace ASP.NET Core hostované serverem.

Další materiály

• Požadavky pro .NET Core v Linuxu
• Nginx: Binární vydání: Oficiální balíčky Debian/Ubuntu
• Řešení potíží s projekty ASP.NET Core a jejich ladění
• Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení
• NGINX: Použití předávané hlavičky