abgekapseltes Webspace aufm Server

Mr.Tr33 · 12/28/2016, 16:35

Hallo,

ich habe für ein kleines Projekt en Ubuntuserver worauf ich ein minimales Webspace packen möchte.
Das Webspace soll jedoch vollständig abgeschottet sein, sprich wenn ich "gehackt" werde über die Weboberfläche, dass der Angreifer nicht weiter kommt als das Webspace selbst.

Ich habe keine Ahnung vom Hosting oder Linux, jedoch kann ich kein einfaches Webspace nehmen.

Ich habe mir Docker angeschaut, aber mir wurde gesagt, dass bei jedem Neustart die Daten zurück gesetzt werden. Das ist bei mir ziemlich unpraktisch.
Es sollte aber irgendwie Ressourcenfreundlich sein.

Wie man früher schön sagte, ich bin ein völliger "noob" und hoffe um eure detaillierte Hilfe

Entonsammler · 12/28/2016, 20:30

Falls der Webspace nicht öffentlich zugänglich sein muss kannst du ihn mit ner htpasswd absichern.

Mr.Tr33 · 12/28/2016, 22:12

Mir gehts nicht direkt ums absichern vom Server. Ich muss erstmal so ein Webspace irgendwie hinbekommen, dass von sich aus sicher ist.
Am Ende muss es von aussen zugänglich sein.

Der-Eddy · 12/28/2016, 23:33

Die beste Möglichkeit wäre wenn du einen virtuellen Server erstellen könntest

Wenn das keine Option ist (Ressourcenfressend), dann wäre überhaupt die Frage wo bei deiner Webseite die Angriffsmöglichkeiten liegen
Wird PHP und oder eine Datenbank genutzt?
=> Vielleicht überlegen nicht einen externen Webspace zu mieten? Standard Webspace Server gibts schon für 1~2€ im Monat und man muss selber nicht um die Pflege kümmern

Ansonsten wenn es eine reine HTML Seite werden kann (z.B. Blog über jekyll oder ein statisches Resume), dann einfach Lighttpd drauf und fertig (Tausend mal Ressourcen sparender als Apache2)

Quote:

Originally Posted by Mr.Tr33

Ich habe mir Docker angeschaut, aber mir wurde gesagt, dass bei jedem Neustart die Daten zurück gesetzt werden.

Nope, so ganz stimmt das nicht
Ich hab jetzt auch aber auch nicht die krasseste Docker Expertise

Zypr · 12/29/2016, 00:09

Generell ist es aufgrund des in Linux eingesetzten Rechtesystems heutzutage fast gar nicht mehr möglich auf Dateien zuzugreifen, die sich außerhalb des Webroots befinden. Wenn du PHP nutzt, dann kannst du trotzdem noch was tun und solltest dir open_basedir und sessions.save-path anschauen:

Christoph Fischer hat das auf seiner Seite ziemlich gut zusammengefasst:

Falls du HHVM nutzt, damit kannst du die Einstellungen auch verwenden.

Mr.Tr33 · 12/29/2016, 00:17

Es ist ein internes Projekt von mir was eine Webseite "enthällt", daher ist ein externes Webspace ausgeschlossen. Grundsätzlich sollte niemand ungewolltes drauf kommen, aber man weiß ja nie.

Die Webseite ist mit PHP und MySQL geschrieben und habe nginx genommen.

Meine Idee war z.B. Froxlor zu nehmen und ein Webspace zu erstellen, es sollte ja die Berechtigungen schon richtig setzen. Jedoch kommt Froxlor nicht drauf klar, wenn es keine Domain hat

Eigentlich suche ich nur eine einfache Möglichkeit irgendwie einzustellen, dass wenn jemand aufs Webspace kommt, dass er nicht weiter als der Webspaceordner gelangt und keine Rechte hat irgendwas auszuführen. Würde dafür schon open_basedir und sessions.save-path schon reichen?

Und danke für den Link zu Christoph Fischer, werde es gleich mal genauer lesen

Zypr · 12/29/2016, 04:40

