Leitfaden zur Härtung und Sicherheit des Apache Webservers

Eine praktische Anleitung zum Sichern und Härten des Apache HTTP Servers.

Der Webserver ist ein wichtiger Bestandteil webbasierter Anwendungen. Der Apache Webserver befindet sich oft am Rande des Netzwerks und ist daher einer der anfälligsten Dienste für Angriffe.

Die Standardkonfiguration liefert viele sensible Informationen, mit denen Hacker einen Angriff auf die Anwendungen vorbereiten können. Die meisten Angriffe auf Webanwendungen erfolgen über XSS, Info Leakage, Session Management und SQL Injection, die auf schwachen Programmiercode und mangelnde Bereinigung der Infrastruktur von Webanwendungen zurückzuführen sind.

Eine interessante Studie von Positive Technologies zeigt, dass 52% der gescannten Anwendungen hohe Sicherheitslücken aufweisen.

In diesem Artikel spreche ich über einige der besten Methoden zur Absicherung des Apache HTTP-Servers auf der Linux-Plattform.

Die folgenden Tests wurden mit der Version Apache 2.4.x durchgeführt.

Dies setzt voraus, dass Sie Apache auf der UNIX-Plattform installiert haben. Falls nicht, können Sie die Installationsanleitung durchgehen.
Ich werde das Apache-Installationsverzeichnis /opt/apache in dieser Anleitung als $Web_Server bezeichnen.
Wir empfehlen Ihnen, vor jeder Änderung eine Sicherungskopie der bestehenden Konfigurationsdatei zu erstellen.

Zielgruppe

Diese Anleitung richtet sich an Middleware-Administratoren, Anwendungssupporter, Systemanalytiker und alle, die sich mit den Richtlinien für Härtung und Sicherheit befassen oder befassen möchten.

Grundlegende Kenntnisse des Apache Webservers und der UNIX-Befehle sind erforderlich.

Hinweise

Für einige der Implementierungsüberprüfungen benötigen Sie ein Tool zur Untersuchung der HTTP-Header. Hierfür gibt es zwei Möglichkeiten.

Verwenden Sie die browserinternen Entwickler-Tools, um die HTTP-Header zu untersuchen. Normalerweise finden Sie diese unter der Registerkarte Netzwerk
Verwenden Sie ein Online-Tool zur Überprüfung von HTTP-Antwort-Headern

Serverversions-Banner entfernen

Ich würde sagen, dass dies eines der ersten Dinge ist, die Sie bedenken sollten, da Sie die Version des Webservers, den Sie verwenden, nicht preisgeben wollen. Wenn Sie die Version preisgeben, helfen Sie den Hackern, den Erkundungsprozess zu beschleunigen.

In der Standardkonfiguration werden die Apache-Version und der Betriebssystemtyp wie unten gezeigt angezeigt.

Gehen Sie zum Ordner $Web_Server/conf
Ändern Sie httpd.conf mit dem Editor vi
Fügen Sie die folgende Direktive hinzu und speichern Sie die httpd.conf

ServerTokens Prod
ServerSignature Aus

Starten Sie apache neu

ServerSignature entfernt die Versionsinformationen aus der vom Apache generierten Seite.

ServerTokens ändert Header nur in Production, d.h. Apache

Wie Sie unten sehen können, sind die Versions- und Betriebssysteminformationen verschwunden.

Verzeichnisauflistung im Browser deaktivieren

Deaktivieren Sie die Auflistung der Verzeichnisse in einem Browser, so dass der Besucher nicht sieht, welche Dateien und Ordner Sie im Stammverzeichnis oder in einem Unterverzeichnis haben.

Lassen Sie uns testen, wie es in den Standardeinstellungen aussieht.

Wechseln Sie in das Verzeichnis $Web_Server/htdocs
Erstellen Sie einen Ordner und einige Dateien darin

# mkdir test
# touch hi
# touch hello

Versuchen wir nun, über http://localhost/test auf den Apache zuzugreifen

Wie Sie sehen können, werden alle Dateien/Ordner angezeigt, die Sie haben, und ich bin sicher, dass Sie diese nicht preisgeben wollen.

Wechseln Sie in das Verzeichnis $Web_Server/conf
Öffnen Sie httpd.conf mit vi
Suchen Sie nach Directory und ändern Sie die Direktive Options in None oder -Indexes

<Verzeichnis /opt/apache/htdocs>
Optionen -Indexe
</Verzeichnis>

(oder)

<Verzeichnis /opt/apache/htdocs>
Optionen None
</Verzeichnis>

Apache neu starten

Hinweis: Wenn Sie mehrere Directory-Direktiven in Ihrer Umgebung haben, sollten Sie in Erwägung ziehen, das Gleiche für alle zu tun.

Versuchen wir nun, den Apache über http://localhost/test aufzurufen

Wie Sie sehen können, wird ein verbotener Fehler angezeigt, anstatt die Liste der Testordner anzuzeigen.

Etag

Über den Etag-Header können entfernte Angreifer sensible Informationen wie Inode-Nummer, Multipart-MIME-Grenze und Child-Prozess auslesen.

Um diese Schwachstelle zu verhindern, müssen wir sie wie folgt implementieren. Dies ist erforderlich, um die PCI-Konformität zu gewährleisten.

Wechseln Sie in das Verzeichnis $Web_Server/conf
Fügen Sie die folgende Anweisung hinzu und speichern Sie die httpd.conf

FileETag Keine

Starten Sie Apache neu

Starten Sie Apache von einem nicht privilegierten Konto aus

Eine Standardinstallation läuft als nobody oder Daemon. Die Verwendung eines separaten, nicht privilegierten Benutzers für Apache ist sinnvoll.

Die Idee dahinter ist, andere laufende Dienste zu schützen, falls eine Sicherheitslücke auftritt.

Erstellen Sie einen Benutzer und eine Gruppe namens apache

# groupadd apache
# useradd -G apache apache

Ändern Sie den Besitz des apache-Installationsverzeichnisses auf einen neu angelegten, nicht privilegierten Benutzer

# chown -R apache:apache /opt/apache

Wechseln Sie zu $Web_Server/conf
Ändern Sie httpd.conf mit vi
Suchen Sie nach User & Group Directive und ändern Sie diese als nicht-privilegiertes Konto apache

Benutzer apache 
Gruppe apache

Speichern Sie die httpd.conf
Starten Sie Apache neu

suchen Sie mit grep nach dem laufenden http-Prozess und stellen Sie sicher, dass er mit dem Benutzer apache läuft

# ps -ef |grep http

Sie sollten sehen, dass ein Prozess mit root läuft. Das liegt daran, dass der Apache auf Port 80 lauscht und mit root gestartet werden muss.

Berechtigung für Binär- und Konfigurationsverzeichnis schützen

Standardmäßig ist die Berechtigung für das Binär- und das Konfigurationsverzeichnis 755, d.h. jeder Benutzer auf einem Server kann die Konfiguration einsehen. Sie können einem anderen Benutzer den Zugriff auf die Ordner conf und bin verweigern.

Gehen Sie zum Verzeichnis $Web_Server
Ändern Sie die Rechte für die Ordner bin und conf

# chmod -R 750 bin conf

Schutz der Systemeinstellungen

Bei einer Standardinstallation können Benutzer die Apache-Konfiguration mit .htaccess überschreiben. Wenn Sie verhindern möchten, dass Benutzer die Einstellungen Ihres Apache-Servers ändern, können Sie AllowOverride wie unten gezeigt auf None setzen.

Dies muss auf der Root-Ebene geschehen.

Wechseln Sie in das Verzeichnis $Web_Server/conf
Öffnen Sie httpd.conf mit vi
Suchen Sie auf Root-Ebene nach Directory

<Verzeichnis /> 
Optionen -Indexe 
AllowOverride None
</Verzeichnis>

Speichern Sie die httpd.conf
Starten Sie Apache neu

HTTP-Anfrage-Methoden

Das HTTP 1.1-Protokoll unterstützt viele Abfragemethoden, die möglicherweise nicht benötigt werden und von denen einige ein potenzielles Risiko darstellen.

In der Regel benötigen Sie in einer Webanwendung die Abfragemethoden GET, HEAD und POST, die in der entsprechenden Verzeichnisanweisung konfiguriert werden können.

Die Standardkonfiguration unterstützt die Methoden OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT im HTTP 1.1 Protokoll.

Wechseln Sie in das Verzeichnis $Web_Server/conf
Öffnen Sie httpd.conf mit vi
Suchen Sie nach dem Verzeichnis und fügen Sie Folgendes hinzu

<LimitExcept GET POST HEAD>
deny from all
</LimitExcept>

Starten Sie Apache neu

Deaktivieren Sie Trace HTTP Request

Standardmäßig ist die Trace-Methode im Apache-Webserver aktiviert.

Wenn sie aktiviert ist, kann sie Cross Site Tracing-Angriffe ermöglichen und einem Hacker die Möglichkeit geben, Cookie-Informationen zu stehlen. Schauen wir uns an, wie es in der Standardkonfiguration aussieht.

Führen Sie eine Telnet-Anfrage an die IP-Adresse des Webservers mit dem zuhörenden Port aus
Stellen Sie eine TRACE-Anfrage wie unten gezeigt

#telnet localhost 80 
Versucht 127.0.0.1...
Verbunden mit localhost.
Escape-Zeichen ist '^]'.
TRACE / HTTP/1.1 Host: test
HTTP/1.1 200 OK
Datum: Sat, 31 Aug 2013 02:13:24 GMT
Server: Apache
Transfer-Encoding: chunked
Content-Type: message/http 20
TRACE / HTTP/1.1
Host: test 
0
Verbindung von fremdem Host geschlossen.
#

Wie Sie in der obigen TRACE-Anfrage sehen können, hat sie auf meine Anfrage geantwortet. Deaktivieren wir ihn und testen wir ihn.

Wechseln Sie in das Verzeichnis $Web_Server/conf
Fügen Sie die folgende Anweisung hinzu und speichern Sie die httpd.conf

TraceEnable ausschalten

Starten Sie Apache neu

Rufen Sie die IP-Adresse des Webservers mit dem Listen-Port über Telnet auf und stellen Sie eine TRACE-Anfrage wie unten gezeigt

#telnet localhost 80
Versucht 127.0.0.1...
Verbunden mit localhost.
Escape-Zeichen ist '^]'.
TRACE / HTTP/1.1 Host: test
HTTP/1.1 405 Method Not Allowed
Date: Sat, 31 Aug 2013 02:18:27 GMT
Server: Apache Allow:Content-Length: 223Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0///DE"> <html><head> 
<title>405 Method Not Allowed</title> </head><body> 
<h1>Method Not Allowed</h1>
<p>Die angeforderte Methode TRACE ist für die URL / nicht erlaubt.</p> </body></html>
Verbindung durch fremden Host geschlossen.
#

Wie Sie in der obigen TRACE-Anfrage sehen können, hat er meine Anfrage mit HTTP 405 Method Not Allowed blockiert.

Dieser Webserver lässt also keine TRACE-Anfrage zu und hilft bei der Abwehr von Cross Site Tracing-Angriffen.

Setzen Sie Cookies mit HttpOnly und Secure Flag

Mit den Flaggen HttpOnly und Secure in einem Cookie können Sie die meisten gängigen Cross-Site-Scripting-Angriffe entschärfen. Ohne HttpOnly und Secure ist es möglich, Sitzungen und Cookies von Webanwendungen zu stehlen oder zu manipulieren, und das ist gefährlich.

Stellen Sie sicher, dass mod_headers.so in Ihrer httpd.conf aktiviert ist
Wechseln Sie in das Verzeichnis $Web_Server/conf
Fügen Sie die folgende Anweisung hinzu und speichern Sie die httpd.conf

Header bearbeiten Set-Cookie ^(.*)$ $1;HttpOnly;Secure

Starten Sie apache neu

Clickjacking-Angriff

Clickjacking ist eine bekannte Sicherheitslücke in Webanwendungen.

Stellen Sie sicher, dass mod_headers.so in Ihrer httpd.conf aktiviert ist
Wechseln Sie in das Verzeichnis $Web_Server/conf
Fügen Sie die folgende Direktive hinzu und speichern Sie die httpd.conf

Header immer anhängen X-Frame-Options SAMEORIGIN

Starten Sie Apache neu

X-Frame-Options unterstützt außerdem zwei weitere Optionen, die ich hier erklärt habe.

Serverseitiges Einbinden

Server Side Include (SSI) birgt das Risiko, die Belastung des Servers zu erhöhen. Wenn Sie eine gemeinsam genutzte Umgebung und stark frequentierte Webanwendungen haben, sollten Sie in Erwägung ziehen, SSI durch Hinzufügen von Includes in der Options-Direktive zu deaktivieren.

SSI-Angriffe ermöglichen die Ausnutzung einer Webanwendung, indem Skripte in HTML-Seiten injiziert oder Codes aus der Ferne ausgeführt werden.

Wechseln Sie in das Verzeichnis $Web_Server/conf
Öffnen Sie httpd.conf mit vi
Suchen Sie nach Directory und fügen Sie Includes in der Options-Direktive hinzu

<Verzeichnis /opt/apache/htdocs>
Options -Indexes -Includes
Order allow,denyAllow from all
</Verzeichnis>

Apache neu starten

Hinweis: Wenn Sie mehrere Directory-Direktiven in Ihrer Umgebung haben, sollten Sie in Erwägung ziehen, das Gleiche für alle zu tun.

X-XSS-Schutz

Der Cross Site Scripting (XSS) Schutz kann in vielen Browsern umgangen werden. Sie könnten diesen Schutz für eine Webanwendung anwenden, wenn er vom Benutzer deaktiviert wurde. Dieser Schutz wird von der Mehrzahl der großen Webunternehmen wie Facebook, Twitter, Google usw. verwendet.

Wechseln Sie in das Verzeichnis $Web_Server/conf
Öffnen Sie die Datei httpd.conf mit vi und fügen Sie folgende Header-Anweisung hinzu

Header setze X-XSS-Schutz "1; mode=block"

Starten Sie Apache neu

Wie Sie sehen können, wird XSS-Protection in den Antwort-Header eingefügt.

Deaktivieren Sie das HTTP 1.0 Protokoll

Wenn wir über Sicherheit sprechen, sollten wir so viel wie möglich schützen. Warum also verwenden wir ältere HTTP-Versionen des Protokolls, sollten wir diese auch deaktivieren?

HTTP 1.0 hat eine Sicherheitsschwäche im Zusammenhang mit Session Hijacking. Wir können dies mit dem Modul mod_rewrite deaktivieren.

Stellen Sie sicher, dass das Modul mod_rewrite in der Datei httpd.conf geladen ist
Aktivieren Sie die RewriteEngine-Direktive wie folgt und fügen Sie die Rewrite-Bedingung hinzu, um nur HTTP 1.1 zuzulassen

RewriteEngine On
RewriteCond %{THE_REQUEST} !HTTP/1.1$
RewriteRule .* - [F]

Konfiguration des Timeout-Werts

Standardmäßig beträgt der Timeout-Wert des Apache 300 Sekunden, was zu Slow Loris-Angriffen und DoS führen kann. Um dies abzuschwächen, können Sie den Timeout-Wert auf etwa 60 Sekunden herabsetzen.

Wechseln Sie in das Verzeichnis $Web_Server/conf
Öffnen Sie httpd.conf mit vi
Fügen Sie in httpd.conf Folgendes hinzu

Zeitüberschreitung 60

SSL

SSL ist eine zusätzliche Sicherheitsebene, die Sie der Webanwendung hinzufügen. Die Standard-SSL-Konfiguration führt jedoch zu bestimmten Schwachstellen, und Sie sollten in Erwägung ziehen, diese Konfigurationen zu optimieren.

SSL-Schlüssel

SSL-Schlüssel zu knacken ist schwer, aber nicht unmöglich. Es ist nur eine Frage der Rechenleistung und der Zeit.

Wie Sie vielleicht wissen, können Sie mit einem PC aus dem Jahr 2009, der etwa 73 Tage lang geknackt wird, einen 512-Bit-Schlüssel zurückentwickeln.

Je höher also die Schlüssellänge ist, desto komplizierter wird es, den SSL-Schlüssel zu knacken. Die meisten großen Internetunternehmen verwenden 2048-Bit-Schlüssel, wie unten dargestellt

Outlook.de
Microsoft.de
Live.de
Skype.de
Apple.de
Yahoo.de
Bing.de
Hotmail.de
Twitter.de

Sie können OpenSSL verwenden, um eine CSR mit 2048 Bit wie folgt zu erzeugen.

openssl req -out geekflare.csr -newkey rsa:2048 -nodes -keyout geekflare.key

Es wird eine CSR erzeugt, die Sie an eine Zertifizierungsstelle senden müssen, um sie zu signieren. Sobald Sie die signierte Zertifikatsdatei erhalten haben, können Sie sie in der Datei httpd-ssl.conf hinzufügen

SSLCertificateFile #Zertifikat signiert von der Autorität
SSLCertificateChainFile #Zertifikatssignierer angegeben von der Autorität
SSLCertificateKeyFile #Schlüsseldatei, die Sie oben erzeugt haben

Starten Sie den Apache Webserver neu und versuchen Sie, die URL mit https aufzurufen

SSL-Chiffre

SSL Cipher ist ein Verschlüsselungsalgorithmus, der als Schlüssel zwischen zwei Computern über das Internet verwendet wird. Die Datenverschlüsselung ist der Prozess der Umwandlung von Klartext in geheime, chiffrierte Codes.

Die Datenverschlüsselung basiert auf der Konfiguration Ihres Webservers SSL Cipher. Daher ist es wichtig, dass Sie eine SSL-Chiffre konfigurieren, die stärker und nicht angreifbar ist.

Gehen Sie zum Ordner $Web_Server/conf/extra
Ändern Sie die Direktive SSLCipherSuite in httpd-ssl.conf wie folgt, um nur höhere Verschlüsselungsalgorithmen zu akzeptieren

SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4

Speichern Sie die Konfigurationsdatei und starten Sie den Apache-Server neu

Hinweis: Wenn Sie viele schwache Chiffren in Ihrem SSL-Überprüfungsbericht haben, können Sie diese schnell ablehnen, indem Sie ! am Anfang hinzufügen.

Deaktivieren Sie SSL v2 & v3

SSL v2 & v3 hat viele Sicherheitsmängel, und wenn Sie auf Penetrationstests oder PCI-Compliance hinarbeiten, dann wird von Ihnen erwartet, dass Sie die Sicherheitsfindung schließen, um SSL v2/v3 zu deaktivieren.

