SMTP: Was ist es und wie funktioniert es?

Wichtige Erkenntnisse

Maximale Sicherheit durch regelmäßige Updates
Keine ungewollte Informationspreisgabe
Restriktive Berechtigungen minimieren Risiken
Gezielte Verzeichniskonfiguration erhöht den Schutz

Das Internet steckt voller Cyber-Gefahren – und dein Webserver steht dabei an vorderster Front. Neben dem Code deiner Webseiten und Webanwendungen (z. B. dein CMS) spielt auch die Absicherung der Server-Basis eine entscheidende Rolle. Dazu gehören:

Die Serveranwendung selbst (häufig Apache oder Nginx)
Die Datenbankverwaltung (z. B. MySQL/MariaDB)
PHP und weitere Skriptsprachen

Hier erfährst du, wie du deinen Apache-Webserver absichern kannst, um Angriffe und Sicherheitsrisiken zu minimieren.

Schwachstellen vermeiden

Beim Absichern deines Webservers musst du zwei Arten von Gefahren berücksichtigen:

Sicherheitslücken in der Software
Konfigurationsfehler, die ungewollt Zugriff ermöglichen

Damit du dich vor Sicherheitslücken schützt, halte dich an diese zwei goldenen Regeln:

Halte deinen Webserver und alle Module immer aktuell!
Lade nur die Module, die du wirklich brauchst!

Zwar finden sich im Vergleich zu anderer Software in Apache relativ wenig kritische Sicherheitslücken, aber sie kommen doch vor. Die Schwachstellen-Datenbank CVE Details listet für die letzten 20 Jahre insgesamt 225 Lücken auf, von denen 14 in 2019 entdeckt wurden (vor Veröffentlichung aktualisieren – Daten zu 2020 noch nicht enthalten). Die meisten davon (79) sind Denial-of-Service-Schwachstellen (der Webserver reagiert nicht mehr), aber immerhin 25 würden sogar die Ausführung von unerwünschtem Code erlauben. Deshalb ist es wichtig, dass Web-Admins in Bezug auf mögliche Sicherheitsbedrohungen auf dem Laufenden bleiben und Updates zügig einspielen.

Nur benötigte Module laden

Apache lädt im Standard zahlreiche Module, von denen du wahrscheinlich nicht alle benötigst. Wenn du die für deine Anwendung überflüssigen Module deaktivierst, erhöhst du nicht nur die Sicherheit (die meisten Security-Schwachstellen stecken in Modulen), sondern verbesserst auch die Performance deines Servers. Allerdings lassen sich an dieser Stelle schlecht pauschale Empfehlungen aussprechen, nicht nur, weil es von deinen Anforderungen abhängt, was du deaktivieren kannst, sondern auch, weil Apache auf unterschiedlichen Systemen nicht die gleichen Module standardmäßig lädt (auf Ubuntu sind es wesentlich weniger als auf RHEL/CentOS).

Welche Module sind aktuell geladen?

Gib in der Kommandozeile folgendes ein:

Für Debian/Ubuntu:

apache2ctl -M

Für RHEL (CentOS, Fedora) und Windows:

httpd -M

Zur Deaktivierung eines Moduls verwendest du (auf Debian-basierten Systemen wie Ubuntu oder Linux Mint) den Befehl a2dismod zusammen mit dem jeweiligen Modulnamen. Ohne solche Angabe listet a2dismod dir alle Module auf, die du deaktivieren kannst, ohne Apache neu zu kompilieren. Informiere dich bei deinen Deaktivierungskandidaten im Zweifelsfall über Funktion und Abhängigkeiten und teste nach dem Deaktivieren (und Apache-Neustart) gründlich dein System.

Wie Apache kritische Informationen preisgibt – und wie du das verhinderst

