Handbuch zur Härtung und Sicherheit von Apache Webservern

Veröffentlicht: 2015-02-14

Ein praktischer Leitfaden zum Sichern und Härten von Apache HTTP Server.

Der Webserver ist ein entscheidender Bestandteil webbasierter Anwendungen. Apache Web Server wird oft am Rand des Netzwerks platziert, wodurch er zu einem der anfälligsten Dienste für Angriffe wird.

Die Standardkonfiguration liefert viele sensible Informationen, die Hackern helfen können, sich auf einen Angriff auf die Anwendungen vorzubereiten. Die Mehrzahl der Angriffe auf Webanwendungen erfolgt über XSS, Info Leakage, Session Management und SQL Injection-Angriffe, die auf schwachen Programmiercode und mangelnde Bereinigung der Infrastruktur von Webanwendungen zurückzuführen sind.

Interessante Untersuchungen von Positive Technologies zeigen, dass 52 % der gescannten Anwendungen hohe Schwachstellen aufwiesen.

Schwachstellenbericht

In diesem Artikel werde ich über einige der Best Practices zur Sicherung des Apache HTTP-Servers auf der Linux-Plattform sprechen.

Folgendes wurde auf der Version Apache 2.4.x getestet.

  • Dies setzt voraus, dass Sie Apache auf einer UNIX-Plattform installiert haben. Wenn nicht, können Sie die Installationsanleitung durchgehen.
  • Ich werde das Apache-Installationsverzeichnis /opt/apache in diesem Handbuch als $Web_Server bezeichnen.
  • Es wird empfohlen, vor jeder Änderung eine Sicherungskopie der vorhandenen Konfigurationsdatei zu erstellen.

Publikum

Dies ist für Middleware-Administratoren, Anwendungssupport, Systemanalysten oder alle Personen gedacht, die mit den Richtlinien für Härtung und Sicherheit arbeiten oder daran interessiert sind, diese zu lernen.

Faire Kenntnisse über Apache Web Server und UNIX-Befehle sind erforderlich.

Anmerkungen

Sie benötigen ein Tool, um HTTP-Header für einige der Implementierungsüberprüfungen zu untersuchen. Dazu gibt es zwei Möglichkeiten.

  1. Verwenden Sie im Browser integrierte Entwicklertools, um die HTTP-Header zu untersuchen. Normalerweise befindet es sich auf der Registerkarte Netzwerk
  2. Verwenden Sie das Online-HTTP-Response-Header-Checker-Tool

Serverversionsbanner entfernen

Ich würde sagen, dass dies eines der ersten Dinge ist, die Sie berücksichtigen sollten, da Sie nicht preisgeben möchten, welche Webserver-Version Sie verwenden. Die Offenlegung der Version bedeutet, dass Sie dem Hacker helfen, den Aufklärungsprozess zu beschleunigen.

Die Standardkonfiguration zeigt die Apache-Version und den Betriebssystemtyp wie unten gezeigt.

Apache-Server-Banner

  • Gehen Sie zum Ordner $Web_Server/conf
  • Ändern Sie httpd.conf mit dem vi-Editor
  • Fügen Sie die folgende Direktive hinzu und speichern Sie die httpd.conf
 ServerTokens Prod ServerSignature Off
  • Apache neu starten

ServerSignature entfernt die Versionsinformationen von der von Apache generierten Seite.

ServerTokens ändern den Header nur in Produktion, dh Apache

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

apache-server-banner-maskiert

Deaktivieren Sie die Auflistung des Verzeichnisbrowsers

Deaktivieren Sie die Verzeichnisauflistung in einem Browser, sodass der Besucher nicht sieht, welche Dateien und Ordner Sie im Stamm- oder 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 Apache zuzugreifen

Apache-Verzeichnisliste

Wie Sie sehen konnten, zeigt es, welche Dateien/Ordner Sie haben, und ich bin sicher, Sie möchten das nicht offenlegen.

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

(oder)

 <Directory /opt/apache/htdocs> Options None </Directory>
  • Starten Sie Apache neu

Hinweis : Wenn Sie mehrere Verzeichnisdirektiven in Ihrer Umgebung haben, sollten Sie in Betracht ziehen, dasselbe für alle zu tun.

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

Verzeichnisliste deaktiviert

