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

Autor: Sourabh Shirhatti

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 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.

Prerequisites

Ubuntu

• Přístup k Ubuntu 20.04 se standardním uživatelským účtem s oprávněním sudo.
• Nejnovější stabilní modul runtime .NET nainstalovaný na serveru.
• Existující aplikace ASP.NET Core.

Red Hat Enterprise Linux

• Přístup ke službě Red Hat Enterprise (RHEL) 8.0 nebo novější se standardním uživatelským účtem s oprávněním sudo.
• Na serveru je nainstalován nejnovější stabilní modul runtime .NET.
• Existující aplikace ASP.NET Core.

SUSE Linux Enterprise Server

• Přístup k SLES 12 nebo 15 se standardním uživatelským účtem s oprávněním sudo.
• Nejnovější stabilní modul runtime .NET 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ě v Development 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:

  • Deaktivovat middleware pro přesměrování HTTPS v prostředí Development (Program.cs):

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

    Další informace najdete v tématu běhová prostředí ASP.NET Core.

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

Další informace o konfiguraci podle prostředí naleznete v části ASP.NET Core runtime environments.

Spusťte dotnet publish z prostředí Development, abyste zabalili aplikaci do adresáře (například bin/Release/{TARGET FRAMEWORK MONIKER}/publish), kde je zástupný symbol {TARGET FRAMEWORK MONIKER}Target Framework Moniker (TFM), který může běžet na serveru.

dotnet publish --configuration Release

Aplikaci můžete také publikovat jako samostatné nasazení, pokud nechcete udržovat .NET runtime na serveru.

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

Note

V rámci scénáře produkčního nasazení pracovní postup kontinuální integrace provede publikování aplikace a kopírování prostředků na server.

Otestujte aplikaci:

1. Z příkazového řádku spusťte aplikaci: dotnet <app_assembly>.dll.
2. V prohlížeči přejděte na http://<serveraddress>:<port> a ověřte, že aplikace funguje lokálně 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 balíčku, který je automaticky zahrnut do aplikací ASP.NET Core prostřednictvím metabalíčku sdíleného frameworku Microsoft.AspNetCore.App. Middleware aktualizuje Request.Scheme pomocí hlavičky X-Forwarded-Proto, aby přesměrovací URI a další bezpečnostní zásady 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 spustit middleware Forwarded Headers po middleware pro diagnostiku a zpracování chyb, přečtěte si sekci Pořadí middlewaru pro předávané hlavičky.

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

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ává důvěryhodný proxy server s IP adresou 10.0.0.100 ke middlewaru Forwarded Headers KnownProxies.

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

var builder = WebApplication.CreateBuilder(args);

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

builder.Services.AddAuthentication();

var app = builder.Build();

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

app.UseAuthentication();

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

app.Run();

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

Ubuntu

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: linuxové balíčky – Ubuntu.

Red Hat Enterprise Linux

Slouží yum-utils k výběru a instalaci streamu modulu Nginx. Postupujte podle pokynů k instalaci RHEL na serveru Nginx: Balíčky Pro Linux – RHEL.

SUSE Linux Enterprise Server

Slouží yum-utils k výběru a instalaci streamu modulu Nginx. Postupujte podle pokynů k instalaci pro SLES na serveru Nginx: Balíčky Pro Linux – SLES.

Note

Pokud jsou požadovány volitelné moduly Nginx, může být vyžadováno sestavení Nginx ze zdroje.

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 Nginx

Ubuntu

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 a znovu vytvořte symlink. Po vytvoření /etc/nginx/sites-available/default souboru pomocí následujícího příkazu vytvořte symlink:

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

Otevřete /etc/nginx/sites-available/default v textovém editoru a nahraďte obsah následujícím fragmentem kódu:

Red Hat Enterprise Linux

Chcete-li nakonfigurovat Nginx jako reverzní proxy pro předávání požadavků HTTP do aplikace ASP.NET Core, upravte /etc/nginx.conf. http{} Aktualizujte blok kódu následujícím fragmentem kódu:

SUSE Linux Enterprise Server

Chcete-li nakonfigurovat Nginx jako reverzní proxy pro předávání požadavků HTTP do aplikace ASP.NET Core, upravte /etc/nginx.conf. http{} Aktualizujte blok kódu následujícím fragmentem kódu:

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 nebo Blazor Server aplikaci, další informace najdete v tématu produkční hostování a škálování ASP.NET Core SignalR a hostování a nasazení aplikací ASP.NET Core na straně serveru Blazor.

Pokud žádná server_name shoda není, 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.

Warning

Nespecifikování správné direktivy server_name vystavuje vaši aplikaci bezpečnostním zranitelnostem. Vazba zástupných znaků subdomény (například *.example.com) nepředstavuje toto bezpečnostní riziko, pokud řídíte celou nadřazenou doménu (na rozdíl od *.com, která je zranitelná). Další informace naleznete v dokumentu RFC 9110: Sémantika HTTP (oddíl 7.2: Hostitel a :authority).

Po vytvoření konfigurace Nginx spusťte sudo nginx -t ke kontrole syntaxe konfiguračních souborů. Pokud je test konfiguračního souboru úspěšný, přinuťte Nginx, aby si změn všiml 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.

Ubuntu

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í nutné povolit pravidlo odchozího portu 80, protože odchozí provoz je automaticky povolen, když je povolené příchozí pravidlo.

Red Hat Enterprise Linux

Pokud aplikace běží na serveru, ale nereaguje přes internet, zkontrolujte bránu firewall serveru a ověřte, že je otevřený port 80.

SUSE Linux Enterprise Server