Würdest du einem Hacker freiwillig mitteilen, mit welchen Softwareversionen von Anwendungen, Modulen oder Bibliotheken und mit welchen Einstellungen du deinen Webserver betreibst? Natürlich nicht, denn du weißt ja, dass sich ein Hacker mit diesen Informationen ganz gezielt auf bekannte Schwachstellen deines Systems konzentrieren kann. Dennoch fanden sich, wie die c’t berichtete, bei einem systematischen Test mehr als 70.000 de-Domains, bei denen solche Infos oder auch Benutzernamen, IP-Adressen von Besuchern und von diesen besuchte URLs oder Kennungen von Videokonferenzräumen öffentlich zugänglich waren. Zu den betroffenen Serverbetreibern gehörten auch große Organisationen wie Banken, das Bundesfinanzministerium und sogar IT-Sicherheitsspezialisten wie G-Data oder das BSI (CERT-Bund). Dies zeigt schon, dass es nicht immer ganz einfach ist, solche Effekte zu verhindern – dazu später mehr.

Apache gibt auf verschiedenen Wegen Informationen preis, die für den Admin nützlich, öffentlich sichtbar aber kritisch sein können. Das geschieht zum Beispiel in servergenerierten Seiten, z. B. Fehlermeldungen und Statusseiten, sowie in den Kopfzeilen von Antworten auf HTTP-Requests (HTTP-Response-Header). Im gerade erwähnten Test ging es um Infoseiten der Module mod_info (Serverkonfiguration) und mod_status (Server-Monitoring). Tipp: Auch diese beiden Module kannst du im Produktiveinsatz gefahrlos deaktivieren (siehe oben) und nur dann laden, wenn du entsprechende Infos brauchst.

Webserver absichern - Apache-Konfiguration bearbeiten

Um zu verhindern, dass die Ergebnisseiten von mod_info oder mod_status von jedermann gelesen werden können, musst du die Konfiguration anpassen. Auch das ist wieder betriebssystemabhängig und geschieht normalerweise für die meisten hier genannten Punkte in der Konfigurationsdatei httpd.conf oder in separaten Dateien, die per include in diese eingebunden werden (Infos dazu finden sich jeweils im einleitenden Abschnitt der httpd.conf). Damit Konfigurationsänderungen wirksam werden, musst du Apache neu starten.

Den Zugriff auf die Info- bzw. Statusseite schränkst du über eine Require-Anweisung ein, etwa auf bestimmte Rechner (ip / host) oder auf Anwendungen auf dem gleichen System (local), zum Beispiel:

<Location "/server-status">
    SetHandler server-status
    Require host example.com
    Require ip 192.168.1.10
</Location>

bzw.

<Location "/server-info">
    SetHandler server-info
    Require host local
</Location>

Aber Achtung: Läuft auf dem gleichen System etwa ein Loadbalancer, erscheinen Apache alle Requests von lokal zu kommen. Zudem können sich Konfigurationsanweisungen verschiedener Bereiche überlagern und dadurch unter Umständen wirkungslos werden (ein Beispiel finden Sie im oben verlinkten c’t-Artikel).

Apache kann auch in der Fußzeile von servergenerierten Standardseiten, etwa von Fehlermeldungen wie 404 Not Found“, Systeminformationen einblenden. Die entsprechende Einstellung ServerSignature ist allerdings im Standard deaktiviert (ServerSignature Off). Sicherheitsrelevanter ist Apaches Angewohnheit, in der Voreinstellung bei jeder HTTP-Anfrage Informationen über Serverversion, Betriebssystem und einkompilierte Module im Response-Header „Server“ mitzuliefern, zum Beispiel:

Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2

Mit der Einstellung ServerTokens (Standardeinstellung: Full) kannst du Apaches Auskunftsfreude zügeln: Durch

ServerTokens Prod

weise Apache an, sich im Server-Header auf die Nennung des „Produkts“ (Server: Apache) zu beschränken.

Berechtigungen

