Hostowanie aplikacji ASP.NET Core w systemie Linux z serwerem Nginx

Przez Sourabh Shirhatti

W tym przewodniku opisano konfigurowanie gotowego do produkcji środowiska ASP.NET Core dla systemów Ubuntu, Red Hat Enterprise (RHEL) i SUSE Linux Enterprise Server.

Aby uzyskać informacje na temat innych dystrybucji systemu Linux obsługiwanych przez platformę ASP.NET Core, zobacz Wymagania wstępne dotyczące platformy .NET Core w systemie Linux.

Ten przewodnik:

• Umieszcza istniejącą aplikację ASP.NET Core za zwrotnym serwerem proxy.
• Konfiguruje zwrotny serwer proxy do przekazywania żądań do serwera internetowego Kestrel .
• Gwarantuje, że aplikacja internetowa jest uruchamiana podczas uruchamiania jako demon.
• Konfiguruje narzędzie do zarządzania procesami, aby ułatwić ponowne uruchomienie aplikacji internetowej.

Wymagania wstępne

Ubuntu

• Dostęp do systemu Ubuntu 20.04 przy użyciu konta użytkownika standardowego z uprawnieniami sudo.
• Najnowsze stabilne środowisko uruchomieniowe platformy .NET zainstalowane na serwerze.
• Istniejąca aplikacja ASP.NET Core.

Red Hat Enterprise Linux

• Dostęp do oprogramowania Red Hat Enterprise (RHEL) 8.0 lub nowszego przy użyciu standardowego konta użytkownika z uprawnieniami sudo.
• Najnowsze stabilne środowisko uruchomieniowe platformy .NET zainstalowane na serwerze.
• Istniejąca aplikacja ASP.NET Core.

SUSE Linux Enterprise Server

• Dostęp do systemu SLES 12 lub 15 przy użyciu konta użytkownika standardowego z uprawnieniami sudo.
• Najnowsze stabilne środowisko uruchomieniowe platformy .NET zainstalowane na serwerze.
• Istniejąca aplikacja ASP.NET Core.

W dowolnym momencie po uaktualnieniu platformy udostępnionej uruchom ponownie aplikacje ASP.NET Core hostowane przez serwer.

Publikowanie i kopiowanie w aplikacji

Skonfiguruj aplikację na potrzeby wdrożenia zależnego od platformy.

Jeśli aplikacja jest uruchamiana lokalnie w środowisku programistycznym i nie jest skonfigurowana przez serwer w celu zapewnienia bezpiecznych połączeń HTTPS, zastosuj jedną z następujących metod:

• Skonfiguruj aplikację do obsługi bezpiecznych połączeń lokalnych. Aby uzyskać więcej informacji, zobacz sekcję Konfiguracja protokołu HTTPS.

• Skonfiguruj aplikację do uruchamiania w niezabezpieczonym punkcie końcowym:

  • Dezaktywowanie oprogramowania pośredniczącego przekierowania HTTPS w środowisku deweloperów (Program.cs):

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

    Więcej informacji można znaleźć w temacie Używanie wielu środowisk na platformie ASP.NET Core.

  • Usuń https://localhost:5001 (jeśli jest obecny) z applicationUrl właściwości w Properties/launchSettings.json pliku.

Aby uzyskać więcej informacji na temat konfiguracji według środowiska, zobacz Używanie wielu środowisk w programie ASP.NET Core.

Uruchom polecenie dotnet publish from the development environment (aby spakować aplikację do katalogu) (na przykład bin/Release/{TARGET FRAMEWORK MONIKER}/publish, gdzie {TARGET FRAMEWORK MONIKER} symbol zastępczy to Target Framework Moniker (TFM)), który można uruchomić na serwerze:

dotnet publish --configuration Release

Aplikację można również opublikować jako wdrożenie samodzielne, jeśli nie chcesz obsługiwać środowiska uruchomieniowego platformy .NET Core na serwerze.

Skopiuj aplikację ASP.NET Core na serwer przy użyciu narzędzia integrującego się z przepływem pracy organizacji (na przykład SCP, SFTP). Często lokalizowanie aplikacji internetowych w var katalogu (na przykład var/www/helloapp).

Uwaga

W scenariuszu wdrażania produkcyjnego przepływ pracy ciągłej integracji wykonuje pracę publikowania aplikacji i kopiowania zasobów na serwer.

