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 Development 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-átirányítási köztes szoftver inaktiválása a Development 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 publish parancsot a Development környezetből annak érdekében, hogy egy alkalmazást egy könyvtárba csomagoljon (például bin/Release/{TARGET FRAMEWORK MONIKER}/publish), ahol a {TARGET FRAMEWORK MONIKER} helyőrző a Target Framework Moniker (TFM), amely a szerveren futtatható.

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 reverse proxy továbbítja, használja a csomagból származó Microsoft.AspNetCore.HttpOverrides, amelyet az ASP.NET Core-alkalmazások automatikusan tartalmaznak a megosztott keretrendszer Microsoft.AspNetCore.App metacsomagja révén. 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éceket kezelő köztes rétegnek a többi köztes réteg előtt kell lefutnia. 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 tekintse meg a továbbított fejlécek köztes szoftverének sorrendjét.

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á a(z) 10.0.0.100 IP-című, továbbított fejléceket kezelő köztes szoftverhez 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=SIGTERM
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(z) systemd beállítása, amely egyben a KillSignal alapértelmezett KillSignal=SIGTERM is, lehetővé teszi, hogy a .NET-alkalmazások szabályosan leálljanak, és megfelelően felszabadítsák az erőforrásokat. Kerülje a(z) KillSignal=SIGINT beállítását, mivel a .NET élettartam-integrációk a(z) SIGTERM jelre figyelnek a szabályos leállítás kezdeményezéséhez, és más jelek hirtelen leállást eredményezhetnek.

A TimeoutStopSec használatával beállíthatja, mennyi ideig kell várni az alkalmazás leállására a kezdeti leállítási jel fogadása után. Ha az alkalmazás ebben az időszakban nem áll le, az alkalmazás leállításához a(z) SIGKILL parancs kerül kiadásra. 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 végtelenként (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-átirányítási köztes szoftver 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-átirányítási köztes szoftver 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.

Kapcsolódó tartalom

• 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