Grundsätzlich ist bei Webserver-Einstellungen ein möglichst restriktives Vorgehen ratsam. Das heißt: Erlaube jeder Benutzerrolle nur das, was für die Nutzung deiner Anwendungen jeweils erforderlich ist. Verlasse dich nicht darauf, dass du jegliche Kompromittierung deines Webservers verhindern kannst: Hacker versuchen mit zum Teil sehr ausgefeilten Methoden, etwa per SQL-Injektion oder Cross-Site-Scripting, sich die Rechte angemeldeter User zu verschaffen, und je mehr sie damit tun können, desto höher ist die Gefahr für deine Installation.

Dies ist auch der Grund, warum bestimmte Webserver-Prozesse nicht mit Root-Rechten laufen dürfen. Zwar werden Webserver mit Root-Rechten gestartet, damit sie auf Ports unterhalb von 1024 zugreifen können (Standard: Port 80 unverschlüsselt bzw. 443 verschlüsselt). Für die Beantwortung von Anfragen ist aber ein eigener, nur für den Webserver reservierter Benutzer ohne Root-Rechte zuständig. Würde dann trotz allem einmal dein Webserver gehackt, ist dadurch zumindest nicht der Rest des Systems gefährdet.

Apache erstellt dafür bei der Installation einen Default-User, in den der Webserver nach dem Start wechselt (bei Debian-basierten Linux-Distributionen wie Ubuntu heißt er www-data, bei RHEL/CentOS/Fedora apache; jeweils mit gleichlautender User Group). Wenn du einen eigenen Nutzer dafür brauchst, lege diesen per

sudo useradd [Benutzername]

an und konfiguriere ihn mit den Apache-Direktiven Group und User als Apache-Benutzer. Wie bei jeder Konfigurationsänderung ist dann ein Neustart des Webservers nötig:

apachectl -k restart (als root)

Achte auch darauf, dass die Schreibrechte für das Apache-Installationsverzeichnis (das du mit ServerRoot festlegen kannst, Standard ist „/usr/local/apache“), und seine Unterverzeichnisse („bin“, „conf“, „logs“) restriktiv gesetzt sind (chmod -r 755, nur Besitzer Root darf schreiben). Unter Umständen ist es sinnvoll, anderen Nutzern als Root auch das Anschauen von Programmverzeichnis und Konfiguration zu verbieten (chmod -r 750 bin conf).

Relevante Verzeichnisse

Aus Sicherheitsgründen nutzen Webserver auch ein eigenes Verzeichnis für die auszuliefernden Webseiten-Dateien, genannt „Document Root". In der Standardkonfiguration von Apache 2.x ist das „/usr/local/apache2/htdocs". Aber auch hier kochen verschiedene Distributionen ihr eigenes Süppchen: Bei Debian und Ubuntu heißt Document Root „/var/www", bei CentOS/RHEL/Fedora „/var/www/html". Willst du ein anderes Verzeichnis verwenden, lege das in der zentralen Apache-Konfigurationsdatei (üblicherweise httpd.conf) über die Direktive DocumentRoot fest.

Auch wichtig: Im „Server Root" genannten Verzeichnis, üblicherweise das Installationsverzeichnis, erwartet der Webserver standardmäßig Konfigurationsfiles, Logs, Module etc. Das Verzeichnis kann vor der Kompilierung festgelegt werden; Default ist bei Apache „/usr/local/apache2", bei Debian-basierten Linux-Distros „/ect/apache2" und bei CentOS/RHEL/Fedora „/etc/httpd". Die entsprechende Direktive ServerRoot in der httpd.conf wird bei der Installation automatisch gesetzt, kann aber bei Bedarf angepasst werden. Pfadangaben in der httpd.conf ohne vorangestelltes „/" bezieht Apache immer auf Server Root.

Lagerst du deine httpd.conf nicht am vorgesehenen Speicherort, kannst du das Apache beim Start mit der Option „-f" mitteilen, zum Beispiel:

apachectl -f /usr/local/apache2/myconf/httpd.conf

Einstellungen für Document Root

Document Root bezeichnet die Stelle im Verzeichnisbaum, von der aus der Webserver nach angeforderten Ressourcen sucht. Ist beispielsweise Document Root auf „/var/www" gesetzt und ein Client fordert eine HTML-Datei unter der URL „example.com/forum/index.html" an, sucht der Server im Dateisystem nach der Datei /var/www/forum/index.html. Er hängt also den Pfad aus der angeforderten URL (hinter dem Domainnamen) an Document Root an, um den Pfad zum Dokument zu ermitteln.

Die Ressourcen unter Document Root sollten nur Benutzer ändern können, die mit der Pflege deiner Website betraut sind. Der Webserver bzw. der für das Bedienen von Anfragen zuständige User (zum Beispiel www-data) muss Ressourcen zwar lesen und ausführen können, darf aber keine Schreibrechte haben. Du kannst als Besitzer der Daten und Verzeichnisse in Document Root also den User root angeben oder, wenn mehrere Personen Schreibrechte brauchen, dafür eine neue Gruppe anlegen, beispielsweise „www" mit einem ersten User. Auf Debian-basierten Systemen tust du das etwa mit:

sudo groupadd www
sudo adduser USERNAME www
sudo chgrp www /var/www/html
sudo chmod g+w /var/www/html.

Auch in der httpd.conf finden sich einige relevante Einstellungen für Document Root, definiert über die verzeichnisbezogene Direktive Directory. Im Einzelnen betrifft das die Direktiven AllowOverride, mit der du bestimmst, welche Konfigurationen per .htaccess-Datei überschrieben werden dürfen, sowie Require zur Zugriffsregelung und Options für Verzeichnisoptionen wie Verzeichnisbrowsing, symbolische Links oder Server Side Includes. In der Regel sind Verzeichnisbrowsing und symbolische Links für Document Root aktiv – hier solltest du ggf. nachbessern:

<Directory /var/www>		# gilt für Document Root = /var/www
Options -Indexes        	# Verzeichnis-Listing deaktiviert
# Einschalten entsprechend mit +Indexes
</Directory>

Dateien außerhalb von Document Root

Dateien, die für deine Website benötigt werden, aber nicht für die Allgemeinheit zugänglich sein sollten, lege besser in einem Ordner außerhalb von Document Root ab. Beachte aber auch, dass es etwa per Alias-Direktive oder über symbolische Links möglich ist, auch Dateien bzw. Verzeichnisse außerhalb von Document Root aus dem Web erreichbar zu machen. Damit wächst die Gefahr unautorisierter Zugriffe und erfolgreicher Hacker-Angriffe.

Deshalb solltest du darauf achten, dass die Verzeichniseinstellungen für dein Dateisystem sehr restriktiv gesetzt sind (neuere Apache-Versionen tun das bereits weitgehend) und nur bei Bedarf für bestimmte Verzeichnisse gelockert werden:

<Directory />    	# gilt für alle Verzeichnisse im Dateisystem
Require all denied 	# Zugriff auf Resourcen 
                        # wird verweigert
Options None		# Optionen nur bei Bedarf akivieren
AllowOverride None	# .htaccess-Dateien werden ignoriert
</Directory>

Dann gelten diese restriktiven Einstellungen für alle Verzeichnisse inkl. Document Root, sodass du dort keine eigenen Einschränkungen mehr vornehmen musst. Du kannst aber beispielsweise die .htaccess-Steuerung für Document Root oder Inhalteauflistung für ein Downloadverzeichnis explizit erlauben:

<Directory /var/www>		# gilt für Document Root = /var/www
Require all granted 		# Zugriff ohne Autorisierung erlaubt
AllowOverride All		# .htaccess-Dateien voll nutzbar
</Directory>

bzw.