Wie Sie sehen konnten, zeigt es einen verbotenen Fehler an, anstatt die Liste der Testordner anzuzeigen.

Tag

Es ermöglicht entfernten Angreifern, vertrauliche Informationen wie Inode-Nummer, mehrteilige MIME-Grenzen und untergeordnete Prozesse über den Etag-Header zu erhalten.

Um diese Schwachstelle zu verhindern, implementieren wir sie wie folgt. Dies ist erforderlich, um die PCI-Konformität zu beheben.

  • Wechseln Sie in das Verzeichnis $Web_Server/conf
  • Fügen Sie die folgende Direktive hinzu und speichern Sie die httpd.conf
 FileETag None
  • Apache neu starten

Führen Sie Apache von einem nicht privilegierten Konto aus

Eine Standardinstallation wird als "Niemand" oder "Daemon" ausgeführt. Die Verwendung eines separaten nicht privilegierten Benutzers für Apache ist gut.

Die Idee hier ist, andere laufende Dienste im Falle einer Sicherheitslücke zu schützen.

  • 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 erstellten nicht privilegierten Benutzer
 # chown –R apache:apache /opt/apache
  • Gehen Sie zu $Web_Server/conf
  • Ändern Sie httpd.conf mit vi
  • Suchen Sie nach Benutzer- und Gruppenrichtlinie und ändern Sie es als nicht privilegierter Konto-Apache
 User apache Group apache
  • Speichern Sie die httpd.conf
  • Starten Sie Apache neu

grep zum Ausführen des HTTP-Prozesses und stellen Sie sicher, dass er mit dem Apache-Benutzer ausgeführt wird

 # ps –ef |grep http

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

Schützen Sie die Berechtigung für Binär- und Konfigurationsverzeichnisse

Standardmäßig ist die Berechtigung für Binärdateien und Konfiguration 755, was bedeutet, dass jeder Benutzer auf einem Server die Konfiguration anzeigen kann. Sie können einem anderen Benutzer verbieten, in den Ordner „conf“ und „bin“ zu gelangen.

  • Wechseln Sie in das Verzeichnis $Web_Server
  • Ändern Sie die Berechtigung des bin- und conf-Ordners
 # chmod –R 750 bin conf

Schutz der Systemeinstellungen

In einer Standardinstallation können Benutzer die Apache-Konfiguration mit .htaccess überschreiben. Wenn Sie verhindern möchten, dass Benutzer Ihre Apache-Servereinstellungen ändern, können Sie AllowOverride zu None hinzufügen, wie unten gezeigt.

Dies muss auf der Root-Ebene erfolgen.

  • Wechseln Sie in das Verzeichnis $Web_Server/conf
  • Öffnen Sie httpd.conf mit vi
  • Suchen Sie auf Stammebene nach Verzeichnis
 <Directory /> Options -Indexes AllowOverride None </Directory>
  • Speichern Sie die httpd.conf
  • Starten Sie Apache neu

HTTP-Anforderungsmethoden

Das HTTP 1.1-Protokoll unterstützt viele Anforderungsmethoden, die möglicherweise nicht erforderlich sind, und einige von ihnen bergen potenzielle Risiken.

Typischerweise benötigen Sie in einer Webanwendung möglicherweise GET-, HEAD- und POST-Anforderungsmethoden, die in der entsprechenden Directory-Direktive konfiguriert werden können.

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 Verzeichnis und fügen Sie Folgendes hinzu
 <LimitExcept GET POST HEAD> deny from all </LimitExcept>
  • Starten Sie Apache neu

Deaktivieren Sie Trace-HTTP-Anforderung

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

Wenn dies aktiviert ist, können Cross-Site-Tracing-Angriffe ermöglicht und einem Hacker möglicherweise die Möglichkeit gegeben werden, Cookie-Informationen zu stehlen. Mal sehen, wie es in der Standardkonfiguration aussieht.

  • Führen Sie eine Telnet-Webserver-IP mit Listening-Port aus
  • Stellen Sie eine TRACE-Anforderung wie unten gezeigt
 #telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. TRACE / HTTP/1.1 Host: test HTTP/1.1 200 OK Date: 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 Connection closed by foreign host. #

