Hostování ASP.NET Core v Linuxu se serverem Nginx

Od Sourabh Shirhatti

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

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

Tato příručka:

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

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 nainstalovaný na serveru.
• Existující ASP.NET Core aplikace.

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

Publikování a kopírování aplikace

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

Pokud je aplikace spuštěná místně a není nakonfigurovaná pro zabezpečené připojení (HTTPS), přistupte k jednomu z následujících přístupů:

• Nakonfigurujte aplikaci tak, aby zvládla zabezpečená místní připojení. Další informace najdete v části Konfigurace HTTPS.
• Odeberte https://localhost:5001 (pokud je k dispozici) applicationUrl z vlastnosti v souboru Properties/launchSettings.json .

Spusťte dotnet publish z vývojového prostředí a zabalte aplikaci do adresáře (například , kde zástupný symbol je moniker cílové architektury bin/Release/{TARGET FRAMEWORK MONIKER}/publish nebo TFM), který se může spustit {TARGET FRAMEWORK MONIKER} 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 ASP.NET Core na server pomocí nástroje, který se integruje do pracovního postupu organizace (například SCP , SFTP ). Webové aplikace se běžně nachází v adresáři 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 na a http://<serveraddress>:<port> ověřte, že aplikace funguje místně v Linuxu.

Konfigurace zpětného proxy server

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

Použití zpětného proxy server

Kestrelje skvělý pro obsluhu dynamického obsahu z ASP.NET Core. Možnosti webových služeb ale nejsou tak bohaté na funkce, jako jsou servery jako IIS, Apache nebo Nginx. Reverzní proxy server může přesouvat práci, například obsluhu statického obsahu, ukládání požadavků do mezipaměti, komprimaci požadavků a ukončení protokolu HTTPS ze serveru HTTP. Reverzní proxy server může být umístěn 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 serveru Nginx. Běží na stejném serveru společně se serverem HTTP. Na základě požadavků je možné zvolit jiné nastavení.

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

Middleware předaných hlaviček by se měla spustit před jiným middlewarem. Toto řazení zajišťuje, aby middleware spoléhající se na předané informace hlaviček mohl spotřebovat hodnoty hlaviček pro zpracování. Pro spuštění předávaných middlewarových hlaviček po diagnostice a middlewaru zpracování chyb si přečtěte téma pořadí middlewaru u předaných hlaviček.

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

using Microsoft.AspNetCore.HttpOverrides;

...

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

app.UseAuthentication();

Pokud ForwardedHeadersOptions middleware zadáte hodnotu no, výchozí hlavičky, které se mají předat dál, jsou None .

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

using System.Net;

...

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

Další informace naleznete 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

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

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

sudo service nginx start

Ověřte, že prohlížeč zobrazí výchozí úvodní stránku serveru Nginx. Ke cílové stránce je možné se dostat na http://<server_IP_address>/index.nginx-debian.html adrese .

Konfigurace služby Nginx

Pokud chcete nakonfigurovat Nginx jako reverzní proxy server pro předávání požadavků HTTP ASP.NET Core vaší aplikaci, 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 je aplikace nebo , další informace najdete v tématu a SignalR Blazor Server SignalRASP.NET Core hostování a škálování v produkčním prostředí Hostování a nasazení ASP.NET Core Blazor Server .

Pokud se server_name žádná shoda shoduje, použije Nginx výchozí server. Pokud není definovaný žádný výchozí server, prvním serverem v konfiguračním souboru je výchozí server. Osvědčeným postupem je přidat konkrétní výchozí server, který do konfiguračního souboru 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;
}

Jakmile je konfigurace Nginx vytvořená, spuštěním příkazu ověřte sudo nginx -t syntaxi konfiguračních souborů. Pokud je test konfiguračního souboru úspěšný, vynucujte, aby server Nginx nasbíral změny spuštěním sudo nginx -s reload .

Pokud chcete aplikaci spustit přímo na serveru:

1. Přejděte do adresáře aplikace.
2. Spusťte aplikaci: dotnet <app_assembly.dll> , kde je název souboru sestavení app_assembly.dll 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é povolí příchozí provoz na portu 80. Není potřeba povolovat pravidlo odchozího portu 80, protože odchozí provoz se při povolení příchozího pravidla uděluje automaticky.

Po otestování aplikace vypněte aplikaci stisknutím kláves Ctrl + C na příkazovém řádku.

Monitorování aplikace

Server je nastavený tak, aby předal požadavky na hodnotu on do http://<serveraddress>:80 aplikace ASP.NET Core běžící na Kestrel adrese http://127.0.0.1:5000 . Nginx ale není nastavený pro správu Kestrel tohoto procesu. systemd lze použít k vytvoření souboru služby ke spuštění a monitorování podkladové webové aplikace. systemd je ini thajovací 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 pomocí User Možnosti. Uživatel ( www-data ) musí existovat a musí mít správné vlastnictví souborů aplikace.

Slouží TimeoutStopSec ke konfiguraci časového intervalu, po který se má čekat na vypnutí aplikace po přijetí počátečního signálu přerušení. Pokud se aplikace v tomto období neukončí, SIGKILL se vydá pro ukončení aplikace. Zadejte hodnotu jako nejednotkové sekundy (například 150 ), hodnotu časového rozsahu (například 2min 30s ) nebo infinity zakažte časový limit. TimeoutStopSec ve výchozím nastavení se jedná o hodnotu DefaultTimeoutStopSec v konfiguračním souboru správce ( systemd-system.conf , system.conf.d , systemd-user.conf , user.conf.d ). Výchozí časový limit pro většinu distribucí je 90 sekund.

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

