Ziel
Das Ziel ist die Einrichtung des Apache-Webservers mit SSL/TLS-Unterstützung auf Red Hat Linux unter Verwendung der mit der Distribution gelieferten Pakete.
Betriebssystem- und Softwareversionen
- Betriebssystem: Red Hat Enterprise Linux 7.5
- Software: Apache httpd, mod_ssl
Anforderungen
Privilegierter Zugriff auf den Webserver.
Schwierigkeit
EINFACH
Konventionen
- # – erfordert, dass bestimmte Linux-Befehle mit Root-Rechten ausgeführt werden, entweder direkt als Root-Benutzer oder durch Verwendung von
sudoBefehl - $ – gegebene Linux-Befehle, die als normaler nicht-privilegierter Benutzer ausgeführt werden sollen
Einführung
Die Installation eines Webservers ist bei modernen Distributionen ziemlich einfach, da Anwendungsfälle eines Webservers so häufig sind, dass die meisten, wenn nicht alle Distributionen Pakete in ihren Repositories bereitstellen. Apache httpd ist ein zuverlässiger Webserver, der von einem großen Teil des Internets verwendet wird, und viele Module sind verfügbar, um seine Funktionalität zu erweitern.
Die technischen Nachrichten dieser Tage sind voll von Sicherheitsverletzungen, Datendiebstahl/Datenlecks und einem wachsenden Drang, Verschlüsselung zu verwenden,
wo es möglich ist. Während die Verwendung von HTTPS sowohl auf der Server- als auch auf der Clientseite einen gewissen Rechenaufwand verursacht, bedeutet die Nichtverwendung, dass alle in beide Richtungen gesendeten Daten Klartext sind und von jedem gelesen werden können, der den Datenverkehr lesen kann, während er durch das Netzwerk geleitet wird.
Angenommen, Sie haben einen Webdienst, bei dem sich Clients mit ihrem Benutzernamen und Passwort anmelden können – einer gängigen Authentifizierungsmethode –, um auf ihre eigenen Daten zuzugreifen, einschließlich der Administratoren der Website. Wenn Sie diesen Dienst über http bereitstellen, können alle diese Informationen aufgezeichnet werden, sodass jemand alle Anmeldeinformationen erhalten, sich als Administrator der Website anmelden und die echten Administratoren aussperren oder Inhalte veröffentlichen kann, die für Besucher schädlich sind.
Die Möglichkeit, beim Browsen Verschlüsselung zu verwenden, ist seit langem in alle gängigen modernen Browser integriert, und auf die gleiche Weise steht die Verschlüsselung seit vielen Jahren auch Webservern zur Verfügung.
Installieren Sie den Apache-Webserver mit SSL/TLS-Unterstützung
Um die erforderlichen Pakete zu installieren, führen Sie einfach als root aus:
# yum install httpd mod_ssl -y
Wenn auf dem Server bereits httpd installiert ist, müssen Sie nur mod_ssl installieren , die gesamte erforderliche Konfiguration
wird vom Installationsprogramm durchgeführt. Beachten Sie jedoch, dass Sie in diesem Fall httpd neu starten müssen, damit es das SSL-Modul laden kann. Durch die Verwendung
der mit der Distribution gelieferten Pakete können wir uns das Leben erheblich erleichtern, da Red Hat ordnungsgemäß getestete Updates sowohl für das Betriebssystem als auch für den Webserver bereitstellt. Natürlich benötigen Sie ein Abonnement, um die Updates zu erhalten – aber das Betriebssystem benötigt sowieso Updates, um auf dem neuesten Stand zu bleiben.
HTTPD-Server aktivieren und starten
Mit systemd können Sie den Webserver mit dem folgenden Befehl aktivieren und starten:
# systemctl enable httpd && systemctl start httpd
Auf diese Weise wird der httpd-Dienst bei jedem Systemstart automatisch von systemd gestartet.
Installation und Status überprüfen
Sie können den Status des Webservers mit systemd überprüfen:
# systemctl status httpd -l
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2018-07-07 21:35:33 CEST; 1 weeks 4 days ago
Docs: man:httpd(8)
man:apachectl(8)
Main PID: 1292 (httpd)
Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec"
Tasks: 9
CGroup: /system.slice/httpd.service
├─ 1292 /usr/sbin/httpd -DFOREGROUND
├─13271 /usr/sbin/httpd -DFOREGROUND
├─13272 /usr/sbin/httpd -DFOREGROUND
├─13273 /usr/sbin/httpd -DFOREGROUND
├─27508 /usr/sbin/httpd -DFOREGROUND
├─27509 /usr/sbin/httpd -DFOREGROUND
├─27510 /usr/sbin/httpd -DFOREGROUND
├─27511 /usr/sbin/httpd -DFOREGROUND
└─27512 /usr/sbin/httpd -DFOREGROUND
Jul 07 21:35:32 web.foobar.com systemd[1]: Starting The Apache HTTP Server...
Jul 07 21:35:33 web.foobar.com systemd[1]: Started The Apache HTTP Server.
So prüfen Sie, ob mod_ssl richtig installiert ist:
# rpm -q mod_ssl
mod_ssl-2.4.6-80.el7.x86_64
Und wird als Modul in den httpd-Server geladen:
# apachectl -M | grep ssl
ssl_module (shared)
Zertifikatsnutzung
Wenn wir das mod_ssl-Paket installieren, fügt sich das Modul zum httpd-Server hinzu, sodass es beim nächsten Start geladen wird.
Standardmäßig wird ein selbstsigniertes Zertifikat generiert, das verwendet wird, um eine verschlüsselte Verbindung mit dem Browser herzustellen.
Öffnen Sie einen Browser und verweisen Sie ihn über https:
SSL-Fehlermeldung im Firefox-Browser Lassen Sie uns dies vorerst ignorieren, fügen Sie die Sicherheitsausnahme hinzu (setzen Sie nicht „diese Ausnahme dauerhaft speichern“) und fahren Sie fort. Die Standardseite wird angezeigt. Im Falle von Red Hat sieht dies wie folgt aus:
Standardhomepage einer httpd-Webserverinstallation unter Red Hat Linux Beachten Sie das Ausrufezeichen neben der URL (andere Browser zeigen möglicherweise eine andere Warnung).
Unser Webserver läuft jetzt über https mit einem selbstsignierten Zertifikat und ist bereit, veröffentlichte Inhalte
unter /var/www/html bereitzustellen , das standardmäßige Content-Stammverzeichnis des Webservers auf Red Hat.
Die Verbindung zwischen dem Webserver und dem Browser ist jetzt verschlüsselt, sodass es schwieriger ist, den Datenverkehr zu fälschen (was
zum Beispiel zum Stehlen von Anmeldeinformationen verwendet werden kann). Sind wir fertig? In gewisser Weise haben wir unser Ziel erreicht.
Die Tatsache, dass unser Browser das Serverzertifikat nicht als gültig identifizieren kann, hindert ihn nicht daran, verschlüsselt mit dem Server zu kommunizieren, wenn wir uns ausdrücklich dafür entscheiden, diesem Zertifikat zu vertrauen. Dies kann für ein kleines (Heim-)System geeignet sein, in dem Sie nur wenige Benutzer sowie nur wenige Webserver haben – Sie müssen das selbstsignierte Zertifikat in Browsern akzeptieren, die Clients der Webserver sein sollen, und alle anderen Browser der Welt sollten die von diesen Servern bereitgestellten Inhalte niemals sehen.
Beachten Sie jedoch, dass dieses selbstsignierte Zertifikat mit der Zeit abläuft (wie jedes andere Zertifikat auch), und Sie es
erneuern müssen, um es verwenden zu können. Abgelaufene Zertifikate werden von den Browsern als ungültig angesehen, genauso wie Zertifikate, deren Gültigkeit nicht durch eine darüber liegende gültige Zertifikatskette nachgewiesen werden kann.
Um herauszufinden, wann das selbstsignierte (oder ein anderes) Zertifikat abläuft, müssen wir es im Dateisystem finden, indem wir die Konfigurationsdatei des SSL-Moduls konsultieren:
# grep SSLCertificateFile /etc/httpd/conf.d/ssl.conf | grep -v "#"
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
Verwenden Sie dann openssl, um das Ablaufdatum abzurufen:
# openssl x509 -enddate -noout -in /etc/pki/tls/certs/localhost.crt
notAfter=Jul 10 07:06:17 2019 GMT
Nachdem (oder eher bevor) das Zertifikat abläuft, müssen Sie es erneuern oder durch ein Zertifikat ersetzen, dem die Clients vertrauen. Ein
eleganterer Ansatz im Gegensatz zu selbstsignierten Zertifikaten besteht darin, ein Zertifikat von einer CA
(Certificate Authority) anzufordern und zu verwenden, der Ihre Kunden bereits vertrauen, entweder von Ihrer internen CA (die wiederum eine global
vertrauenswürdige Root-CA darüber) oder direkt von einer global vertrauenswürdigen CA.
Um das erhaltene Zertifikat anstelle des Standardzertifikats zu verwenden, müssen die folgenden Parameter auf die Zertifikatsdatei, den
Zertifikatsschlüssel und das Zertifikat der Zertifizierungsstelle verweisen, die das SSL-Zertifikat signiert hat. Die Dateien müssen auf
den Webserver kopiert werden und für den Benutzer des Betriebssystems lesbar sein, der den Webserver ausführt – im Falle einer Standardinstallation von Red Hat der Apache-Benutzer. Diese Parameter sind in der oben erwähnten ssl.conf zu finden .
SSLCertificateFile /etc/httpd/custom-cert/server-ssl.crt SSLCertificateKeyFile /etc/httpd/custom-cert/server-ssl.key SSLCACertificateFile /etc/httpd/custom-cert/ca.crt
Umleitung von HTTP-Verkehr zu https
Jetzt, da wir über https dienen, können wir die Verwendung von https erzwingen, während wir alle oder einen Teil unserer Inhalte bereitstellen. In unserem
Beispiel sind wir sehr sicher und verwenden http nur, um eingehende Clients auf https umzuleiten.
Es stellt sich vielleicht die Frage, wenn wir nur https sprechen wollen, warum hören wir dann überhaupt auf http? Angenommen, ein Endbenutzer, der gerade von unserer Website gehört hat, hat von einem Freund eine URL erhalten, die das Protokoll nicht enthält. Bis heute verwenden die meisten Browser standardmäßig das HTTP-Protokoll, wenn eines nicht explizit angegeben ist. Wenn wir die Bereitstellung über http beenden, erhält der Benutzer, der die URL ohne https eingibt, eine Fehlermeldung, wenn sein/ihr Browser versucht, unseren Server über http zu erreichen.
Um alle eingehenden HTTP-Anfragen auf https umzuleiten, erstellen wir eine Datei unter /etc/httpd/conf.d mit einem aussagekräftigen Namen, z. B. redirect_http.conf mit folgendem Inhalt (wobei web.foobar.com der DNS-Name der Site ist):
<VirtualHost _default_:80>
Servername web.foobar.com
Redirect permanent / https://web.foobar.com/
</VirtualHost>
Und starten Sie den Webserver neu. Ob die Umleitung korrekt funktioniert, können wir von der Kommandozeile aus mit wget testen (von einem Host, der dem SSL-Zertifikat des Webservers vertraut):
$ wget http://web.foobar.com/
--2018-07-19 16:13:01-- http://web.foobar.com/
Resolving web.foobar.com (web.foobar.com)... 10.9.8.7
Connecting to web.foobar.com (web.foobar.com)|10.9.8.7|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://web.foobar.com/ [following]
--2018-07-19 16:13:01-- https://web.foobar.com/
Connecting to web.foobar.com (web.foobar.com)|10.9.8.7|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 240 [text/html]
Saving to: ‘index.html’
100%[====================================================================================>] 240 --.-K/s in 0s
2018-07-19 16:13:01 (7.04 MB/s) - ‘index.html’ saved [240/240]
Die Ausgabe zeigt die http 301-Antwort, und wir können sehen, wie unser wget-Client der Umleitung folgt, um eine Verbindung mit dem https-Protokoll herzustellen. Standardmäßig wird der SSL-Verkehr in anderen Protokolldateien protokolliert als der http-Verkehr. Wir finden die obige
Anfrage protokolliert in /var/log/httpd/ssl_access_log :
10.9.8.8 - - [19/Jul/2018:16:13:01 +0200] "GET / HTTP/1.1" 200 240
Schlussfolgerung
Damit haben wir unser Ziel erreicht, wir haben einen Webserver eingerichtet, der https verwendet, um mit Clients zu sprechen, und eingehende HTTP-Anfragen ebenfalls an https umleitet.