Maker-Hub bei GitHub Maker-Hub bei Printables Maker-Hub bei MakerWorld Maker-Hub bei YouTube

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 -yCode-Sprache: Bash (bash)

Danach installieren wir Apache. Verwende dazu den folgenden Befehl:

sudo apt install apache2 -yCode-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.

Apache2 Debian Default Page

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 configtestCode-Sprache: Bash (bash)

kannst du deine Konfigurationsdateien nach dem Ändern auf Syntaxfehler testen.

Den Apache-Server statest du mit

sudo service apache2 restartCode-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 rewriteCode-Sprache: Bash (bash)

Danach passen wir die apache2.conf an:

sudo nano /etc/apache2/apache2.confCode-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:

Antwortheader der Apache Standardinstallation

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 headersCode-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.confCode-Sprache: Bash (bash)

Wir ändern:

ServerTokens OSCode-Sprache: Apache (apache)

in

# Deleting server versions banner and system information
ServerTokens ProdCode-Sprache: Apache (apache)

und

ServerSignature OnCode-Sprache: Apache (apache)

in

# Deleting server versions banner and system information
ServerSignature OffCode-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.confCode-Sprache: Bash (bash)

Fügen folgende Direktive im Abschnitt <Directory /var/www/> hinzu:

FileETag NoneCode-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.confCode-Sprache: Bash (bash)

Füge die folgende Direktive im Abschnitt <Directory /> hinzu:

Header always append X-Frame-Options SAMEORIGINCode-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.confCode-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.confCode-Sprache: Bash (bash)

Füge die folgende Direktive im Abschnitt <Directory /> hinzu:

Header set X-Content-Type-Options "nosniff"Code-Sprache: Apache (apache)
Antwortheader mit X-Content-Type-Options

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.confCode-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.confCode-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)
Antwortheader mit Content-Security-Policy

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.confCode-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 FollowSymLinksCode-Sprache: Apache (apache)

in

Options -IndexesCode-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.confCode-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 headersCode-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.confCode-Sprache: Apache (apache)

Füge die folgende Direktive im Abschnitt <Directory /> hinzu:

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;SecureCode-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.confCode-Sprache: Bash (bash)

Wir ändern den Wert von

Timeout 300Code-Sprache: Apache (apache)

auf

Timeout 10Code-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.confCode-Sprache: Bash (bash)

Wir ändern den Wert von

MaxKeepAliveRequests 100Code-Sprache: Apache (apache)

auf

MaxKeepAliveRequests 10Code-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