IT Security in Web Anwendungen VI – Web Server Security

Doğan Uçar
IT Security in Web Anwendungen VI - Web Server Security
Server Hard Disks, Foto @Pexels/panumas nikhomkhai

In dem sechsten Teil der Blogserie „IT Security in Web Anwendungen“ thematisieren wir Web Server, ihre Abhärtung gegenüber Angreifer und böswilligen Attacken sowie Tipps im Bezug auf Prävention und Monitoring. Anhand konkreter Beispiele – aufgezeigt mit dem Apache Web Server – wollen wir die wichtigsten Punkte im Bezug auf IT-Security im Web Server-Umfeld aufzeigen und Best Practices auflisten.

In unserem ersten Post dieser Blogserie sind wir das Thema „Injections“ angegangen und haben gezeigt, wie diese zustandekommen bzw. zu verhindern sind. In dem zweiten Teil der Serie sind wir auf  File Up-/Download und Storage eingegangen und haben allgemeine Sicherheitsrisiken sowie Prävention und Alternativen aufgelistet. In dem dritten Teil thematisieren wir Sessions und Session Hijacking-Attacken sowie einen möglichen Schutz gegen solcher Attacken. Der vierte Teil thematisierte das HTTP(S)-Protokoll im Allgemeinen und ist auf sicherheitsrelevante Aspekte eingegangen. In dem fünften Teil beschäftigten wir uns mit Datenbanken und wie man sicher mit ihnen kommuniziert.

Alle Posts dieser Blogserie sind unabhängig voneinander und das Lesen der vorherigen Posts ist keine Voraussetzung. Zu dem besseren Verständnis zu dem Thema „IT-Security“ empfehlen wir jedoch bei Post #1 anzufangen. Da alle vorangegangenen Posts im Web-Umfeld thematisiert werden, ist es empfehlenswert zumindest die Grundkenntnisse zu haben.

In dem kommenden Posts der Blogserie möchten wir uns tiefergehend mit den verschiedenen Bereichen der IT Security beschäftigen. In insgesamt neun Blogposts möchten wir tiefergehend auf verschiedene Szenarien eingehen, mögliche Schutzmechanismen präsentieren und diese – wenn möglich – durch praktische Beispiele demonstrieren. Nach Blogpost #9 werden wir diese Serie und weitere Tipps und Tricks als PDF zur Verfügung stellen. Sie können sich unter dem nachfolgenden Formular zum Newsletter anmelden, um das PDF zu erhalten:

Web Server und Security

Ein Web Server ist ein Programm auf einem (Linux-)Server, welcher die Eigenschaft besitzt mit anderen Servern über z.B. TCP oder UDP sicher zu kommunizieren. Aufgrund der (sensiblen) Daten, die auf einem Web Server gespeichert sind, gehören sie zu den öffentlichen digitalen Bereichen, die am häufigsten angegriffen werden. Daher ist es genauso wichtig, den Web Server selbst so wie die Web Anwendung bzw. das umgebende Netzwerk zu sichern. Haben Sie eine sichere Web Anwendung und einen unsicheren Web Server (oder umgekehrt), sind Sie in den allermeisten Fällen nicht geschützt. Denn es gilt: Sicherheit ist nur so stark wie eine Schwachstelle. Und außerdem: Standardeinstellungen sind in der Regel nicht ausreichend im Bezug auf Schutz vor Angriffen aus dem Internet.

Zwar existieren viele Web Server Implementierungen wie Apache, Nginx, Lightpd oder IIS von Microsoft. Jedoch dominiert Apache mit mehr als 35% Anteile den Markt und ist relativ stabil, weswegen wir uns im Nachfolgenden auf diesen konzentrieren. Die Punkte und Tipps gelten jedoch ebenfalls für anderen Server und weichen meist nur sehr wenig von einander ab.

Eines der wichtigsten Punkte ist die sichere Kommunikation zwischen Client und Server. Der Web Server sollte so konfiguriert sein, dass unverschlüsselte Verbindungen (z.B. über HTTP anstelle HTTPS) nicht akzeptiert wird. Mehr zu dem Thema HTTP(S) finden Sie in unserem Blogpost #4. SSL/TLS erschwert Cross-Side-Scripting-Attacken (siehe #1) und verhindert das Mitlesen der Kommunikation zwischen beiden Parteien (die sogenannte „man-in-the-middle“-Attacke). Waren SSL-Zertifikate früher teuer und hatten u.U. eine kurze Laufzeit, gibt es sie heutzutage gratis und automatisierte Tools helfen bei dem Erneuern. Ohnehin verweigern moderne Browser wie der Chrome, Firefox, Edge und Safari das Öffnen von HTTP Webseiten. Trotzdem sollten Sie SSL-Zertifikate nicht als Selbstläufer sehen. Administratoren sind angehalten konstant Zertifikate auf Gültigkeit und/oder schwache Verschlüsselung zu prüfen und notfalls auszutauschen.

