Hosten von ASP.NET Core unter Linux mit Apache

  • Artikel
  • 15 Minuten Lesedauer

Von Shayne Boyer

In diesem Leitfaden finden Sie Informationen zur Einrichtung von Apache als Reverseproxyserver für CentOS 7 zur Weiterleitung von HTTP-Datenverkehr an eine ASP.NET Core-Web-App, die auf einem Kestrel-Server ausgeführt wird. Durch die Erweiterung mod_proxy und zugehörige Module wird der Reverseproxy des Servers erstellt.

Voraussetzungen

  • Ein Server, auf dem CentOS 7 ausgeführt wird, mit einem Standardbenutzerkonto mit sudo-Berechtigung.
  • Installieren Sie die .NET Core-Runtime auf dem Server.
    1. Besuchen Sie die .NET Core-Downloadseite.
    2. Wählen Sie die neueste Version von .NET Core aus, die keine Vorschauversion ist.
    3. Laden Sie die neueste Runtime aus der Tabelle unter Run apps - Runtime (App-Ausführung – Runtime) herunter, bei der es sich nicht um eine Vorschauversion handelt.
    4. Klicken Sie auf den Link zu den Anweisungen zum Linux-Paket-Manager, und führen Sie die CentOS-Anweisungen aus.
  • Eine vorhandene ASP.NET Core-App.

Starten Sie die vom Server gehosteten ASP.NET Core-Apps zu einem beliebigen Zeitpunkt nach dem Upgrade des freigegebenen Frameworks neu.

Veröffentlichen und Kopieren der App

Konfigurieren Sie die App für eine Framework-abhängige Bereitstellung.

Wenn die App lokal in der Entwicklungsumgebung ausgeführt wird und vom Server nicht für abgesicherte HTTPS-Verbindungen konfiguriert ist, wählen Sie einen der folgenden Ansätze:

  • Konfigurieren der App, sodass diese sichere lokale Verbindungen verarbeitet. Weitere Informationen finden Sie im Abschnitt HTTPS-Konfiguration.

  • Konfigurieren der App so, dass sie am unsicheren Endpunkt ausgeführt wird:

    • Deaktivieren der Middleware für HTTPS-Umleitung in der Entwicklungsumgebung (Program.cs):

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

      Weitere Informationen finden Sie unter Verwenden mehrerer Umgebungen in ASP.NET Core.

    • Entfernen Sie https://localhost:5001 (falls vorhanden) aus der applicationUrl-Eigenschaft in der Datei Properties/launchSettings.json.

Weitere Informationen zur umgebungsabhängigen Konfiguration finden Sie unter Verwenden mehrerer Umgebungen in ASP.NET Core.

Führen Sie in der Entwicklungsumgebung dotnet publish aus, um eine App in ein Verzeichnis zu packen (z. B. bin/Release/{TARGET FRAMEWORK MONIKER}/publish, wobei der Platzhalter {TARGET FRAMEWORK MONIKER} der TFM [Target Framework Moniker, Zielframeworkmoniker] ist), der auf dem Server ausgeführt werden kann:

dotnet publish --configuration Release

Die App kann auch als eine eigenständige Bereitstellung veröffentlicht werden, wenn Sie die .NET Core-Runtime nicht auf dem Server verwalten möchten.

Kopieren Sie die ASP.NET Core-App auf den Server, indem Sie ein beliebiges Tool verwenden, das in den Workflow der Organisation integriert ist (z.B. SCP oder SFTP). Web-Apps befinden sich üblicherweise im Verzeichnis var (z.B. var/www/helloapp).

Hinweis

In einem Szenario für die Bereitstellung in der Produktion übernimmt ein Continuous Integration-Workflow die Veröffentlichung der App und das Kopieren der Objekte auf den Server.

Konfigurieren eines Proxyservers

Ein Reverseproxy wird im Allgemeinen zur Unterstützung dynamischer Web-Apps eingerichtet. Der Reverseproxy beendet die HTTP-Anforderung und leitet diese an die ASP.NET-App weiter.

Ein Proxyserver dient zum Weiterleiten von Clientanforderungen an einen anderen Server, anstatt Anforderungen selbst zu erfüllen. Ein Reverseproxy leitet Daten an ein festes Ziel meist im Auftrag beliebiger Clients weiter. In diesem Leitfaden wird Apache als Reverseproxy konfiguriert, der auf demselben Server ausgeführt wird, auf dem Kestrel die ASP.NET Core-App verarbeitet.