Przetestuj aplikację:

1. W wierszu polecenia uruchom aplikację: dotnet <app_assembly>.dll.
2. W przeglądarce przejdź do adresu , aby http://<serveraddress>:<port> sprawdzić, czy aplikacja działa lokalnie w systemie Linux.

Konfigurowanie zwrotnego serwera proxy

Zwrotny serwer proxy to typowa konfiguracja obsługi dynamicznych aplikacji internetowych. Zwrotny serwer proxy kończy żądanie HTTP i przekazuje je do aplikacji ASP.NET Core.

Używanie zwrotnego serwera proxy

Kestrel doskonale nadaje się do obsługi zawartości dynamicznej z platformy ASP.NET Core. Jednak funkcje obsługujące sieć Web nie są tak bogate w funkcje, jak serwery, takie jak USŁUGI IIS, Apache lub Nginx. Zwrotny serwer proxy może odciążać pracę, taką jak obsługa zawartości statycznej, żądania buforowania, kompresowanie żądań i kończenie żądań HTTPS z serwera HTTP. Zwrotny serwer proxy może znajdować się na dedykowanej maszynie lub może zostać wdrożony wraz z serwerem HTTP.

Na potrzeby tego przewodnika jest używane pojedyncze wystąpienie serwera Nginx. Działa on na tym samym serwerze wraz z serwerem HTTP. W zależności od wymagań można wybrać inną konfigurację.

Ponieważ żądania są przekazywane przez zwrotny serwer proxy, należy użyć oprogramowania pośredniczącego nagłówków przekazywanych z Microsoft.AspNetCore.HttpOverrides pakietu, który jest automatycznie uwzględniany w aplikacjach ASP.NET Core za pośrednictwem metapakiety udostępnionej Microsoft.AspNetCore.App platformy. Oprogramowanie pośredniczące aktualizuje Request.Schemeelement przy użyciu nagłówka X-Forwarded-Proto , aby identyfikatory URI przekierowania i inne zasady zabezpieczeń działały poprawnie.

Oprogramowanie pośredniczące przekazanych nagłówków powinno być uruchamiane przed innym oprogramowaniem pośredniczącym. Takie określenie kolejności gwarantuje, że oprogramowanie pośredniczące polegające na informacjach przekazanych nagłówków może zużywać wartości nagłówków do przetwarzania. Aby uruchomić oprogramowanie pośredniczące przekazanych nagłówków po oprogramowaniu pośredniczącym diagnostyki i obsługi błędów, zobacz Kolejność oprogramowania pośredniczącego przekazanych nagłówków.

Wywołaj metodę UseForwardedHeaders przed wywołaniem innego oprogramowania pośredniczącego. Skonfiguruj oprogramowanie pośredniczące, aby przekazywać dalej X-Forwarded-For nagłówki i 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();

Jeśli nie ForwardedHeadersOptions określono żadnego oprogramowania pośredniczącego, domyślne nagłówki do przekazania to None.

Serwery proxy uruchomione na adresach sprzężenia zwrotnego (127.0.0.0/8, [::1]), w tym standardowy adres localhost (127.0.0.1), są domyślnie zaufane. Jeśli inne zaufane serwery proxy lub sieci w organizacji obsługują żądania między Internetem a serwerem internetowym, dodaj je do listy KnownProxies lub KnownNetworks za pomocą ForwardedHeadersOptionspolecenia . Poniższy przykład dodaje zaufany serwer proxy pod adresem 10.0.0.100 IP do oprogramowania KnownProxiespośredniczącego nagłówków przekazywanych:

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

Aby uzyskać więcej informacji, zobacz Konfigurowanie platformy ASP.NET Core pod kątem pracy z serwerami proxy i modułami równoważenia obciążenia.

Instalowanie serwera Nginx

Ubuntu

Użyj polecenia apt-get , aby zainstalować serwer Nginx. Instalator tworzy systemd skrypt init, który uruchamia serwer Nginx jako demon podczas uruchamiania systemu. Postępuj zgodnie z instrukcjami instalacji systemu Ubuntu w witrynie Nginx: Oficjalne pakiety Debian/Ubuntu.

Red Hat Enterprise Linux