Faustformel: so wenig wie möglich (von allem)

Die Devise ist denkbar einfach und genau so effektiv: je weniger Services auf dem Server laufen desto weniger wahrscheinlich ist ein Sicherheitsvorfall. Denn mehr Software bedeutet mehr potenzielle Sicherheitslücken und mehr Software, die betreut und gewartet werden muss.

Die Liste lässt sich beliebig erweitern, wie in etwa: je weniger Menschen (SSH-)Zugang bzw. je mehr Clients öffentlichen Zugriff oder je mehr Dateien Sie auf Ihrem Server liegen haben, desto höher ist das Sicherheitsrisiko. Deaktivieren Sie das Auflisten von Web Server Verzeichnissen und stellen Sie sicher, dass Metadaten wie z.B. der fälschlicherweise hochgeladene .git Ordner oder Backups im Web Root enthalten sind. Navigieren Sie zum Deaktivieren der Verzeichnisse in die Apache Konfigurationsdatei für den vhost der Appklikation und suchen Sie nach der directory Direktive für das Root Verzeichnis, um Options -Indexes hinzuzufügen. Protokollieren Sie Zugänge und insbesondere Zugangsversuche und benachrichtigen Sie Administratoren. Beschränken Sie den Zugriff auf ein Minimum indem Sie z.B. Whitelists über IP Adressen führen. Bewerten Sie jeden Service, jedes Programm und jeden Zugriff in festen Zeitintervallen neu und entfernen oder limitieren Sie wenn nötig.

Ist einem Service oder einem Benutzer erst einmal der Zugriff gewährt, gilt weiterhin: je weniger Berechtigungen, desto kontrollierbarer ein Sicherheitsvorfall. Beispielsweise muss nicht jeder Benutzer gleich root Zugriff erhalten oder nicht jeder Service als root laufen.Verweigern Sie standardmäßig alle Zugriffe auf allen Resourcen und Services. Führen Sie ein zu Ihnen passendes Zugangskontrollsystem ein und setzen Sie es konsequent auf allen Ebenen Ihres Web Servers um.


Sicherheit durch Open Source

Kennen Sie schon unseren Open Source Passwort Manager Keestash? Wir bieten für Unternehmen, Teams und Endnutzern sicheres Verwalten von Passwörtern. Auf Wunsch hosten wir Keestash für Sie oder Sie installieren Keestash auf Ihre eigene Hardware.

Interesse? Schreiben Sie uns einfach eine E-Mail oder testen Keestash einfach unter app.keestash.com

Halten Sie alle Services aktuell

Alle großen und seriösen Anbieter von Software Services bieten regelmäßig Updates und insbesondere Sicherheitsupdates an. Halten Sie sich auf dem Laufenden bzgl. ihrer verwendeten Services und installieren Sie alle Updates zeitnah. Dies schließt das Betriebssystem mit ein. Insbesondere bei Sicherheitsupdates sollten Sie nicht lange zögern: ist eine Lücke erst einmal öffentlich bekannt, ist es nur eine Frage der Zeit bis Angreifer entsprechende Szenarios zum Ausnutzen der Lücke aufbereiten bzw. aktiv ausnutzen. Es gibt keinerlei Garantie dass Ihr Web Server nicht das nächste Ziel sein könnte.

Darüber hinaus können Apache Module wie mod_security und mod_evasive helfen. Ersteres ist eine Open-Source-IDS- und Präventions-Engine, während Letzteres Ihren Web Server mit eingebauten Schutzmaßnahmen ausstattet, wenn es feststellt, dass Ihre Anwendung möglicherweise angegriffen wird. „IDS“ steht für „Introdusion-Detection-System“.

mod_security fungiert als zusätzliche Firewall für den Web Server, die es Ihnen ermöglicht, den Datenverkehr in Echtzeit zu überwachen und gleichzeitig Verbindungen zu verhindern, die potenziell Brute-Force-Attacken darstellen. mod_evasive hilft, DDOS-Angriffe zu verhindern, indem es Verbindungen schließt, wenn zu viele Anfragen zu einer bestimmten Anwendung zu schnell eingehen.

Separieren Sie Test- und produktive Server

