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

Przez Shayne Boyer

Korzystając z tego przewodnika, dowiedz się, jak skonfigurować serwer Apache jako zwrotny serwer proxy w systemie CentOS 7 w celu przekierowania ruchu HTTP do aplikacji internetowej ASP.NET Core uruchomionej na Kestrel serwerze. Rozszerzenie mod_proxy i powiązane moduły tworzą zwrotny serwer proxy serwera.

Uwaga

W tym artykule odwołuje się do systemu CentOS — dystrybucji systemu Linux, która zbliża się do stanu zakończenia życia (EOL). Rozważ odpowiednie użycie i zaplanuj. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące zakończenia życia systemu CentOS.

Wymagania wstępne

• Serwer z systemem CentOS 7 ze standardowym kontem użytkownika z uprawnieniami sudo.
• Zainstaluj środowisko uruchomieniowe platformy .NET Core na serwerze.
  1. Odwiedź stronę Pobieranie platformy .NET Core.
  2. Wybierz najnowszą wersję platformy .NET Core spoza wersji zapoznawczej.
  3. Pobierz najnowsze środowisko uruchomieniowe spoza wersji zapoznawczej w tabeli w obszarze Uruchamianie aplikacji — środowisko uruchomieniowe.
  4. Wybierz link Instrukcje menedżera pakietów systemu Linux i postępuj zgodnie z instrukcjami systemu CentOS.
• 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 katalogu var (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.

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

Serwer proxy przekazuje żądania klientów do innego serwera zamiast przesyłania żądań. Zwrotny serwer proxy jest przekazywany do stałego miejsca docelowego, zazwyczaj w imieniu dowolnych klientów. W tym przewodniku platforma Apache jest skonfigurowana jako zwrotny serwer proxy uruchomiony na tym samym serwerze obsługującym Kestrel aplikację ASP.NET Core.

Ponieważ żądania są przekazywane przez zwrotny serwer proxy, użyj oprogramowania pośredniczącego Nagłówki przekazywane z pakietu Microsoft.AspNetCore.HttpOverrides. 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.

Każdy składnik, który zależy od schematu, takiego jak uwierzytelnianie, generowanie linków, przekierowania i geolokalizacja, należy umieścić po wywołaniu oprogramowania pośredniczącego Nagłówki przekazywane.

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 w górnej Startup.Configure części elementu 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 .

Microsoft.AspNetCore.HttpOverrides Dodaj przestrzeń nazw na początku pliku:

using Microsoft.AspNetCore.HttpOverrides;

W potoku przetwarzania aplikacji:

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

app.UseAuthentication();

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

Serwery proxy działające 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 IP 10.0.0.100 do oprogramowania KnownProxies pośredniczącego Nagłówki przekazywane w programie Startup.ConfigureServices:

System.Net Dodaj przestrzeń nazw na początku pliku:

using System.Net;

Użyj następującej rejestracji usługi:

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

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 oprogramowania Apache

Zaktualizuj pakiety CentOS do najnowszych stabilnych wersji:

sudo yum update -y

Zainstaluj serwer internetowy Apache w systemie CentOS za pomocą jednego yum polecenia:

sudo yum -y install httpd mod_ssl

Przykładowe dane wyjściowe po uruchomieniu polecenia:

Downloading packages:
httpd-2.4.6-40.el7.centos.4.x86_64.rpm               | 2.7 MB  00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : httpd-2.4.6-40.el7.centos.4.x86_64      1/1 
Verifying  : httpd-2.4.6-40.el7.centos.4.x86_64      1/1 

Installed:
httpd.x86_64 0:2.4.6-40.el7.centos.4

Complete!

Uwaga

W tym przykładzie dane wyjściowe odzwierciedlają httpd.86_64, ponieważ wersja CentOS 7 jest 64-bitowa. Aby sprawdzić, gdzie jest zainstalowany system Apache, uruchom polecenie whereis httpd w wierszu polecenia.

Konfigurowanie platformy Apache

Pliki konfiguracji dla oprogramowania Apache znajdują się w /etc/httpd/conf.d/ katalogu . W systemie Apache w systemie Ubuntu wszystkie pliki konfiguracji hosta wirtualnego są przechowywane w programie /etc/apache2/sites-available. Każdy plik z rozszerzeniem conf jest przetwarzany w kolejności alfabetycznej oprócz plików konfiguracji modułu w /etc/httpd/conf.modules.d/programie , który zawiera pliki konfiguracji niezbędne do załadowania modułów.

Utwórz plik konfiguracji o nazwie helloapp.conf dla aplikacji:

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}s
</VirtualHost>