Das reicht vollkommen aus. Du musst bedenken, dass der Prozess von nginx selbst, sofern du es nicht absichtlich abgeändert hast, auch nur auf einen bestimmten User beschränkt ist.. also in der Regel den User nginx oder www-data und die haben auch durch das Linux Datei-Rechtesystem ihre Limitierung was Zugriffe auf Dateien angeht. Zusätzlich arbeitest du bei nginx (und auch Apache) mit virtuellen Umgebungen (Virtual Hosts), dort definierst du das root-Verzeichnis ja auch noch mal und beschränkst den Zugriff zusätzlich. Da nginx die PHP-Skripte selbst gar nicht ausführt, sondern per Socket oder TCP/IP an den PHP FPM (FastCGI Process Manager) weitergibt, gilt hier auch lediglich die Beschränkung, die der Webserver und PHP an sich schon mitbringen. Durch open_basedir und sessions.save-path machst du das Ganze noch explizit, sodass niemand durch eine Injection in irgendeiner Weise mit Hilfe eines PHP-Befehls wie fopen() an Dateien kommt, auf die man eigentlich gar nicht zugreifen darf.

Mach dir also keinen Kopf darüber :-)

Mr.Tr33 · 12/29/2016, 14:20

Okay, das klingt super.
Und was ist mit z.B. shell_exec (oder so), muss ich das auch extra deaktivieren?

Zypr · 12/30/2016, 02:13

Quote:

Originally Posted by Mr.Tr33

Okay, das klingt super.
Und was ist mit z.B. shell_exec (oder so), muss ich das auch extra deaktivieren?

Wenn du es nicht brauchst, solltest du es unbedingt deaktivieren.

Hier mal eine Hilfestellung von nixCraft (man beachte auch die Kommentarfunktion, dort gibt es auch ein paar zusätzliche Angaben):

Mr.Tr33 · 12/30/2016, 15:40

Danke

Auf der Seite steht was interessantes in den Kommentaren.
Wie deaktiviere ich, dass man über z.B.ini_set (oder so) und der .htaccess z.B. exec wieder aktivieren kann?

Zypr · 12/30/2016, 18:49

Quote:

Originally Posted by Mr.Tr33

Danke
Auf der Seite steht was interessantes in den Kommentaren.
Wie deaktiviere ich, dass man über z.B.ini_set (oder so) und der .htaccess z.B. exec wieder aktivieren kann?

Geht auch ganz einfach über disable_functions

~~FlyffServices~~ · 12/31/2016, 11:15

Was ist mit RCE nginx exploits? Damit könnte man nginx root rechte geben und so das System übernehmen was aber unwahrscheinlich ist

Zypr · 12/31/2016, 15:41

Quote:

Originally Posted by FlyffServices

Was ist mit RCE nginx exploits? Damit könnte man nginx root rechte geben und so das System übernehmen was aber unwahrscheinlich ist

Ist bereits behoben. Sofern er keine ältere Version einsetzt ist das nicht mehr möglich.

Siehe CVE-2016-1247:

~~FlyffServices~~ · 12/31/2016, 18:56

Quote:

Originally Posted by Zypr

Ist bereits behoben. Sofern er keine ältere Version einsetzt ist das nicht mehr möglich.

Siehe CVE-2016-1247:

Ich mein nonpublic exploits wie z.b die von Cisco die die NSA über 6 jahre hatte.
Aber sowas ist wie gesagt so unwahrscheinlich das es niemals passieren wird

Che · 01/02/2017, 11:10

Grundsätzlich solltest du als unerfahrener Nutzer keine Produktionssysteme verwalten. Da ist es intelligenter, das an jemand erfahreneren (zB. ein vertrauenswürdiger Dienstleister) auszulagern.

Für dein Vorhaben genügt vermutlich schon ein chroot [1] "jail" [2].

Auch interessant: CloudLinux [3]. Die Hauptfeature dieser Distro ist, dass alles in virtuellen Environments ausgeführt wird. Dein Webserver ist also by-default abgekapselt.

Ebenfalls erwähnenswert ist noch FireJail [4]. Das ist eine Art Sandbox, mit der du Zugriffsrechte per-Prozess sehr sauber regeln kannst. Beachte allerdings, dass der Webserver Teile des Systems lesen können muss.

Das System selbst nochmal abzusichern ist eine eigene Geschichte. Weil faul und viel zu viel Zeug, welches du als Laie ohnehin nicht nachvollziehen können wirst, erspar ich dir das mal.
Wie schon erwähnt: Lies dich ordentlich ein und spiel lokal rum, bevor du irgendwas ans Netz hängst, was dich in Probleme bringen kann. Angriffsziel zu sein ist übrigens nicht spaßig - Opfer zu sein und die Abuse-Benachrichtigungen vom Provider lesen zu müssen noch viel weniger.

[1] https://en.wikipedia.org/wiki/Chroot
[2]

[3]

[4]