Linux má systém souborů s rozlišováním velkých a malých písmen. Nastavení ASPNETCORE_ENVIRONMENT na Production výsledky hledání konfiguračního souboru appsettings.Production.json , ne appsettings.production.json .

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

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

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, zda 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 spravovaným reverzním proxy serverem Kestrel systemd je webová aplikace plně nakonfigurovaná a je dostupná z prohlížeče v místním počítači na adrese http://localhost . Je dostupná taky ze vzdáleného počítače a znemožňuje bránu firewall, která může být zablokovaná. při kontrole hlaviček odpovědi se v Server hlavičce zobrazuje ASP.NET Core aplikace, 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 webová aplikace, která používá aplikaci Kestrel , je spravována pomocí nástroje systemd , všechny události a procesy jsou protokolovány do centralizovaného deníku. Tento deník ale obsahuje všechny položky pro všechny služby a procesy, které spravuje systemd . Chcete-li zobrazit kestrel-helloapp.service položky specifické pro zobrazení, použijte následující příkaz:

sudo journalctl -fu kestrel-helloapp.service

Pro další filtrování, časová nastavení, jako například --since today , --until 1 hour ago , nebo kombinace těchto hodnot může 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

sada ASP.NET Core Data Protection stack je používána několika ASP.NET Core middlewary, včetně middlewaru ověřování (například cookie middlewaru) a ochrany proti padělání žádostí mezi lokalitami (CSRF). I v případě, že rozhraní API ochrany dat nejsou volána uživatelským kódem, je třeba chránit data, aby bylo možné vytvořit 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 klíčového prstence při restartu aplikace uloží do paměti:

• U cookie tokenů ověřování na základě jsou neověřené.
• Uživatelé se musí znovu přihlásit na svůj další požadavek.
• Data chráněná pomocí Key ringu už nebude možné dešifrovat. to může zahrnovat CSRF tokeny a ASP.NET Core MVC TempData cookie s.

Pokud chcete nakonfigurovat ochranu dat, aby zachovala a zašifroval klíč Ring, přečtěte si:

• Zprostředkovatelé úložiště klíčů v ASP.NET Core
• šifrování klíčů v klidovém Windows a Azure pomocí ASP.NET Core

Pole hlavičky dlouhé žádosti

Výchozí nastavení proxy serveru obvykle omezuje pole hlaviček požadavku na 4 KB nebo 8 KB 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, je výchozí nastavení proxy server vyžadovat úpravu. Hodnoty, které mají být použity, závisí na scénáři. Další informace najdete v dokumentaci k vašemu serveru.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Zabezpečení aplikace

Povolit AppArmor

Moduly zabezpečení Linux (LSM) jsou rozhraní, které je součástí jádra Linux od verze Linux 2,6. LSM podporuje různé implementace modulů zabezpečení. AppArmor je lsm, který implementuje povinný Access Control systém, který umožňuje programu confining program na omezené sady prostředků. Ujistěte se, že je povolená a správně nakonfigurovaná možnost AppArmor.

Konfigurace brány firewall

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

Nainstalujte ufw a nakonfigurujte ho tak, aby povoloval přenosy 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í Nginx

Změnit název 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í brány firewall webových aplikací, jako je například ModSecurity, k posílení aplikace.

Konfigurace HTTPS

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

Příkaz příkazového řádku dotnet používá vlastnosti nebo launchSettings.jsaplikace v souboru, což nakonfiguruje aplikaci tak, aby naslouchala adresám URL poskytnutým applicationUrl vlastností. Například, https://localhost:5001;http://localhost:5000.

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

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

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

• Posílit zabezpečení tím, že se využívaly některé postupy, které jsou znázorněné v následujícím souboru /etc/Nginx/Nginx.conf .

• Následující příklad neprovádí konfiguraci serveru pro přesměrování nezabezpečených požadavků. Doporučujeme použít middleware pro přesměrování protokolu HTTPS. Další informace naleznete v tématu Vynutilit HTTPS v ASP.NET Core.

  Poznámka

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

• Přidáním Strict-Transport-Security hlavičky (HSTS) se zajistí, že všechny následné požadavky, které klient provede, budou přes protokol HTTPS. Pokyny k nastavení Strict-Transport-Security hlavičky najdete v tématu Vynutilit HTTPS v ASP.NET Core .

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

  • Nepřidávejte hlavičku HSTS.
  • Vyberte 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;

Obsah konfiguračního souboru /etc/nginx/nginx.conf nahraďte následujícím souborem. Příklad obsahuje oddíly http a server 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í služby Nginx před kliknutím

Kliknutí na ,označované také jako útok na nápravu uživatelského rozhraní, je škodlivý útok, kdy je návštěvník webu zveden k kliknutí na odkaz nebo tlačítko na jiné stránce, než je aktuálně navštěvovaná. K X-FRAME-OPTIONS zabezpečení lokality použijte .

Zmírnění útoků klikání:

1. Upravte soubor nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

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

2. Soubor uložte.

3. Restartujte Nginx.

Sniffing typu MIME

Tato hlavička brání většině prohlížečů v tom, aby při vychytávání odpovědi mimo deklarovaný typ obsahu schvalovat, protože hlavička instruuje prohlížeč, aby nepřepíše typ obsahu odpovědi. Pokud server říká, že je obsah , prohlížeč ho vykreslí nosniff text/html 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. Soubor uložte.

3. Restartujte Nginx.

Další návrhy služby Nginx

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

Další zdroje informací

• Požadavky pro .NET Core v Linuxu
• Nginx: Binární verze: Oficiální balíčky Debian/Ubuntu
• řešení potíží a ladění ASP.NET Corech projektů
• Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení
• NGINX: Použití hlavičky Forwarded