Pokud aplikace běží na serveru, ale nereaguje přes internet, zkontrolujte bránu firewall serveru a ověřte, že je otevřený port 80.

Po dokončení testování aplikace v příkazovém prostředí aplikaci vypněte Ctrl+C.

Zvýšit keepalive_requests

keepalive_requests může být zvýšena pro vyšší výkon. Další informace najdete v této záležitosti na GitHubu.

Monitorování aplikace

Server je nastavený tak, aby požadavky zaslané na http://<serveraddress>:80 byly přesměrovány na aplikaci ASP.NET Core běžící na adrese Kestrel na 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 nezavře během této doby, je vyslán signál SIGKILL, aby ukončil aplikaci. Zadejte hodnotu jako sekundy bez jednotky (například 150), hodnotu časového rozsahu (například 2min 30s), nebo infinity pro deaktivaci časového limitu. TimeoutStopSec má výchozí hodnotu DefaultTimeoutStopSec v konfiguračním souboru manažera (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 na Production způsobí hledání konfiguračního souboru appsettings.Production.json, nikoli appsettings.production.json.

Některé hodnoty (například připojovací řetězce SQL) musí být escapeované, aby zprostředkovatelé konfigurace mohli číst proměnné prostředí. Pomocí následujícího příkazu vygenerujte správně escapovanou 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řevádí dvojité podtržítko na dvojtečky, když se proměnné prostředí načítají do konfigurace. V následujícím příkladu je klíč připojovacího řetězce ConnectionStrings:DefaultConnection nastaven v definičním souboru služby takto: ConnectionStrings__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 reverzním proxy serverem , spravovaným přes , je webová aplikace plně nakonfigurovaná a lze ji přistupovat z prohlížeče na místním počítači na adrese . Je také přístupný ze vzdáleného počítače, pokud nějaký firewall nezablokuje přístup. 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 pomocí Kestrel spravuje systemd, všechny události a procesy se zaznamenávají 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 today, --until 1 hour ago, nebo kombinace těchto možností 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í klíčů v klidu 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

Warning

Nezvyšujte výchozí hodnoty vyrovnávacích pamětí proxy serveru, pokud to není nutné. Zvýšení těchto hodnot zvyšuje riziko přetečení vyrovnávací paměti (overflow) a útoků DoS (Denial of Service) škodlivými uživateli.

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á.

Nakonfigurujte bránu firewall

Zavřete všechny externí porty, které se nepoužívají. Jednoduchá brána firewall (ufw) poskytuje rozhraní iptables tím, že nabízí rozhraní příkazového řádku pro konfiguraci brány firewall.

Ubuntu

Warning

Firewall zabraňuje přístupu k celému systému, pokud není správně nakonfigurovaná. Pokud při připojení používáte SSH a správný port SSH není zadán správně, efektivně to zabrání vašemu přístupu do systému. Výchozí port je 22. Další informace najdete v úvodu k ufw a příručce.

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

Red Hat Enterprise Linux

Warning

Brána firewall zabraňuje přístupu k celému systému, pokud není správně nakonfigurován. Pokud nespecifikujete správný port SSH, fakticky se tím zablokujete ze systému, když se k němu pokoušíte připojit pomocí SSH. Výchozí port je 22. Další informace najdete v úvodu k ufw.

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

sudo yum -y install ufw

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

sudo ufw enable

SUSE Linux Enterprise Server

Warning

Brána firewall zabraňuje přístupu k celému systému, pokud není správně nakonfigurován. Pokud nespecifikujete správně SSH port, efektivně se tím při používání SSH zablokujete mimo systém. Výchozí port je 22. Další informace najdete v úvodu k ufw.

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

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 ModSecurity, pro zpevnění 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ým vlastností applicationUrl. 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)

Warning

Konfigurace zabezpečení v této části je obecná konfigurace, která se má použít jako výchozí bod pro další přizpůsobení. Nemůžeme poskytovat podporu pro nástroje, servery a operační systémy třetích stran. Použijte konfiguraci v této části na vlastní nebezpečí. Další informace najdete v následujících zdrojích informací:

• Konfigurace serverů HTTPS (dokumentace K serveru Nginx)
• Generátor konfigurace protokolu MOZILLA.ORG SSL

• 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 pro přesměrování HTTPS. Další informace najdete v tématu Vynucení HTTPS v ASP.NET Core.

  Note

  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;

Ubuntu

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

Red Hat Enterprise Linux

Upravit /etc/nginx/nginx.conf. Otevřete ho v textovém editoru a nahraďte obsah uvnitř bloků kódu http{} a server{} následujícím úryvkem kódu:

SUSE Linux Enterprise Server

Upravit /etc/nginx/nginx.conf. Otevřete ho v textovém editoru a nahraďte bloky kódu http{} a server{} následujícím úryvkem.

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

Note

Blazor WebAssembly aplikace vyžadují větší burst hodnotu parametru, aby vyhovovaly většímu počtu požadavků provedených aplikací. Další informace najdete v části Hostování a nasazení ASP.NET Core Blazor WebAssembly s Nginx.

Note

Předchozí příklad zakazuje OCSP stapling (Online Certificate Status Protocol). Pokud je tato funkce povolená, ověřte, že certifikát tuto funkci podporuje. Další informace a pokyny k povolení OCSP najdete v článku o modulu ngx_http_ssl_module (dokumentace Nginx):

• ssl_stapling
• ssl_stapling_file
• ssl_stapling_responder
• ssl_stapling_verify

Zabezpečení Nginx proti clickjackingu

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

Jak zmírnit útoky 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. Při využití možnosti nosniff, 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.

Dodatečné zdroje

• Požadavky pro .NET v Linuxu
• Nginx: Balíčky Pro Linux – 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