Wie Sie in der obigen TRACE-Anfrage sehen konnten, hat sie meine Anfrage beantwortet. Lassen Sie es uns deaktivieren und testen.

  • Wechseln Sie in das Verzeichnis $Web_Server/conf
  • Fügen Sie die folgende Direktive hinzu und speichern Sie die httpd.conf
 TraceEnable off
  • Apache neu starten

Führen Sie eine Telnet-Webserver-IP mit Listen-Port durch und stellen Sie eine TRACE -Anforderung wie unten gezeigt

 #telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 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//EN"> <html><head> <title>405 Method Not Allowed</title> </head><body> <h1>Method Not Allowed</h1> <p>The requested method TRACE is not allowed for the URL /.</p> </body></html> Connection closed by foreign host. #

Wie Sie in der obigen TRACE-Anfrage sehen konnten, hat sie meine Anfrage mit HTTP 405 Method Not Allowed blockiert.

Jetzt erlaubt dieser Webserver keine TRACE-Anfrage und hilft beim Blockieren von Cross-Site-Tracing-Angriffen.

Setze Cookie mit HttpOnly und Secure Flag

Sie können die meisten gängigen Cross-Site-Scripting-Angriffe mit HttpOnly und einem Secure-Flag in einem Cookie entschärfen. Ohne HttpOnly und Secure ist es möglich, Webanwendungssitzungen und Cookies zu stehlen oder zu manipulieren, und es 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 Direktive hinzu und speichern Sie die httpd.conf
 Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
  • Apache neu starten

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 always append X-Frame-Options SAMEORIGIN
  • Apache neu starten

Apache-x-Frame-Optionen

X-Frame-Optionen unterstützen auch zwei weitere Optionen, die ich hier erklärt habe.

Serverseitiges Include

Server Side Include (SSI) birgt das Risiko, die Last auf dem Server zu erhöhen. Wenn Sie die Umgebung und Webanwendungen mit hohem Datenverkehr gemeinsam genutzt haben, sollten Sie erwägen, SSI zu deaktivieren, indem Sie die Direktive Includes in Options hinzufügen.

Ein SSI-Angriff ermöglicht die Ausnutzung einer Webanwendung durch das Einfügen von Skripts in HTML-Seiten oder das Ausführen von Codes aus der Ferne.

  • Wechseln Sie in das Verzeichnis $Web_Server/conf
  • Öffnen Sie httpd.conf mit vi
  • Suchen Sie nach Directory und fügen Sie Includes in Options direkt hinzu
 <Directory /opt/apache/htdocs> Options –Indexes -Includes Order allow,denyAllow from all </Directory>
  • Starten Sie Apache neu

Hinweis: Wenn Sie mehrere Verzeichnisdirektiven in Ihrer Umgebung haben, sollten Sie in Betracht ziehen, dasselbe 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. Dies wird von den meisten großen Webunternehmen wie Facebook, Twitter, Google usw. verwendet.

  • Wechseln Sie in das Verzeichnis $Web_Server/conf
  • Öffnen Sie httpd.conf mit vi und fügen Sie die folgende Header-Direktive hinzu
 Header set X-XSS-Protection "1; mode=block"
  • Starten Sie Apache neu

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

apache-xss

Deaktivieren Sie das HTTP 1.0-Protokoll

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

HTTP 1.0 weist eine Sicherheitslücke im Zusammenhang mit Session-Hijacking auf. Wir können dies deaktivieren, indem wir das Modul mod_rewrite verwenden.

  • Stellen Sie sicher, dass Sie das Modul mod_rewrite in die Datei httpd.conf laden
  • 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 Apache-Timeout-Wert 300 Sekunden, was ein Opfer von Slow Loris-Angriffen und DoS sein kann. Um dies abzumildern, können Sie den Timeout-Wert auf vielleicht 60 Sekunden verringern.

  • Wechseln Sie in das Verzeichnis $Web_Server/conf
  • Öffnen Sie httpd.conf mit vi
  • Fügen Sie Folgendes in httpd.conf hinzu
 Timeout 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 erwägen, diese Konfigurationen zu optimieren.

SSL-Schlüssel

Das Brechen des SSL-Schlüssels ist schwierig, 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 knackte, einen 512-Bit-Schlüssel zurückentwickeln.