<VirtualHost *:80>
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5000/
    ServerName www.example.com
    ServerAlias *.example.com
    ErrorLog ${APACHE_LOG_DIR}/helloapp-error.log
    CustomLog ${APACHE_LOG_DIR}/helloapp-access.log common
</VirtualHost>

Uwaga: wersje apache wcześniejsze niż 2.4.6 nie wymagają końcowego RequestHeader setselementu :

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

Aby uzyskać więcej informacji, zobacz w temacie %{VARNAME}s Apache Module mod_headers.

Blok VirtualHost może pojawiać się wiele razy w co najmniej jednym pliku na serwerze. W poprzednim pliku konfiguracji apache akceptuje ruch publiczny na porcie 80. Domena www.example.com jest obsługiwana, a *.example.com alias jest rozpoznawany dla tej samej witryny internetowej. Aby uzyskać więcej informacji, zobacz Obsługa hosta wirtualnego opartego na nazwach. Żądania są proxied w katalogu głównym do portu 5000 serwera pod adresem 127.0.0.1. W przypadku komunikacji ProxyPass dwukierunkowej i ProxyPassReverse są wymagane. Aby zmienić Kestreladres IP/port, zobacz Kestrel: Konfiguracja punktu końcowego.

Ostrzeżenie

Nie można określić właściwej dyrektywy ServerName w bloku VirtualHost 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).

Rejestrowanie można skonfigurować zgodnie VirtualHost z dyrektywami i CustomLog .ErrorLog ErrorLog to lokalizacja, w której serwer rejestruje błędy, i CustomLog ustawia nazwę pliku i format pliku dziennika. W takim przypadku jest to miejsce, w którym rejestrowane są informacje o żądaniu. Dla każdego żądania znajduje się jeden wiersz.

Zapisz plik i przetestuj konfigurację. Jeśli wszystko przejdzie pomyślnie, odpowiedź powinna mieć wartość Syntax [OK].

sudo apachectl configtest

Uruchom ponownie platformę Apache:

sudo systemctl restart httpd
sudo systemctl enable httpd

Aby uzyskać więcej informacji na temat wartości dyrektywy nagłówka, zobacz Apache Module mod_headers.

Monitorowanie aplikacji

Platforma Apache jest teraz skonfigurowana do przekazywania żądań wysyłanych do http://localhost:80 aplikacji ASP.NET Core uruchomionej na Kestrel stronie http://127.0.0.1:5000. Jednak platforma Apache nie jest skonfigurowana do zarządzania procesem Kestrel . Użyj systemu i utwórz plik usługi, aby uruchomić i monitorować podstawową aplikację internetową. systemd to system inicjowania, 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

Przykładowy plik usługi dla aplikacji:

[Unit]
Description=Example .NET Web API App running on CentOS 7

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/local/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=apache
Environment=ASPNETCORE_ENVIRONMENT=Production 

[Install]
WantedBy=multi-user.target

Uwaga: ustaw local/bin folder dystrybucji. Niektóre wersje systemu Ubuntu wymagają ExecStart=/usr/bin/dotnet

W poprzednim przykładzie użytkownik, który zarządza usługą, jest określony przez User opcję . Użytkownik (apache) 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 to wartość w DefaultTimeoutStopSec 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

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 CentOS 7
    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 systemu aplikacja internetowa jest w pełni skonfigurowana i może być dostępna z przeglądarki na komputerze lokalnym pod adresem http://localhost. Sprawdzając nagłówki odpowiedzi, nagłówek Serwera wskazuje, że aplikacja ASP.NET Core jest obsługiwana przez usługę 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

