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.
- Odwiedź stronę Pobieranie platformy .NET Core.
- Wybierz najnowszą wersję platformy .NET Core spoza wersji zapoznawczej.
- Pobierz najnowsze środowisko uruchomieniowe spoza wersji zapoznawczej w tabeli w obszarze Uruchamianie aplikacji — środowisko uruchomieniowe.
- 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) zapplicationUrl
właściwości wProperties/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.Scheme
element 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 set
s
elementu :
<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.
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.
Utwórz link symboliczny do /etc/apache2/sites-enabled
katalogu dla platformy Apache do odczytu podczas uruchamiania:
sudo ln -s /etc/apache2/sites-available/helloapp.conf /etc/apache2/sites-enabled/
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
:
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.service
elementy 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:
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:
Edytuj plik httpd.conf:
sudo nano /etc/httpd/conf/httpd.conf
Dodaj wiersz
Header append X-FRAME-OPTIONS "SAMEORIGIN"
.Zapisz plik.
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
Opinia
https://aka.ms/ContentUserFeedback.
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla