Sicherheitsfragen zu Apache2

[Hoeze]

Ich möchte auf meinem Server gerne OwnCloud laufen lassen.
Da ich aber auch noch ein paar andere Sachen laufen lassen möchte, würde ich diese gerne voneinander trennen.

Ich möchte sicherstellen, dass, sofern jemand bspw. vollen Zugriff auf den OwnCloud-Ordner bekommt, dieser trotzdem nicht ausbrechen und auf andere Sachen wie PhpMyAdmin oder sogar auf das System zugreifen kann.
Wie stelle ich das an?

Bis jetzt hab ich schon von ziemlich vielen Ansätzen gelesen, virtualhosts, cgi, Apache im chroot, ...
Schön langsam frage ich mich, wie ich das alles unter einen Hut bekomme...

 

[Revolution]

Was willst du genau erreichen. Das was du derzeit frägst ergibt so keinen sinn. Bzw. hat nichts mit dem Apache zu tun.

 

[Hoeze]

Ich sollte vielleicht noch erwähnen, dass ich verschiedene Sachen von verschiedenen Seiten aus zugänglich machen möchte. Ich habe nämlich für verschiedene Sachen verschiedene OpenVPN-Server am laufen.

- Komplett öffentlich erreichbare Webseiten
- ein VPN für Freunde, die eigene Webseiten + die komplett öffentlich erreichbaren Webseiten sehen dürfen
- ein privates VPN, das zusätzlich noch OwnCloud-Zugriff ermöglichen soll
- ein VPN-Tunnel zur Komfiguration (ohne Einschränkungen)

Ergänzung (20. Juli 2013)

Was willst du genau erreichen. Das was du derzeit frägst ergibt so keinen sinn. Bzw. hat nichts mit dem Apache zu tun.

Ich möchte sicherstellen, dass ein kompromittierter Teil der Webseiten nicht die Möglichkeit eröffnet, andere Teile des Servers zu "bearbeiten". Mit der Standard-Config wie ich sie jetzt habe, mit Apache, PHP, mod_php5... bekommt ein Script leicht Zugriff auf andere Teile des Servers, die es gar nicht benötigt.

 

[andryyy]

Puh, verstehe dich. Viele Services auf einem Host sind immer unsicherer, aber man muss auch überlegen, warum ein Angreifer sich ausgerechnet an deinem Server austoben sollen wollte. Egal, weiter...

Musste erstmal suchen, was denn ownCloud so verwendet, um das zu verstehen.

Ich habe mir solche Fragen vor einer Weile mal ein gutes HowTo gespeichert, um mir Erklärungen zu erleichtern: http://www.debianroot.de/server/apache2-worker-php-fcgid-fastcgi-suexec-debian-lenny-1004.html

Das sollte etwa das sein, was du möchtest. Ein User mit Namen XY (üblicherweise eben der Name des vHosts), der "gejailt" ist in seinem www-root und nur da seine Rechte ausleben darf. Jeder vHost hat eben einen eigenen User. Die Vor- und Nachteile sind da ebenfalls etwas beschrieben, aber glaub mir, da findest du ganz einfach und ganz viel bei Google.

Üblich sind bei ownCloud nach schnellem Überfliegen auch eher SQLInjections, womit man dann Zugriff auf die Daten der Cloud bekommen kann (User erstellen, einloggen, blabla). Würde der Apache exploitet, würde man "eigentlich" auch "nur" Zugriff auf den jeweiligen User bekommen, der den vHost ausführt, bringt auch nicht viel. Und die Shell ist für den Login eh nicht erlaubt. Aber da gibt es in ganz entfernten Szenarien auch wieder andere "Möglichkeiten".

So dramatisch ist die Standardkonfiguration vom Apache2 für dich auch nicht. Aber die suexec Lösung ist schon toll. Ist auch echt gut dokumentiert da.

Edit: Auch gut sind in dem Fall dann die eigenen PHP-Configs, wo eben das open_basedir festgelegt werden kann.
Edit2: Das ist jetzt zwar für Debian, aber das Prinzip gilt global. Habe sowas auch schon häuftig eingerichtet, habe da einen Haufen an Notizen zu, wie du es optimieren kannst und Probleme, auf die man stoßen kann bei so einer Config. Und ein Script zum Erstellen von Sites + FTP Zugang + MySQL Datenbank nur für diese Site und User und Versand der Daten per Mail hätte ich da. Aber entscheide dich erstmal!

 

[Daaron]

Bis jetzt hab ich schon von ziemlich vielen Ansätzen gelesen, virtualhosts, cgi, Apache im chroot, ...
Schön langsam frage ich mich, wie ich das alles unter einen Hut bekomme...