Wyświetlanie dzienników

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

sudo journalctl -fu kestrel-helloapp.service

W przypadku filtrowania czasu określ opcje czasu za pomocą polecenia . Na przykład użyj polecenia --since today , aby odfiltrować bieżący dzień lub --until 1 hour ago wyświetlić wpisy z poprzedniej godziny. Aby uzyskać więcej informacji, zobacz stronę człowieka dla journalctl.

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 ASP.NET Core MVC TempData cookies.

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

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

Zabezpieczanie aplikacji

Konfigurowanie zapory

Zapora to dynamiczny demon do zarządzania zaporą z obsługą stref sieciowych. Porty i filtrowanie pakietów mogą być nadal zarządzane przez tabele iptable. Zapora powinna być instalowana domyślnie. yum Może służyć do instalowania pakietu lub sprawdzania, czy został zainstalowany.

sudo yum install firewalld -y

Użyj firewalld polecenia , aby otworzyć tylko porty wymagane dla aplikacji. W takim przypadku używane są porty 80 i 443. Następujące polecenia trwale ustawiają porty 80 i 443 do otwarcia:

sudo firewall-cmd --add-port=80/tcp --permanent
sudo firewall-cmd --add-port=443/tcp --permanent

Załaduj ponownie ustawienia zapory. Sprawdź dostępne usługi i porty w strefie domyślnej. Dostępne są opcje, sprawdzając element firewall-cmd -h.

sudo firewall-cmd --reload
sudo firewall-cmd --list-all

public (default, active)
interfaces: eth0
sources: 
services: dhcpv6-client
ports: 443/tcp 80/tcp
masquerade: no
forward-ports: 
icmp-blocks: 
rich rules: 

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:

• Szyfrowanie Apache SSL/TLS (dokumentacja platformy Apache)
• Generator konfiguracji protokołu SSL mozilla.org

Aby skonfigurować platformę Apache dla protokołu HTTPS, używany jest moduł mod_ssl . Po zainstalowaniu modułu httpd moduł mod_ssl również został zainstalowany. Jeśli nie został zainstalowany, użyj polecenia yum , aby dodać go do konfiguracji.

sudo yum install mod_ssl

Aby wymusić mod_rewrite protokół HTTPS, zainstaluj moduł, aby włączyć ponowne zapisywanie adresów URL:

sudo yum install mod_rewrite

Zmodyfikuj plik helloapp.conf, aby umożliwić bezpieczną komunikację na porcie 443.

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.

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

<VirtualHost *:443>
    Protocols             h2 http/1.1
    ProxyPreserveHost     On
    ProxyPass             / http://127.0.0.1:5000/
    ProxyPassReverse      / http://127.0.0.1:5000/
    ErrorLog              /var/log/httpd/helloapp-error.log
    CustomLog             /var/log/httpd/helloapp-access.log common
    SSLEngine             on
    SSLProtocol           all -SSLv3 -TLSv1 -TLSv1.1
    SSLHonorCipherOrder   off
    SSLCompression        off
    SSLSessionTickets     on
    SSLUseStapling        off
    SSLCertificateFile    /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
    SSLCipherSuite        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
</VirtualHost>

Uwaga

W tym przykładzie jest używany lokalnie wygenerowany certyfikat. Plik SSLCertificateFile powinien być plikiem certyfikatu podstawowego dla nazwy domeny. SslCertificateKeyFile powinien być plikiem klucza generowanym podczas tworzenia csr. SSLCertificateChainFile powinien być plikiem certyfikatu pośredniego (jeśli istnieje) dostarczonym przez urząd certyfikacji.

Serwer Apache HTTP Server w wersji 2.4.43 lub nowszej jest wymagany do obsługi serwera internetowego TLS 1.3 z protokołem OpenSSL 1.1.1.

Uwaga

Powyższy przykład wyłącza zszywania protokołu OCSP (Online Certificate Status Protocol). Aby uzyskać więcej informacji i wskazówek dotyczących włączania dostawcy OCSP, zobacz OCSP Stapling (dokumentacja apache).

