One place for hosting & domains

      FreeBSD

      Empfohlene Schritte zum Härten von Apache unter FreeBSD 12.0


      Der Autor wählte den Free and Open Source Fund, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      Die standardmäßige Installation eines Apache-HTTP-Servers ist zwar bereits sicher, seine Konfiguration kann jedoch mit einigen Änderungen erheblich verbessert werden. Sie können bereits vorhandene Sicherheitsmechanismen ergänzen, indem Sie z. B. Schutzmechanismen für Cookies und Header einrichten, damit Verbindungen auf der Client-Ebene des Benutzers nicht manipuliert werden können. Dadurch können Sie die Möglichkeiten mehrerer Angriffsmethoden wie Cross-Site Scripting (auch als XSS bezeichnet) drastisch reduzieren. Sie können auch andere Arten von Angriffen verhindern, wie z. B. Cross-Site Request Forgery, Session Hijacking und Denial-of-Service-Angriffe.

      In diesem Tutorial werden Sie einige empfohlene Schritte implementieren, um die Informationen zu reduzieren, die auf Ihrem Server verfügbar sind. Sie werden die Verzeichnislisten verifizieren und die Indizierung deaktivieren, um den Zugriff auf Ressourcen zu überprüfen. Außerdem ändern Sie den Standardwert der Anweisung timeout, um das Risiko von Angriffen wie Denial of Service zu verringern. Des Weiteren deaktivieren Sie die TRACE-Methode, damit Sitzungen nicht zurückverfolgt und gehackt werden können. Abschließend sichern Sie Header und Cookies.

      Die meisten Konfigurationseinstellungen werden auf die Hauptkonfigurationsdatei des Apache HTTP angewendet, die sich in /usr/local/etc/apache24/httpd.conf befindet.

      Voraussetzungen

      Bevor Sie diese Anleitung beginnen, benötigen Sie Folgendes:

      Mit diesen Voraussetzungen haben Sie ein FreeBSD-System mit einem Stack, der Webinhalt mit allem in PHP Geschriebenen, wie wesentliche CMS-Software, bereitstellen kann. Außerdem haben Sie sichere Verbindungen über Let’s Encrypt verschlüsselt.

      Reduzieren der Serverinformationen

      Das Betriebssystem-Banner ist eine Methode, die von Computern, Servern und Geräten aller Art zur Präsentation in Netzwerken verwendet wird. Bösartige Akteure können diese Informationen verwenden, um relevante Systeme anzugreifen. In diesem Abschnitt reduzieren Sie die Menge an Informationen, die von diesem Banner veröffentlicht werden.

      Anweisungssätze​​​ kontrollieren, wie diese Informationen angezeigt werden. Zu diesem Zweck ist die Anweisung ServerTokens wichtig: Sie zeigt standardmäßig dem Client, zu dem die Verbindung hergestellt wird, alle Details über das Betriebssystem sowie die kompilierte Module an.

      Sie verwenden ein Netzwerk-Scanning-Tool um zu prüfen, welche Informationen derzeit angezeigt werden, bevor Sie alle Änderungen vornehmen. Um nmap zu installieren, führen Sie den folgenden Befehl aus:

      Um die IP-Adresse Ihres Servers zu erhalten, können Sie den folgenden Befehl ausführen:

      • ifconfig vtnet0 | awk '/inet / {print $2}'

      Sie können die Antwort des Webservers mit dem folgenden Befehl überprüfen:

      • nmap -sV -p 80 your-server-ip

      Rufen Sie zum Ausführen eines Scans nmap auf (folglich das Flag -s), um die Version (das Flag -V) auf Port 80 (das Flag -p) auf der gegebenen IP oder Domäne anzuzeigen.

      Sie erhalten Informationen über Ihren Webserver, ähnlich wie die folgenden:

      Output

      Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:30 CET Nmap scan report for 206.189.123.232 Host is up (0.054s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.41 ((FreeBSD) OpenSSL/1.1.1d-freebsd Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

      Diese Ausgabe zeigt, dass Informationen wie das Betriebssystem, die Apache-HTTP-Version und OpenSSL sichtbar sind. Damit können Angreifer Informationen über den Server erhalten (zum Beispiel ein Sicherheitsrisiko in der Software, die auf dem Server ausgeführt wird) und die richtigen Tools für den Angriff auswählen.

      Platzieren Sie die Anweisung ServerTokens in die Hauptkonfigurationsdatei, da sie nicht standardmäßig konfiguriert ist. Weil diese Konfiguration fehlt, zeigt Apache HTTP die vollständigen Informationen über den Server als Dokumentationszustand an. Um die Informationen zu begrenzen, die über Ihren Server und Ihre Konfiguration preisgegeben werden, platzieren Sie die Anweisung ServerTokens in die Hauptkonfigurationsdatei.

      Platzieren Sie diese Anweisung nach der ServerName-Eingabe in die Konfigurationsdatei. Führen Sie den folgenden Befehl aus, um die Anweisung zu suchen:

      • grep -n 'ServerName' /usr/local/etc/apache24/httpd.conf

      Danach können Sie die Zeilennummer mit vi suchen:

      Output

      226 #ServerName www.example.com:80

      Führen Sie den folgenden Befehl aus:

      • sudo vi +226 /usr/local/etc/apache24/httpd.conf

      Fügen Sie die folgende hervorgehobene Zeile hinzu:

      /usr/local/etc/apache24/httpd.conf

      . . .
      #ServerName www.example.com:80
      ServerTokens Prod
      

      Speichern und schließen Sie die Datei mit :wq und der EINGABETASTE.

      Durch die Einstellung der Anweisung ServerTokens auf Prod wird lediglich angezeigt, dass dies ein Apache-Webserver ist.

      Damit dies in Kraft tritt, starten Sie den Apache-HTTP-Server neu:

      Um die Änderungen zu testen, führen Sie den folgenden Befehl aus:

      • nmap -sV -p 80 your-server-ip

      Sie sehen eine ähnliche Ausgabe wie die folgende, mit weniger Informationen über Ihren Apache-Webserver:

      Output

      Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:58 CET Nmap scan report for WPressBSD (206.189.123.232) Host is up (0.056s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

      Sie haben gesehen, welche Informationen der Server vor der Änderung preisgegeben hat, und Sie haben dies nun auf ein Minimum reduziert. Dadurch geben Sie einem externen Akteur weniger Hinweise über Ihren Server. Im nächsten Schritt verwalten Sie die Verzeichnislisten für Ihren Webserver.

      Verwalten von Verzeichnislisten

      In diesem Schritt stellen Sie sicher, dass die Verzeichnisliste korrekt konfiguriert ist, damit die gewünschten Informationen über das System öffentlich verfügbar und die übrigen geschützt sind.

      Anmerkung: Wenn ein Argument deklariert ist, ist es aktiv, aber das + kann visuell untermauern, dass es tatsächlich aktiviert ist. Wenn ein Minuszeichen - eingegeben wird, wird das Argument verweigert, z. B. Options -Indexes.

      Argumente mit + und/oder - können nicht kombiniert werden – dies wird als schlechte Syntax in Apache HTTP erachtet und könnte beim Starten verweigert werden.

      Durch Hinzufügen der Anweisung Options -Indexes wird der Inhalt im Datenpfad /usr/local/www/apache24/data so eingestellt, dass (read listed) nicht automatisch indiziert wird, wenn keine .html-Datei vorhanden ist, sowie nicht gezeigt wird, wenn eine URL diesem Verzeichnis zugeordnet ist. Dies gilt auch bei der Verwendung von virtuellen Host-Konfigurationen wie z. B. jener, die für das Tutorial über Voraussetzungen für das Let’s-Encrypt-Zertifikat verwendet werden.

      Sie richten die Anweisung Options mit dem Argument -Indexes und der Anweisung +FollowSymLinks ein, wodurch symbolische Links besucht werden können. Sie verwenden das Symbol +, um die Konventionen von Apache HTTP zu befolgen.

      Führen Sie den folgenden Befehl aus, um die Zeile zu suchen, die in der Konfigurationsdatei bearbeitet werden soll:

      • grep -n 'Options Indexes FollowSymLinks' /usr/local/etc/apache24/httpd.conf

      Sie werden eine Ausgabe ähnlich der folgenden sehen:

      Output

      263 : Options Indexes FollowSymLinks

      Führen Sie diesen Befehl aus, um direkt auf die Zeile zur Bearbeitung zuzugreifen:

      • sudo vi +263 /usr/local/etc/apache24/httpd.conf

      Bearbeiten Sie nun die Zeile gemäß der Konfiguration:

      /usr/local/etc/apache24/httpd.conf

      . . .
      #
      Options -Indexes +FollowSymLinks
      
      #
      . . .
      

      Speichern und schließen Sie die Datei mit :wq und der EINGABETASTE.

      Starten Sie Apache HTTP zur Implementierung dieser Änderungen neu:

      Auf Ihrer Domäne im Browser sehen Sie eine „Zugriff verboten“-Nachricht, auch als Fehler 403 bekannt. Grund dafür sind Ihre Änderungen. Durch die Eingabe von -Indexes in die Anweisung Options wurde die Funktion Auto-Index von Apache HTTP deaktiviert und daher gibt es im Datenpfad keine index.html-Datei.

      Das können Sie lösen, indem Sie eine index.html-Datei im VirtualHost ablegen, den Sie im Tutorial​​​ über Voraussetzungen für das Let’s-Encrypt-Zertifikat aktiviert haben. Verwenden Sie den Standardblock innerhalb von Apache HTTP und legen Sie ihn im gleichen Ordner wie die DocumentRoot ab, die Sie im virtuellen Host deklariert haben.

      /usr/local/etc/apache24/extra/httpd-vhosts.conf

      <VirtualHost *:80>
          ServerAdmin your_email@your_domain.com
          DocumentRoot "/usr/local/www/apache24/data/your_domain.com"
          ServerName your_domain.com
          ServerAlias www.your_domain.com
          ErrorLog "/var/log/your_domain.com-error_log"
          CustomLog "/var/log/your_domain.com-access_log" common
      </VirtualHost>
      

      Verwenden Sie hierzu den folgenden Befehl:

      • sudo cp /usr/local/www/apache24/data/index.html /usr/local/www/apache24/data/your_domain.com/index.html

      Jetzt sehen Sie die Nachricht It works! beim Besuch Ihrer Domäne.

      In diesem Abschnitt haben Sie der Anweisung Indexes Beschränkungen hinzugefügt, um nicht automatisch unbeabsichtigten Inhalt einzutragen und anzuzeigen. Wenn nun keine index.html-Datei im Datenpfad ist, erstellt Apache HTTP nicht automatisch ein Verzeichnis des Inhalts. Im nächsten Schritt gehen Sie über das Verbergen von Informationen hinaus und passen verschiedene Anweisungen an.

      Den Wert der Timeout-Anweisung verringern

      Die Anweisung Timeout legt das Limit für die Zeit fest, die Apache HTTP auf eine neue Eingabe/Ausgabe wartet, bevor die Verbindungsanforderung fehlschlägt. Dieser Fehler kann aufgrund von verschiedenen Umständen auftreten, wie z. B. Pakete, die nicht beim Server ankommen, oder Daten, die vom Client nicht als empfangen bestätigt werden.

      Standardmäßig ist das Zeitlimit auf 60 Sekunden eingestellt. In Umgebungen, in denen das Internet langsam ist, kann dieser Standardwert sinnvoll sein. Eine Minute ist jedoch ziemlich lange, insbesondere dann, wenn der Server Benutzer mit schnellerem Internet abdeckt. Außerdem kann die Zeit, in der der Server die Verbindung nicht schließt, für Denial-of-Service-Angriffe (DoS) ausgenützt werden. Wenn es zu einer Vielzahl dieser schädlichen Verbindungen kommt, gerät der Server ins Stolpern und könnte gesättigt werden und nicht mehr reagieren.

      Um den Wert zu ändern, finden Sie die Timeout-Einträge in der Datei httpd-default.conf:

      • grep -n 'Timeout' /usr/local/etc/apache24/extra/httpd-default.conf

      Sie sehen eine ähnliche Ausgabe wie die folgende:

      Output

      8 # Timeout: The number of seconds before receives and sends time out. 10 Timeout 60 26 # KeepAliveTimeout: Number of seconds to wait for the next request from the 29 KeepAliveTimeout 5 89 RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

      In der Ausgabezeile legt 10 den Wert der Timeout-Anweisung fest. Um direkt auf diese Zeile zuzugreifen, führen Sie den folgenden Befehl aus:

      • sudo vi +10 /usr/local/etc/apache24/extra/httpd-default.conf

      Stellen Sie ihn zum Beispiel auf 30 Sekunden ein, wie nachfolgend gezeigt:

      /usr/local/etc/apache24/extra/httpd-default.conf

      #
      # Timeout: The number of seconds before receives and sends time out.
      #
      Timeout 30
      

      Speichern und schließen Sie die Datei mit :wq und der EINGABETASTE.

      Der Wert der Anweisung Timeout muss groß genug sein, damit eine legitime und erfolgreiche Verbindung hergestellt werden kann, und klein genug, um unerwünschte Verbindungsversuche zu verhindern.

      Anmerkung: Denial-of-Service-Angriffe können die Ressourcen des Servers ziemlich effektiv erschöpfen. Eine komplementäre und sehr fähige Gegenmaßnahme ist die Verwendung eines Threaded MPM, um für die Verbindungen und Prozesse von Apache HTTP die beste Leistung zu erzielen. Im Tutorial So konfigurieren Sie Apache HTTP mit MPM Event und PHP-FPM unter FreeBSD 12.0 finden Sie Schritte zur Aktivierung dieser Fähigkeit.

      Damit diese Änderung in Kraft tritt, starten Sie den Apache-HTTP-Server neu:

      Sie haben den Standardwert der Timeout-Anweisung geändert, um das Risiko von DoS-Angriffen teilweise zu reduzieren.

      Deaktivieren der TRACE-Methode

      Das Hypertext-Übertragungsprotokoll wurde nach einem Client-Server-Modell entwickelt und als solches hat das Protokoll Anforderungsmethoden, um Informationen vom Server abzurufen oder im Server abzulegen. Der Server muss diese Methodensätze und die Interaktion zwischen ihnen verstehen. In diesem Schritt konfigurieren Sie die mindestens erforderlichen Methoden.

      Die Methode TRACE, die als harmlos angesehen wurde, wurde für die Durchführung von Cross-Site-Tracing-Angriffen genutzt. Diese Art von Angriffen ermöglicht bösartigen Akteuren, Benutzersitzungen mithilfe dieser Methode zu stehlen. Die Methode wurde zum Zwecke des Debugging konzipiert, wobei der Server die gleiche Anfrage zurückgibt, die ursprünglich vom Client gesendet wurde. Da das Cookie aus der Sitzung des Browsers an den Server gesendet wird, wird es erneut zurückgesendet. Das könnte jedoch eventuell von einem bösartigen Akteur abgefangen werden, der dann die Verbindung eines Browsers zu einer Website umleiten kann, über die er die Kontrolle hat, anstatt zum ursprünglichen Server.

      Aufgrund des potenziellen Missbrauchs der TRACE-Methode wird empfohlen, sie nur für das Debugging und nicht in einer Produktivumgebung zu verwenden. In diesem Abschnitt deaktivieren Sie diese Methode.

      Bearbeiten Sie die Datei httpd.conf mit dem folgenden Befehl und drücken Sie dann G, um das Ende der Datei zu erreichen:

      • sudo vi /usr/local/etc/apache24/httpd.conf

      Fügen Sie am Ende der Datei folgenden Einstiegspfad hinzu:

      /usr/local/etc/apache24/httpd.conf

      . . .
      TraceEnable off
      

      Eine bewährte Vorgehensweise ist die Angabe der Methoden, die Sie auf Ihrem Apache-HTTP-Webserver verwenden. Dadurch werden potenzielle Einstiegspunkte für bösartige Akteure begrenzt.

      LimitExcept kann für diesen Zweck nützlich sein, da es keine anderen Methoden zulässt als die in ihm deklarierten. So kann beispielsweise eine Konfiguration wie diese erstellt werden:

      /usr/local/etc/apache24/httpd.conf

      DocumentRoot "/usr/local/www/apache24/data"
      <Directory "/usr/local/www/apache24/data">
          Options -Indexes +FollowSymLinks -Includes
          AllowOverride none
           <LimitExcept GET POST HEAD>
             deny from all
          </LimitExcept>
          Require all granted
      </Directory>
      

      Wie in der Anweisung LimitExcept deklariert, sind nur die Methoden GET, POST und HEAD in der Konfiguration erlaubt.

      • Die GET-Methode ist Teil des HTTP-Protokolls und dient zum Abrufen von Daten.
      • Die POST-Methode ist auch Teil des HTTP-Protokolls und dient dazu, Daten an den Server zu senden.
      • Die HEAD-Methode ist ähnlich wie GET, hat jedoch keinen Antworttext.

      Verwenden Sie den folgenden Befehl und legen Sie den LimitExcept-Block in der Datei ab:

      • sudo vi +272 /usr/local/etc/apache24/httpd.conf

      Um diese Konfiguration einzustellen, legen Sie den folgenden Block im Anweisungseintrag DocumentRoot ab, aus dem der Inhalt gelesen wird, genauer gesagt im Eintrag des Verzeichnisses:

      /usr/local/etc/apache24/httpd.conf

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

      Starten Sie Apache HTTP neu, damit die Änderungen übernommen werden:

      Die neuere Anweisung AllowedMethods​​​ hat eine ähnliche Funktionalität, ihr Status ist jedoch noch experimentell.

      Sie kennen nun HTTP-Methoden, ihre Verwendung und den Schutz, den sie vor bösartigen Aktivitäten mithilfe der TRACE-Methode bieten. Des Weiteren wissen Sie, wie man deklariert, welche Methoden verwendet werden sollen. Als Nächstes arbeiten Sie mit weiteren Schutzmaßnahmen für HTTP-Header und Cookies.

      In diesem Schritt richten Sie spezifische Anweisungen ein, um die Sitzungen zu schützen, die die Client-Rechner beim Besuch Ihres Apache-HTTP-Webservers öffnen. So lädt Ihr Server keinen unerwünschten Inhalt, die Verschlüsselung wird nicht heruntergeladen und Sie vermeiden Content Sniffing.

      Header sind Bestandteile der Anforderungsmethoden. Es gibt Header zum Anpassen der Authentifizierung, für die Kommunikation zwischen Server und Client, Zwischenspeicherung, Inhaltsaushandlung usw.

      Cookies sind Informationen, die vom Server an den Browser gesendet werden. Diese Informationen ermöglichen es dem Server, den Client-Browser von unterschiedlichen Computern zu unterscheiden. Außerdem ermöglichen sie Servern, Benutzersitzungen zu erkennen. Sie können beispielsweise den Einkaufswagen eines angemeldeten Benutzers, Zahlungsinformationen, den Verlauf etc. verfolgen. Cookies werden im Webbrowser des Clients verwendet und gespeichert, da HTTP ein zustandsloses Protokoll ist. Das bedeutet, sobald die Verbindung geschlossen wird, erinnert sich der Server nicht mehr an die Anfragen der einzelnen Clients.

      Es ist wichtig, sowohl Header als auch Cookies zu schützen, da sie eine Kommunikation zwischen Webbrowser-Client und Webserver bereitstellen.

      Das Modul Header ist standardmäßig aktiviert. Überprüfen Sie mit dem folgenden Befehl, ob es geladen wurde:

      • sudo apachectl -M | grep 'headers'

      Sie sehen die folgende Ausgabe:

      Output

      headers_module (shared)

      Wenn Sie keine Ausgabe sehen, überprüfen Sie, ob das Modul in der Apache-Datei httpd.conf aktiviert ist:

      • grep -n 'mod_headers' /usr/local/etc/apache24/httpd.conf

      Als Ausgabe sehen Sie eine unkommentierte Zeile, die auf das spezifische Modul für Header verweist:

      /usr/local/etc/apache24/httpd.conf

      . . .
      122  LoadModule headers_module libexec/apache24/mod_headers.so
      . . .
      

      Entfernen Sie den Hashtag am Anfang der Zeile mod_headers.so, falls vorhanden, um die Anweisung zu aktivieren.

      Durch die Verwendung der folgenden Apache-HTTP-Anweisungen schützen Sie Header und Cookies vor bösartigen Aktivitäten, um das Risiko für Clients und Server zu verringern.

      Jetzt richten Sie den Schutz des Headers ein. Legen Sie all diese Header-Werte in einen Block ab. Sie können diese Werte nach eigenem Ermessen anwenden, es werden jedoch alle empfohlen.

      Bearbeiten Sie die Datei httpd.conf mit dem folgenden Befehl und drücken Sie dann G, um das Ende der Datei zu erreichen:

      • sudo vi /usr/local/etc/apache24/httpd.conf

      Legen Sie den folgenden Block am Ende der Datei ab:

      /usr/local/etc/apache24/httpd.conf

      . . .
      <IfModule mod_headers.c>
        # Add security and privacy related headers
        Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;"
        Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
        Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure"
        Header set X-Content-Type-Options "nosniff"
        Header set X-XSS-Protection "1; mode=block"
        Header set Referrer-Policy "strict-origin"
        Header set X-Frame-Options: "deny"
        SetEnv modHeadersAvailable true
      </IfModule>
      
      • Header Strict-Transport-Security "max-age​​, includeSubDomains": HTTP Strict Transport Security (HTSTS) ist ein Mechanismus für Webserver und Clients (hauptsächlich Browser) zur Einrichtung von Kommunikationen mit ausschließlich HTTPS. Durch die Implementierung vermeiden Sie Man-in-the-middle-Angriffe, bei denen ein Dritter in der Kommunikation potenziell auf Informationen zugreifen und diese manipulieren kann.

      • Header always edit Set-Cookie (. *) "$1; HttpOnly; Secure": Die Flags HttpOnly and Secure auf den Headern verringern das Risiko von Cross-Site-Scripting-Angriffen (XSS). Cookies können von Angreifern missbraucht werden, um sich als legitime Besucher bzw. als eine andere Person auszugeben (Identitätsdiebstahl), oder sie können manipuliert werden.

      • Header set Referrer-Policy "strict-origin​​": Der Header Referrer-Policy legt fest, welche Informationen im Header-Feld als Verweiser-Information enthalten sind.

      • Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;": Der Content-Security-Policy header (CSP) verhindert, dass Inhalt geladen wird, der in den Parametern nicht angegeben ist. Das ist hilfreich, um Cross-Site-Scripting-Angriffe (XSS) zu verhindern. Es gibt viele Parameter für die Konfiguration der Richtlinie dieses Headers. Entscheidend ist die Konfiguration zum Laden von Inhalt derselben Site und das Aktualisieren jedes Inhalts mit HTTP-Ursprung.

      • Header set X-XSS-Protection "1; mode=block": Dies unterstützt ältere Browser, die mit Content-Security-Policy nicht fertig werden. Der Header ‘X-XSS-Protection’ bietet Schutz vor Cross-Site-Scripting-Angriffen. Sie müssen diesen Header nicht einrichten, außer Sie müssen alte Browser-Versionen unterstützen, was selten ist.

      • Header set X-Frame-Options: "deny": Das verhindert clickjacking-Angriffe. Der Header ‘X-Frame-Options’ teilt einen Browser mit, wenn eine Seite in ein <frame>, <iframe>, <embed> oder <object> gerendert werden kann. So kann Inhalt von Sites nicht in andere eingebettet werden, wodurch Clickjacking-Angriffe verhindert werden. Hier verweigern Sie jegliches Frame-Rendering, damit die Webseite nicht irgendwo anders eingebettet werden kann, nicht einmal innerhalb derselben Website. Sie können dies Ihren Bedürfnissen anpassen, wenn Sie z. B. das Rendering bestimmter Seiten autorisieren müssen, da es sich um Anzeigen oder Kooperationen mit spezifischen Websites handelt.

      • Header set X-Content-Type-Options "nosniff": Der Header ‘X-Content-Type-Options’ steuert MIME types, damit sie nicht geändert und gefolgt werden können. MIME types sind Dateiformat-Standards: Sie funktionieren mit Text, Audio, Video, Image usw. Dieser Header hält bösartige Akteure von Content Sniffing der Dateien ab sowie vor dem Versuch, Dateitypen zu ändern.

      Starten Sie Apache neu, damit die Änderungen wirksam werden:

      Um die Sicherheitsebenen Ihrer Konfigurationseinstellungen zu überprüfen, besuchen Sie die Website Security Headers. Nach Ausführung der Schritte in diesem Tutorial wird Ihre Domäne die Note A erhalten.

      Anmerkung: Wenn Sie Ihre Header auf https://securityheaders.com/ überprüfen und ein F erhalten, könnte das daran liegen, dass in der DocumentRoot Ihrer Website kein index.html ist, wie am Ende von Schritt 2 beschrieben. Wenn Sie Ihre Header überprüfen und eine andere Note als A oder F erhalten, prüfen Sie jede Header set-Zeile auf Tippfehler, die zu der Herabstufung geführt haben könnten.

      In diesem Schritt haben Sie mit bis zu sieben Einstellungen gearbeitet, um die Sicherheit Ihrer Header und Cookies zu verbessern. Dadurch wird das Risiko von Cross-Site-Scripting, Clickjacking und anderen Arten von Angriffen verhindert.

      Zusammenfassung

      In diesem Tutorial haben Sie sich mit verschiedenen Sicherheitsaspekten befasst, wie der Preisgabe von Informationen, dem Schutz von Sitzungen sowie mit alternativen Konfigurationseinstellungen für wichtige Funktionen.

      Weitere Ressourcen zum Härten von Apache finden Sie hier:

      Weitere Tools zum Schutz von Apache HTTP:



      Source link

      Étapes recommandées pour renforcer Apache HTTP sous FreeBSD 12.0


      L’auteur a choisi le Free and Open Source Fund comme récipiendaire d’une donation dans le cadre du programme Write for Donations.

      Introduction

      Bien que l’installation par défaut d’un serveur Apache HTTP soit déjà sûre, sa configuration peut être considérablement améliorée grâce à quelques modifications. Vous pouvez compléter les mécanismes de sécurité déjà existants, par exemple en mettant en place des protections autour des cookies et des en-têtes, afin que les connexions ne puissent pas être altérées au niveau du client de l’utilisateur. Ce faisant, vous pouvez considérablement réduire les possibilités de plusieurs méthodes d’attaque, comme les attaques de type “Cross-Site Scripting” (également connues sous le nom de XSS). Vous pouvez également éviter d’autres types d’attaques, telles que la falsification de requête inter-sites, ou le détournement de session, ainsi que les attaques par déni de service.

      Dans ce tutoriel, vous allez implémenter certaines mesures recommandées pour réduire la quantité d’informations exposées sur votre serveur. Vous vérifierez la liste des répertoires et désactiverez l’indexation pour vérifier l’accès aux ressources. Vous modifierez également la valeur par défaut de la directive sur le délai d'attente afin d’atténuer les attaques de type déni de service. En outre, vous désactiverez la méthode TRACE afin que les sessions ne puissent pas être inversées et détournées. Enfin, vous sécuriserez les en-têtes et les cookies.

      La plupart des paramètres de configuration seront appliqués au fichier de configuration principal d’Apache HTTP qui se trouve dans /usr/local/etc/apache24/httpd.conf.

      Conditions préalables

      Avant de commencer ce guide, vous aurez besoin des éléments suivants :

      Une fois ces conditions préalables réunies, vous disposez d’un système FreeBSD avec une pile capable de servir du contenu web en utilisant tout ce qui est écrit en PHP, comme les principaux logiciels de gestion de contenu (CMS). De plus, vous avez chiffré des connexions sécurisées grâce à Let’s Encrypt.

      Réduire les informations sur le serveur

      La bannière de système d’exploitation est une méthode utilisée par les ordinateurs, les serveurs et les dispositifs de toutes sortes pour se présenter sur les réseaux. Des personnes malveillantes peuvent utiliser ces informations pour exploiter les systèmes concernés. Dans cette section, vous réduirez la quantité d’informations publiées par cette bannière.

      Des ensembles de directives contrôlent la manière dont ces informations sont affichées. À cet effet, la directive ServerTokens est importante ; par défaut, elle affiche au client qui s’y connecte tous les détails sur le système d’exploitation et les modules compilés.

      Vous utiliserez un outil de balayage du réseau pour vérifier quelles informations sont actuellement révélées avant d’appliquer tout changement. Pour installer nmap, exécutez la commande suivante :

      Pour obtenir l’adresse IP de votre serveur, vous pouvez exécuter la commande suivante :

      • ifconfig vtnet0 | awk '/inet / {print $2}'

      Vous pouvez vérifier la réponse du serveur web en utilisant la commande suivante :

      • nmap -sV -p 80 your-server-ip

      Vous appelez nmap pour effectuer un scan (d’où le drapeau -s), pour afficher la version (le drapeau -V) sur le port 80 (le drapeau -p) sur l’IP ou le domaine donné.

      Vous recevrez des informations sur votre serveur web, semblables à celles qui suivent :

      Output

      Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:30 CET Nmap scan report for 206.189.123.232 Host is up (0.054s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.41 ((FreeBSD) OpenSSL/1.1.1d-freebsd Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

      Cette sortie montre que des informations telles que le système d’exploitation, la version d’Apache HTTP et OpenSSL sont visibles. Cela peut être utile aux attaquants pour obtenir des informations sur le serveur et choisir les bons outils à exploiter, par exemple, une vulnérabilité dans le logiciel fonctionnant sur le serveur.

      Vous placerez la directive ServerTokens dans le fichier de configuration principal puisqu’elle n’est pas configurée par défaut. L’absence de cette configuration fait qu’Apache HTTP affiche les informations complètes sur le serveur, comme l’indique la documentation. Pour limiter les informations qui sont révélées sur votre serveur et votre configuration, vous placerez la directive ServerTokens dans le fichier de configuration principal.

      Vous placerez cette directive à la suite de l’entrée ServerName dans le fichier de configuration. Exécutez la commande suivante pour trouver la directive :

      • grep -n 'ServerName' /usr/local/etc/apache24/httpd.conf

      Vous trouverez le numéro de ligne que vous pouvez ensuite rechercher avec vi :

      Output

      226 #ServerName www.example.com:80

      Exécutez la commande suivante :

      • sudo vi +226 /usr/local/etc/apache24/httpd.conf

      Ajoutez la ligne surlignée suivante :

      /usr/local/etc/apache24/httpd.conf

      . . .
      #ServerName www.example.com:80
      ServerTokens Prod
      

      Enregistrez et quittez le fichier avec :wq et ENTER.

      En réglant la directive ServerTokens sur Prod, on affichera uniquement qu’il s’agit d’un serveur web Apache.

      Pour que cela prenne effet, redémarrez le serveur Apache HTTP :

      Pour tester les changements, exécutez la commande suivante :

      • nmap -sV -p 80 your-server-ip

      Vous obtiendrez un résultat similaire à celui qui suit, avec un minimum d’informations sur votre serveur web Apache :

      Output

      Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:58 CET Nmap scan report for WPressBSD (206.189.123.232) Host is up (0.056s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

      Vous avez vu quelles informations le serveur annonçait avant la modification et vous avez maintenant réduit celles-ci au minimum. De ce fait, vous fournissez moins d’indices sur votre serveur à un acteur externe. Au cours de l’étape suivante, vous gérerez les listes du répertoire pour votre serveur web.

      Gestion des listes du répertoire

      Au cours de cette étape, vous vous assurerez que les listes du répertoire sont correctement configurées, de sorte que les bonnes parties du système soient accessibles au public comme prévu, tandis que les autres sont protégées.

      Remarque : lorsqu’un argument est déclaré, il est actif, mais le + peut le renforcer visuellement, il est en fait activé. Lorsqu’un signe moins - est placé, l’argument est refusé, par exemple, Options -Indexes.

      Les arguments avec + et/ou - ne peuvent pas être mélangés, cela est considéré comme une mauvaise syntaxe dans Apache HTTP et peut être rejeté au démarrage.

      L’ajout de l’énoncé Options -Indexes permet de définir le contenu du chemin de données /usr/local/www/apache24/data pour qu’il ne soit pas indexé (read listed) automatiquement si un fichier .html n’existe pas, et qu’il n’indique pas si une URL correspond à ce répertoire. Cela s’appliquera également lors de l’utilisation de configurations d’hôtes virtuels telles que celui utilisé pour le tutoriel préalable au certificat Let’s Encrypt.

      Vous définirez la directive Options avec l’argument -Indexes et avec la directive +FollowSymLinks, qui permettra de suivre des liens symboliques. Vous utiliserez le symbole + afin de respecter les conventions HTTP d’Apache.

      Exécutez la commande suivante pour trouver la ligne à modifier dans le fichier de configuration :

      • grep -n 'Options Indexes FollowSymLinks' /usr/local/etc/apache24/httpd.conf

      Vous verrez une sortie similaire à ce qui suit :

      Output

      263 : Options Indexes FollowSymLinks

      Exécutez cette commande pour accéder directement à la ligne que vous souhaitez modifier :

      • sudo vi +263 /usr/local/etc/apache24/httpd.conf

      Modifiez maintenant la ligne conformément à la configuration :

      /usr/local/etc/apache24/httpd.conf

      . . .
      #
      Options -Indexes +FollowSymLinks
      
      #
      . . .
      

      Enregistrez et quittez le fichier avec :wq et ENTER.

      Redémarrez Apache HTTP pour implémenter ces modifications :

      Au niveau de votre domaine dans le navigateur, vous verrez un message d’accès interdit, également connu sous le nom d’erreur 403. Cela est dû aux changements que vous avez appliqués. Le placement de -Indexes dans la directive Options a désactivé la capacité d’auto-indexation d’Apache HTTP et il n’y a donc pas de fichier index.html dans le chemin des données.

      Vous pouvez résoudre ce problème en plaçant un fichier index.html à l’intérieur du VirtualHost que vous avez activé dans le tutoriel préalable au certificat Let’s Encrypt. Vous utiliserez le bloc par défaut dans Apache HTTP et le placerez dans le même dossier que le DocumentRoot que vous avez déclaré dans l’hôte virtuel.

      /usr/local/etc/apache24/extra/httpd-vhosts.conf

      <VirtualHost *:80>
          ServerAdmin your_email@your_domain.com
          DocumentRoot "/usr/local/www/apache24/data/your_domain.com"
          ServerName your_domain.com
          ServerAlias www.your_domain.com
          ErrorLog "/var/log/your_domain.com-error_log"
          CustomLog "/var/log/your_domain.com-access_log" common
      </VirtualHost>
      

      Utilisez la commande suivante pour ce faire :

      • sudo cp /usr/local/www/apache24/data/index.html /usr/local/www/apache24/data/your_domain.com/index.html

      Vous verrez maintenant un message Ça marche ! lorsque vous visiterez votre domaine.

      Dans cette section, vous avez imposé des restrictions à la directive Indexes afin de ne pas inclure et afficher automatiquement un contenu autre que celui que vous avez prévu. Désormais, s’il n’existe pas de fichier index.html dans le chemin de données, Apache HTTP ne créera pas automatiquement un index du contenu. Dans la prochaine étape, vous irez au-delà de l’obscurcissement des informations et vous adapterez différentes directives.

      Réduire la valeur de la directive sur le délai d’attente

      La directive Timeout fixe la limite du délai pendant lequel Apache HTTP attendra une nouvelle entrée/sortie avant l’échec de la demande de connexion. Cette échec peut être du à différentes circonstances telles que des paquets n’arrivant pas au serveur ou des données n’étant pas confirmées comme ayant été reçues par le client.

      Par défaut, le délai d’attente est fixé à 60 secondes. Dans les environnements où le service Internet est lent, cette valeur par défaut peut être raisonnable, mais une minute est une durée assez longue, en particulier si le serveur couvre une cible d’utilisateurs avec un service Internet plus rapide. En outre, la période pendant laquelle le serveur ne ferme pas la connexion peut être utilisée abusivement pour effectuer des attaques par déni de service (DoS). Si une invasion de ces connexions malveillantes se produit, le serveur faiblira et s’exposera à des risques de saturation et d’incapacité à répondre.

      Pour modifier la valeur, vous trouverez les entrées Timeout dans le fichier httpd-default.conf :

      • grep -n 'Timeout' /usr/local/etc/apache24/extra/httpd-default.conf

      Vous verrez une sortie similaire à :

      Output

      8 # Timeout: The number of seconds before receives and sends time out. 10 Timeout 60 26 # KeepAliveTimeout: Number of seconds to wait for the next request from the 29 KeepAliveTimeout 5 89 RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

      Dans la ligne de sortie, 10 définit la valeur de la directive Timeout. Pour accéder directement à cette ligne, exécutez la commande suivante :

      • sudo vi +10 /usr/local/etc/apache24/extra/httpd-default.conf

      Vous la modifierez pour la régler sur 30 secondes, par exemple, comme suit :

      /usr/local/etc/apache24/extra/httpd-default.conf

      #
      # Timeout: The number of seconds before receives and sends time out.
      #
      Timeout 30
      

      Enregistrez et quittez le fichier avec :wq et ENTER.

      La valeur de la directive Timeout doit trouver un équilibre entre une période suffisamment longue pour que ces événements permettent une connexion légitime et réussie, et suffisamment courte pour empêcher des tentatives de connexion non souhaitées.

      Remarque : les attaques par déni de service peuvent drainer les ressources du serveur de manière assez efficace. Utiliser un MPM threadé pour obtenir les meilleures performances de la manière dont Apache HTTP gère les connexions et les processus constitue une contre-mesure complémentaire et très efficace. Dans ce tutoriel Comment configurer Apache HTTP avec l’événement MPM et PHP-FPM sous FreeBSD 12.0, il y a des étapes pour activer cette fonctionnalité.

      Pour que cette modification prenne effet, redémarrez le serveur Apache HTTP :

      Vous avez modifié la valeur par défaut de la directive Timeout afin d’atténuer partiellement les attaques par déni de service.

      Désactiver la méthode TRACE

      Le Hypertext Transport Protocol a été développé selon un modèle client-serveur et, à ce titre, le protocole dispose de méthodes de requête pour récupérer ou placer des informations depuis/vers le serveur. Le serveur doit comprendre ces ensembles de méthodes et l’interaction entre elles. Dans cette étape, vous configurerez les méthodes minimales nécessaires.

      La méthode TRACE, considérée comme inoffensive, a été utilisée pour réaliser des attaques de type Cross Site Tracing. Ces types d’attaques permettent à des acteurs malveillants de voler des sessions d’utilisateurs grâce à cette méthode. La méthode a été conçue à des fins de débogage. Le serveur renvoie la même requête que celle envoyée à l’origine par le client. Comme le cookie de la session du navigateur est envoyé au serveur, il sera renvoyé à nouveau. Cependant, cela peut potentiellement être intercepté par un acteur malveillant, qui peut alors rediriger la connexion d’un navigateur vers un site sous son contrôle et non vers le serveur d’origine.

      En raison de la possibilité d’une utilisation abusive de la méthode TRACE, il est recommandé de ne l’utiliser que pour le débogage et non en production. Dans cette section, vous désactiverez cette méthode.

      Modifiez le fichier httpd.conf avec la commande suivante, puis appuyez sur G pour atteindre la fin du fichier :

      • sudo vi /usr/local/etc/apache24/httpd.conf

      Ajoutez le chemin d’entrée suivant à la fin du fichier :

      /usr/local/etc/apache24/httpd.conf

      . . .
      TraceEnable off
      

      Une bonne pratique consiste à spécifier uniquement les méthodes que vous utiliserez dans votre serveur web Apache HTTP. Cela permettra de limiter les points d’entrée potentiels pour les acteurs malveillants.

      LimitExcept peut être utile à cette fin, car il n’autorise aucune autre méthode que celles qui y sont déclarées. Par exemple, une configuration peut être établie comme celle-ci :

      /usr/local/etc/apache24/httpd.conf

      DocumentRoot "/usr/local/www/apache24/data"
      <Directory "/usr/local/www/apache24/data">
          Options -Indexes +FollowSymLinks -Includes
          AllowOverride none
           <LimitExcept GET POST HEAD>
             deny from all
          </LimitExcept>
          Require all granted
      </Directory>
      

      Comme indiqué dans la directive LimitExcept, seules les méthodes GET, POST et HEAD sont autorisées dans la configuration.

      • La méthode GET fait partie du protocole HTTP et elle est utilisée pour récupérer des données.
      • La méthode POST fait également partie du protocole HTTP et est utilisée pour envoyer des données au serveur.
      • La méthode HEAD est similaire à la méthode GET, mais elle n’a pas d’organe de réponse.

      Vous utiliserez la commande suivante et placerez le bloc LimitExcept à l’intérieur du fichier :

      • sudo vi +272 /usr/local/etc/apache24/httpd.conf

      Pour définir cette configuration, vous placerez le bloc suivant dans l’entrée de la directive DocumentRoot où le contenu sera lu, plus précisément dans l’entrée Directory :

      /usr/local/etc/apache24/httpd.conf

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

      Pour appliquer les modifications, redémarrez Apache HTTP :

      La nouvelle directive AllowedMethods offre des fonctionnalités similaires, bien que son statut soit encore expérimental.

      Vous avez vu ce que sont les méthodes HTTP, leur utilisation et la protection qu’elles offrent contre les activités malveillantes se servant de la méthode TRACE, ainsi que la manière de déclarer les méthodes à utiliser. Maintenant, vous allez travailler avec d’autres protections dédiées aux en-têtes et aux cookies HTTP.

      Sécuriser des en-têtes et des cookies

      Au cours de cette étape, vous allez définir des directives spécifiques pour protéger les sessions que les machines clientes ouvriront lorsqu’elles visiteront votre serveur web Apache HTTP. De cette façon, votre serveur ne chargera pas de contenu indésirable, le chiffrage ne sera pas déclassé et vous éviterez que votre contenu soit fouillé.

      Les en-têtes sont des éléments des méthodes de requêtes. Il existe des en-têtes pour ajuster l’authentification, la communication entre le serveur et le client, la mise en cache, la négociation de contenu, etc.

      Les cookies sont des éléments d’information envoyés par le serveur au navigateur. Ces bits permettent au serveur de reconnaître le navigateur du client d’un ordinateur à l’autre. Ils permettent également aux serveurs de reconnaître les sessions des utilisateurs. Ils peuvent, par exemple, suivre le panier d’un utilisateur connecté, ses informations de paiement, son historique, etc. Les cookies sont utilisés et conservés dans le navigateur web du client puisque HTTP est un protocole apatride, ce qui signifie qu’une fois la connexion fermée, le serveur ne se souvient pas de la requête envoyée par un client, ou un autre.

      Il est important de protéger les en-têtes ainsi que les cookies car ils assurent la communication entre le client du navigateur web et le serveur web.

      Le module des en-têtes est activé par défaut. Pour vérifier s’il est chargé, vous utiliserez la commande suivante :

      • sudo apachectl -M | grep 'headers'

      Vous verrez la sortie suivante :

      Output

      headers_module (shared)

      Si vous ne voyez aucune sortie, vérifiez si le module est activé dans le fichier httpd.conf d’Apache :

      • grep -n 'mod_headers' /usr/local/etc/apache24/httpd.conf

      En sortie, vous verrez une ligne non commentée renvoyant au module spécifique pour les en-têtes :

      /usr/local/etc/apache24/httpd.conf

      . . .
      122  LoadModule headers_module libexec/apache24/mod_headers.so
      . . .
      

      Supprimez le hashtag au début de la ligne mod_headers.so, s’il est présent, pour activer la directive.

      En utilisant les directives HTTP Apache suivantes, vous protégerez les en-têtes et les cookies contre les activités malveillantes, afin de réduire le risque pour les clients et les serveurs.

      Vous allez maintenant régler la protection de l’en-tête. Vous placerez toutes ces valeurs d’en-tête dans un seul bloc. Vous pouvez choisir d’appliquer ces valeurs comme vous le souhaitez, mais toutes sont recommandées.

      Modifiez le fichier httpd.conf avec la commande suivante, puis appuyez sur G pour atteindre la fin du fichier :

      • sudo vi /usr/local/etc/apache24/httpd.conf

      Placez le bloc suivant à la fin du fichier :

      /usr/local/etc/apache24/httpd.conf

      . . .
      <IfModule mod_headers.c>
        # Add security and privacy related headers
        Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;"
        Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
        Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure"
        Header set X-Content-Type-Options "nosniff"
        Header set X-XSS-Protection "1; mode=block"
        Header set Referrer-Policy "strict-origin"
        Header set X-Frame-Options: "deny"
        SetEnv modHeadersAvailable true
      </IfModule>
      
      • Jeu d'en-tête Strict-Transport-Security "max-age=31536000 ; includeSubDomains" : le HTTP Strict Transport Security (HTSTS) est un mécanisme permettant aux serveurs et clients web (principalement les navigateurs) d’établir des communications en utilisant uniquement le HTTPS. En l’implémentant, vous évitez les attaques de type “man-in-the-middle”, où une tierce partie entre les communications pourrait potentiellement accéder aux bits, mais aussi les altérer.

      • En-tête always edit Set-Cookie (. *) "$1 ; HttpOnly ; Secure" : les drapeaux HttpOnly et Secure sur les en-têtes aident à prévenir les attaques de type “cross-site scripting”, également connues sous le nom de XSS. Les cookies peuvent être utilisés à mauvais escient par les pirates pour se faire passer pour des visiteurs légitimes se présentant comme quelqu’un d’autre (vol d’identité), ou être trafiqués.

      • En-tête Referrer-Policy "strict-origin" : l’en-tête Referrer-Policy définit les informations qui sont incluses en tant qu’informations de référence dans le champ d’en-tête.

      • En-tête Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;": l’en-tête Content-Security-Policy (CSP) empêchera complètement le chargement de contenu non spécifié dans les paramètres, ce qui est utile pour prévenir les attaques par script inter-sites (XSS). Il existe de nombreux paramètres possibles pour configurer la politique pour cet en-tête. L’essentiel est de le configurer pour charger le contenu du même site et de mettre à jour tout contenu ayant une origine HTTP.

      • En-tête X-XSS-Protection "1; mode=block" : cette option prend en charge les anciens navigateurs qui ne sont pas compatibles avec les en-têtes Content-Security-Policy. L’en-tête ‘X-XSS-Protection’ assure une protection contre les attaques de type Cross-Site Scripting. Vous n’avez pas besoin de définir cet en-tête, sauf si vous devez prendre en charge d’anciennes versions de navigateur, ce qui est rare.

      • En-tête X-Frame-Options: "deny": cela permet d’éviter les attaques de type “clickjacking”. L’en-tête “X-Frame-Options” indique au navigateur si une page peut être rendue dans un <frame>, <iframe>, <embed> ou <object>. Ainsi, le contenu d’autres sites ne peut pas être intégré à d’autres, ce qui empêche les attaques de type “clickjacking”. Ici, vous refusez tout rendu de trame afin que la page web ne puisse être intégrée nulle part ailleurs, pas même à l’intérieur du même site web. Vous pouvez l’adapter à vos besoins, si, par exemple, vous devez autoriser le rendu de certaines pages parce qu’il s’agit de publicités ou de collaborations avec des sites web spécifiques.

      • En-tête X-Content-Type-Options "nosniff": l’en-tête “X-Content-Type-Options” contrôle les types MIME afin qu’ils ne soient pas modifiés et suivis. Les types MIME sont des normes de format de fichier ; ils fonctionnent pour le texte, l’audio, la vidéo, l’image, etc. Cet en-tête empêche les acteurs malveillants de fouiller le contenu de ces fichiers et d’essayer de modifier les types de fichiers.

      Redémarrez maintenant Apache pour que les modifications prennent effet :

      Pour vérifier les niveaux de sécurité de vos paramètres de configuration, visitez le site web des en-têtes de sécurité. Après avoir suivi les étapes de ce tutoriel, votre domaine obtiendra la note A.

      Remarque : si vous faites vérifier vos en-têtes en visitant https://securityheaders.com/ et que vous obtenez une note F, cela pourrait être dû au fait qu’il n’y a pas d’index.html dans le DocumentRoot de votre site, comme indiqué à la fin de l’étape 2. Si, en vérifiant vos en-têtes, vous obtenez une note différente d’un A ou d’un F, vérifiez chaque ligne de l'ensemble des en-têtes à la recherche de toute faute d’orthographe qui aurait pu causer le déclassement.

      Dans cette étape, vous avez utilisé jusqu’à sept paramètres pour améliorer la sécurité de vos en-têtes et cookies. Ces mesures permettront d’éviter les attaques de type Cross-Site Scripting, le “clickjacking” et d’autres types d’attaques.

      Conclusion

      Dans ce tutoriel, vous avez abordé plusieurs aspects liés à la sécurité, à la divulgation d’informations à la protection des sessions, en passant par la définition d’autres paramètres de configuration pour les fonctionnalités importantes.

      Pour d’autres ressources concernant le renforcement d’Apache, voici quelques autres références :

      Pour connaître des outils supplémentaires de protection d’Apache HTTP :



      Source link

      Passos recomendados para proteger o HTTP Apache no FreeBSD 12.0


      O autor selecionou o Free and Open Source Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      Embora a instalação padrão de um servidor HTTP Apache já seja segura para usar, sua configuração pode ser melhorada substancialmente com algumas modificações. É possível complementar os mecanismos de segurança atuais como, por exemplo, definindo proteções em torno de cookies e cabeçalhos, de modo que as conexões não possam ser alteradas no nível cliente do usuário. Ao fazer isso, é possível reduzir drasticamente as possibilidades de vários métodos de ataque, como ataques de Cross-Site Scripting (também conhecidos por XSS). Também é possível evitar outros tipos de ataques, como a solicitação intersite forjada (XSRF), ou sequestro de sessão, bem como ataques de negação de serviço.

      Neste tutorial, você implementará alguns passos recomendados para reduzir o nível de exposição das informações em seu servidor. Você verificará as listas de diretórios e desativará a indexação para verificar o acesso aos recursos. Você também vai alterar o valor padrão da diretiva timeout, para ajudar a mitigar os ataques do tipo negação de serviço. Além disso, você desativará o método TRACE, de modo que as sessões não possam ser invertidas e sequestradas. Por fim, protegerá cabeçalhos e cookies.

      A maioria das definições de configuração serão aplicadas ao arquivo de configuração principal do HTTP Apache encontrado em /usr/local/etc/apache24/httpd.conf.

      Pré-requisitos

      Antes de iniciar este guia, você precisará do seguinte:

      Com os pré-requisitos instalados, você terá um sistema FreeBSD com uma pilha sobre ele, capaz de atender o conteúdo Web usando qualquer coisa escrita em PHP, tais como softwares de CMS importantes. Além disso, você criptografou conexões seguras através do Let’s Encrypt.

      Reduzindo as informações do servidor

      A faixa do sistema operacional é um método usado por computadores, servidores e dispositivos de todos os tipos para se apresentarem nas redes. Atores mal-intencionados podem usar essa informação para conseguir acesso às vulnerabilidades de sistemas relevantes. Nesta seção, você reduzirá a quantidade de informações publicadas por essa faixa.

      Conjuntos de diretivas controlam como essa informação é exibida. Para essa finalidade, a diretiva ServerTokens é importante; por padrão, ela mostra todos os detalhes sobre o sistema operacional e os módulos compilados para o cliente que está se conectando a ele.

      Você usará uma ferramenta de verificação de rede para conferir quais informações são atualmente reveladas, antes de aplicar qualquer alteração. Para instalar o nmap, execute o seguinte comando:

      Para obter o endereço IP do seu servidor, execute o seguinte comando:

      • ifconfig vtnet0 | awk '/inet / {print $2}'

      Verifique a resposta do servidor Web, usando o seguinte comando:

      • nmap -sV -p 80 your-server-ip

      Você invoca o nmap para fazer uma verificação (por conseguinte, o sinalizador -s), para exibir a versão (o sinalizador -V) na porta 80 (o sinalizador -p) de um determinado IP ou domínio.

      Você receberá informações sobre seu servidor Web, semelhantes às seguintes:

      Output

      Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:30 CET Nmap scan report for 206.189.123.232 Host is up (0.054s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.41 ((FreeBSD) OpenSSL/1.1.1d-freebsd Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

      Esse resultado mostra que informações como o sistema operacional, a versão HTTP Apache e o OpenSSL estão visíveis. Isso pode ser útil para que invasores consigam informações sobre o servidor e escolham as ferramentas certas para acessar, por exemplo, uma vulnerabilidade no software que está em execução no servidor.

      Você colocará a diretiva ServerTokens no arquivo de configuração principal, já que ela não vem configurada por padrão. A falta dessa configuração faz com que o HTTP Apache mostre toda a informação sobre o servidor, da maneira como está na documentação. Para limitar as informações que são reveladas sobre seu servidor e configuração, você colocará a diretiva ServerTokens dentro do arquivo de configuração principal.

      Coloque essa diretiva após a entrada ServerName, no arquivo de configuração. Execute o seguinte comando para encontrar a diretiva:

      • grep -n 'ServerName' /usr/local/etc/apache24/httpd.conf

      Você encontrará o número da linha que você poderá pesquisar com o vi:

      Output

      226 #ServerName www.example.com:80

      Execute o seguinte comando:

      • sudo vi +226 /usr/local/etc/apache24/httpd.conf

      Adicione a linha destacada a seguir:

      /usr/local/etc/apache24/httpd.conf

      . . .
      #ServerName www.example.com:80
      ServerTokens Prod
      

      Salve e saia do arquivo com :wq e ENTER.

      Definir a diretiva ServerTokens para Prod fará com que ela exiba apenas que este é um servidor Web Apache.

      Para que isso entre em vigor, reinicie o servidor HTTP Apache:

      Para testar as alterações, execute o seguinte comando:

      • nmap -sV -p 80 your-server-ip

      Você verá um resultado semelhante ao seguinte, com informações reduzidas sobre seu servidor Web Apache:

      Output

      Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:58 CET Nmap scan report for WPressBSD (206.189.123.232) Host is up (0.056s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

      Você viu quais informações o servidor estava anunciando antes da mudança e agora reduziu isso a um mínimo. Com isso, estará fornecendo menos pistas sobre seu servidor a um agente externo. No próximo passo, você irá gerenciar as listagens de diretórios para seu servidor Web.

      Gerenciando listagens de diretórios

      Neste passo, você irá assegurar que a listagem de diretórios esteja devidamente configurada, de modo que as partes certas do sistema fiquem publicamente disponíveis, conforme pretendido, ao passo que as demais partes fiquem protegidas.

      Nota: quando um argumento estiver declarado como estando ativo, o sinal de adição + poderá reforçar visualmente que ele está, de fato, habilitado. Quando um sinal de subtração - for usado, significa que o argumento foi negado como, por exemplo, em Options -Indexes.

      Argumentos com sinais de adição + e/ou de subtração - não podem ser misturados, pois esta é uma sintaxe considerada ruim no HTTP Apache e pode ser rejeitada na inicialização.

      Adicionar a instrução Options -Indexes definirá o conteúdo dentro do caminho de dados /usr/local/www/apache24/data para não indexar (leia listado) automaticamente se não existir um arquivo .html e para não exibir se um URL mapear esse diretório. Isso também se aplicará quando usar configurações de host virtual, como a que foi usada no tutorial com os pré-requisitos para o certificado Let’s Encrypt.

      Você definirá a diretiva Options com o argumento -Indexes e com a diretiva +FollowSymLinks, o que permitirá que links simbólicos sejam seguidos. Você usará o símbolo + para cumprir com as convenções do HTTP do Apache.

      Execute o seguinte comando para encontrar a linha a ser editada no arquivo de configuração:

      • grep -n 'Options Indexes FollowSymLinks' /usr/local/etc/apache24/httpd.conf

      Você verá um resultado similar ao seguinte:

      Output

      263 : Options Indexes FollowSymLinks

      Execute este comando para acessar diretamente a linha para edição:

      • sudo vi +263 /usr/local/etc/apache24/httpd.conf

      Agora, edite a linha de acordo com a configuração:

      /usr/local/etc/apache24/httpd.conf

      . . .
      #
      Options -Indexes +FollowSymLinks
      
      #
      . . .
      

      Salve e saia do arquivo com :wq e ENTER.

      Reinicie o HTTP Apache para implementar estas alterações:

      No seu domínio, no navegador, você verá uma mensagem de acesso proibido, também conhecida como erro 403. Isso se deve às alterações que você aplicou. Colocar -Indexes na diretiva Options desabilitou a capacidade de auto-indexação do HTTP Apache e, portanto, não haverá nenhum arquivo index.html no caminho dos dados.

      Você pode resolver isso, colocando um arquivo index.html dentro do VirtualHost que você habilitou no tutorial com os pré-requisitos para o certificado Let’s Encrypt. Você usará o bloco padrão dentro do HTTP Apache e o colocará na mesma pasta que o DocumentRoot que tiver declarado no host virtual.

      /usr/local/etc/apache24/extra/httpd-vhosts.conf

      <VirtualHost *:80>
          ServerAdmin your_email@your_domain.com
          DocumentRoot "/usr/local/www/apache24/data/your_domain.com"
          ServerName your_domain.com
          ServerAlias www.your_domain.com
          ErrorLog "/var/log/your_domain.com-error_log"
          CustomLog "/var/log/your_domain.com-access_log" common
      </VirtualHost>
      

      Use o comando a seguir para fazer isso:

      • sudo cp /usr/local/www/apache24/data/index.html /usr/local/www/apache24/data/your_domain.com/index.html

      Agora você verá uma mensagem It works! (Funciona!) ao visitar o seu domínio.

      Nesta seção, você definiu restrições na diretiva dos Indexes, de modo a não listar nem exibir automaticamente o conteúdo, exceto o que você quiser que seja listado e exibido. Agora, caso não haja um arquivo index.html dentro do caminho de dados, o HTTP Apache não criará automaticamente um índice dos conteúdos. No próximo passo, você irá além do ocultamento de informações e personalizará diferentes diretivas.

      Reduzindo o valor da diretiva de Tempo Limite

      A diretiva Timeout (tempo limite) define o limite de tempo que o HTTP Apache vai aguardar por novas entradas/saídas, antes de falhar o pedido de conexão. Esta falha pode ocorrer devido a diversas circunstâncias, como pacotes que não chegam no servidor ou dados que não estão sendo confirmados como recebidos pelo cliente.

      Por padrão, o tempo limite é definido em 60 segundos. Em ambientes onde o serviço de internet é lento, esse valor padrão pode fazer sentido. No entanto, um minuto é um tempo consideravelmente longo, especialmente se o servidor estiver cobrindo usuários alvo com um serviço de internet mais rápido. Além disso, durante o tempo em que o servidor não está fechando, a conexão pode ser explorada para a realização de ataques de negação de serviço (do inglês, DoS). Caso uma enorme quantidade dessas conexões mal-intencionadas ocorra, o servidor irá fraquejar e possivelmente ficará saturado e deixará de responder.

      Para alterar o valor, encontre as entradas de Timeout no arquivo httpd-default.conf:

      • grep -n 'Timeout' /usr/local/etc/apache24/extra/httpd-default.conf

      Você verá um resultado parecido com este:

      Output

      8 # Timeout: The number of seconds before receives and sends time out. 10 Timeout 60 26 # KeepAliveTimeout: Number of seconds to wait for the next request from the 29 KeepAliveTimeout 5 89 RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

      No resultado, a linha 10 define o valor da diretiva Timeout. Para acessar diretamente essa linha, execute o seguinte comando:

      • sudo vi +10 /usr/local/etc/apache24/extra/httpd-default.conf

      Você irá alterar o valor para 30 segundos, assim como no exemplo a seguir:

      /usr/local/etc/apache24/extra/httpd-default.conf

      #
      # Timeout: The number of seconds before receives and sends time out.
      #
      Timeout 30
      

      Salve e saia do arquivo com :wq e ENTER.

      O valor da diretiva Timeout precisa equilibrar um intervalo longo o bastante, para que tais eventos permitam que uma conexão legítima e bem-sucedida ocorra, mas suficientemente curto para evitar tentativas de conexão indesejadas.

      Nota: os ataques de negação de serviço podem drenar os recursos do servidor de modo bastante eficaz. Uma contramedida complementar e bem eficaz é usar um MPM (Multi-Processing Module [Módulo de processamento múltiplo]) encadeado para conseguir o melhor desempenho da maneira como o HTTP Apache lida com conexões e processos. No tutorial sobre Como configurar o HTTP Apache com o evento MPM e PHP-FPM no FreeBSD 12.0, há passos sobre como habilitar essa capacidade.

      Para que essa alteração entre em vigor, reinicie o servidor HTTP Apache:

      Você alterou o valor padrão da diretiva Timeout para mitigar parcialmente os ataques de DoS.

      Desabilitando o método TRACE

      O HTTP (Hypertext Transport Protocol [Protocolo de Transporte de Hipertexto]) foi desenvolvido de acordo com um modelo cliente-servidor e, como tal, o protocolo tem métodos de solicitação para recuperar ou posicionar informações vindas do servidor ou enviadas para ele. O servidor precisa entender esses conjuntos de métodos e como eles interagem entre si. Neste passo, você irá configurar os métodos mínimos necessários.

      O método TRACE – antes considerado inofensivo – foi potencializado para a realizar ataques de rastreamento intersites. Esses tipos de ataques permitem que atores mal-intencionados roubem as sessões do usuário através desse método. O método foi projetado para a finalidade de depuração pelo servidor, retornando o mesmo pedido enviado originalmente pelo cliente. Como o cookie da sessão do navegador é enviado para o servidor, ele será enviado de volta novamente. No entanto, possivelmente isso poderia ser interceptado por um ator mal-intencionado que poderia, então, redirecionar a conexão de um navegador para um site controlado por ele e não para o servidor original.

      Devido à possibilidade do uso indevido do método TRACE, é recomendável usá-lo apenas para depuração e não na produção. Nesta seção, você desativará esse método.

      Edite o arquivo httpd.conf com o comando a seguir e, em seguida, pressione G para chegar ao final do arquivo:

      • sudo vi /usr/local/etc/apache24/httpd.conf

      Adicione o seguinte caminho de entrada ao final do arquivo:

      /usr/local/etc/apache24/httpd.conf

      . . .
      TraceEnable off
      

      Uma prática recomendável é especificar apenas os métodos que você usará no seu servidor Web HTTP Apache. Isso ajudará a limitar possíveis pontos de entrada para atores mal-intencionados.

      O LimitExcept pode ser útil para este propósito, uma vez que ele não permite nenhum outro método senão os que estão declarados nele. Por exemplo, uma configuração pode ser estabelecida desta forma:

      /usr/local/etc/apache24/httpd.conf

      DocumentRoot "/usr/local/www/apache24/data"
      <Directory "/usr/local/www/apache24/data">
          Options -Indexes +FollowSymLinks -Includes
          AllowOverride none
           <LimitExcept GET POST HEAD>
             deny from all
          </LimitExcept>
          Require all granted
      </Directory>
      

      Como declarado dentro da diretiva LimitExcept, apenas os métodos GET, POST e HEAD foram permitidos na configuração.

      • O método GET faz parte do protocolo HTTP e é usado para recuperar dados.
      • O método POST também faz parte do protocolo HTTP e é usado para enviar dados ao servidor.
      • O método HEAD é semelhante ao GET, porém, ele não possui nenhum corpo de resposta.

      Você usará o comando a seguir e colocará o bloco LimitExcept dentro do arquivo:

      • sudo vi +272 /usr/local/etc/apache24/httpd.conf

      Para definir essa configuração, você colocará o seguinte bloco na entrada da diretiva DocumentRoot, a partir do qual o seu conteúdo será lido, mais especificamente dentro da entrada Directory:

      /usr/local/etc/apache24/httpd.conf

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

      Para aplicar as alterações, reinicie o HTTP Apache:

      A diretiva mais recente AllowedMethods oferece funcionalidades semelhantes, embora ainda esteja com status experimental.

      Você viu o que são os métodos HTTP, seus usos e a proteção que oferecem contra atividades mal-intencionadas, que potencializam o método TRACE, além de como declarar quais métodos usar. A seguir, você trabalhará com proteções adicionais, dedicadas aos cabeçalhos e cookies HTTP.

      Protegendo cabeçalhos e cookies

      Neste passo, você irá configurar diretivas específicas para proteger as sessões que as máquinas clientes abrirão ao visitar seu servidor Web HTTP Apache. Dessa forma, seu servidor não irá carregar conteúdo indesejado, a criptografia não será reduzida e você evitará a detecção de conteúdo.

      Os cabeçalhos são componentes dos métodos de solicitação. Existem cabeçalhos para ajustar a autenticação, a comunicação entre servidor e cliente, o cache, a negociação de conteúdo etc.

      Os cookies são partes de informações enviadas pelo servidor para o navegador. Essas partes permitem que o servidor reconheça o navegador do cliente de um computador para outro. Elas também permitem que os servidores reconheçam as sessões dos usuários. Por exemplo, elas podem rastrear um carrinho de compras de um usuário conectado, informações de pagamento, histórico e assim por diante. Os cookies são usados e mantidos no navegador Web do cliente, uma vez que o HTTP é um protocolo sem estado, ou seja, assim que a conexão se fecha, o servidor não se lembra do pedido enviado por um cliente, ou outro.

      É importante proteger os cabeçalhos, bem como os cookies, pois eles proporcionam comunicação entre o cliente do navegador Web e o servidor Web.

      O módulo headers (cabeçalhos) vem ativado por padrão. Para verificar se ele está carregado, use o seguinte comando:

      • sudo apachectl -M | grep 'headers'

      Você verá o seguinte resultado:

      Output

      headers_module (shared)

      Se não ver nenhum resultado, verifique se o módulo está ativado dentro do arquivo do Apache httpd.conf:

      • grep -n 'mod_headers' /usr/local/etc/apache24/httpd.conf

      Como resultado, você verá uma linha não comentada, referindo-se ao módulo específico para os cabeçalhos:

      /usr/local/etc/apache24/httpd.conf

      . . .
      122  LoadModule headers_module libexec/apache24/mod_headers.so
      . . .
      

      Remova a hashtag no início da linha mod_headers.so, se houver, para ativar a diretiva.

      Ao utilizar as diretivas do HTTP Apache a seguir, você protegerá os cabeçalhos e cookies de atividade mal-intencionada, reduzindo o risco para clientes e servidores.

      Agora, você irá configurar a proteção do cabeçalho. Você colocará todos esses valores de cabeçalho em um bloco. Você pode escolher aplicar esses valores como desejar, mas todos são recomendados.

      Edite o arquivo httpd.conf com o comando a seguir e, em seguida, pressione G para chegar ao final do arquivo:

      • sudo vi /usr/local/etc/apache24/httpd.conf

      Posicione o seguinte bloco ao final do arquivo:

      /usr/local/etc/apache24/httpd.conf

      . . .
      <IfModule mod_headers.c>
        # Add security and privacy related headers
        Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;"
        Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
        Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure"
        Header set X-Content-Type-Options "nosniff"
        Header set X-XSS-Protection "1; mode=block"
        Header set Referrer-Policy "strict-origin"
        Header set X-Frame-Options: "deny"
        SetEnv modHeadersAvailable true
      </IfModule>
      
      • Header set Strict-Transport-Security "max-age=31536000; includeSubDomains": o HTTP Strict Transport Security (HTSTS) [Segurança de Transporte Estrito HTTP] é um mecanismo para servidores e clientes Web (principalmente navegadores) para estabelecer comunicações usando apenas HTTPS. Ao implementar isso, você está evitando ataques de intermediários (do inglês, man-in-the-middle ou MITM), nos quais um terceiro, no meio da comunicação, possivelmente poderia acessar partes dos dados, bem como adulterá-las.

      • Header always edit Set-Cookie (. *) "$1; HttpOnly; Secure": os sinalizadores HttpOnly e Secure nos cabeçalhos ajudam a evitar ataques de script intersites, também conhecidos como XSS. Invasores podem usar os cookies indevidamente, passando-se por visitantes legítimos, ou seja, apresentando-se como outras pessoas (roubo ou falsificação de identidade).

      • Header set Referrer-Policy "strict-origin": o cabeçalho Referrer-Policy define quais informações são incluídas como informações de referenciador no campo do cabeçalho.

      • Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;": o cabeçalho Content-Security-Policy (CSP) evitará completamente o carregamento de conteúdo não especificado nos parâmetros, o que é útil para prevenir ataques de scripts intersites (XSS). Existem muitos parâmetros possíveis para configurar a política para este cabeçalho. A linha final está configurando-o para carregar conteúdo a partir do mesmo site e atualizar qualquer conteúdo com origem de HTTP.

      • Header set X-XSS-Protection "1; mode=block": este cabeçalho é compatível com navegadores mais antigos que não estão à altura dos cabeçalhos Content-Security-Policy. O cabeçalho ‘X-XSS-Protection’ fornece proteção contra os ataques de script intersites. Você não precisa definir esse cabeçalho, a menos que precise dar suporte às versões antigas de navegadores, o que é raro.

      • Header set X-Frame-Options: "deny": isso impede os ataques de clickjacking [ataques à interface do usuário]. O cabeçalho ‘X-Frame-Options’ diz a um navegador se uma página pode ser renderizada em um <frame>, <iframe>, <embed> ou <object>. Dessa forma, o conteúdo de outros sites não pode ser inserido em outros, impedindo os ataques de clickjacking. Aqui, você está negando toda renderização de quadros, para que a página Web não possa ser inserida em nenhum outro lugar, nem mesmo dentro do mesmo site. Você pode adaptar isso às suas necessidades, caso, por exemplo, precise autorizar a renderização de algumas páginas por se tratarem de anúncios ou colaborações com sites específicos.

      • Header set X-Content-Type-Options "nosniff": o cabeçalho ‘X-Content-Type-Options’ controla os tipos MIME, de modo que não sejam alterados nem seguidos. Os tipos MIME são padrões de formatos de arquivos; eles funcionam para texto, áudio, vídeo, imagem etc. Esse cabeçalho impede que atores mal-intencionados detectem tais arquivos e tentem alterar os tipos de arquivos.

      Agora, reinicie o Apache para que as alterações entrem em vigor:

      Para verificar os níveis de segurança das suas configurações, visite o site de cabeçalhos de segurança. Após seguir os passos neste tutorial, seu domínio irá obter uma nota A.

      Nota: se você fizer a verificação dos seus cabeçalhos visitando o sitehttps://securityheaders.com/ e obtiver uma nota F, isso pode significar que não há um index.html dentro do DocumentRoot do seu site – conforme instrução ao final do Passo 2. Se, ao fazer a verificação dos seus cabeçalhos, você obtiver uma nota diferente de A, ou F, verifique cada linha do Header set, procurando por eventuais erros de ortografia que possam ter levado à redução da nota.

      Neste passo, você trabalhou com até sete configurações para melhorar a segurança dos seus cabeçalhos e cookies. Esses recursos ajudarão a evitar ataques do tipo script intersites, clickjacking, entre outros.

      Conclusão

      Neste tutorial, você lidou com vários aspectos de segurança, desde a divulgação de informações, até a proteção de sessões, definindo ajustes alternativos na configuração de funcionalidades importantes.

      Para obter mais recursos para proteger o Apache, aqui estão algumas outras referências:

      Para obter outras ferramentas para proteger o HTTP Apache:



      Source link