ASP.NET Core üzemeltetése Linuxon az Nginx használatával

Készítette: Sourabh Shirhatti

Ez az útmutató egy éles használatra kész ASP.NET Core-környezet beállítását ismerteti az Ubuntu, a Red Hat Enterprise (RHEL) és a SUSE Linux Enterprise Server számára.

Az ASP.NET Core által támogatott egyéb Linux-disztribúciókról a Linuxon futó .NET előfeltételei című témakörben olvashat.

Ez az útmutató:

• Egy meglévő ASP.NET Core-alkalmazást helyez egy fordított proxykiszolgáló mögé.
• Beállítja a fordított proxykiszolgálót a kérések Kestrel webkiszolgálóra való továbbításához.
• Biztosítja, hogy a webalkalmazás indításkor démonként fusson.
• Folyamatkezelő eszközt konfigurál a webalkalmazás újraindításához.

Prerequisites

Ubuntu

• Hozzáférés az Ubuntu 20.04-hez egy sudo jogosultsággal rendelkező standard felhasználói fiókkal.
• A kiszolgálóra telepített legújabb stabil .NET-futtatókörnyezet.
• Egy meglévő ASP.NET Core-alkalmazás.

Red Hat Enterprise Linux

• Hozzáférés a Red Hat Enterprise (RHEL) 8.0-s vagy újabb verziójához egy sudo jogosultsággal rendelkező standard felhasználói fiókkal.
• A kiszolgálóra telepített legújabb stabil .NET-futtatókörnyezet.
• Egy meglévő ASP.NET Core-alkalmazás.

SUSE Linux Enterprise Server

• Hozzáférés az SLES 12-hez vagy 15-höz egy sudo jogosultsággal rendelkező standard felhasználói fiókkal.
• A kiszolgálóra telepített legújabb stabil .NET-futtatókörnyezet.
• Egy meglévő ASP.NET Core-alkalmazás.

A megosztott keretrendszer frissítése után a jövőben bármikor indítsa újra a kiszolgáló által üzemeltetett ASP.NET Core-alkalmazásokat.

Közzététel és másolás az alkalmazáson keresztül

Konfigurálja az alkalmazást egy keretrendszerfüggő üzembe helyezési.

Ha az alkalmazás helyileg fut a fejlesztői környezetben, és a kiszolgáló nem konfigurálja biztonságos HTTPS-kapcsolatok létesítésére, alkalmazza az alábbi módszerek egyikét:

• Konfigurálja az alkalmazást a biztonságos helyi kapcsolatok kezelésére. További információkért lásd a HTTPS-konfiguráció szakaszt.

• Konfigurálja az alkalmazást a nem biztonságos végponton való futtatásra:

  • HTTPS Redirection Middleware inaktiválása a fejlesztési környezetben (Program.cs):

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

    További információ: ASP.NET Core futtatókörnyezetek.

  • Távolítsa el https://localhost:5001 (ha van ilyen) a applicationUrl fájl Properties/launchSettings.json tulajdonságából.

További információ a környezetek szerinti konfigurációról: ASP.NET Core futtatókörnyezetek.

Futtassa a dotnet-közzétételt a fejlesztői környezetből, és csomagoljon be egy alkalmazást egy könyvtárba (például bin/Release/{TARGET FRAMEWORK MONIKER}/publishahol a {TARGET FRAMEWORK MONIKER} helyőrző a Target Framework Moniker (TFM)), amely futtatható a kiszolgálón:

dotnet publish --configuration Release

Az alkalmazás közzétehető önálló üzemelő példányként is, ha nem szeretné fenntartani a .NET-futtatókörnyezetet a kiszolgálón.

Másolja a ASP.NET Core alkalmazást a kiszolgálóra egy olyan eszközzel, amely integrálható a szervezet munkafolyamatába (például SCP, SFTP). Gyakran előfordul, hogy webalkalmazásokat keres a var könyvtárban (például var/www/helloapp).

Note

Éles üzembe helyezési forgatókönyv esetén a folyamatos integrációs munkafolyamat elvégzi az alkalmazás közzétételét és az eszközök kiszolgálóra másolását.

Az alkalmazás tesztelése:

1. A parancssorból futtassa az alkalmazást: dotnet <app_assembly>.dll.
2. A böngészőben nyissa meg a http://<serveraddress>:<port> oldalt, és ellenőrizze, hogy az alkalmazás Linuxon helyileg működik-e.

Fordított proxykiszolgáló konfigurálása

A fordított proxy a dinamikus webalkalmazások kiszolgálásának gyakori beállítása. A fordított proxy leállítja a HTTP-kérést, és továbbítja azt a ASP.NET Core-alkalmazásnak.

Fordított proxykiszolgáló használata

Kestrel kiválóan alkalmas dinamikus tartalmak kiszolgálására ASP.NET Core-ból. A webes kiszolgálói képességek azonban nem olyan gazdagok, mint például az IIS, az Apache vagy az Nginx. A fordított proxykiszolgálók képesek levenni a munkaterhet az HTTP-kiszolgálóról úgy, mint a statikus tartalom kiszolgálása, a kérések gyorsítótárazása, azok tömörítése és a HTTPS kapcsolatok lezárása. Előfordulhat, hogy a fordított proxykiszolgáló egy dedikált gépen található, vagy egy HTTP-kiszolgáló mellett is üzembe helyezhető.

Az útmutató alkalmazásában a rendszer egyetlen Nginx-példányt használ. Ugyanazon a kiszolgálón fut a HTTP-kiszolgáló mellett. A követelmények alapján másik beállítás is kiválasztható.

Mivel a kéréseket fordított proxy továbbítja, használja a csomag Microsoft.AspNetCore.HttpOverrides, amely automatikusan bekerül az ASP.NET Core-alkalmazásokba a megosztott keretrendszer Microsoft.AspNetCore.App metapackage. A köztes szoftver frissíti a Request.Scheme-t a X-Forwarded-Proto fejléc használatával, hogy az átirányítási URI-k és más biztonsági szabályzatok megfelelően működjenek.

A továbbított fejlécek köztes szoftvernek a többi köztes szoftver előtt kell futnia. Ez a rendezés biztosítja, hogy a továbbított fejlécekre támaszkodó köztes szoftver feldolgozhassa a fejlécértékeket. A továbbított fejlécek köztes szoftver diagnosztikát és hibakezelést követő futtatásához lásd a Továbbított fejlécek köztes szoftver sorrendjerészt.

Más köztes szoftver meghívása előtt hívja meg a UseForwardedHeaders metódust. Konfigurálja a köztes szoftvert a X-Forwarded-For és X-Forwarded-Proto fejlécek továbbítására:

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

Ha nincs megadva ForwardedHeadersOptions a köztes szoftvernek, a továbbítandó alapértelmezett fejlécek Nonelesznek.

Alapértelmezés szerint a visszacsatolási címeken (127.0.0.0/8, [::1]) futó proxyk, beleértve a standard localhost-címet (127.0.0.1) is, alapértelmezés szerint megbízhatók. Ha a szervezeten belül más megbízható proxyk vagy hálózatok kezelik az internet és a webszerver közötti kérelmeket, vegye fel őket a KnownProxies vagy KnownNetworks listára a ForwardedHeadersOptionssegítségével. Az alábbi példa egy megbízható proxykiszolgálót ad hozzá az 10.0.0.100 IP-címet a Továbbított fejlécek köztes réteghez 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();

További információ: A ASP.NET Core konfigurálása proxykiszolgálókkal és terheléselosztókkal.

Az Nginx telepítése

Ubuntu

Nginx telepítéséhez használja a apt-get-t. A telepítő létrehoz egy systemd init szkriptet, amely démonként futtatja az Nginxet a rendszerindításkor. Kövesse az Ubuntu telepítési utasításait az Nginx: Linux-csomagok – Ubuntu címen.

Red Hat Enterprise Linux

Nginx-modulstream kiválasztásához és telepítéséhez használja a yum-utils. Kövesse az RHEL telepítési utasításait Nginx: Linux-csomagok – RHEL.

SUSE Linux Enterprise Server

Nginx-modulstream kiválasztásához és telepítéséhez használja a yum-utils. Kövesse az SLES telepítési utasításait Nginx: Linux-csomagok – SLES.

Note

Ha nem kötelező Nginx-modulokra van szükség, szükség lehet az Nginx forrásból való létrehozására.