<Directory /var/www/downloads>	# gilt für Download-Verzeichnis 
Options +Indexes		# Verzeichnis-Listing aktiviert
</Directory>

Das Prinzip ist klar: Verzeichnisspezifisch wird nur aktiviert, was benötigt wird. Dabei kannst du die Berechtigungen sehr detailliert regeln:

<Directory /example>
Options SymLinksIfOwnerMatch	#Besitzer von Link und Ziel
# sind identisch
Require group admin		# Zugriff nur für Mitglieder 
# der admin-Gruppe
</Directory>

Server Root schützen

Mit diesen <Directory />-Anweisungen ist auch das Server-Root-Verzeichnis inkl. Unterverzeichnissen bereits gut geschützt. Achte aber darauf, dass außer root niemand Dateien und Verzeichnisse in Server Root und seinen Unterverzeichnissen (bin, conf, logs) ändern darf (chmod 755, wenn root der Besitzer ist). Um sicherzustellen, dass die ausführbare Datei (httpd) nicht verändert werden kann, empfiehlt sich dafür chmod 511 (Besitzer darf lesen und ausführen, alle anderen nur ausführen):

chmod 511 /usr/local/apache2/bin/httpd

Außerdem empfehlen die Apache-Entwickler, die folgende Zeile in die Konfiguration aufzunehmen:

UserDir disabled root

UserDir macht Verzeichnisse registrierter Benutzer per URL verfügbar. Mit der genannten Einstellung verhinderst du Sicherheitsprobleme durch Fehlkonfiguration.

HTTP-Tricks zur Webserver-Absicherung

Neben direkten Angriffen auf den Server selbst nehmen Cyber-Kriminelle allerdings häufig auch die Kommunikation zwischen Webserver und Clients ins Visier. Code-Injection-Angriffe, zum Beispiel per Cross-Site-Scripting (XSS), versuchen dem Browser zusätzlich zu den angeforderten Inhalten eigenen Code unterzuschieben, der dann im Sicherheitskontext des Nutzers ausgeführt wird. Dieser Beitrag zeigt, wie du die Kommunikation zwischen Webserver und Browser beeinflussen kannst.

Webserver und Browser tauschen Nachrichten aus und bedienen sich dabei einer gemeinsamen Sprache: HTTP (Hypertext Transfer Protocol). HTTP ist ein Client-Server-Protokoll: Damit eine Interaktion zustande kommt, muss stets der Client zunächst eine Anfrage (HTTP Request) an den Server starten. Dieser beantwortet die Anfrage per HTTP Response. Beide Nachrichtentypen besitzen neben der Nutzlast (Daten) im Message Body auch einen Kopfzeilenbereich (Header) mit zugehörigen Informationen.

HTTP-Methoden einschränken

Anfragen können verschiedene HTTP-Methoden verwenden. Die häufigste Request-Methode ist GET zur Anforderung von Daten vom Server. Sollen dagegen Daten (z. B. Formulardaten) zum Server geschickt werden, eignet sich die POST-Methode. Während diese Methoden vergleichsweise unkritisch sind, können andere HTTP-Methoden leicht missbraucht werden. Durch PUT und PATCH kann beispielsweise bösartiger Code auf den Server gelangen, und per DELETE-Requests können Clients Ressourcen gezielt vom Server löschen. Unsicher ist auch die TRACE-Methode für die Fehlersuche. Sie kann für einen Angriff namens Cross-Site-Tracing verwendet werden, bei dem sich Dritte möglicherweise kritische Informationen wie Authentifizierungsdaten verschaffen können. Wenn deine Anwendungen diese Methoden nicht benötigen, kannst du sie deaktivieren.