Je höher die Schlüssellänge, desto komplizierter wird es also, den SSL-Schlüssel zu knacken. Die Mehrheit der großen Web-Unternehmen verwendet 2048-Bit-Schlüssel, wie unten, also warum nicht wir?

  • Outlook.com
  • Microsoft.com
  • Live.com
  • Skype.com
  • Apple.com
  • Yahoo.com
  • Bing.com
  • Hotmail.com
  • Twitter.com

Sie können OpenSSL verwenden, um CSR mit 2048 Bit wie unten zu generieren.

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

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

 SSLCertificateFile #Certificate signed by authority SSLCertificateChainFile #Certificate signer given by authority SSLCertificateKeyFile #Key file which you generated above
  • Starten Sie den Apache-Webserver neu und versuchen Sie, mit https auf die URL zuzugreifen

SSL-Verschlüsselung

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

Basierend auf der SSL-Verschlüsselungskonfiguration Ihres Webservers findet die Datenverschlüsselung statt. Daher ist es wichtig, die SSL-Verschlüsselung zu konfigurieren, die stärker und nicht anfällig ist.

  • Gehen Sie zum Ordner $Web_Server/conf/extra
  • Ändern Sie die SSLCipherSuite-Direktive in httpd-ssl.conf wie unten, 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-Überwachungsbericht haben, können Sie das Hinzufügen schnell ablehnen! am Anfang.

Deaktivieren Sie SSL v2 & v3

SSL v2 & v3 weist viele Sicherheitslücken auf, und wenn Sie auf Penetrationstests oder PCI-Konformität hinarbeiten, wird von Ihnen erwartet, dass Sie die Sicherheitsfeststellung schließen, um SSL v2/v3 zu deaktivieren.

Jede SSL v2/v3-Kommunikation kann anfällig für einen Man-in-the-Middle-Angriff sein, der eine Datenmanipulation oder -offenlegung ermöglichen könnte.

Lassen Sie uns den Apache-Webserver implementieren, um nur das neueste TLS zu akzeptieren und SSL v2/v3-Verbindungsanforderungen abzulehnen.

  • Gehen Sie zum Ordner $Web_Server/conf/extra
  • Ändern Sie die SSLProtocol-Direktive in httpd-ssl.conf wie unten, um nur TLS 1.2+ zu akzeptieren
 SSLProtocol –ALL +TLSv1.2

Sobald Sie mit der SSL-Konfiguration fertig sind, ist es eine gute Idee, Ihre Webanwendung mit dem Online-Tool für SSL/TLS-Zertifikate zu testen, um Konfigurationsfehler zu finden.

Mod-Sicherheit

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

Es kommt als Modul, das Sie kompilieren und installieren müssen. Wenn Sie sich keine kommerzielle Firewall für Webanwendungen leisten können, wäre dies eine ausgezeichnete Wahl.

Um allgemeinen Schutz für Webanwendungen bereitzustellen, verwenden die Grundregeln 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 Prüfung mit der Google Safe Browsing API.
  • HTTP-Denial-of-Service-Schutz – Schutz vor HTTP-Flooding und langsamen HTTP-DoS-Angriffen.
  • Schutz vor häufigen Webangriffen – Erkennung häufiger Sicherheitsangriffe auf Webanwendungen
  • Automatisierungserkennung – Erkennung von Bots, Crawlern, Scannern und anderen schädlichen Oberflächenaktivitäten
  • Integration mit AV-Scannen für Datei-Uploads – identifiziert bösartige Dateien, die über die Webanwendung hochgeladen wurden.
  • Verfolgen sensibler Daten – Verfolgt die Verwendung von Kreditkarten und blockiert Datenlecks.
  • Trojaner-Schutz – Erkennung des Zugriffs auf Trojaner.
  • Identifizierung von Anwendungsfehlern – Warnungen bei Anwendungsfehlkonfigurationen.
  • Fehlererkennung und -ausblendung – Verschleierung von 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 eines davon nicht vorhanden ist, schlägt die Kompilierung von Mod Security fehl. 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
  • Modul mod_unique_id im Paket mit dem Apache-Webserver