Um Named Virtualhosts wirst du nicht drumrum kommen. Erst die Trennung der verschiedenen Projekte in VHosts ermöglicht weitere Sicherheitsstufen.

Was die Trennung der VHosts angeht:
Die allereinfachste Version ist, die VHosts nicht als mod_php laufen zu lassen sondern über suPHP. Diese Lösung verhindert aber z.B. den Einsatz von OpCode-Caches und auch so ist die Leistung eher mau.
Viel eleganter ist apache2-mpm-itk statt mpm-prefork. MPM-ITK lässt die VHosts automatisch im Kontext separater User laufen, obwohl man mod_php verwendet. Das ermöglicht dann z.B. die Verwendung von OpCode-Caches. Auf MPM-ITK kann man dann noch PHP-FPM (den Fast Process Manager) aufsetzen, in Kombination mit FastCGI/FCGID. Das Ding ist dann richtig flott.
Natürlich geht auch ne Lösung mit MPM-Worker + FCGID + suEXEC

Üblich sind bei ownCloud nach schnellem Überfliegen auch eher SQLInjections, womit man dann Zugriff auf die Daten der Cloud bekommen kann (User erstellen, einloggen, blabla). Würde der Apache exploitet, würde man "eigentlich" auch "nur" Zugriff auf den jeweiligen User bekommen, der den vHost ausführt, bringt auch nicht viel. Und die Shell ist für den Login eh nicht erlaubt. Aber da gibt es in ganz entfernten Szenarien auch wieder andere "Möglichkeiten".

Das ist so eben nicht ganz korrekt. Wenn du MPM-Prefork mit mod_php verwendest (oder ähnlich unsichere Ansätze), dann würde ein erfolgreicher Angreifer alles dürfen, was "www-data" darf.... er dürfte also jede Webseite manipulieren und könnte da z.B. schadhaften JS-Code einschleusen.

 

[andryyy]

Die Antwort war schon bezogen auf die Lösung im HowTo. ! Also nicht mit'm Prefork und mod_php!

Hm, deine Kombination da oben habe ich noch gar nicht getestet... Aber ist das wirklich performant? Muss ich mal ausprobieren!

 

[Daaron]

Ist ein guter Kompromiss aus Geschwindigkeit, Speicherlast, Sicherheit und Wartbarkeit. Unsere Live-Server beschweren sich nicht. Es ist natürlich langsamer als worker+fcgid, schon allein weils nicht threaded läuft. Dafür isses stabil... Außerdem ist es auch etwas langsamer als mpm-prefork + mod_php, weil itk einen zusätzlichen (sehr schnellen) Fork genötigt.

Einer der größten Vorteile von mpm-itk gegenüber worker ist, dass du eben AUCH mal mod_php verwenden kannst. Für irgend ein kleines Kundenweb, das PHP nur für einen Include des Headers, Footers und der Navi sowie für n Formular benutzt, und das eh inkl. Bots nur 30 Hits am Tag hat, brauchst du somit kein FCGID laufen lassen und kannst den Speicher dynamisch freigeben. Das heißt auch, dass selbst solche Fusselwebs auf APC & Co zugreifen können. Sehr nützlich.

Der erste echte Nachteil an ITK, den ich bisher finden konnte: Es spinnt, wenn man mod_ruby verwendet. Sobald man das Ruby-Modul für Apache verwendet klappen Dienst-Neustarts des Apachen nicht mehr sauber. Da bleiben teilweise Prozesse übrig, die den Port 80 belagern und die man nur über kill -9 los wird.
Der Bug besteht sowohl unter Ubuntu 12.04 als auch unter Debian 7.

 

[Hoeze]

sry falscher thread....

 

[kwai]

Kannst im Apache2 auf z.B. definieren, dass auf phpmyadmin nur localhost oder dein internes Netz drauf darf, keiner aus dem Internet usw.
Dann vielleicht noch mit htaccess abfragen.

Zusätzlich in der Site die Ordner Berechtigungen richtig einstellen und dann dürfte nichts passieren.

 

[Daaron]

Ohne feste IP wird so eine Form der Berechtigung aber ziemlich nervig. Jedes Mal erst die Deny/Allow-Regeln umschreiben, bevor man an den Kram ran darf...
Dann doch lieber htpasswd-basierten Auth mit nem starken Passwort und nem Usernamen != "admin" oder sowas. Dann noch Fehlschläge loggen und mit Fail2Ban drauf reagieren -> kommt nur noch ein Profi rein, und den kann man eh nicht draußen halten

 

[kwai]

Mit Hostnames/FQDN kommt der Apache2 nicht klar ?
Habe es noch nie probiert und frage deshalb.

 

[Daaron]

Doch, die Regeln sollten auch auf Hostnamen reagieren. Wenn du n DynDNS hast, dann würde das wohl funktionieren.