Zapisz plik i przetestuj konfigurację:

sudo service httpd configtest

Uruchom ponownie platformę Apache:

sudo systemctl restart httpd

Dodatkowe sugestie dotyczące platformy Apache

Ponowne uruchamianie aplikacji za pomocą aktualizacji platformy udostępnionej

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

Dodatkowe nagłówki

Aby zabezpieczyć się przed złośliwymi atakami, istnieje kilka nagłówków, które należy zmodyfikować lub dodać. Upewnij się, że mod_headers moduł jest zainstalowany:

sudo yum install mod_headers

Zabezpieczanie serwera Apache przed atakami typu clickjacking

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 httpd.conf:

   sudo nano /etc/httpd/conf/httpd.conf
   

   Dodaj wiersz Header append X-FRAME-OPTIONS "SAMEORIGIN".

2. Zapisz plik.

3. Uruchom ponownie platformę Apache.

Wąchanie typu MIME

Nagłówek X-Content-Type-Options uniemożliwia programowi Internet Explorer sniffing (określanie plików Content-Type z zawartości pliku). Jeśli serwer ustawi Content-Type nagłówek na text/html z zestawem nosniff opcji, program Internet Explorer renderuje zawartość text/html niezależnie od zawartości pliku.

Edytuj plik httpd.conf:

sudo nano /etc/httpd/conf/httpd.conf

Dodaj wiersz Header set X-Content-Type-Options "nosniff". Zapisz plik. Uruchom ponownie platformę Apache.

Równoważenie obciążenia

W tym przykładzie pokazano, jak skonfigurować i skonfigurować platformę Apache w systemie CentOS 7 i Kestrel na tym samym komputerze wystąpienia. Aby nie mieć jednego punktu awarii; używanie mod_proxy_balancer i modyfikowanie hosta wirtualnego umożliwia zarządzanie wieloma wystąpieniami aplikacji internetowych za serwerem proxy Apache.

sudo yum install mod_proxy_balancer

W pliku konfiguracji pokazanym poniżej zostanie skonfigurowane dodatkowe wystąpienie programu helloapp do uruchomienia na porcie 5001. Sekcja Serwer proxy jest ustawiana z konfiguracją modułu równoważenia z dwoma elementami członkowskimi w celu równoważenia obciążenia przez elementy.

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
    ProxyPass / balancer://mycluster/ 

    ProxyPassReverse / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5001/

    <Proxy balancer://mycluster>
        BalancerMember http://127.0.0.1:5000
        BalancerMember http://127.0.0.1:5001 
        ProxySet lbmethod=byrequests
    </Proxy>

    <Location />
        SetHandler balancer
    </Location>
    ErrorLog /var/log/httpd/helloapp-error.log
    CustomLog /var/log/httpd/helloapp-access.log common
    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!RC4+RSA:+HIGH:+MEDIUM:!LOW:!RC4
    SSLCertificateFile /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
</VirtualHost>

Limity szybkości

Użycie mod_ratelimit, który jest zawarty w module httpd , przepustowość klientów może być ograniczona:

sudo nano /etc/httpd/conf.d/ratelimit.conf

Przykładowy plik ogranicza przepustowość jako 600 KB/s w lokalizacji głównej:

<IfModule mod_ratelimit.c>
    <Location />
        SetOutputFilter RATE_LIMIT
        SetEnv rate-limit 600
    </Location>
</IfModule>

Długie pola nagłówka żądania

Domyślne ustawienia serwera proxy zwykle ograniczają pola nagłówka żądania do 8190 bajtów. 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, dyrektywa LimitRequestFieldSize serwera proxy wymaga dostosowania. Wartość do zastosowania zależy od scenariusza. Aby uzyskać więcej informacji, zobacz dokumentację serwera.

Ostrzeżenie

Nie należy zwiększać wartości domyślnej, LimitRequestFieldSize chyba że jest to konieczne. Zwiększenie 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.

Dodatkowe zasoby

• Wymagania wstępne dotyczące platformy .NET Core w systemie Linux
• 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