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:
- http://httpd.apache.org/docs/2.4/
- http://www.modsecurity.org/documentation/
- https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
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.