Auch wenn dieser Punkt banal klingt: er ist von großer Bedeutung. Auf Testumgebungen können Features getestet und Schwachstellen, die in der Entwicklung nicht aufgefallen sind, behoben werden. Beispielsweise kann ein E-Mail-Feature, welches sensitive Informationen beinhaltet, davon abgehalten werden (an falsche Empfänger) abgeschickt zu werden.

Auf Testumgebungen sollten Sie andere Zugangsdaten wie auf der produktiven Umgebung haben. Dies gilt für alle Services, die sie nutzen. Um bei dem E-Mail-Beispiel zu bleiben: wenn Sie für Ihren Test und produktiven E-Mail-Server die gleichen Zugangsdaten hätten, wäre es einfach (und nur eine Frage der Zeit) die Server zu verwechseln. Test-E-Mails würden an den produktive E-Mail-Server gehen und die E-Mails würden an Benutzer geschickt.

Achten Sie auf Angaben in dem HTTP Header

Web Server und Services hängen wertvolle Informationen an den HTTP Header. Diese können je nach Einstellungen auch in produktiven Umgebungen angeschaltet sein. Zwei von diesem stechen besonders hervor: Die Angabe über den eingesetzten Web Service inkl. Version (z.B. Apache) und die Angabe der Programmiersprache (z.B. PHP) und Version. Hat der Web Server oder die Programmiersprache in der angegebenen Version eine Schwachstelle, kann diese Information genutzt werden, um Ihren Server zu anzugreifen.

Die Web Server Angabe schalten Sie mit der Direktive ServerSignature On | Off in der Apache Konfiguration an oder aus. Die PHP Informationen können Sie in der PHP Konfigurationsdatei mit expose_php On | Off an- oder abschalten.

Des Weiteren sollten sie die HTTP Header TRACE und TRACK in der Apache Konfiguration ausschalten. TRACE und TRACK sind dazu gedacht, Verbindungen zu Web Servern zu debuggen und TRACE könnte u.U. HTTP Header (insbesondere Cookies) auslesen und an Angreifer weiterleiten. TRACE und TRACK können Sie mit TraceEnable On | Off abschalten.

Nutzen Sie „Environment As Code“ Lösungen

Viele Server im Einsatz bedeutet vor allem: viel Arbeit. Alleine die Umsetzung der im vorhergehenden Abschnitt genannten Direktiven verlangt das Einloggen auf allen Server Instanzen und Editieren von Konfigurationsdateien. Zur Minimierung potenzieller Fehler und zum Einsparen wertvoller Zeit sollten Sie „Environment As Code“ Lösungen wie Puppet, Ansible, Chef oder Docker einsetzen. So können Sie Ihre Änderungen testen und nach Fertigstellung auf eine zentralen Verwaltungsinstanz hochladen. Ihre Server ziehen sich dann die neuen Konfigurationen und setzen sie automatisch.

Der Einsatz von den genannten Tools bringt nicht nur Zeitersparnis mit sich. Sie können auf diesem Wege auch mit minimalem Aufwand neue Server hochfahren. Des Weiteren können Sie den Code in einem Versionsverwaltungssystem wie git verwalten, damit Sie Änderungen nachvollziehen und ggf. rückgängig machen können.

IT Security mit Ucar Solutions

Wir bieten Ihnen vollumfänglichen System- und Source-Code Audit zum Absichern Ihrer Datenbanken, Server und Anwendungen gegen eine Vielzahl potenzieller Sicherheitsrisiken und weiteren sicherheitsrelevanten Aspekten. Durch automatisierte und manuelle Prozesse helfen wir Ihnen, Ihre sensiblen und geschäftskritischen Informationen zu schützen und die geltenden Gesetze einzuhalten.

Unsere automatisierten Tests beinhalten u.a. Penetrationtests, toolbasierte Codeanalyse und -dokumentation. Darauf aufbauend analysieren wir den Source-Coden persönlich, versuchen die Architektur zu verstehen und mögliche Probleme bzw. Vorschläge in dem Zusammenhang zu identifizieren bzw. unterbreiten.

Des Weiteren agieren wir auch als „Software-as-a-Service“ (kurz SaaS) Vendor und bieten Ihnen verschiedene Teil- oder Vollkomponenten als Software-Service an, welche vollumfänglich, unter Berücksichtigung aller o.g. sicherheitsrelevanten ununterbrochen zur Verfügung stehen. So können Sie sich um Ihre Anwendung kümmern während wir Teilbereiche zur Verfügung stellen.

Nutzen Sie das nachfolgende Kontaktformular und kontaktieren Sie uns heute noch für ein unverbindliches Erstgespräch. Wir freuen uns darauf!