Lassen Sie uns jetzt die neueste stabile Version von Mod Security 2.7.5 von hier herunterladen

  • Übertragen Sie die heruntergeladene Datei nach /opt/apache
  • Extrahieren Sie modsecurity-apache_2.7.5.tar.gz
 # gunzip –c modsecurity-apache_2.7.5.tar.gz | tar xvf –
  • Gehen Sie zum extrahierten Ordner modsecurity-apache_2.7.5
 # cd modsecurity-apache_2.7.5
  • Führen Sie das Konfigurationsskript einschließlich des apxs-Pfads zum vorhandenen Apache aus
 # ./configure –with-apxs=/opt/apache/bin/apxs
  • Mit Make-Skript kompilieren und installieren
 # make # make install
  • Sobald die Installation abgeschlossen ist, sehen Sie mod_security2.so im Modulordner unter /opt/apache

Damit ist abgeschlossen, dass Sie das Mod Security-Modul auf dem vorhandenen Apache-Webserver installiert haben.

Aufbau

Um die Mod-Sicherheitsfunktion mit Apache zu verwenden, müssen wir das Mod-Sicherheitsmodul in httpd.conf laden. Das Modul mod_unique_id ist 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 folgende Zeile zum Laden von Modul für Mod Security in httpd.conf hinzu 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 jetzt installiert!

Als nächstes müssen Sie die Mod Security-Kernregel installieren, um ihre Funktion voll auszunutzen.

Die neueste Kernregel kann über einen kostenlosen Link heruntergeladen werden. https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

  • Kopieren Sie die heruntergeladene Kernregel-ZIP-Datei in den Ordner /opt/apache/conf
  • Kernregeldatei entpacken
  • Vielleicht möchten Sie den Ordner in einen kurzen und leicht zu merkenden Namen umbenennen. In diesem Beispiel werde ich 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 es mit dem Apache-Webserver funktioniert.

  • 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 Mod Security-Hauptkonfigurationsdatei modsecurity_crs_10_setup.conf und die Basisregeln base_rules/*.conf, die von Mod Security Core Rules bereitgestellt werden, um Webanwendungen zu schützen.

  • Starten Sie den Apache-Webserver neu

Sie haben Mod Security erfolgreich mit Apache konfiguriert!

Gut erledigt. Jetzt ist der Apache-Webserver durch die Mod Security-Webanwendungs-Firewall geschützt.

Einstieg

Beginnen wir mit einigen der kritischen Konfigurationen in Mod Security, um Webanwendungen zu härten 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 zu Beispielzwecken als setup.conf bezeichnen.

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 werden intensiv getestet, und wahrscheinlich ist die Fehlalarmquote geringer.

Experimentelle Regeln – diese Regeln dienen zu experimentellen Zwecken und Sie können einen hohen Fehlalarm haben. Es ist wichtig, in UAT zu konfigurieren, zu testen und zu implementieren, bevor Sie diese in einer Produktionsumgebung verwenden.

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

Wenn Sie nach Schutz durch CSRF, Benutzerverfolgung, Sitzungsentführung usw. suchen, können Sie die Verwendung optionaler Regeln in Betracht ziehen. Wir haben die grundlegenden, optionalen und experimentellen Regeln nach dem Extrahieren der heruntergeladenen crs-Zip-Datei von der OWASP-Downloadseite.

Diese Regelkonfigurationsdatei ist in den Ordnern crs/base_rules, crs/optional_rules und crs/experimental_rules verfügbar. Machen wir uns mit einigen Grundregeln vertraut.

  • modsecurity_crs_20_protocol_violations.conf: Diese Regel schützt vor Protokollschwachstellen wie Response-Splitting, Request-Smuggling, Verwendung eines nicht erlaubten Protokolls (HTTP 1.0).
  • modsecurity_crs_21_protocol_anomalies.conf: Dies soll vor einer Anfrage schützen, die mit Host, Accept, User-Agent im Header fehlt.
  • modsecurity_crs_23_request_limits.conf: Diese Regel hat die Abhängigkeit von anwendungsspezifischen Anforderungen wie Anfragegröße, Uploadgröße, Länge eines Parameters usw.
  • modsecurity_crs_30_http_policy.conf: Dies dient zum Konfigurieren und Schützen erlaubter oder nicht erlaubter Methoden wie CONNECT, TRACE, PUT, DELETE usw.
  • modsecurity_crs_35_bad_robots.conf: Erkennung bösartiger Roboter
  • modsecurity_crs_40_generic_attacks.conf: Dies dient zum Schutz vor OS Command Injection, Remote File Inclusion usw.
  • modsecurity_crs_41_sql_injection_attacks.conf: Diese Regel zum Schutz von SQL und Blind-SQL-Inject-Requests.
  • modsecurity_crs_41_xss_attacks.conf: Schutz vor Cross-Site-Scripting-Anfrage.
  • modsecurity_crs_42_tight_security.conf: Erkennung und Schutz von Directory Traversal.
  • modsecurity_crs_45_trojans.conf: Diese Regel zum Erkennen generischer Dateiverwaltungsausgaben, Hochladen einer HTTP-Backdoor-Seite, bekannte Signatur.
  • modsecurity_crs_47_common_exceptions.conf: Dies wird als Ausnahmemechanismus verwendet, um häufige Fehlalarme zu entfernen, die als interne Apache-Dummy-Verbindung, SSL-Pinger usw. auftreten können.

Protokollierung

Die Protokollierung ist eines der ersten Dinge, die konfiguriert werden müssen, sodass Sie Protokolle für das erstellen lassen können, was Mod Security tut. Es stehen zwei Arten der Protokollierung zur Verfügung; Debug- und Audit-Protokoll.

Debug-Protokoll: Dies dient zum Duplizieren der Apache-Fehler-, Warn- und Hinweismeldungen aus dem Fehlerprotokoll.

Audit-Protokoll: Dies dient zum Schreiben der Transaktionsprotokolle, die durch die Mod-Sicherheitsregel gekennzeichnet sind. Mod-Sicherheit gibt Ihnen die Flexibilität, Audit-, Debug- oder beide Protokolle zu konfigurieren.

Standardmäßig schreibt die Konfiguration beide Protokolle. Sie können jedoch je nach Bedarf ändern. Das Protokoll wird in der SecDefaultAction Direktive gesteuert. Schauen wir uns die Standardprotokollierungskonfiguration in setup.conf an

 SecDefaultAction “phase:1,deny,log”

Um das Debug- und Audit-Protokoll zu protokollieren – verwenden Sie „log“. Um nur das Audit-Protokoll zu protokollieren – verwenden Sie „nolog, auditlog“. Richtlinie.

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

  • Fügen Sie die SecAuditLog-Direktive in setup.conf hinzu und starten Sie Apache Web Server neu
 SecAuditLog /opt/apache/logs/modsec_audit.log
  • Nach dem Neustart sollten Sie sehen, dass modsec_audit.log generiert wird

Regel-Engine aktivieren

Standardmäßig ist die Engine-Regel deaktiviert, das heißt, wenn Sie die Rule Engine nicht aktivieren, nutzen Sie nicht alle Vorteile der Mod-Sicherheit.

Das Aktivieren oder Deaktivieren der Rule Engine wird durch die SecRuleEngine Direktive gesteuert.

  • Fügen Sie die SecRuleEngine-Direktive in setup.conf hinzu und starten Sie Apache Web Server neu
 SecRuleEngine On

Es gibt drei Werte für SecRuleEngine:

  • Ein – um die Rule Engine zu aktivieren
  • Aus – zum Deaktivieren der Rule Engine
  • DetectionOnly – Rule Engine aktivieren, aber niemals Aktionen wie Blockieren, Verweigern, Verwerfen, Zulassen, Proxy oder Umleiten ausführen

Sobald Rule Engine eingeschaltet ist, ist Mod Security bereit, mit einigen der gängigen Angriffstypen zu schützen.

Schutz vor allgemeinen Angriffstypen

Jetzt ist der Webserver bereit, mit gängigen Angriffstypen wie XSS, SQL Injection, Protocol Violation usw. zu schützen, da wir Core Rule installiert und Rule Engine aktiviert haben. Lassen Sie uns einige davon testen.

XSS-Angriff

  • Öffnen Sie Firefox und greifen Sie auf Ihre Anwendung zu und fügen Sie das Tag <script> am Ende oder an der URL ein
  • Überwachen Sie die Datei modsec_audit.log im Ordner apache/logs

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

Directory-Traversal-Angriff: – Directory-Traversal-Angriffe können großen Schaden anrichten, indem sie diese Schwachstellen ausnutzen und auf systembezogene Dateien zugreifen. Bsp. – /etc/passwd, .htaccess usw.

  • Öffnen Sie Firefox und greifen Sie mit Directory Traversal auf Ihre Anwendung zu
  • Überwachen Sie die Datei modsec_audit.log im Ordner apache/logs
 http://localhost/?../.../boot
  • Sie werden feststellen, dass Mod Security die Anforderung blockiert, da sie Verzeichnisdurchquerung enthält.

Server-Banner ändern

An früherer Stelle in diesem Handbuch haben Sie gelernt, wie Sie den Apache- und Betriebssystemtyp entfernen, Versionshilfe der ServerTokens-Direktive.

Lassen Sie uns einen Schritt voraus gehen, wie wäre es, wenn Sie den Servernamen behalten, wie Sie möchten? Dies ist mit der SecServerSignature -Direktive in Mod Security möglich. Sie sehen, es ist interessant.

Hinweis: Um Mod Security zum Manipulieren von Server-Bannern aus einem Header zu verwenden, müssen Sie ServerTokesn in httpd.conf des Apache-Webservers auf Full setzen.

  • Fügen Sie die SecServerSignature-Direktive mit Ihrem gewünschten Servernamen in setup.conf hinzu und starten Sie Apache Web Server neu
 SecServerSignature YourServerName

Ex:

 [/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.

Zuhören konfigurieren

Wenn Sie mehrere Schnittstellen und IPs auf einem einzelnen Server haben, wird empfohlen, die Listen-Anweisung mit absoluter IP und Portnummer zu konfigurieren.

Wenn Sie die Apache-Konfiguration so belassen, dass alle IPs mit einer bestimmten Portnummer überwacht werden, kann dies zu Problemen bei der Weiterleitung von HTTP-Anforderungen an einen anderen Webserver führen. Dies ist in der gemeinsam genutzten Umgebung durchaus üblich.

  • Konfigurieren Sie die Listen-Direktive in httpd.conf mit absoluter IP und Port als unten gezeigtes Beispiel
 Listen 10.10.10.1:80

Zugriffsprotokollierung

Es ist wichtig, das Zugriffsprotokoll auf Ihrem Webserver richtig zu konfigurieren. Einige der wichtigen Parameter, die im Protokoll erfasst werden müssen, sind die Zeit, die zum Zustellen der Anforderung benötigt wird, sowie die Sitzungs-ID.

Standardmäßig ist Apache nicht zum Erfassen dieser Daten konfiguriert. Sie müssen sie wie folgt manuell konfigurieren.

  • Zur Erfassung der für die Bearbeitung der Anfrage benötigten Zeit und der SESSION-ID in einem Zugriffsprotokoll
  • Fügen Sie %T & %sessionID in httpd.conf unter der LogFormat-Direktive hinzu
 LogFormat "%h %l %u %t "%{sessionID}C" "%r" %>s %b %T" common

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

Deaktivieren Sie das Laden unerwünschter Module

Wenn Sie mit allen Modulen kompiliert und installiert haben, besteht eine hohe Wahrscheinlichkeit, dass Sie viele Module in Apache geladen haben, die möglicherweise nicht erforderlich sind.

Best Practice ist es, Apache mit den erforderlichen Modulen in Ihren Webanwendungen zu konfigurieren. Die folgenden Module haben Sicherheitsbedenken, und Sie könnten daran interessiert sein, sie in httpd.conf von Apache Web Server zu deaktivieren.

WebDAV (Web-based Distributed Authoring and Versioning) Dieses Modul ermöglicht es entfernten Clients, Dateien auf dem Server zu manipulieren und verschiedenen Denial-of-Service-Angriffen ausgesetzt zu sein. Um den folgenden Kommentar in httpd.conf zu deaktivieren

 #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 vertrauliche Informationen mit .htaccess preisgeben, sobald dieses Modul geladen ist. Um den folgenden Kommentar in httpd.conf zu deaktivieren

 #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 bewährten Methoden, mit denen Sie Ihren Apache-Webserver sichern können.

Überprüfen Sie diesen Link, wenn Sie eine benutzerdefinierte Fehlerseite in Apache implementieren möchten.

Wenn Sie neu bei Apache HTTP sind, würde ich empfehlen, den Apache HTTP-Administrationskurs zu belegen.