Da Anforderungen vom Reverseproxy weitergeleitet werden, sollten Sie die Middleware für weitergeleitete Header aus dem Paket Microsoft.AspNetCore.HttpOverrides verwenden. Diese Middleware aktualisiert Request.Scheme mithilfe des X-Forwarded-Proto-Headers, sodass Umleitungs-URIs und andere Sicherheitsrichtlinien ordnungsgemäß funktionieren.

Jede vom Schema abhängige Komponente, wie etwa Authentifizierung, Linkgenerierung, Umleitungen und Geolocation, muss nach dem Aufrufen der Middleware für weitergeleitete Header eingefügt werden.

Die Middleware für weitergeleitete Header muss noch vor einer anderen Middleware ausgeführt werden. Mit dieser Reihenfolge wird sichergestellt, dass die auf Informationen von weitergeleiteten Headern basierende Middleware die zu verarbeitenden Headerwerte nutzen kann. Unter Middleware für weitergeleitete Header: Auftrag finden Sie Informationen zum Ausführen der Middleware für weitergeleitete Header nach der diagnostischen Middleware und der Middleware für die Fehlerbehandlung.

Rufen Sie die Methode UseForwardedHeaders am Anfang von Startup.Configure auf, bevor Sie andere Middleware aufrufen. Konfigurieren Sie die Middleware so, dass die Header X-Forwarded-For und X-Forwarded-Proto weitergeleitet werden:

// using Microsoft.AspNetCore.HttpOverrides;

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

app.UseAuthentication();

Wenn für die Middleware keine ForwardedHeadersOptions angegeben sind, lauten die weiterzuleitenden Standardheader None.

Proxys, die unter Loopbackadressen (127.0.0.0/8, [::1]) ausgeführt werden, einschließlich der Standardadresse von Localhost (127.0.0.1), werden standardmäßig als vertrauenswürdig eingestuft. Wenn andere vertrauenswürdige Proxys oder Netzwerke innerhalb des Unternehmens Anforderungen zwischen dem Internet und dem Webserver verarbeiten, fügen Sie diese der Liste der KnownProxies oder KnownNetworks mit ForwardedHeadersOptions hinzu. Das folgende Beispiel fügt einen vertrauenswürdigen Proxyserver mit der IP-Adresse 10.0.0.0.100 der Middleware für weitergeleitete Header KnownProxies in Startup.ConfigureServices hinzu:

// using System.Net;

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

Weitere Informationen finden Sie unter Konfigurieren von ASP.NET Core für die Arbeit mit Proxyservern und Lastenausgleichen.

Installieren von Apache

So aktualisieren Sie CentOS-Pakete auf ihre aktuellsten stabilen Versionen:

sudo yum update -y

Installieren Sie die Apache-Webserver unter CentOS mit einem einzelnen yum-Befehl:

sudo yum -y install httpd mod_ssl

Beispielausgabe nach der Ausführung des Befehls:

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!

Hinweis

In diesem Beispiel enthält die Ausgabe „httpd.86_64“, da die CentOS 7-Version eine 64-Bit-Version ist. Um zu prüfen, wo Apache installiert ist, führen Sie an einer Eingabeaufforderung whereis httpd aus.

Konfigurieren von Apache

Konfigurationsdateien für Apache befinden sich im Verzeichnis /etc/httpd/conf.d/. In Apache unter Ubuntu werden alle Konfigurationsdateien des virtuellen Hosts in /etc/apache2/sites-availablegespeichert. Dateien mit der Erweiterung .conf werden in alphabetischer Reihenfolge zusätzlich zu den Modulkonfigurationsdateien im Verzeichnis /etc/httpd/conf.modules.d/ verarbeitet, das Konfigurationsdateien enthält, die zum Laden von Modulen erforderlich sind.

So erstellen Sie eine Konfigurationsdatei mit dem Namen helloapp.conf für die App:

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</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>

Der Block VirtualHost kann mehrmals erscheinen, in mindestens einer Datei auf einem Server. In der vorangehenden Konfigurationsdatei akzeptiert Apache öffentlichen Datenverkehr über Port 80. Die Domäne www.example.com wird bearbeitet, und der Alias *.example.com wird auf der gleichen Website aufgelöst. Weitere Informationen finden Sie unter Unterstützung für namensbasierte virtuelle Hosts. Anforderungen werden über einen Proxy auf Stammebene an Port 5000 des Servers unter 127.0.0.1 übergeben. Für bidirektionale Kommunikation sind ProxyPass und ProxyPassReverse erforderlich. Informationen zum Ändern der IP-Adresse oder des Ports von Kestrel finden Sie unter Kestrel: Endpunktkonfiguration.

