In diesem Beitrag zeige ich dir, wie du die Grundlagen legst, um einen Apache-Server auf Debian zu installieren und abzusichern. Wir werden auf die gängigsten Angriffsmöglichkeiten eingehen und Maßnahmen ergreifen, um diese zu verhindern oder zu erschweren.
Beachte, dass Sicherheit ein fortlaufender Prozess ist. Halte dein System stets auf dem neuesten Stand und informiere dich regelmäßig über bewährte Sicherheitspraktiken.
Voraussetzung
Ich verwende einen Raspberry Pi 2B mit Debian Version 12.
Stelle sicher, dass du bereits als normaler Benutzer über PuTTY oder direkt auf dem Debian-System angemeldet bist.
Installation
Der erste Schritt ist, wie immer, apt-get
zu aktualisieren:
sudo apt-get update -y
Code-Sprache: Bash (bash)
Danach installieren wir Apache. Verwende dazu den folgenden Befehl:
sudo apt install apache2 -y
Code-Sprache: Bash (bash)
Damit du auch die Dateien im Webverzeichnis bearbeiten kannst, geben wir dir die notwendigen Rechte:
sudo chown -R [Dein Benutzer]:www-data /var/www/html/
sudo chmod -R 770 /var/www/html/
Code-Sprache: Bash (bash)
Um zu überprüfen ob die Installation erfolgreich war, kannst du im Browser die IP-Adresse des Raspberry aufrufen. Die Ip-Adresse deines System kannst du über den Befehl ip addr
herausfinden.
Härten (sichern und absichern)
Im digitalen Dschungel versuchen ständig Personen, in Webserver einzudringen. Oft sind es keine „echten Hacker“, sondern eher Script-Kiddies oder „normale Benutzer“, die Programme nutzen, um automatisiert Schwachstellen zu finden. Dabei kommen Techniken wie XSS, SQLi oder RCE zum Einsatz.
Bedenke immer:
Kein Computer System ist 100% sicher.
Mit genügend Zeit kann man in jedes System eindringen. Unser Ziel ist es, den Angreifern den Zugriff so schwer wie möglich zu machen und den Aufwand so groß zu gestalten, dass ein anderes System interessanter erscheint.
Mit dem Befehl
sudo apache2ctl configtest
Code-Sprache: Bash (bash)
kannst du deine Konfigurationsdateien nach dem Ändern auf Syntaxfehler testen.
Den Apache-Server statest du mit
sudo service apache2 restart
Code-Sprache: Bash (bash)
neu.
HTTP 1.0-Protokoll deaktivieren (Session-Hijacking)
Als erstes deaktivieren wir die ältere Version des HTTP-Protokolls, nämlich HTTP 1.0.
HTTP 1.0 ist für Session-Hijacking anfällig. Dabei Versuch eines Angreifers, die Kontrolle über eine laufende Sitzung zwischen einem Benutzer und einem Webdienst zu übernehmen. Dabei wird oft die eindeutige Sitzungs-ID des Benutzers gestohlen oder abgefangen, um unautorisierten Zugriff zu erlangen. Dies kann durch Packet Sniffing, Cross-Site Scripting (XSS) oder Man-in-the-Middle-Angriffe erfolgen.
Um dies zu erreichen, müssen wir zuerst das Apache-Module „rewrite“ aktivieren:
sudo a2enmod rewrite
Code-Sprache: Bash (bash)
Danach passen wir die apache2.conf
an:
sudo nano /etc/apache2/apache2.conf
Code-Sprache: Bash (bash)
Füge die folgende Direktive im Abschnitt <Directory />
hinzu:
RewriteEngine On
RewriteCond %{THE_REQUEST} !HTTP/1.1$
RewriteRule .* - [F]
Code-Sprache: Apache (apache)
Serverinformationen im Antwort-Header minimieren
Der Antwort-Header sieht bei der Standardinstallation von Apache wie folgt aus:
Diesen werden wir jetzt verändern um unnötige Informationen zu minimieren.
Damit wir den Antwort-Header manipulieren können muss das Apache-Module mod_headers.so
aktiviert sein:
sudo a2enmod headers
Code-Sprache: Bash (bash)
Serverversionsbanner
Dazu verwenden wir die Einstellungen ServerTokens Prod
und ServerSignature Off
. Diese Einstellungen werden in der security.conf
vorgenommen:
sudo nano /etc/apache2/conf-enabled/security.conf
Code-Sprache: Bash (bash)
Wir ändern:
ServerTokens OS
Code-Sprache: Apache (apache)
in
# Deleting server versions banner and system information
ServerTokens Prod
Code-Sprache: Apache (apache)
und
ServerSignature On
Code-Sprache: Apache (apache)
in
# Deleting server versions banner and system information
ServerSignature Off
Code-Sprache: Apache (apache)
Mit ServerTokens Prod
wird die genaue Apache-Serverversion in den HTTP-Antworten durch den Hinweis ‚Prod‘ ersetzt, was darauf hinweist, dass du dich in einer Produktionsumgebung befindest. Dies hilft, potenziellen Angreifern den Zugang zu Versionsinformationen zu erschweren
Zusätzlich deaktiviert ServerSignature Off
die detaillierte Server-Signatur in Fehlermeldungen und im Antwort-Header. Durch diese Maßnahme wird die Menge an verfügbaren Informationen für potenzielle Angreifer reduziert, was deine Serverumgebung sicherer macht.
Entity Tag (ETag) für Dateien
Die Verwendung des ETag-Headers birgt in bestimmten Situationen potenzielle Risiken wie Information Leakage durch Inode-Nummer, ETag-Tracking oder in Kombination mit anderen Schwachstellen.
Obwohl ETags eine entscheidende Rolle in der Caching-Strategie von Webbrowsern und Proxies spielen, müssen wir die Besonderheiten unseres kleinen Projekts auf einem Raspberry Pi2 berücksichtigen. Da es sich nicht um einen stark frequentierten Server handelt und eher wie eine persönliche Website oder ein kleines Projekt fungiert, priorisieren wir die Sicherheitsaspekte über die Performance.
Daher entscheiden wir uns dafür, ETags zu deaktivieren, um mögliche Sicherheitsrisiken zu minimieren. Diese Entscheidung beruht darauf, dass die Auswirkungen auf die Effizienz des Cachings in einem kleinen Umfeld weniger spürbar sind, und die Sicherheit des Projekts vorrang hat.
Dazu passen wir die apache2.conf
an:
sudo nano /etc/apache2/apache2.conf
Code-Sprache: Bash (bash)
Fügen folgende Direktive im Abschnitt <Directory /var/www/>
hinzu:
FileETag None
Code-Sprache: Apache (apache)
In dem Antwort-Header fehlt jetzt der FileETag:
X-Frame-Options (Clickjacking)
Ziel dieses Angriffs ist es, den Benutzer dazu zu bringen, unbeabsichtigt auf etwas zu klicken, das er nicht beabsichtigt hat. Beispiele für Clickjacking-Angriffe könnten das Überlagern eines unsichtbaren „Gefällt mir“-Buttons über einem unschuldig aussehenden Bild oder Text sein, sodass der Benutzer auf das vermeintlich harmlose Element klickt, aber tatsächlich eine Aktion auf einer anderen, möglicherweise bösartigen Website auslöst.
Um uns vor Clickjacking zu schützen implementieren wir die X-Frame-Options in dem Header. Das Modul mod_headers.so
muss aktiviert sein.
sudo nano /etc/apache2/apache2.conf
Code-Sprache: Bash (bash)
Füge die folgende Direktive im Abschnitt <Directory />
hinzu:
Header always append X-Frame-Options SAMEORIGIN
Code-Sprache: Apache (apache)
X-XSS-Schutz
Wir werden den X-XSS-Schutzheader bewusst nicht aktivieren und stattdessen Content-Security-Policy (CSP) benutzen. X-XSS kann in bestimmten Fällen neue Sicherheitslücken öffnen und die meisten neuen Browser unterstützen diesen Header nicht mehr.
Bitte beachte dazu die Hinweise unter https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection
Solltest du es dennoch aktivieren wollen (weil du ältere Browser unterstützen willst) gehen wie folgt vor:
sudo nano /etc/apache2/apache2.conf
Code-Sprache: Bash (bash)
Füge die folgende Direktive im Abschnitt <Directory />
hinzu:
Header set X-XSS-Protection "1; mode=block"
Code-Sprache: Apache (apache)
X-Content-Type-Options
Der X-Content-Type-Options-Header ist ein Sicherheitsheader, der in HTTP-Antworten verwendet wird. Seine primäre Funktion besteht darin, die MIME-Typen von Dateien zu steuern und sicherzustellen, dass der vom Server gesendete MIME-Typ respektiert wird.
In der Praxis bedeutet dies, dass, selbst wenn ein Angreifer versucht, schädlichen Code als etwas Unschuldiges zu tarnen, der Browser sich strikt an die Informationen hält, die der Server bereitstellt. Das minimiert das Risiko von Angriffen, bei denen versucht wird, die Art einer Datei zu manipulieren. Das Modul mod_headers.so
muss aktiviert sein.
sudo nano /etc/apache2/apache2.conf
Code-Sprache: Bash (bash)
Füge die folgende Direktive im Abschnitt <Directory />
hinzu:
Header set X-Content-Type-Options "nosniff"
Code-Sprache: Apache (apache)
Content Security Policy (CSP)
CSP ist ein Sicherheitsheader, der bestimmt, welche Ressourcen auf userer Website geladen werden dürfen und welche nicht. Das schützt uns vor Cross-Site Scripting (XSS) und Code-Injektions. Das Modul mod_headers.so
muss aktiviert sein.
sudo nano /etc/apache2/apache2.conf
Code-Sprache: Bash (bash)
Füge die folgende Direktive im Abschnitt <Directory />
hinzu:
Header always set Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline';"
Code-Sprache: Apache (apache)
Es wird festgelegt, dass nur auf Inhalte vom eigenen Server zugegriffen werden darf. Mit 'unsafe-inline'
wird bestimmt, dass auch In-Line CSS geladen werden darf.
Möchtest du CSS aus anderen Quellen laden z.B. Material Symbols and Icons muss du den Server expliziert erlauben:
Header always set Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline' fonts.googleapis.com;"
Code-Sprache: Apache (apache)
Strict-Transport-Security (HSTS)
Mit dem HSTS-Header sorgen wir dafür, dass der Webserver ausschließlich über eine sichere HTTPS-Verbindung erreichbar ist. Das bedeutet, dass selbst, wenn jemand versucht, über „http“ auf den Sever zuzugreifen, der Browser automatisch auf „https“ umleitet. Das Modul mod_headers.so
muss aktiviert sein.
sudo nano /etc/apache2/apache2.conf
Code-Sprache: Bash (bash)
Füge die folgende Direktive im Abschnitt <Directory />
hinzu:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Code-Sprache: Apache (apache)
HTTP-TRACE-Methoden-Angriff ( Cross-Site-Tracing (XST))
Der HTTP-TRACE-Angriff ist eine Sicherheitslücke, bei der ein Angreifer versucht, die TRACE
-Methode des HTTP-Protokolls zu missbrauchen.
Die TRACE
-Methode wird normalerweise für Debugging-Zwecke verwendet und ermöglicht es einem Client, eine Schleife zurück zum Absender zu erstellen. Ein Angreifer kann jedoch versuchen, diese Methode zu nutzen, um Cross-Site Tracing (XST) Angriffe durchzuführen. Bei erfolgreichem Angriff kann der Angreifer vertrauliche Informationen, wie z.B. Cookies, abfangen.
Bei meiner Apache Version war die Option TraceEnable Off
schon gesetzt. Es ist aber eine gute Praxis, dies noch mal zu verifizieren. Diese Option wird ebenfalls in der security.conf
Gesetzt:
sudo nano /etc/apache2/conf-enabled/security.conf
Code-Sprache: Bash (bash)
Directory Listings und Server Side Include (SSI)
Um eine potenzielle Sicherheitslücke zu schließen, deaktivieren wir das automatische Auflisten von Dateien im Verzeichnis. In unserem Fall nutzen wir die Einstellung Options None
für das Verzeichnis, in dem unsere Webdateien liegen (/var/www/). Dadurch wird verhindert, dass ein potenzieller Angreifer eine Liste aller Dateien in diesem Verzeichnis einsehen kann, selbst wenn keine Indexdatei vorhanden ist.
Ebenso wird das Einbinden von Skripts in Verbindung mit Server Side Includes (SSI) durch die Abschaltung dieser Funktion minimiert, wodurch mögliche Angriffsvektoren reduziert werden.
Dazu passen wir wieder die apache2.conf
an:
sudo nano /etc/apache2/apache2.conf
Ändern folgende Direktive im Abschnitt <Directory /var/www/>
:
Options Indexes FollowSymLinks
Code-Sprache: Apache (apache)
in
Options -Indexes
Code-Sprache: Apache (apache)
Wir setzen hier bewusst -Indexes
und nicht None
da es sonst zu Problemen mit der HTML 1.0 Unterdrückung gibt.
HTTP-Anforderungsmethoden
Das HTTP 1.1-Protokoll bietet eine umfassende Auswahl an Anforderungsmethoden, von denen einige möglicherweise nicht zwingend erforderlich sind und bestimmte potenzielle Risiken bergen können.
In der Standardkonfiguration werden Methoden wie OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE und CONNECT unterstützt.
Man könnte nun in Betracht ziehen, einfach auf HTTP 1.0 umzusteigen, um das Problem zu lösen. Leider ist auch Version 1.0 nicht uneingeschränkt sicher.
Für viele Webanwendungen genügen oft die Anforderungsmethoden GET, HEAD und POST. Diese können individuell in den entsprechenden Verzeichnisrichtlinien, virtuellen Hosts oder serverweit konfiguriert werden.
Da wir eine einfache Webserver erstellen wollen, werden wird die Methoden auf dem kompletten Server (genauer auf dem Root-Verzeichnis) einschränken. Dazu gehen wir wieder in die apache2.conf:
sudo nano /etc/apache2/apache2.conf
Code-Sprache: Bash (bash)
Füge die folgende Direktive im Abschnitt <Directory />
hinzu:
<LimitExcept GET POST HEAD>
deny from all
</LimitExcept>
Code-Sprache: Apache (apache)
Cookie-Sicherheit verbessern: HttpOnly und Secure-Flag setzen (XSS)
Um unseren Server vor Angriffen wie Cross-Site Scripting zu schützen oder sie zumindest zu erschweren, ist es von entscheidender Bedeutung, die Flags „HttpOnly“ und „Secure“ für Set-Cookie zu aktivieren. Ohne diese Flags könnten Angreifer Sitzungsdaten stehlen oder manipulieren, was ein erhebliches Sicherheitsrisiko darstellt.
Zuerst müssen wir das Modul mod_headers.so
aktivieren, das in der Lage ist, Änderungen am Header/Cookies vorzunehmen.
sudo a2enmod headers
Code-Sprache: Bash (bash)
Anschließend können wir eine Regel/Direktive in die apache2.conf
einfügen, die den Header/Cookie entsprechend verändert:
sudo nano /etc/apache2/apache2.conf
Code-Sprache: Apache (apache)
Füge die folgende Direktive im Abschnitt <Directory />
hinzu:
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Code-Sprache: Apache (apache)
Anfrage-Time-Out
Die Konfiguration des Timeout-Werts in Apache ist eine gute Sicherheitsmaßnahme, um sich vor Angriffen wie Slow Loris und DoS zu schützen. Da es sich bei uns um ein kleines Projekt handelt, werden wir den Wert erst mal extrem klein ansetzt. Sollte es beim Laden der Seite zu TimeOuts kommen, können wir den Wert immer noch erhöhen. Um eine OSM-Karte bereit zu stellen , die in real-time rendern soll, wäre dieser Wert definitive zu gering.
sudo nano /etc/apache2/apache2.conf
Code-Sprache: Bash (bash)
Wir ändern den Wert von
Timeout 300
Code-Sprache: Apache (apache)
auf
Timeout 10
Code-Sprache: Apache (apache)
Max Keep Alive Requests
Das selbe was für die Direktive Timeout
gilt, gilt auch für MaxKeepAliveRequests
. Wir brauchen keine 100 Verbindungen. daher setzte wir hier auch wieder einen kleinen Wert an, den wir bei Problemen anheben können.
sudo nano /etc/apache2/apache2.conf
Code-Sprache: Bash (bash)
Wir ändern den Wert von
MaxKeepAliveRequests 100
Code-Sprache: Apache (apache)
auf
MaxKeepAliveRequests 10
Code-Sprache: Apache (apache)
TLS Zertifikat und sicherheit
Damit Strict-Transport-Security funktionieren kann muss ein TLS-Zertifikat installiert sein. Aber dadurch können neue Sicherheitslücken entstehen. Daher werden wir Apache so konfigurieren, dass wir TLS sicher betreiben können.
Als erstes muss ein TLS Zertifikat erzeugt werden. Wie das geht, zeige ich dir hier. Solltest du schon ein Zertifikat haben, kannst du diesen schritt überspringen.
Wenn dir meine Arbeit gefällt, würde ich mich über einen Kaffee freuen