Mivel az Nginx első alkalommal lett telepítve, explicit módon indítsa el a következő futtatásával:

sudo service nginx start

Ellenőrizze, hogy egy böngésző megjeleníti-e az Nginx alapértelmezett kezdőlapot. A kezdőlap http://<server_IP_address>/index.nginx-debian.htmlérhető el.

Az Nginx konfigurálása

Ubuntu

Ha az Nginxet fordított proxyként szeretné konfigurálni a HTTP-kérések ASP.NET Core-alkalmazásba való továbbításához, módosítsa a /etc/nginx/sites-available/default, és hozza létre újra a szimlinket. A /etc/nginx/sites-available/default fájl létrehozása után a következő paranccsal hozza létre a szimlinket:

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

Nyissa meg a /etc/nginx/sites-available/default egy szövegszerkesztőben, és cserélje le a tartalmat a következő kódrészletre:

Red Hat Enterprise Linux

Ha az Nginxet fordított proxyként szeretné konfigurálni a HTTP-kérések ASP.NET Core-alkalmazásba való továbbításához, módosítsa a /etc/nginx.conf. Frissítse a http{} kódblokkot a következő kódrészlettel:

SUSE Linux Enterprise Server

Ha az Nginxet fordított proxyként szeretné konfigurálni a HTTP-kérések ASP.NET Core-alkalmazásba való továbbításához, módosítsa a /etc/nginx.conf. Frissítse a http{} kódblokkot a következő kódrészlettel:

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

Ha az alkalmazás egy SignalR vagy Blazor Server alkalmazás, további információért tekintse meg a ASP.NET Core SignalR éles üzemeltetéséről és skálázásáról, illetve a ASP.NET Core kiszolgálóoldali Blazor alkalmazások kiszolgálásáról és üzembe helyezéséről.

Ha nincs server_name egyezés, az Nginx az alapértelmezett kiszolgálót használja. Ha nincs megadva alapértelmezett kiszolgáló, a konfigurációs fájl első kiszolgálója az alapértelmezett kiszolgáló. Ajánlott egy adott alapértelmezett kiszolgáló hozzáadása, amely egy 444-as állapotkódot ad vissza a konfigurációs fájlban. Egy alapértelmezett kiszolgálókonfigurációs példa:

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

Az előző konfigurációs fájl és az alapértelmezett kiszolgáló esetén az Nginx a nyilvános forgalmat a 80-as porton fogadja a example.com vagy *.example.comkiszolgálófejléc használatával. Azon kérések, amelyek nem felelnek meg ezeknek a gazdagépeknek, nem lesznek továbbítva Kestrel-ra. Az Nginx továbbítja az egyező kéréseket Kestrel-hoz http://127.0.0.1:5000/-nél. További információ: Hogyan dolgozza fel az nginx a kéréseket. KestrelIP-címének/portjának módosításáról lásd: Kestrel: Végpontkonfigurációs.

Warning

A megfelelő server_name irányelv megadásának elmulasztása az alkalmazást biztonsági réseknek teszi ki. Az altartomány helyettesítő karakterek kötése (például *.example.com) nem jelent ilyen biztonsági kockázatot, ha az egész szülőtartományt ön irányítja (ellentétben a sebezhető *.com-gyel). További információért lásd: RFC 9110: HTTP Szemantika (7.2. szakasz: Host és :authority).

Az Nginx-konfiguráció létrehozása után futtassa a sudo nginx -t a konfigurációs fájlok szintaxisának ellenőrzéséhez. Ha a konfigurációs fájl tesztelése sikeres, kényszerítse az Nginxet a módosítások felvételére a sudo nginx -s reloadfuttatásával.

Az alkalmazás közvetlen futtatása a kiszolgálón:

1. Lépjen az alkalmazás könyvtárába.
2. Futtassa az alkalmazást: dotnet <app_assembly.dll>, ahol a app_assembly.dll az alkalmazás szerelvényfájljának neve.

Ubuntu