Bis vor nicht allzu langer Zeit gab es bei Apache nur die Möglichkeit, mittels Limit- oder LimitExcept-Direktive die Nutzung bestimmter Methoden zu beschränken. Seit Apache 2.3 existiert mit der Direktive Require ein deutlich einfacherer Weg. Um für ein Verzeichnis oder eine Location ausschließlich die Methoden GET, HEAD, POST und OPTIONS zu erlauben, schreibst du in der zentralen Konfiguration (oder .htaccess, falls per AllowOverride AuthConfig gestattet):

Require method GET HEAD POST OPTIONS

Benötigen deine Applikationen auch andere Methoden, kannst du einen RequireAny-Container nutzen, um differenziertere Bedingungen zu formulieren.

Achtung: Leider kann keiner der genannten Wege die Methode TRACE einschränken; diese wird nur von der Direktive TraceEnable beeinflusst. Wer sie deaktivieren will, muss explizit TraceEnable off angeben (Standardeinstellung ist on).

Gefährliche Skripte

Gefahren lauern auch immer dort, wo der Browser Skripte ausführt, die nicht vom Website-Betreiber stammen. Clientseitiges Scripting per JavaScript ist heute für zahlreiche Funktionalitäten unabdingbar. Im Vergleich zu serverseitigen Skripten läuft es auch wesentlich schneller und ist damit benutzerfreundlicher. Die Kehrseite ist die Möglichkeit, dem Browser etwa per XSS bösartigen Code aus anderer Quelle unterzuschieben.

Zwar befolgen Browser seit vielen Jahren standardmäßig die „Same Origin Policy" (SOP), ein Sicherheitskonzept, nach welchem die Skripte auf einer Seite nicht auf Daten anderer Herkunft zugreifen dürfen. Dennoch finden Angreifer immer wieder Sicherheitslücken, die es ihnen erlauben, die SOP durch XSS-Attacken zu umgehen.

Besonders relevant ist hier die unzureichende Absicherung von benutzergeneriertem Input zum Beispiel in Kommentaren oder auf Profilseiten (Persistent XSS) oder in Suchformularen (Non-persistent XSS). Enthält solcher Input bösartigen Code, wird dieser womöglich beim Anzeigen ausgeführt, weil er aus Browser-Sicht die gleiche Herkunft hat wie die Webseite selbst. Solche untergeschobenen Skripte können je nach Sicherheitskontext des Aufrufenden sehr gefährlich sein, zum Beispiel bei angemeldeten Nutzern ganz ohne deren Zutun Cookies mit Authentifizierungsinformationen auslesen. Mit dem übernommenen Konto könnten Hacker dann vielleicht Daten stehlen, weitere Konten hacken oder, wenn es sich ein Admin-Konto handelt, die Website übernehmen.

Cookies schützen: HttpOnly und Secure

Ein Weg, um die Gefahr solcher Angriffe zu reduzieren, ist der Schutz von Cookies. Neben clientseitigen Methoden gibt es dafür auch Maßnahmen, die du als Server-Betreiber ergreifen kannst. Eine Möglichkeit sind die Header-Attribute HttpOnly und Secure.

Das Header-Flag HttpOnly verhindert, dass ein Cookie per JavaScript ausgelesen werden kann. Damit können viele XSS-Attacken vermieden werden. Das Secure-Flag wiederum sorgt dafür, dass ein Cookie nur über verschlüsselte Verbindungen (also über HTTPS) zum Server gesendet wird, was das Mitlesen per Man-in-the-Middle-Angriff erschwert. Cookies sollten stets das Secure-Attribut erhalten und zudem nur im Ausnahmefall, wenn JavaScript-Zugriff unbedingt erforderlich ist, ohne HttpOnly gesendet werden. Zusätzlich wird u. a. empfohlen, ihre Gültigkeitsdauer mittels Expires- oder Max-Age-Attribut so kurz wie möglich zu halten.

Zur Übermittlung und Ausgestaltung von Cookies dient der HTTP-Header Set-Cookie.