Jede SSL v2/v3-Kommunikation kann für einen Man-in-The-Middle-Angriff anfällig sein, der die Manipulation oder Offenlegung von Daten ermöglichen könnte.

Lassen Sie uns den Apache Webserver so implementieren, dass er nur das neueste TLS akzeptiert und SSL v2/v3-Verbindungsanfragen ablehnt.

Wechseln Sie in den Ordner $Web_Server/conf/extra
Ändern Sie die Anweisung SSLProtocol in httpd-ssl.conf wie folgt, um nur TLS 1.2 zu akzeptieren

SSLProtokoll -ALL TLSv1.2

Sobald Sie mit der SSL-Konfiguration fertig sind, sollten Sie Ihre Webanwendung mit dem Online-Tool für SSL/TLS-Zertifikate testen, um eventuelle Konfigurationsfehler zu finden.

Mod Security

Mod Security ist eine Open-Source Web Application Firewall, die Sie mit Apache verwenden können.

Sie wird als Modul geliefert, das Sie kompilieren und installieren müssen. Wenn Sie sich eine kommerzielle Web Application Firewall nicht leisten können, ist dies eine ausgezeichnete Wahl für Sie.

Um einen allgemeinen Schutz für Webanwendungen zu bieten, verwenden die Core Rules die folgenden Techniken:

HTTP-Schutz – Erkennung von Verstößen gegen das HTTP-Protokoll und eine lokal definierte Nutzungsrichtlinie
Blacklist Lookups in Echtzeit – nutzt die IP-Reputation von Drittanbietern
Webbasierte Malware-Erkennung – identifiziert bösartige Webinhalte durch Abgleich mit der Google Safe Browsing API.
HTTP Denial of Service-Schutz – Abwehr von HTTP Flooding und langsamen HTTP DoS-Angriffen.
Schutz vor gängigen Webangriffen – Erkennung gängiger Angriffe auf die Sicherheit von Webanwendungen
Automatisierte Erkennung – Erkennung von Bots, Crawlern, Scannern und anderen bösartigen Oberflächenaktivitäten
Integration mit AV Scanning für Dateiuploads – identifiziert bösartige Dateien, die über die Webanwendung hochgeladen werden.
Verfolgung sensibler Daten – Verfolgt die Nutzung von Kreditkarten und blockiert Datenlecks.
Schutz vor Trojanern – Erkennt den Zugriff auf Trojanische Pferde.
Identifizierung von Anwendungsfehlern – warnt vor Anwendungsfehlkonfigurationen.
Fehlererkennung und -verschleierung – Verschleierung der vom Server gesendeten Fehlermeldungen.

Download & Installation

Die folgenden Voraussetzungen müssen auf dem Server installiert sein, auf dem Sie Mod Security mit Apache verwenden möchten. Wenn eine dieser Voraussetzungen nicht vorhanden ist, wird die Kompilierung von Mod Security fehlschlagen. Sie können yum install unter Linux oder Centos verwenden, um diese Pakete zu installieren.

apache 2.x oder höher
libpcre-Paket
libxml2-Paket
liblua-Paket
libcurl-Paket
libapr und libapr-util Paket
mod_unique_id-Modul, das mit dem Apache-Webserver gebündelt ist

Laden Sie nun die neueste stabile Version von Mod Security 2.7.5 von hier herunter

Übertragen Sie die heruntergeladene Datei nach /opt/apache
Entpacken Sie modsecurity-apache_2.7.5.tar.gz

# gunzip -c modsecurity-apache_2.7.5.tar.gz | tar xvf -

Wechseln Sie in den extrahierten Ordner modsecurity-apache_2.7.5

# cd modsecurity-apache_2.7.5

Führen Sie das configure-Skript aus, das den apxs-Pfad zum bestehenden Apache enthält

# ./configure -mit-apxs=/opt/apache/bin/apxs

Kompilieren und installieren Sie mit dem make-Skript

# make
# make install

Sobald die Installation abgeschlossen ist, sehen Sie mod_security2.so im Ordner modules unter /opt/apache

Damit ist die Installation des Mod Security Moduls auf dem bestehenden Apache Webserver abgeschlossen.

Konfiguration

Um die Mod-Sicherheitsfunktion mit Apache zu nutzen, müssen wir das Modul mod security in httpd.conf laden. Das Modul mod_unique_id ist eine Voraussetzung für Mod Security.

Dieses Modul stellt eine Umgebungsvariable mit einer eindeutigen Kennung für jede Anfrage bereit, die von Mod Security verfolgt und verwendet wird.

Fügen Sie die folgende Zeile zum Laden des Moduls für Mod Security in httpd.conf ein und speichern Sie die Konfigurationsdatei

LoadModule unique_id_module modules/mod_unique_id.so
LoadModule security2_module modules/mod_security2.so

