Webanwendung absichern (Wordpress und co)

[CyberNation_RX]

Hallo zusammen,

ich möchte einige Webanwendungen auf meinem Webserver besser absichern.

Ziel ist es, dass der Server 'Clean' bleibt wenn eine Webanwendung gegen eine Remote-Code Executable Schwachstelle oder ähnliches verwundbar ist. Daher möchte ich mich nicht nur auf die Eingeschränkten Rechte des Webservers verlassen, da diese ggf. durch einen Privilege Escalation Exploit erweitert werden können.
Daher suche ich nach geeigneten Möglichkeiten die Anwendungen zu Sandboxen/Isolieren.
Hier stellen sich folgende Fragen:

Wie viel Sicherheit würde eine Docker Installation der Dienste bringen?

Reicht es aus PHP zu Sandboxen?
Wahrscheinlich nicht da evtl. file_upload Schwachstellen

Kennt wer sonst noch geeignete Lösungen für Linux Server?
Webserver könnte man unter Firejail laufen lassen, dann bräuchte man aber für jede Anwendung einen eigenen Webserver

 

[N1truX]

Naja, die "Haudrauf-Methode" wäre es jede Webseite in eine einzelne VM auszulagern. Da dürfte es für Angreifer schon relativ schwer werden aus der VM auszubrechen.

Andernfalls frage ich mich, welchen speziellen Angriffsvektor Du da genau im Auge hast. Wenn alle Zugriffsrecht ordentlich konfiguriert sind und die Software auf dem aktuell Stand sollten Angreifer wenn dann höchstens Seite X manipulieren können (Dateien, Datenbanken etc.) oder im Extremfall gleich den kompletten Server mit einem Zero Day Exploit. Aber etwas dazwischen erscheint mir recht exotisch.

PS: Ich denke PHP in eine Sandbox zu packen wird vergleichsweise wenig bringen. Dank open_basedir kann man mit PHP schwerlich aus dem vhost (webseite) ausbrechen und wenn die Angreifer eine Ausführbare Datei mit entsprechenden Rechten auf dein System bekommen, ist PHP wohl das geringste Problem^^

 

[CyberNation_RX]