Ha az alkalmazás fut a kiszolgálón, de nem válaszol az interneten keresztül, ellenőrizze a kiszolgáló tűzfalát, és ellenőrizze, hogy a 80-es port nyitva van-e. Ha Azure Ubuntu virtuális gépet használ, adjon hozzá egy hálózati biztonsági csoport (NSG) szabályt, amely engedélyezi a bejövő 80-os port forgalmát. Nincs szükség a 80-as portra vonatkozó kimenő szabály engedélyezésére, mivel a kimenő forgalom automatikusan meg lesz adva, amikor a bejövő szabály engedélyezve van.

Red Hat Enterprise Linux

Ha az alkalmazás fut a kiszolgálón, de nem válaszol az interneten keresztül, ellenőrizze a kiszolgáló tűzfalát, és ellenőrizze, hogy a 80-es port nyitva van-e.

SUSE Linux Enterprise Server

Ha az alkalmazás fut a kiszolgálón, de nem válaszol az interneten keresztül, ellenőrizze a kiszolgáló tűzfalát, és ellenőrizze, hogy a 80-es port nyitva van-e.

Ha végzett az alkalmazás tesztelésével, állítsa le az alkalmazást a parancshéjban a Ctrl + billentyűkombinációval.

A keepalive_requests növelése

keepalive_requests növelhető nagyobb teljesítményhez. További információért lásd ezt a GitHub-jegyzetet: .

Az alkalmazás figyelése

A kiszolgáló úgy van beállítva, hogy továbbítsa a http://<serveraddress>:80 érkező kéréseket a ASP.NET Core alkalmazásnak, amely a Kestrelhttp://127.0.0.1:5000 fut. Az Nginx azonban nincs beállítva a Kestrel folyamat kezelésére. systemd használható egy szolgáltatásfájl létrehozásához a mögöttes webalkalmazás elindításához és figyeléséhez. systemd egy init rendszer, amely számos hatékony funkciót biztosít a folyamatok elindításához, leállításához és kezeléséhez.

A szolgáltatásfájl létrehozása

Hozza létre a szolgáltatásdefiníciós fájlt:

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

Az alábbi példa egy .ini szolgáltatásfájl az alkalmazáshoz:

[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

Az előző példában a szolgáltatást kezelő felhasználót a User beállítás határozza meg. A felhasználónak (www-data) léteznie kell, és rendelkeznie kell az alkalmazás fájljainak megfelelő tulajdonjogával.

A TimeoutStopSec használatával konfigurálhatja, hogy mennyi ideig várjon az alkalmazás a kezdeti megszakítási jel fogadása után. Ha az alkalmazás ebben az időszakban nem áll le, a SIGKILL parancsot kiadják az alkalmazás leállítására. Adja meg az értéket egység nélküli másodpercként (például 150), egy időtartamértékként (például 2min 30s), vagy infinity az időtúllépés letiltásához. TimeoutStopSec alapértelmezés szerint a kezelő konfigurációs fájljában (DefaultTimeoutStopSec, systemd-system.conf, system.conf.d, systemd-user.conf) lévő user.conf.d értéke. A legtöbb disztribúció alapértelmezett időtúllépési ideje 90 másodperc.

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

A Linux kis- és nagybetűkre érzékeny fájlrendszerrel rendelkezik. A ASPNETCORE_ENVIRONMENTProduction beállítása a konfigurációs fájl appsettings.Production.jsonkeresését eredményezi, nem appsettings.production.json.

Bizonyos értékeket (például SQL-kapcsolati sztringeket) escape-elni kell ahhoz, hogy a konfiguráció-szolgáltatók beolvassák a környezeti változókat. A konfigurációs fájlban való használatra a következő paranccsal hozzon létre egy megfelelően kimentett értéket:

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

A kettőspont (:) elválasztók nem támogatottak a környezeti változók neveiben. Kettős aláhúzásjelet (__) használjon kettőspont helyett. A környezeti változók konfigurációszolgáltatója a kettős aláhúzásjeleket kettőspontokká alakítja, amikor a környezeti változókat konfigurációként olvassa be. Az alábbi példában a kapcsolati sztringkulcs ConnectionStrings:DefaultConnectionConnectionStrings__DefaultConnectionkulcsként van beállítva a szolgáltatásdefiníciós fájlban.

Environment=ConnectionStrings__DefaultConnection={Connection String}

Mentse a fájlt, és engedélyezze a szolgáltatást.

sudo systemctl enable kestrel-helloapp.service

Indítsa el a szolgáltatást, és ellenőrizze, hogy fut-e.

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

A fordított proxy konfigurálásával és Kestrelsystemdkeresztüli felügyeletével a webalkalmazás teljes mértékben konfigurálva van, és a helyi gépen található böngészőből érhető el http://localhost. Egy távoli gépről is elérhető, és letiltja az esetlegesen blokkolható tűzfalat. A válaszfejlécek vizsgálatakor a Server fejlécen az Kestreláltal kiszolgált ASP.NET Core-alkalmazás látható.

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

Naplók megtekintése

Mivel a Kestrel használó webalkalmazás kezelése systemdtörténik, a rendszer minden eseményt és folyamatot egy központi naplóba naplóz. Ez a napló azonban az systemdáltal kezelt összes szolgáltatás és folyamat összes bejegyzését tartalmazza. A kestrel-helloapp.service-specifikus elemek megtekintéséhez használja a következő parancsot:

sudo journalctl -fu kestrel-helloapp.service

A további szűréshez az olyan időbeállítások, mint a --since today, a --until 1 hour agovagy ezek kombinációja csökkentheti a visszaadott bejegyzések számát.

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

Adatvédelem

A ASP.NET Core Data Protection vermet számos ASP.NET Core köztes szoftver használja, beleértve a hitelesítési köztes szoftvereket (például cookie köztes szoftvereket) és a helyek közötti kérelemhamisítási (CSRF) védelmet. Annak ellenére, hogy az adatvédelmi API-kat nem felhasználói kód hívja meg, az adatvédelmet konfigurálni kell egy állandó titkosítási kulcstárolólétrehozásához. Ha az adatvédelem nincs konfigurálva, a kulcsok a memóriában lesznek tárolva, és az alkalmazás újraindításakor elvesznek.

Ha a kulcsgyűrű a memóriában van tárolva, amikor az alkalmazás újraindul:

• A rendszer minden egyes cookie-alapú hitelesítési tokent automatikusan érvénytelenít.
• A felhasználóknak ismét be kell jelentkezniük a következő kérésükre.
• A kulcsgyűrűvel védett adatok már nem fejthetők vissza. Ilyenek lehetnek CSRF-jogkivonatok és ASP.NET Core MVC TempData-cookie-k.

A kulcsgyűrű megőrzéséhez és titkosításához az adatvédelem konfigurálásához lásd:

• ASP.NET Core kulcstároló-szolgáltatók
• Kulcs titkosítása nyugalmi állapotban a Windowsban és az Azure-ban az ASP.NET Core segítségével

Hosszú kérelem fejlécmezői

A proxykiszolgáló alapértelmezett beállításai általában a kérelem fejlécmezőit a platformtól függően 4 K-ra vagy 8 K-ra korlátozzák. Egy alkalmazáshoz az alapértelmezettnél hosszabb mezőkre lehet szükség (például Microsoft Entra-azonosítóthasználó alkalmazásokhoz). Ha hosszabb mezőkre van szükség, a proxykiszolgáló alapértelmezett beállításainak módosítása szükséges. Az alkalmazandó értékek a forgatókönyvtől függenek. További információkért tekintse meg a kiszolgáló dokumentációját.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Warning

Ha szükséges, ne növelje a proxypufferek alapértelmezett értékeit. Ezen értékek növelése növeli a puffertúlcsordulás (túlcsordulás) és a Szolgáltatásmegtagadás (DoS) rosszindulatú felhasználók általi támadásainak kockázatát.

Az alkalmazás védelme

AppArmor engedélyezése

A Linux biztonsági modulok (LSM) egy keretrendszer, amely a Linux kernel része a Linux 2.6 óta. Az LSM a biztonsági modulok különböző implementációit támogatja. AppArmor egy olyan LSM, amely egy kötelező hozzáférés-vezérlési rendszert implementál, amely lehetővé teszi a program korlátozott erőforráskészletre való konfigurálását. Győződjön meg arról, hogy az AppArmor engedélyezve van és megfelelően van konfigurálva.

A tűzfal konfigurálása

Zárja be a nem használt külső portokat. Az Uncomplicated Firewall (ufw) egy felhasználói felületet biztosít a iptables számára azáltal, hogy parancssori felületet biztosít a tűzfal konfigurálásához.

Ubuntu

Warning

A tűzfal megakadályozza a teljes rendszerhez való hozzáférést, ha nincs megfelelően konfigurálva. Ha nem adja meg a megfelelő SSH-portot, ezzel hatékonyan kizárja magát a rendszerből, ha SSH-t használ a csatlakozáshoz. Az alapértelmezett port a 22. További információért lásd az ufw bevezetést és a kézikönyv-at.

Telepítse ufw, és konfigurálja úgy, hogy engedélyezze a forgalmat a szükséges portokon.

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

A tűzfal megakadályozza a teljes rendszerhez való hozzáférést, ha nincs megfelelően konfigurálva. Ha nem adja meg a megfelelő SSH-portot, ezzel hatékonyan kizárja magát a rendszerből, ha SSH-t használ a csatlakozáshoz. Az alapértelmezett port a 22. További információért lásd a ufwbevezetést.

Telepítse ufw, és konfigurálja úgy, hogy engedélyezze a forgalmat a szükséges portokon.

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

A tűzfal megakadályozza a teljes rendszerhez való hozzáférést, ha nincs megfelelően konfigurálva. Ha nem adja meg a megfelelő SSH-portot, ezzel hatékonyan kizárja magát a rendszerből, ha SSH-t használ a csatlakozáshoz. Az alapértelmezett port a 22. További információért lásd a ufwbevezetést.

Telepítse ufw, és konfigurálja úgy, hogy engedélyezze a forgalmat a szükséges portokon.

sudo yum -y install ufw

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

sudo ufw enable

Biztonságos Nginx

Az Nginx-válasz nevének módosítása

src/http/ngx_http_header_filter_module.cszerkesztése:

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

Beállítások konfigurálása

Konfigurálja a kiszolgálót további szükséges modulokkal. Érdemes lehet webalkalmazási tűzfalat (például ModSecurity) használni az alkalmazás megerősítéséhez.

HTTPS-konfiguráció

Az alkalmazás konfigurálása biztonságos (HTTPS) helyi kapcsolatokhoz

A dotnet run parancs az alkalmazás Properties/launchSettings.json fájlját használja, amely úgy konfigurálja az alkalmazást, hogy figyelje a applicationUrl tulajdonság által biztosított URL-címeket. Például https://localhost:5001;http://localhost:5000.

Konfigurálja az alkalmazást úgy, hogy a fejlesztés során tanúsítványt használjon a dotnet run parancs- vagy fejlesztői környezethez (F5 vagy Ctrl+F5 a Visual Studio Code-ban) az alábbi módszerek egyikével:

• Az alapértelmezett tanúsítvány cseréje a konfiguráció-ben (Ajánlott)
• KestrelServerOptions.ConfigureHttpsDefaults

A fordított proxy konfigurálása biztonságos (HTTPS) ügyfélkapcsolatokhoz

Warning

Az ebben a szakaszban található biztonsági konfiguráció egy általános konfiguráció, amelyet a további testreszabás kiindulópontjaként kell használni. Nem tudunk támogatást nyújtani külső eszközökhöz, kiszolgálókhoz és operációs rendszerekhez. Az ebben a szakaszban található konfigurációt saját felelősségére használhatja. További információkért keresse fel a következő erőforrásokat:

• HTTPS-kiszolgálók konfigurálása (Nginx-dokumentáció)
• mozilla.org SSL-konfigurációgenerátor

• Konfigurálja a kiszolgálót a HTTPS-forgalom figyelésére a 443-es porton egy megbízható hitelesítésszolgáltató (CA) által kiadott érvényes tanúsítvány megadásával.

• Az alábbi /etc/nginx/nginx.conf fájlban bemutatott eljárások alkalmazásával növelheti a biztonságot.

• Az alábbi példa nem konfigurálja a kiszolgálót a nem biztonságos kérések átirányítására. A HTTPS Redirection Middleware használatát javasoljuk. További információért látogasson el a(z) HTTPS kényszerítése ASP.NET Coreoldalra.

  Note

  Azoknál a fejlesztési környezetekben, ahol a kiszolgáló konfigurációja a HTTPS Redirection Middleware helyett a biztonságos átirányítást kezeli, javasoljuk, hogy ideiglenes átirányításokat (302) használjunk állandó átirányítások helyett (301). A linkek gyorsítótárazása instabil viselkedést okozhat a fejlesztési környezetekben.

• Ha hozzáad egy Strict-Transport-Security (HSTS) fejlécet, akkor az ügyfél által küldött összes további kérés HTTPS-en keresztül történik. A Strict-Transport-Security fejléc beállításával kapcsolatos útmutatóért tekintse meg a következőt: HTTPS kényszerítése az ASP.NET Core-ban.

• Ha a HTTPS le lesz tiltva a jövőben, használja az alábbi módszerek egyikét:

  • Ne adja hozzá a HSTS-fejlécet.
  • Válasszon egy rövid max-age értéket.

Adja hozzá a /etc/nginx/proxy.conf konfigurációs fájlt:

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

Cserélje le a /etc/nginx/nginx.conf konfigurációs fájl tartalmát a következő fájlra. A példa http és server szakaszokat tartalmaz egy konfigurációs fájlban.

Red Hat Enterprise Linux

Módosítsa a /etc/nginx/nginx.conf-t. Nyissa meg egy szövegszerkesztőben, és cserélje le a http{} és server{} kódblokkokat a következő kódrészletre:

SUSE Linux Enterprise Server

Módosítsa a /etc/nginx/nginx.conf-t. Nyissa meg egy szövegszerkesztőben, és cserélje le a http{} és server{} kódblokkokat a következő kódrészletre:

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 alkalmazások nagyobb burst paraméterértéket igényelnek az alkalmazás által küldött kérések számának kielégítéséhez. További információ: Gazdagép és üzembe helyezés ASP.NET Core Blazor WebAssembly with Nginx.

Note

Az előző példa letiltja az online tanúsítványállapot-protokoll (OCSP) stapling használatát. Ha engedélyezve van, ellenőrizze, hogy a tanúsítvány támogatja-e a funkciót. Az OCSP engedélyezésével kapcsolatos további információkért és útmutatásért tekintse meg az alábbi tulajdonságokat a modul ngx_http_ssl_module (Nginx-dokumentáció) cikkben:

• ssl_stapling
• ssl_stapling_file
• ssl_stapling_responder
• ssl_stapling_verify

Az Nginx védelme a kattintáseltérítés ellen

Clickjacking, más néven felhasználói felületi jogorvoslati támadás, egy rosszindulatú támadás, ahol a webhely látogatója trükközik, hogy kattintson egy hivatkozásra vagy gombra egy másik oldalon, mint amit éppen látogat. A webhely biztosításához használja a X-FRAME-OPTIONS-t.

A kattintási támadások mérséklése:

1. Szerkessze az nginx.conf fájlt:

   sudo nano /etc/nginx/nginx.conf
   

   A http{} kódblokkban adja hozzá a következő sort: add_header X-Frame-Options "SAMEORIGIN";

2. Mentse a fájlt.

3. Indítsa újra az Nginxet.

MIME típusú szippantás

Ez a fejléc megakadályozza, hogy a böngészők többsége a válasz tartalomtípustól eltérőt válasszon a MIME-átvizsgálás által, mivel a fejléc arra utasítja a böngészőt, hogy ne bírálja felül a válasz tartalomtípusát. A nosniff lehetőséggel, ha a kiszolgáló azt mondja, hogy a tartalom text/html, a böngésző text/htmljeleníti meg.

1. Szerkessze az nginx.conf fájlt:

   sudo nano /etc/nginx/nginx.conf
   

   A http{} kódblokkban adja hozzá a következő sort: add_header X-Content-Type-Options "nosniff";

2. Mentse a fájlt.

3. Indítsa újra az Nginxet.

További Nginx-javaslatok

Miután frissítette a megosztott keretrendszert a kiszolgálón, indítsa újra a kiszolgáló által üzemeltetett ASP.NET Core-alkalmazásokat.

További erőforrások

• A .NET előfeltételei Linuxon
• Nginx: Linux-csomagok – Ubuntu
• Alapvető projektek ASP.NET hibaelhárítása és hibakeresése
• ASP.NET Core konfigurálása a proxykiszolgálókkal és terheléselosztókkal való együttműködéshez
• NGINX: A Továbbított fejléc használata