Starten Sie den Apache Webserver neu

Mod Security ist nun installiert!

Als Nächstes müssen Sie die Mod Security Core Rule installieren, um die Vorteile dieser Funktion voll auszuschöpfen.

Die neueste Core Rule können Sie unter folgendem Link herunterladen, der kostenlos ist: https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

Kopieren Sie die heruntergeladene core rule zip-Datei in den Ordner /opt/apache/conf
Entpacken Sie die Datei core rule
Vielleicht möchten Sie den Ordner in einen kurzen und leicht zu merkenden Namen umbenennen. In diesem Beispiel werde ich ihn in crs umbenennen.
Gehen Sie zum Ordner crs und benennen Sie modsecurity_crs10_setup.conf.example in modsecurity_crs10_setup.conf um

Lassen Sie uns nun diese Regeln aktivieren, damit sie mit dem Apache-Webserver funktionieren.

Fügen Sie Folgendes in httpd.conf hinzu

<IfModule security2_module>
Include conf/crs/modsecurity_crs_10_setup.confInclude conf/crs/base_rules/*.conf
</IfModule>

In der obigen Konfiguration laden wir die Hauptkonfigurationsdatei von Mod Security, modsecurity_crs_10_setup.conf, und die Basisregeln base_rules/*.conf, die von Mod Security Core Rules zum Schutz von Webanwendungen bereitgestellt werden.

Apache Webserver neu starten

Sie haben Mod Security erfolgreich mit Apache konfiguriert!

Gut gemacht. Jetzt ist der Apache-Webserver durch die Mod Security Web Application Firewall geschützt.

Erste Schritte

Beginnen wir mit einigen der wichtigsten Konfigurationen in Mod Security, um Webanwendungen zu schützen und zu sichern.

In diesem Abschnitt werden wir alle Konfigurationsänderungen in /opt/apache/conf/crs/modsecurity_crs_10_setup.conf vornehmen.

Wir werden /opt/apache/conf/crs/modsecurity_crs_10_setup.conf in diesem Abschnitt als setup.conf bezeichnen, um ein Beispiel zu geben.

Es ist wichtig zu verstehen, welche OWASP-Regeln kostenlos zur Verfügung gestellt werden. Es gibt zwei Arten von Regeln, die von OWASP bereitgestellt werden.

Basisregeln – diese Regeln wurden ausgiebig getestet, und die Fehlalarmquote ist wahrscheinlich geringer.

Experimentelle Regeln – diese Regeln sind für einen experimentellen Zweck gedacht und es kann zu einem hohen Fehlalarm kommen. Es ist wichtig, sie zu konfigurieren, zu testen und in UAT zu implementieren, bevor Sie sie in einer Produktionsumgebung einsetzen.

Optionale Regeln – diese optionalen Regeln sind möglicherweise nicht für die gesamte Umgebung geeignet. Je nach Ihren Anforderungen können Sie sie verwenden.

Wenn Sie sich vor CSRF, User Tracking, Session Hijacking usw. schützen möchten, können Sie optionale Regeln verwenden. Wir haben die Basis-, optionalen und experimentellen Regeln nach dem Entpacken der heruntergeladenen crs-Zip-Datei von der OWASP-Download-Seite.

Die Konfigurationsdatei für diese Regeln finden Sie im Ordner crs/base_rules, crs/optional_rules und crs/experimental_rules. Machen wir uns zunächst mit einigen der Basisregeln vertraut.

modsecurity_crs_20_protocol_violations.conf: Diese Regel schützt vor Protokollschwachstellen wie Antwortsplitting, Request Smuggling, Verwendung eines nicht zulässigen Protokolls (HTTP 1.0).
modsecurity_crs_21_protocol_anomalies.conf: Zum Schutz vor Anfragen, bei denen Host, Accept, User-Agent im Header fehlen.
modsecurity_crs_23_request_limits.conf:Diese Regel ist abhängig von anwendungsspezifischen Faktoren wie der Größe der Anfrage, der Größe des Uploads, der Länge eines Parameters usw.
modsecurity_crs_30_http_policy.conf:Damit konfigurieren und schützen Sie erlaubte oder nicht erlaubte Methoden wie CONNECT, TRACE, PUT, DELETE, usw.
modsecurity_crs_35_bad_robots.conf:Erkennung von bösartigen Robotern
modsecurity_crs_40_generic_attacks.conf:Zum Schutz vor OS-Befehlsinjektion, Remote File Inclusion usw.
modsecurity_crs_41_sql_injection_attacks.conf:Diese Regel schützt vor SQL- und Blind SQL-Inject-Anfragen.
modsecurity_crs_41_xss_attacks.conf:Schutz vor Cross-Site Scripting-Anfragen.
modsecurity_crs_42_tight_security.conf:Erkennung und Schutz vor Directory Traversal.
modsecurity_crs_45_trojans.conf:Diese Regel erkennt allgemeine Dateiverwaltungsausgaben, das Hochladen von HTTP-Backdoor-Seiten und bekannte Signaturen.
modsecurity_crs_47_common_exceptions.conf:Diese Regel wird als Ausnahmemechanismus verwendet, um häufige Fehlalarme zu entfernen, die auftreten können, wie z.B. Apache-interne Dummy-Verbindungen, SSL-Pinger usw.

Protokollierung

Die Protokollierung ist eines der ersten Dinge, die Sie konfigurieren müssen, damit Sie Protokolle über die Vorgänge in Mod Security erstellen können. Es sind zwei Arten von Protokollen verfügbar: Debug- und Audit-Protokoll.

Debug-Protokoll: Hier werden die Apache-Fehler-, Warn- und Hinweismeldungen aus dem Fehlerprotokoll dupliziert.

Audit Log: Hier werden die Transaktionsprotokolle geschrieben, die durch die Mod Security-Regel markiert sind. Mod Security bietet Ihnen die Flexibilität, Audit, Debug oder beide Protokollierungsarten zu konfigurieren.

In der Standardkonfiguration werden beide Protokolle geschrieben. Sie können dies jedoch je nach Ihren Anforderungen ändern. Das Protokoll wird durch die Anweisung SecDefaultAction gesteuert. Sehen wir uns die Standardkonfiguration für die Protokollierung in setup.conf an

SecDefaultAction "phase:1,deny,log"

Um Debug- und Audit-Protokolle zu protokollieren – verwenden Sie “log” Um nur Audit-Protokolle zu protokollieren – verwenden Sie “nolog,auditlog” Um nur Debug-Protokolle zu protokollieren – verwenden Sie “log,noauditlog” Sie können den Speicherort des Audit-Protokolls angeben, der durch die Anweisung SecAuditLog gesteuert wird.

Lassen Sie uns das Audit-Protokoll in /opt/apache/logs/modsec_audit.log schreiben, indem wir es wie unten gezeigt hinzufügen.

Fügen Sie die Anweisung SecAuditLog in die setup.conf ein und starten Sie den Apache Web Server neu

SecAuditLog /opt/apache/logs/modsec_audit.log

Nach dem Neustart sollten Sie sehen, dass modsec_audit.log generiert wird

Aktivieren Sie die Regel-Engine

Standardmäßig ist die Engine Rule ausgeschaltet, d.h. wenn Sie die Rule Engine nicht aktivieren, können Sie nicht alle Vorteile von Mod Security nutzen.

Die Aktivierung oder Deaktivierung der Rule Engine wird durch die SecRuleEngine Direktive gesteuert.

Fügen Sie die Anweisung SecRuleEngine in die setup.conf ein und starten Sie den Apache Web Server neu

SecRuleEngine Ein

Es gibt drei Werte für SecRuleEngine:

On – um die Rule Engine zu aktivieren
Off – zum Deaktivieren der Rule Engine
DetectionOnly – aktiviert die Rule Engine, führt aber keine Aktionen wie block, deny, drop, allow, proxy oder redirect aus

Sobald die Rule Engine aktiviert ist, ist Mod Security bereit, Sie vor einigen der häufigsten Angriffsarten zu schützen.

Schutz gegen gängige Angriffsarten

Da wir Core Rule installiert und Rule Engine eingeschaltet haben, ist der Webserver nun bereit, sich gegen gängige Angriffstypen wie XSS, SQL Injection, Protokollverletzung usw. zu schützen. Lassen Sie uns ein paar davon testen.

XSS-Angriff

Öffnen Sie Firefox, rufen Sie Ihre Anwendung auf und fügen Sie den <script>-Tag am Ende der URL ein
Überwachen Sie das modsec_audit.log im Ordner apache/logs

Sie werden feststellen, dass Mod Security die Anfrage blockiert, da sie den <script>-Tag enthält, der die Ursache des XSS-Angriffs ist.

Directory Traversal Attack:- Directory Traversal Attacken können großen Schaden anrichten, indem sie diese Schwachstellen ausnutzen und auf systembezogene Dateien zugreifen. Zum Beispiel /etc/passwd, .htaccess usw.

Öffnen Sie Firefox und greifen Sie mit Directory Traversal auf Ihre Anwendung zu
Überwachen Sie das modsec_audit.log im Ordner apache/logs

http://localhost/?../.../boot

Sie werden feststellen, dass Mod Security die Anfrage blockiert, da sie einen Directory Traversal enthält.

Server-Banner ändern

In diesem Leitfaden haben Sie bereits gelernt, wie Sie mit Hilfe der Direktive ServerTokens den Apache- und Betriebssystemtyp sowie die Version entfernen können.

Gehen wir noch einen Schritt weiter: Wie wäre es, wenn Sie den Servernamen so beibehalten, wie Sie es wünschen? Das ist mit der SecServerSignature-Direktive in Mod Security möglich. Sie sehen, es ist interessant.

Hinweis: Um mit Mod Security das Server-Banner aus einem Header zu manipulieren, müssen Sie ServerTokesn in der httpd.conf des Apache Webservers auf Full setzen.

Fügen Sie die Direktive SecServerSignature mit dem gewünschten Servernamen in die setup.conf ein und starten Sie den Apache Webserver neu

SecServerSignatur IhrServername

Beispiel:

[/opt/apache/conf/crs] #grep SecServer modsecurity_crs_10_setup.conf
SecServerSignature geekflare.com
[/opt/apache/conf/crs] #

Allgemeine Konfiguration

Schauen wir uns einige der allgemeinen Konfigurationen als Best Practice an.

Konfigurieren Sie Listen

Wenn Sie mehrere Schnittstellen und IPs auf einem einzigen Server haben, empfiehlt es sich, die Listen-Direktive mit einer absoluten IP- und Port-Nummer zu konfigurieren.

Wenn Sie den Apache so konfigurieren, dass er auf allen IPs mit einer bestimmten Portnummer lauscht, kann es zu Problemen bei der Weiterleitung von HTTP-Anfragen an einen anderen Webserver kommen. Dies ist in einer gemeinsam genutzten Umgebung durchaus üblich.

Konfigurieren Sie die Listen-Anweisung in der httpd.conf mit einer absoluten IP und einem Port, wie im folgenden Beispiel gezeigt

Listen 10.10.10.1:80

Zugriffsprotokollierung

Es ist wichtig, dass Sie das Zugriffsprotokoll in Ihrem Webserver richtig konfigurieren. Einige der wichtigen Parameter, die im Protokoll erfasst werden müssen, sind die Zeit, die für die Bearbeitung der Anfrage benötigt wird, und die SESSION ID.

Standardmäßig ist der Apache nicht so konfiguriert, dass er diese Daten erfasst. Sie müssen sie wie folgt manuell konfigurieren.

So erfassen Sie die Zeit für die Bereitstellung der Anfrage und die SESSION-ID in einem Zugriffsprotokoll
Fügen Sie %T & %sessionID in httpd.conf unter der Anweisung LogFormat hinzu

LogFormat "%h %l %u %t "%{sessionID}C" "%r" %>s %b %T" common

Eine vollständige Liste der Parameter, die in der LogFormat-Direktive im Apache Web Server unterstützt werden, finden Sie unter http://httpd.apache.org/docs/2.2/mod/mod_log_config.html.

Deaktivieren Sie das Laden unerwünschter Module

Wenn Sie alle Module kompiliert und installiert haben, ist die Wahrscheinlichkeit groß, dass viele Module in Apache geladen sind, die nicht benötigt werden.

Am besten konfigurieren Sie Apache mit den erforderlichen Modulen für Ihre Webanwendungen. Die folgenden Module sind sicherheitsrelevant und Sie sollten sie in der httpd.conf des Apache Webservers deaktivieren.

WebDAV (Web-based Distributed Authoring and Versioning) Dieses Modul ermöglicht es Remote-Clients, Dateien auf dem Server zu manipulieren und ist für verschiedene Denial-of-Service-Angriffe anfällig. So deaktivieren Sie den folgenden Kommentar in httpd.conf

#LoadModule dav_module modules/mod_dav.so
#LoadModule dav_fs_module modules/mod_dav_fs.so
#Include conf/extra/httpd-dav.conf

Info-Modul Das mod_info-Modul kann sensible Informationen über .htaccess preisgeben, sobald dieses Modul geladen ist. So deaktivieren Sie folgenden Kommentar in httpd.conf

#LoadModule info_module modules/mod_info.so

Hinweis: Dies wäre ohne die Anleitung unter folgendem Link nicht möglich:

Das waren also einige der besten Praktiken, die Sie zur Sicherung Ihres Apache-Webservers verwenden können.

Sehen Sie sich diesen Link an, wenn Sie eine benutzerdefinierte Fehlerseite in Apache implementieren möchten.

Wenn Sie mit Apache HTTP noch nicht vertraut sind, empfehle ich Ihnen, den Apache HTTP-Administrationskurs zu besuchen.

Chandan Kumar

Autor

Chandan Kumar ist der Gründer von Geekflare. Er hat Millionen von Menschen geholfen, sich im digitalen Bereich zu verbessern. Er hat eine Leidenschaft für Technologie und ist auf einer Mission, die Welt zu erforschen und das Wachstum von Fachleuten und Unternehmen zu steigern.