Bei Apache generierst du Set-Cookie-Headers mittels der Direktive Header, die auch in .htaccess-Dateien verfügbar ist. Das folgende Beispiel fügt die genannten Attribute an alle Set-Cookie-Header an, deren Cookie-Name mit „session_id" beginnt:

<IfModule mod_headers.c>
Header always edit Set-Cookie ^(session_id.*)$ "$1; Max-Age=900; Secure; HttpOnly"
</IfModule>

Das Ergebnis sieht also so aus:

Collapse

Set-Cookie: session_id=123abc456; Max-Age=900; Secure; HttpOnly

Weitere der Sicherheit dienliche Header sind die Folgenden:

#(Re-)aktiviert XSS-Filter aktueller Browser:
Header set X-XSS-Protection "1; mode=block"
#Frame-Einbettung beschränken gegen Clickjacking-Attacken
Header always append X-Frame-Options SAMEORIGIN
#Blockiert Content-Sniffing
Header set X-Content-Type-Options nosniff

Content Security Policy

Die genannten Security-Header können die Sicherheit erhöhen, bleiben aber Stückwerk. Um XSS-, Clickjacking- und andere Code-Injection-Angriffe zu verhindern, entwickelte Mozilla ein als „Content Security Policy" (CSP)" bezeichnetes Sicherheitskonzept, das heute von allen modernen Browsern unterstützt wird. Eine W3C-Empfehlung befindet sich in der Ausarbeitung.

Das Konzept: Um nicht autorisierte Skriptausführungen zu verhindern, soll sämtlicher JavaScript-Code in externe Dateien (oder alternativ in gehashte Code-Blöcke) ausgelagert und so strikt von HTML-Inhalten (auch dynamisch generierten) getrennt werden. Externe Skriptingcode-Dateien können nur aus einer vertrauenswürdigen Domäne aufgerufen werden. Der dynamische Inline-Aufruf von JavaScript-Code und CSS-Statements in HTML-/PHP-Dateien und die dynamische Code-Ausführung über bestimmte Funktionen sind nicht gestattet. Ein Browser setzt diese CSP um, wenn er einen oder mehrere Content-Security-Policy-Header in der Server-Antwort vorfindet. In diesen Headern teilt der Server dem Client konkrete Policy-Direktiven mit, insbesondere die vertrauenswürdigen Speicherorte für Skripte, Stylesheets, Fonts, Bilder, Objekte (Plugins) etc. Das folgende Beispiel verbietet die Inline-Ausführung von JavaScript-Code und verlangt, dass jegliche Ressourcen außer Bildern vom Ursprungsserver geladen werden (gleiche Domain, auch keine abweichende Subdomain gestattet):

Content-Security-Policy-Report-Only: default-src 'self'; img-src *;

Auch du solltest für deine Inhalte eine CSP definieren und einsetzen.

Übrigens: Diese kann auch im HTML-Dokument per Meta-Tag aktiviert werden.

Webserver absichern mit HTTP-Tweaks

Ein weiterer Weg, die Sicherheit deines Webservers zu erhöhen, sind HTTP-Tweaks – die Beeinflussung des Antwortverhaltens des Servers. Neben den schon erwähnten Maßnahmen zum Infoverhalten gehören dazu beispielsweise auch die Beschränkung der zulässigen HTTP-Methoden für Requests (etwa per LimitExcept) oder die gezielte Konfiguration von Antwort-Kopfzeilen per Header.

Zu guter Letzt: Auch Profis kann es passieren, dass sie eine unsichere Einstellung ihrer Webserver-Konfiguration übersehen. Deshalb empfehlen wir dir, auch einen Blick auf nützliche Tools und Module zu werfen, die deine Konfiguration auf Fehler überprüfen, Einstellungen vorschlagen oder als Firewall gegen DDoS- und andere Attacken fungieren. Oder schaue dir gleich Website Security an, das Ihnen darüber hinaus auch noch einen Rundum-Schutz inkl. Malware-Scans und -Beseitigung bietet.