@N1truX
Stimmt, mit VMs und Port-forwarding wäre das möglich. Und solange man nicht VMware nutzt (https://www.heise.de/newsticker/meldung/Hacker-brechen-aus-virtueller-Maschine-aus-3658416.html) ist das sogar relativ sicher
Weiterleiten könnte man die VHosts dann als transparenten Proxy an die jeweilige VMs.
Das wäre allerdings schon ziemlicher Aufwand und würde sehr viele Ressourcen kosten.

Mein Ziel ist es einfach noch einen zusätzlichen Sicherheitslayer einzubauen. Eine gut konfigurierte Sandbox sollte es schaffen die meisten normalen ZeroDay Exploits einzuschränken, da um aus der Sandbox auszubrechen diese in den meisten Fällen zusätzlich angegriffen werden müsste.

 

[fax668]

Du könntest den Webserver in ein chroot packen, das ist nicht so aufwendig wie z.B. firejail.

Eine physisch oder virtuell getrennte Box, d.h. einen Load Balancer bzw. Proxy hängt praktisch jeder professionelle Webdienst da draußen vor seine Webserver. So muss ein Angreifer erst mal diese Maschine übernehmen bevor er die Maschine mit dem Webserver hacken kann.

 

[mensch183]

eine Webanwendung gegen eine Remote-Code Executable Schwachstelle oder ähnliches verwundbar ist. Daher möchte ich mich nicht nur auf die Eingeschränkten Rechte des Webservers verlassen, da diese ggf. durch einen Privilege Escalation Exploit erweitert werden können.

Auch VMs, Jails, diverse Container, Sandkästen u.ä. sind nicht 100%ig gegen einen Ausbruch sicher. Das sind auch alles nur verschiedene Formen von "eingeschränkten Rechten". Die zusätzliche Komplexität durch weitere, von dir manuell gestrickte "Sicherheitsverbeserungen" macht die Gesamtlage wahrscheinlich nicht besser sondern vergrößert ggf. gar die Angriffsfläche.

Konzentriere dich darauf, deinen Webserver und die Anwendungen ordentlich auszuwählen, ordentlich zu konfigurieren und aktuell zu halten. Baue keinen esoterischen Sicherheitspopanz auf sondern betreibe nur die sowieo nötigen Komponenten nach den sehr gut dokumentierten "best practices". An _dieser_ Stelle haben Admins i.d.R. versagt, wenn ihre Systeme Opfer von Angriffen wurden. Beschäftige dich also lieber _intensiv_ mit deinem Webserver und den Anwendungen, statt dies zu unterlassen und zu versuchen, Angriffe wegen Fehlkonfigurationen durch Installation von Drittsoftware abzufangen, die sonst gar nicht abzufangen wären. Dein Viel-Hilft-Viel-Wischiwaschi (Antwort #3, 2. Absatz) ist der falsche Weg.

Die von dir so wenig wertgeschätzten, normalen, sehr simplen "Eingeschränkten Rechte des Webservers", die im Zusammenspiel Webserver + OS-Kernel Sicherheitsgarantien bieten, gehören zu den am besten untersuchten Absicherungen die es gibt. Nutze diese korrekt und verlass dich auf sie!

Wenn du nicht gerade einen der superduperwichtigsen Webserver der Welt betreibst, sind ZeroDay Exploits für dich übrigens gar keine relevante Bedrohung. Niemand würde mit sowas wertvollem irgendwelche Feld-Wald-Und-Wiesen-Webserver angreifen, weil er dabei jedes Mal das Risiko eingeht, dass der wertvolle Exploit bekannt wird. Wird der Exploit bekannt, patchst du zeitnah deine Server und bleibst auf der sicheren Seite.

Lies die Mailinglisten zu Updates der von dir verwendeten Softwarekomponenten mit, wenn du dich nicht auf einen OS-Anbieter (z.B. die Linux-Distro) verlassen möchtest. Ohne Updates läuft gar nichts.

Sieh mehr dich selbst in der Admin-Rolle als Sicherheitsproblem, nicht den bösen, supertalentierten Hacker, der es ausgerechnet auf deine Server abgesehen hat.

 

[Piktogramm]

Das was mensch183 sagt, wenn wordpress mit ein paar Plugins laufen, dann musst du davon ausgehen, dass die Masse an automatisierten Angriffen genau dagegen laufen wird. Solang die Services wie der Webserver aktuell gehalten werden, ist es in der Regel kein nennenswertes Problem, dass Services direkt angegriffen werden. EIn typisches Problem solcher Gebilde wie du es vor hast ist im übrigen, dass sich kein Schwein drum kümmert die in der VM bzw. im Container laufenden Anwendungen zu aktualisieren. Wobei es im Endeffekt egal ist ob ein gekapertes Wordpress auf der nativen Maschine oder im Container als DDoS Bot agiert -.-

Das was du als Angriffsszenario beschreibst ist hingegen sehr aufwendig und bevor du dir solche Angriffe einhandelst musst du wirklich die falschen Leute verärgern.

 

[snaxilian]

+1 für mensch183

Sofern du mehrere Webseiten betreibst, kannst du natürlich diese voneinander trennen indem du jede in einen Container (Docker oder LXC) packst. Alternativ kannst du Zugriffe untereinander durch SELinux absichern, ist aber nicht ganz so trivial einzurichten.

Deine Anwendungen an sich, sofern sie sicher eingerichtet und aktuell sind, kannst du noch mit mod_security etwas absichern aber auch hier reicht nicht die reine Installation sondern du musst die Regeln auch aktivieren und pflegen.

Ebenso für jeden Dienst einen anderen Nutzer mit so wenig Rechten wie möglich + sichere Kennwörter. Bei Remote-Anmeldung im besten Fall nur mit public key arbeiten, z.B. bei SSH.

 

[CyberNation_RX]

+1 für eure Antworten

Eure Aussagen treffen es ziemlich genau. Ich alle nicht Web-Anwendungen(mit Netzzugang außer SSH) auf meinem Server schon durch Firejail und SELinux abgesichert. Allerdings trifft ihr das Problem zu, dass sich Updates schwieriger gestalten und deshalb meist erst verspätet aufgespielt werden. Der Server kann vlt. nicht komplett übernommen werden, aber der Punkt das dieser zum DDOS missbraucht werden kann trifft voll zu.

Ich nutze bereits SE-Linux auf meinem Webserver (was die Einrichtung und Updates von Webanwendungen auch etwas aufwendiger macht). Werde mich vermutlich mit einem zusätzlichen Chroot pro Anwendung begnügen.

Der Hinweis mit den "Mailinglisten zu Updates" ist ebenfalls sehr wichtig. Ich nutze beispielsweise RSS Feeds zu neuen CVEs zu von mir genutzten Anwendungen.

Nochmal vielen Dank für eure Hinweise

Ergänzung (2. April 2017)

Edit:
Aber eins würde mich noch interessieren. Machen Docker Container bzgl. Sicherheit Sinn? Oder bringen diese so gut wie gar nichts?

 

[Snowiron]

Docker macht schon Sinn, da es einen zusätzlichen Layer gibt. Allerdings war Docker nie auf Sicherheit getrimmt bzw. nie im Fokus. RKT von CoreOS ist da schon aus meiner Sicht als sicherer einzuschätzen. Hier noch etwas Lesestoff zu Containersicherheit: https://www.nccgroup.trust/globalas...erstanding_hardening_linux_containers-1-1pdf/

 

[Piktogramm]

Eine einzelne technische Lösung bringen keinen Nennenswerten Unterschied. Sicherheitskonzepte machen einen Unterschied und diese können Technologien einbinden.

Services zu trennen kann sinnvoll sein, kann aber auch negativ sein. Webserver vom Datenbankserver zu trennen bringt nicht soviel, denn Daten müssen die in der Regel so oder so austauschen und damit gibt es Schnittstellen, die auch Angreifer nutzen können. Dafür steigert sich aber mitunter der Verwaltungsaufwand, was das ausrollen von Updates ausbremsen kann und damit überwiegt dann die negative Wirkung.

Andererseits bedeutet ein Container, dass man eigene Services bei Updates "nur" gegen die Umgebung die der Container zur Verfügung stellt testen zu müssen anstatt auf verschiedenen Systemen. Gleichzeitig lassen sich de Container dann gut auf div. Systemen ausrollen. Damit kann sich die Geschwindigkeit erhöhen mit denen du getestete (!) Updates ausrollen kannst -> Bringt einen Mehrwert.

Also mach ein paar Entwürfe wie du mit welchen Technologien reagierst wenn dir Dienste übernommen
wurden, wie du kritische Fehler schnell abstellen kannst bzw. Updates zeitnah ausrollst. Kontrolliere ob das klappt und der Weg du du am besten handhaben kannst und bei dem der Updatepfad auf absehbare Zeit sicher zur Verfügung steht. Dabei am besten gleich den Backup & Restore Workflow mit einbinden. Ziel sollte sein, dass du einen sicheren Plan A hast, Plan B ohne Aufwand kurzfristig einsetzbar ist und ein Plan C als belastbares Konzept vorhanden ist.


##########################################

@Snowiron
Zusätzliche Schichten einzuziehen um deren Selbst willen ist kontraproduktiv. Damit erhöht sich die Komplexität auf jeden Fall, die Anfälligkeit für Angriffe beeinflusst in erster Linie aber negativ, da komplexere Systeme eine größere Angriffsfläche bieten und eine größere Chance, dass beim Konfigurieren Fehler gemacht werden.

 

[fax668]

Wenn du schon mit SE-Linux und Co rummachst, würde ich auch mal einen Blick über den Zaun zu OpenBSD empfehlen. Einiger neuer Kram wie Docker läuft dort nicht, dafür wird das BS schon seit zwei Jahrzehnten sehr sorgfältig und gründlich weiterentwickelt und man setzt auf bewährte und bekannt sichere Technologie (und mistet nebenbei solche Sauställe wie OpenSSL aus).

 

[Kanibal]

Ich halte relativ viel von seccomp-Filters. Grob gesagt ist das ein Mechanismus, um die syscalls von Userspace Anwendungen einschränken zu können. Beispielsweise lässt sich dadurch verhindern, dass der Webserver-Prozess mount-Calls an den Kernel absetzt. Einige Exploits in letzter Zeit haben das beispielsweise verwendet, um aus Sandboxen auszubrechen.
Für nginx gibt es hier ein schönes Tutorial.

Erste Priorität sollte aber natürlich sein, den Webserver und die Webanwendungen aktuell zu halten. Wordpress ist berüchtigt für seine fiesen Sicherheitslücken, da viele Admins ihre Systeme leider nicht ausreichend warten und updaten.

 

[mensch183]

Für nginx gibt es hier ein schönes Tutorial.

Schön? Dieses Vorgehen ist vollkommen Banane. Der Autor merkt selbst an: "This list is usually not complete and we’ll need some additional trial and error." - eben. Mit seiner Methode weiß man nie, ob der Filter nun endlich alles nötige enthält oder immer noch nicht, d.h. die Chance ist hoch, dass der Servers genau dann aufgrund des Filters abgeschossen wird, wenn er mal irgendwas halbwegs außergewöhnliches zu tun hat. Sich in spannenden Betriebsphasen ggf. vorsichtshalber selbst ins Knie zu schießen ist nur in wenigen Szenarion eine gute Strategie. Untauglich für Endnutzer.

 

[Kanibal]

Untauglich für Endnutzer.

Ich gehe absolut mit, die Methodik in der Anleitung ist eher fragwürdig. Die Einschätzung als "schönes Tutorial" meinerseits war etwas voreilig.

Ob es aber "Untauglich für Endnutzer" ist, möchte ich gerne zur Diskussion stellen. Im Zweifel ist es doch besser, wenn das System nicht mehr zur Verfügung steht (DoS), als dass es zu Code Execution / Data Leak kommt. Ich überlege gerade, wie man die Matrix der benötigten Syscalls auf formale Art und Weise ermitteln könnte. Das müsste doch über eine statische Analyse einer sauberen Binary möglich sein?