Der Block VirtualHost kann mehrmals erscheinen, in mindestens einer Datei auf einem Server. In der vorangehenden Konfigurationsdatei akzeptiert Apache öffentlichen Datenverkehr über Port 80. Die Domäne www.example.com wird bearbeitet, und der Alias *.example.com wird auf der gleichen Website aufgelöst. Weitere Informationen finden Sie unter Unterstützung für namensbasierte virtuelle Hosts. Anforderungen werden über einen Proxy auf Stammebene an Port 5000 des Servers unter 127.0.0.1 übergeben. Für bidirektionale Kommunikation sind ProxyPass und ProxyPassReverse erforderlich. Informationen zum Ändern der IP-Adresse oder des Ports von Kestrel finden Sie unter Kestrel: Endpunktkonfiguration.

Erstellen Sie eine symbolische Verknüpfung mit dem /etc/apache2/sites-enabled-Verzeichnis, das Apache während des Starts lesen soll:

sudo ln -s /etc/apache2/sites-available/helloapp.conf /etc/apache2/sites-enabled/

Warnung

Schlägt die Angabe einer ordnungsgemäßen ServerName-Anweisung im Block VirtualHost fehl, ist Ihre App Sicherheitsrisiken ausgesetzt. Platzhalterbindungen in untergeordneten Domänen (z.B. *.example.com) verursachen kein Sicherheitsrisiko, wenn Sie die gesamte übergeordnete Domäne steuern (im Gegensatz zu *.com, das angreifbar ist). Weitere Informationen finden Sie unter RFC 9110: HTTP-Semantik (Abschnitt 7.2. Host und :authority).

Die Protokollierung kann über VirtualHost mit den ErrorLog- und CustomLog-Anweisungen konfiguriert werden. ErrorLog ist der Speicherort, an dem der Server Fehler protokolliert. CustomLog legt den Dateinamen und das Format der Protokolldatei fest. In diesem Fall werden hier Anforderungsinformationen protokolliert. Für jede Anforderung gibt es eine Zeile.

Speichern Sie die Datei, und testen Sie die Konfiguration. Wenn alle Anforderungen durchgehen, muss die Antwort Syntax [OK] lauten.

sudo apachectl configtest

So starten Sie Apache neu:

sudo systemctl restart httpd
sudo systemctl enable httpd

Überwachen der App

Apache ist jetzt dafür eingerichtet, Anforderungen an http://localhost:80 an die ASP.NET Core-App weiterzuleiten, die auf Kestrel unter http://127.0.0.1:5000 ausgeführt wird. Apache ist jedoch nicht dafür eingerichtet, den Kestrel-Prozess zu verwalten. Verwenden Sie systemd, und erstellen eine Dienstdatei, um die zugrunde liegende Web-App zu starten und zu überwachen. SystemD ist ein Initialisierungssystem, das viele leistungsstarke Features zum Starten, Beenden und Verwalten von Prozessen bereitstellt.

Erstellen der Dienstdatei

Erstellen Sie die Dienstdefinitionsdatei:

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

Eine Beispieldienstdatei für die App:

[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

Im vorherigen Beispiel wird der Benutzer, der den Dienst verwaltet, durch die Option User angegeben. Der Benutzer (apache) muss vorhanden und der ordnungsgemäße Besitzer der App-Dateien sein.

Verwenden Sie TimeoutStopSec, um die Dauer der Wartezeit bis zum Herunterfahren der App zu konfigurieren, nachdem diese das anfängliche Interruptsignal empfangen hat. Wenn die App in diesem Zeitraum nicht heruntergefahren wird, wird SIGKILL ausgegeben, um die App zu beenden. Geben Sie den Wert als einheitenlose Sekunden (z.B. 150), einen Zeitspannenwert (z.B. 2min 30s) oder infinity an, um das Timeout zu deaktivieren. TimeoutStopSec ist standardmäßig der Wert DefaultTimeoutStopSec in der Manager-Konfigurationsdatei (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). Das Standardtimeout für die meisten Distributionen beträgt 90 Sekunden.

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

Einige Werte (z.B. SQL-Verbindungszeichenfolgen) müssen mit Escapezeichen versehen werden, damit die Konfigurationsanbieter die Umgebungsvariablen lesen können. Mit dem folgenden Befehl können Sie einen ordnungsgemäß mit Escapezeichen versehenen Wert für die Verwendung in der Konfigurationsdatei generieren:

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

Doppelpunkte (:) als Trennzeichen werden in Umgebungsvariablennamen nicht unterstützt. Verwenden Sie statt eines Doppelpunkts zwei Unterstriche (__). Der Umgebungsvariablen-Konfigurationsanbieter konvertiert jeweils die zwei Unterstriche in einen Doppelpunkt, wenn die Umgebungsvariablen in die Konfiguration gelesen werden. Im folgenden Beispiel wird der Verbindungszeichenfolgeschlüssel ConnectionStrings:DefaultConnection als ConnectionStrings__DefaultConnection in die Dienstdefinitionsdatei platziert:

Doppelpunkte (:) als Trennzeichen werden in Umgebungsvariablennamen nicht unterstützt. Verwenden Sie statt eines Doppelpunkts zwei Unterstriche (__). Der Umgebungsvariablen-Konfigurationsanbieter konvertiert jeweils die zwei Unterstriche in einen Doppelpunkt, wenn die Umgebungsvariablen in die Konfiguration gelesen werden. Im folgenden Beispiel wird der Verbindungszeichenfolgeschlüssel ConnectionStrings:DefaultConnection als ConnectionStrings__DefaultConnection in die Dienstdefinitionsdatei platziert:

Environment=ConnectionStrings__DefaultConnection={Connection String}

So speichern Sie die Datei und aktivieren den Dienst:

sudo systemctl enable kestrel-helloapp.service

So starten Sie den Dienst und überprüfen, ob er ausgeführt wird:

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

Wenn der Reverseproxy konfiguriert ist und Kestrel durch systemd verwaltet wird, ist die Webanwendung vollständig konfiguriert. Auf diese kann dann über einen Browser auf dem lokalen Computer unter http://localhost zugegriffen werden. Beim Untersuchen der Antwortheader gibt der Header Server an, dass die ASP.NET Core-App von Kestrel verarbeitet wird:

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

Anzeigen von Protokollen

Da die Web-App mit Kestrel mithilfe von systemd verwaltet wird, werden Ereignisse und Prozesse in einem zentralen Journal protokolliert. Dieses Journal enthält jedoch Einträge für alle Dienste und Prozesse, die von systemd verwaltet werden. Verwenden Sie folgenden Befehl, um die kestrel-helloapp.service-spezifischen Elemente anzuzeigen:

sudo journalctl -fu kestrel-helloapp.service

Geben Sie für die Uhrzeitfilterung mit dem Befehl Uhrzeitoptionen an. Verwenden Sie beispielsweise --since today zum Filtern für den aktuellen Tag oder --until 1 hour ago, um die Einträge der letzten Stunde anzuzeigen. Weitere Informationen finden Sie auf der Manpage für „journalctl“.

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

Schutz von Daten

Der Stapel zum Schutz von Daten in ASP.NET Core wird von mehreren ASP.NET Core-Middlewares verwendet. Hierzu gehören die Authentifizierungsmiddleware (zum Beispiel die cookiemiddleware) und Maßnahmen zum Schutz vor websiteübergreifenden Anforderungsfälschungen (CSRF). Selbst wenn Datenschutz-APIs nicht im Benutzercode aufgerufen werden, sollte der Schutz von Daten konfiguriert werden, um einen persistenten kryptografischen Schlüsselspeicher zu erstellen. Wenn der Schutz von Daten nicht konfiguriert ist, werden die Schlüssel beim Neustarten der App im Arbeitsspeicher gespeichert und verworfen.

Falls der Schlüsselbund im Arbeitsspeicher gespeichert wird, wenn die App neu gestartet wird, gilt Folgendes:

  • Alle cookiebasierten Authentifizierungstoken werden für ungültig erklärt.
  • Benutzer müssen sich bei ihrer nächsten Anforderung erneut anmelden.
  • Alle mit dem Schlüsselbund geschützte Daten können nicht mehr entschlüsselt werden. Dies kann CSRF-Token und ASP.NET Core-MVC-TempData-cookies einschließen.

Wenn Sie den Schutz von Daten konfigurieren möchten, um den Schlüsselring persistent zu speichern und zu verschlüsseln, finden Sie in den folgenden Artikeln weitere Informationen:

Sichern der App

Konfigurieren der Firewall

Firewalld ist ein dynamischer Daemon zum Verwalten der Firewall mit Unterstützung für Netzwerkzonen. Ports und Paketfilterung können weiterhin mit „iptables“ verwaltet werden. Firewalld sollte standardmäßig installiert werden. yum kann für die Installation oder zur Überprüfung einer erfolgreichen Installation verwendet werden.

sudo yum install firewalld -y

Mit firewalld können Sie nur die für die App erforderlichen Ports öffnen. In diesem Fall werden die Ports 80 und 443 verwendet. Über die folgenden Befehle werden die Ports 80 und 443 dauerhaft geöffnet:

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

Laden Sie die Firewalleinstellungen erneut. Überprüfen Sie die verfügbaren Dienste und Ports in der Standardzone. Über firewall-cmd -h können Sie verfügbare Optionen ermitteln.

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:

HTTPS-Konfiguration

Konfigurieren der App für sichere (HTTPS) lokale Verbindungen

Der dotnet run-Befehl verwendet die Properties/launchSettings.json-Datei der App, die die App so konfiguriert, dass diese an den URLs lauscht, die von der applicationUrl-Eigenschaft bereitgestellt werden, z. B. https://localhost:5001;http://localhost:5000.

Konfigurieren Sie mithilfe eines der folgenden Ansätze die App so, dass sie bei der Entwicklung für den Befehl dotnet run oder die Entwicklungsumgebung (F5 oder STRG+F5 in Visual Studio Code) ein Zertifikat verwendet:

Konfigurieren des Reverseproxys für sichere (HTTPS) Clientverbindungen

Warnung

Die Sicherheitskonfiguration in diesem Abschnitt ist eine allgemeine Konfiguration, die als Ausgangspunkt für weitere Anpassungen verwendet werden kann. Wir können keine Unterstützung für Tools, Server und Betriebssysteme von Drittanbietern bereitstellen. Die Verwendung der Konfiguration in diesem Abschnitt erfolgt auf eigene Gefahr. Weitere Informationen finden Sie in den folgenden Ressourcen:

Für die Konfiguration von Apache für HTTPS wird das Modul mod_ssl verwendet. Wenn das Modul httpd installiert wurde, wurde das Modul mod_ssl ebenfalls installiert. Wurde es nicht installiert, fügen Sie es mit yum zur Konfiguration hinzu.

sudo yum install mod_ssl

Installieren Sie zur Erzwingung von HTTPS das Modul mod_rewrite, um eine URL-Umschreibung zu aktivieren:

sudo yum install mod_rewrite

Ändern Sie die Datei helloapp.conf, um sichere Kommunikation an Port 443 zu aktivieren.

Im folgenden Beispiel wird der Server nicht für Umleitung unsicherer Anforderungen konfiguriert. Wir empfehlen die Verwendung von HTTPS-Umleitungsmiddleware. Weitere Informationen finden Sie unter Erzwingen von HTTPS in ASP.NET Core.

Hinweis

Für Entwicklungsumgebungen, in denen die Serverkonfiguration anstelle der HTTPS-Umleitungsmiddleware die sichere Umleitung verarbeitet, empfehlen wir die Verwendung von temporären Umleitungen (302) anstelle von permanenten Umleitungen (301). Das Zwischenspeichern von Links kann in Entwicklungsumgebungen zu instabilem Verhalten führen.

Durch das Hinzufügen eines Strict-Transport-Security-Headers (HSTS) wird sichergestellt, dass alle nachfolgenden Anforderungen vom Client über HTTPS erfolgen. Anweisungen zum Festlegen des Strict-Transport-Security-Headers finden Sie unter Erzwingen von HTTPS in 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>

Hinweis

In diesem Beispiel wird ein lokal generiertes Zertifikat verwendet. SSLCertificateFile muss die primäre Zertifikatdatei für den Domänennamen sein. SSLCertificateKeyFile muss die Schlüsseldatei sein, die beim Erstellen der Zertifikatsignaturanforderung (Certificate Signing Request, CSR) generiert wurde. SSLCertificateChainFile muss die Zwischenzertifikatdatei (falls vorhanden) sein, die von der Zertifizierungsstelle bereitgestellt wurde.

Apache HTTP Server Version 2.4.43 oder höher ist erforderlich, um einen TLS 1.3-Webserver mit OpenSSL 1.1.1 zu betreiben.

Hinweis

Im Beispiel oben wird OCSP-Stapling (Online Certificate Status Protocol) deaktiviert. Weitere Informationen und Anleitungen zum Aktivieren von OCSP finden Sie unter OCSP-Stapling (Apache-Dokumentation).

So speichern Sie die Datei und testen die Konfiguration:

sudo service httpd configtest

So starten Sie Apache neu:

sudo systemctl restart httpd

Weitere Vorschläge für Apache

Neustarten von Apps bei Updates für das freigegebene Framework

Starten Sie die vom Server gehosteten ASP.NET Core-Apps nach dem Upgrade des freigegebenen Frameworks neu.

Zusätzliche Header

Als Schutz gegen Angriffe müssen einige Header geändert oder hinzugefügt werden. So stellen Sie sicher, dass das Modul mod_headers installiert wurde:

sudo yum install mod_headers

Schützen von Apache vor Clickjacking-Angriffen

Clickjacking, auch bekannt als UI Redress-Angriff, ist ein böswilliger Angriff, bei dem ein Websitebesucher dazu verleitet wird, auf einen Link oder eine Schaltfläche zu klicken, der bzw. die sich auf einer anderen Seite als der aktuell besuchten Seite befindet. Verwenden Sie X-FRAME-OPTIONS zum Sichern der Website.

So wehren Sie Clickjacking-Angriffe ab:

  1. So bearbeiten Sie die Datei httpd.conf:

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

    Fügen Sie die Zeile Header append X-FRAME-OPTIONS "SAMEORIGIN" hinzu.

  2. Speichern Sie die Datei.

  3. Starten Sie Apache neu.

MIME-Typermittlung

Der Header X-Content-Type-Options verhindert, dass eine MIME-Ermittlung über Internet Explorer (dabei wird der Content-Type einer Datei aus dem Dateiinhalt bestimmt) erfolgt. Wenn der Server den Header Content-Type auf text/html festlegt und die Option nosniff festgelegt ist, rendert Internet Explorer den Inhalt unabhängig vom Dateiinhalt als text/html.

So bearbeiten Sie die Datei httpd.conf:

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

Fügen Sie die Zeile Header set X-Content-Type-Options "nosniff" hinzu. Speichern Sie die Datei. Starten Sie Apache neu.

Lastenausgleich

Dieses Beispiel veranschaulicht das Einrichten und Konfigurieren von Apache unter CentOS 7 und Kestrel auf demselben Instanzcomputer. Damit es zu keinem Single Point of Failure kommt, ermöglicht die Verwendung von mod_proxy_balancer und das Ändern von VirtualHost das Verwalten mehrerer Instanzen der Web-Apps hinter dem Apache-Proxyserver.

sudo yum install mod_proxy_balancer

In der unten dargestellten Konfigurationsdatei wird eine zusätzliche Instanz von helloapp zur Ausführung an Port 5001 eingerichtet. Der Abschnitt Proxy wird mit einer Lastenausgleichskonfiguration mit zwei Mitgliedern für den Lastenausgleich von byrequests festgelegt.

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

Begrenzung der Bandbreite

Mit dem Modul mod_ratelimit, das im Modul httpd enthalten ist, kann die Bandbreite von Clients begrenzt werden:

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

In der Beispieldatei wird die Bandbreite am Stammspeicherort auf 600 KB/Sek. begrenzt:

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

Lange Anforderungsheaderfelder

Die Standardeinstellungen für den Proxyserver schränken die Anforderungsheaderfelder in der Regel auf 8.190 Bytes ein. Eine App erfordert möglicherweise Felder, die länger als die Standardwerte sind (z. B. Apps, die Azure Active Directory verwenden). Wenn längere Felder erforderlich sind, muss die Anweisung LimitRequestFieldSize des Proxyservers angepasst werden. Der anzuwendende Wert hängt vom jeweiligen Szenario ab. Weitere Informationen finden Sie in der Dokumentation Ihres Servers.

Warnung

Erhöhen Sie den Standardwert von LimitRequestFieldSize nur dann, wenn dies absolut erforderlich ist. Ein Erhöhen dieses Werts vergrößert das Risiko von Pufferüberlauf- (Überlauf-) und Denial-of-Service-Angriffen durch böswillige Benutzer.

Zusätzliche Ressourcen