Użyj yum-utils polecenia , aby wybrać i zainstalować strumień modułu Nginx. Postępuj zgodnie z instrukcjami instalacji systemu RHEL w witrynie Nginx: Pakiety systemu Linux — RHEL.

SUSE Linux Enterprise Server

Użyj yum-utils polecenia , aby wybrać i zainstalować strumień modułu Nginx. Postępuj zgodnie z instrukcjami instalacji systemu SLES w witrynie Nginx: Pakiety systemu Linux — SLES.

Uwaga

Jeśli wymagane są opcjonalne moduły Nginx, może być wymagane utworzenie serwera Nginx ze źródła.

Ponieważ serwer Nginx został zainstalowany po raz pierwszy, jawnie uruchom go, uruchamiając polecenie:

sudo service nginx start

Sprawdź, czy przeglądarka wyświetla domyślną stronę docelową serwera Nginx. Strona docelowa jest osiągalna pod adresem http://<server_IP_address>/index.nginx-debian.html.

Konfigurowanie serwera Nginx

Ubuntu

Aby skonfigurować serwer Nginx jako zwrotny serwer proxy do przesyłania dalej żądań HTTP do aplikacji ASP.NET Core, zmodyfikuj /etc/nginx/sites-available/default i utwórz ponownie link symlinku. Po utworzeniu /etc/nginx/sites-available/default pliku użyj następującego polecenia, aby utworzyć link syymlinku:

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

Otwórz /etc/nginx/sites-available/default plik w edytorze tekstów i zastąp zawartość następującym fragmentem kodu:

Red Hat Enterprise Linux

Aby skonfigurować serwer Nginx jako zwrotny serwer proxy do przekazywania żądań HTTP do aplikacji ASP.NET Core, zmodyfikuj element /etc/nginx.conf. http{} Zaktualizuj blok kodu przy użyciu następującego fragmentu kodu:

SUSE Linux Enterprise Server

Aby skonfigurować serwer Nginx jako zwrotny serwer proxy do przekazywania żądań HTTP do aplikacji ASP.NET Core, zmodyfikuj element /etc/nginx.conf. http{} Zaktualizuj blok kodu przy użyciu następującego fragmentu kodu:

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

Jeśli aplikacja jest aplikacją SignalR lubBlazor Server, zobacz ASP.NET Core SignalR production hosting and scaling and Host and deploy ASP.NET Core server-side apps (Hostowanie i wdrażanie aplikacji po stronie Blazor serwera) ASP.NET Core, aby uzyskać więcej informacji.

W przypadku braku server_name dopasowań serwer Nginx używa serwera domyślnego. Jeśli serwer domyślny nie jest zdefiniowany, pierwszy serwer w pliku konfiguracji jest serwerem domyślnym. Najlepszym rozwiązaniem jest dodanie określonego domyślnego serwera, który zwraca kod stanu 444 w pliku konfiguracji. Domyślny przykład konfiguracji serwera to:

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

Po wcześniejszym pliku konfiguracji i serwerze domyślnym serwer Nginx akceptuje ruch publiczny na porcie 80 z nagłówkiem example.com hosta lub *.example.com. Żądania, które nie pasują do tych hostów, nie będą przekazywane do usługi Kestrel. Serwer Nginx przekazuje pasujące żądania do obiektu Kestrel pod adresem http://127.0.0.1:5000/. Aby uzyskać więcej informacji, zobacz Jak serwer nginx przetwarza żądanie. Aby zmienić Kestreladres IP/port, zobacz Kestrel: Konfiguracja punktu końcowego.

Ostrzeżenie

Nie można określić odpowiedniej dyrektywy server_name uwidacznia aplikację w zabezpieczeniach luk w zabezpieczeniach. Powiązanie symboli wieloznacznych poddomeny (na przykład *.example.com) nie stanowi tego ryzyka zabezpieczeń, jeśli kontrolujesz całą domenę nadrzędną (w przeciwieństwie do *.com, która jest podatna na zagrożenia). Aby uzyskać więcej informacji, zobacz RFC 9110: Http Semantics (Sekcja 7.2: Host i :authority).

Po ustanowieniu konfiguracji serwera Nginx uruchom polecenie sudo nginx -t , aby zweryfikować składnię plików konfiguracji. Jeśli test pliku konfiguracji zakończy się pomyślnie, wymusij na serwerze Nginx pobieranie zmian, uruchamiając polecenie sudo nginx -s reload.

Aby bezpośrednio uruchomić aplikację na serwerze:

1. Przejdź do katalogu aplikacji.
2. Uruchom aplikację: dotnet <app_assembly.dll>, gdzie app_assembly.dll jest nazwą pliku zestawu aplikacji.

Ubuntu

Jeśli aplikacja działa na serwerze, ale nie odpowiada przez Internet, sprawdź zaporę serwera i upewnij się, że port 80 jest otwarty. W przypadku korzystania z maszyny wirtualnej z systemem Ubuntu platformy Azure dodaj regułę sieciowej grupy zabezpieczeń, która umożliwia ruch przychodzący na porcie 80. Nie ma potrzeby włączania reguły portu wychodzącego 80, ponieważ ruch wychodzący jest automatycznie udzielany po włączeniu reguły ruchu przychodzącego.

Red Hat Enterprise Linux

Jeśli aplikacja działa na serwerze, ale nie odpowiada przez Internet, sprawdź zaporę serwera i upewnij się, że port 80 jest otwarty.

SUSE Linux Enterprise Server

Jeśli aplikacja działa na serwerze, ale nie odpowiada przez Internet, sprawdź zaporę serwera i upewnij się, że port 80 jest otwarty.

Po zakończeniu testowania aplikacji zamknij aplikację za pomocą Ctrl+C (Windows) lub ⌘+C (macOS) w wierszu polecenia.

Zwiększanie keepalive_requests

keepalive_requests Można zwiększyć wydajność, aby uzyskać więcej informacji, zobacz ten problem z usługą GitHub.

Monitorowanie aplikacji

Serwer jest skonfigurowany do przesyłania dalej żądań wysyłanych do http://<serveraddress>:80 aplikacji ASP.NET Core uruchomionej na Kestrel stronie http://127.0.0.1:5000. Jednak serwer Nginx nie jest skonfigurowany do zarządzania procesem Kestrel . systemd Umożliwia utworzenie pliku usługi w celu uruchomienia i monitorowania podstawowej aplikacji internetowej. systemd to system init, który udostępnia wiele zaawansowanych funkcji uruchamiania, zatrzymywania i zarządzania procesami.

Tworzenie pliku usługi

Utwórz plik definicji usługi:

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

Poniższy przykład to .ini plik usługi dla aplikacji:

[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

W poprzednim przykładzie użytkownik, który zarządza usługą, jest określony przez User opcję . Użytkownik (www-data) musi istnieć i mieć właściwą własność plików aplikacji.

Użyj TimeoutStopSec polecenia , aby skonfigurować czas oczekiwania na zamknięcie aplikacji po odebraniu sygnału początkowego przerwania. Jeśli aplikacja nie zostanie zamknięta w tym okresie, aplikacja SIGKILL zostanie wydana w celu zakończenia działania aplikacji. Podaj wartość jako bezjednostki sekund (na przykład 150), wartość przedziału czasu (na przykład 2min 30s), lub infinity aby wyłączyć limit czasu. TimeoutStopSec wartość domyślna parametru DefaultTimeoutStopSec w pliku konfiguracji menedżera (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). Domyślny limit czasu dla większości dystrybucji wynosi 90 sekund.

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

System Linux ma system plików z uwzględnieniem wielkości liter. Ustawienie ASPNETCORE_ENVIRONMENT na Production wyniki wyszukiwania pliku appsettings.Production.jsonkonfiguracji, a nie appsettings.production.json.

Niektóre wartości (na przykład parametry połączenia SQL) muszą zostać uniknięci, aby dostawcy konfiguracji odczytywali zmienne środowiskowe. Użyj następującego polecenia, aby wygenerować prawidłowo unikniętą wartość do użycia w pliku konfiguracji:

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

Separatory dwukropka (:) nie są obsługiwane w nazwach zmiennych środowiskowych. Użyj podwójnego podkreślenia (__) zamiast dwukropka. Dostawca konfiguracji Zmienne środowiskowe konwertuje znaki podwójnego podkreślenia na dwukropki, gdy zmienne środowiskowe są odczytywane do konfiguracji. W poniższym przykładzie klucz ConnectionStrings:DefaultConnection parametry połączenia jest ustawiany w pliku definicji usługi jako ConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Zapisz plik i włącz usługę.

sudo systemctl enable kestrel-helloapp.service

Uruchom usługę i sprawdź, czy jest uruchomiona.

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

Po skonfigurowaniu zwrotnego serwera proxy i Kestrel zarządzanym za pośrednictwem systemdprogramu aplikacja internetowa jest w pełni skonfigurowana i może być dostępna z przeglądarki na komputerze lokalnym pod adresem http://localhost. Jest ona również dostępna z komputera zdalnego, zakazując wszelkich zapór, które mogą blokować. Sprawdzając nagłówki odpowiedzi, w nagłówku Server jest wyświetlana aplikacja ASP.NET Core obsługiwana przez Kestrelprogram .

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

Wyświetlanie dzienników

Ponieważ aplikacja internetowa korzystająca z programu Kestrel jest zarządzana przy użyciu programu systemd, wszystkie zdarzenia i procesy są rejestrowane w scentralizowanym dzienniku. Jednak ten dziennik zawiera wszystkie wpisy dla wszystkich usług i procesów zarządzanych przez program systemd. Aby wyświetlić kestrel-helloapp.serviceelementy specyficzne dla elementu, użyj następującego polecenia:

sudo journalctl -fu kestrel-helloapp.service

W celu dalszego filtrowania opcje czasu, takie jak --since today, --until 1 hour agolub kombinacja tych elementów, może zmniejszyć liczbę zwracanych wpisów.

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

Ochrona danych

Stos ASP.NET Core Data Protection jest używany przez kilka ASP.NET Core oprogramowania pośredniczącego, w tym oprogramowania pośredniczącego uwierzytelniania (na przykład cookie oprogramowania pośredniczącego) i ochrony żądań między lokacjami (CSRF). Nawet jeśli interfejsy API ochrony danych nie są wywoływane przez kod użytkownika, należy skonfigurować ochronę danych w celu utworzenia trwałego magazynu kluczy kryptograficznych. Jeśli ochrona danych nie jest skonfigurowana, klucze są przechowywane w pamięci i odrzucane po ponownym uruchomieniu aplikacji.

Jeśli pierścień kluczy jest przechowywany w pamięci po ponownym uruchomieniu aplikacji:

• Wszystkie tokeny uwierzytelniania oparte na systemie cookie są unieważniane.
• Użytkownicy są zobowiązani do ponownego zalogowania się podczas następnego żądania.
• Nie można już odszyfrować żadnych danych chronionych za pomocą pierścienia kluczy. Może to obejmować tokeny CSRF i pliki cookie ASP.NET Core MVC TempData.

Aby skonfigurować ochronę danych w celu utrwalania i szyfrowania pierścienia kluczy, zobacz:

• Dostawcy magazynu kluczy w usłudze ASP.NET Core
• Szyfrowanie kluczy w systemach rest Windows i Azure przy użyciu platformy ASP.NET Core

Długie pola nagłówka żądania

Domyślne ustawienia serwera proxy zwykle ograniczają pola nagłówka żądania do 4 K lub 8 K w zależności od platformy. Aplikacja może wymagać pól dłuższych niż domyślne (na przykład aplikacji korzystających z identyfikatora Entra firmy Microsoft). Jeśli wymagane są dłuższe pola, ustawienia domyślne serwera proxy wymagają dostosowania. Wartości do zastosowania zależą od scenariusza. Aby uzyskać więcej informacji, zobacz dokumentację serwera.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Ostrzeżenie

Nie należy zwiększać wartości domyślnych serwera proxy, chyba że jest to konieczne. Zwiększenie tych wartości zwiększa ryzyko przepełnienia buforu (przepełnienia) i ataków typu "odmowa usługi" (DoS) przez złośliwych użytkowników.

Zabezpieczanie aplikacji

Włączanie aplikacji AppArmor

Moduły zabezpieczeń systemu Linux (LSM) to struktura, która jest częścią jądra systemu Linux od systemu Linux 2.6. Rozwiązanie LSM obsługuje różne implementacje modułów zabezpieczeń. AppArmor to LSM, który implementuje obowiązkowy system kontroli dostępu, który umożliwia ograniczenie programu do ograniczonego zestawu zasobów. Upewnij się, że aplikacja AppArmor jest włączona i prawidłowo skonfigurowana.

Konfigurowanie zapory

Zamknij wszystkie porty zewnętrzne, które nie są używane. Nieskomplikowana zapora (ufw) udostępnia fronton, iptables udostępniając interfejs wiersza polecenia do konfigurowania zapory.

Ubuntu

Ostrzeżenie

Zapora uniemożliwia dostęp do całego systemu, jeśli nie został poprawnie skonfigurowany. Nie można określić poprawnego portu SSH skutecznie blokuje użytkownika z systemu, jeśli używasz protokołu SSH do nawiązania z nim połączenia. Domyślny port to 22. Aby uzyskać więcej informacji, zobacz wprowadzenie do ufw i podręcznika.

Zainstaluj ufw i skonfiguruj go, aby zezwolić na ruch na wszystkich wymaganych portach.

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

Ostrzeżenie

Zapora uniemożliwia dostęp do całego systemu, jeśli nie został poprawnie skonfigurowany. Nie można określić poprawnego portu SSH skutecznie blokuje użytkownika z systemu, jeśli używasz protokołu SSH do nawiązania z nim połączenia. Domyślny port to 22. Aby uzyskać więcej informacji, zobacz wprowadzenie do aplikacji ufw.

Zainstaluj ufw i skonfiguruj go, aby zezwolić na ruch na wszystkich wymaganych portach.

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

Ostrzeżenie

Zapora uniemożliwia dostęp do całego systemu, jeśli nie został poprawnie skonfigurowany. Nie można określić poprawnego portu SSH skutecznie blokuje użytkownika z systemu, jeśli używasz protokołu SSH do nawiązania z nim połączenia. Domyślny port to 22. Aby uzyskać więcej informacji, zobacz wprowadzenie do aplikacji ufw.

Zainstaluj ufw i skonfiguruj go, aby zezwolić na ruch na wszystkich wymaganych portach.

sudo yum -y install ufw

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

sudo ufw enable

Zabezpieczanie serwera Nginx

Zmienianie nazwy odpowiedzi serwera Nginx

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

Konfigurowanie opcji

Skonfiguruj serwer z dodatkowymi wymaganymi modułami. Rozważ użycie zapory aplikacji internetowej, takiej jak ModSecurity, w celu zabezpieczenia aplikacji.

Konfiguracja protokołu HTTPS

Konfigurowanie aplikacji pod kątem bezpiecznych połączeń lokalnych (HTTPS)

Polecenie dotnet run używa pliku aplikacji, który konfiguruje aplikację Properties/launchSettings.json do nasłuchiwania adresów URL dostarczonych przez applicationUrl właściwość . Na przykład https://localhost:5001;http://localhost:5000.

Skonfiguruj aplikację tak, aby używała certyfikatu podczas programowania dla dotnet run polecenia lub środowiska programistycznego (F5 lub Ctrl+F5 w programie Visual Studio Code) przy użyciu jednej z następujących metod:

• Zamień domyślny certyfikat z konfiguracji (zalecane)
• KestrelServerOptions.ConfigureHttpsDefaults

Konfigurowanie zwrotnego serwera proxy na potrzeby bezpiecznych połączeń klienckich (HTTPS)

Ostrzeżenie

Konfiguracja zabezpieczeń w tej sekcji jest ogólną konfiguracją, która ma być używana jako punkt wyjścia do dalszego dostosowywania. Nie możemy zapewnić obsługi narzędzi, serwerów i systemów operacyjnych innych firm. Użyj konfiguracji w tej sekcji na własne ryzyko. Aby uzyskać więcej informacji, uzyskaj dostęp do następujących zasobów:

• Konfigurowanie serwerów HTTPS (dokumentacja serwera Nginx)
• Generator konfiguracji protokołu SSL mozilla.org

• Skonfiguruj serwer do nasłuchiwania ruchu HTTPS na porcie 443, określając prawidłowy certyfikat wystawiony przez zaufany urząd certyfikacji.

• Wzmacnianie zabezpieczeń przez zastosowanie niektórych praktyk przedstawionych w poniższym pliku /etc/nginx/nginx.conf .

• Poniższy przykład nie konfiguruje serwera do przekierowywania niezabezpieczonych żądań. Zalecamy używanie oprogramowania pośredniczącego przekierowania HTTPS. Aby uzyskać więcej informacji, zobacz Wymuszanie protokołu HTTPS w ASP.NET Core.

  Uwaga

  W przypadku środowisk deweloperskich, w których konfiguracja serwera obsługuje bezpieczne przekierowywanie zamiast oprogramowania pośredniczącego przekierowania HTTPS, zalecamy używanie tymczasowych przekierowań (302), a nie stałych przekierowań (301). Buforowanie łączy może spowodować niestabilne zachowanie w środowiskach deweloperskich.

• Dodanie nagłówka Strict-Transport-Security (HSTS) gwarantuje, że wszystkie kolejne żądania wysyłane przez klienta są za pośrednictwem protokołu HTTPS. Aby uzyskać wskazówki dotyczące ustawiania nagłówka Strict-Transport-Security , zobacz Wymuszanie protokołu HTTPS w ASP.NET Core.

• Jeśli protokół HTTPS zostanie wyłączony w przyszłości, użyj jednego z następujących podejść:

  • Nie dodawaj nagłówka HSTS.
  • Wybierz krótką max-age wartość.

Dodaj plik konfiguracji /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

Zastąp zawartość pliku konfiguracji /etc/nginx/nginx.conf następującym plikiem. W przykładzie znajdują się obie http sekcje i server w jednym pliku konfiguracji.

Red Hat Enterprise Linux

Zmodyfikuj plik /etc/nginx/nginx.conf. Otwórz go w edytorze tekstów i zastąp http{} bloki kodu i server{} zawartością następującym fragmentem kodu:

SUSE Linux Enterprise Server

Zmodyfikuj plik /etc/nginx/nginx.conf. Otwórz go w edytorze tekstów i zastąp http{} bloki kodu i server{} zawartością następującym fragmentem kodu:

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

Uwaga

Blazor WebAssembly aplikacje wymagają większej burst wartości parametru, aby obsłużyć większą liczbę żądań wysyłanych przez aplikację. Aby uzyskać więcej informacji, zobacz Host and deploy ASP.NET Core Blazor WebAssembly.

Uwaga

Powyższy przykład wyłącza zszywania protokołu OCSP (Online Certificate Status Protocol). Jeśli ta opcja jest włączona, upewnij się, że certyfikat obsługuje tę funkcję. Aby uzyskać więcej informacji i wskazówek dotyczących włączania dostawcy OCSP, zobacz następujące właściwości w artykule Module ngx_http_ssl_module (dokumentacja serwera Nginx):

• ssl_stapling
• ssl_stapling_file
• ssl_stapling_responder
• ssl_stapling_verify

Zabezpieczanie serwera Nginx od kliknięcia

Clickjacking, znany również jako atak zadośćuczynienia interfejsu użytkownika, jest złośliwym atakiem, w którym odwiedzający witrynę internetową jest podszyty do kliknięcia linku lub przycisku na innej stronie niż obecnie odwiedza. Użyj X-FRAME-OPTIONS polecenia , aby zabezpieczyć witrynę.

Aby wyeliminować ataki typu clickjacking:

1. Edytuj plik nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

   http{} W bloku kodu dodaj wiersz:add_header X-Frame-Options "SAMEORIGIN";

2. Zapisz plik.

3. Uruchom ponownie serwer Nginx.

Wąchanie typu MIME

Ten nagłówek uniemożliwia większości przeglądarek sniffing odpowiedzi z dala od zadeklarowanego typu zawartości, ponieważ nagłówek instruuje przeglądarkę, aby nie przesłaniała typu zawartości odpowiedzi. nosniff Jeśli na serwerze text/htmljest wyświetlana opcja , przeglądarka renderuje ją jako text/html.

1. Edytuj plik nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

   http{} W bloku kodu dodaj wiersz:add_header X-Content-Type-Options "nosniff";

2. Zapisz plik.

3. Uruchom ponownie serwer Nginx.

Dodatkowe sugestie serwera Nginx

Po uaktualnieniu platformy udostępnionej na serwerze uruchom ponownie aplikacje ASP.NET Core hostowane przez serwer.

Dodatkowe zasoby

• Wymagania wstępne dotyczące platformy .NET Core w systemie Linux
• Nginx: Wersje binarne: oficjalne pakiety Debian/Ubuntu
• Rozwiązywanie problemów i debugowanie projektów ASP.NET Core
• Konfigurowanie platformy ASP.NET Core pod kątem pracy z serwerami proxy i modułami równoważenia obciążenia
• NGINX: używanie nagłówka Przekazywane