Sicherheit bei suphp

[reto]

hallo zusammen

bevor ich mir einen rootserver kaufe, möchte ich zuerst geklärt haben wie ich php anständig mit suphp absichere:

Mit der lösung suphp werden die phpscripte nicht mehr unter dem apacheuser sondern unter einem bestimmbaren user (vhost) ausgeführt.
der einzige schutz der jetzt suphp bietet ist, dass die user nicht dateien von anderen user anschauen können.
jedoch können mit suphp genau gleich lücken in phpscripten ausgenutzt werden. der angreifer kann dann irgendein telnet daemon raufladen und unter dem im vhost eingestellten benutzer ausführen. danach ein rootkit nachladen und den server rooten. oder liege ich da falsch?

wenn nein, dann nützt das ganze eigentlich auch nicht wirklich viel!?

könnte man vielleicht mittels limits.conf was einstellen, dass der suphp benutzer keine terminalloginrechte hat oder was ähnliches?
oder sollte man hierfür strikte iptables regeln erstellen, die das verhindern?
ein anderes problem wären dann phpshells, die der angreifer benutzen könnte als alternative zum telnetd.

wie kann ich denn mein server bisschen anständig absichern gegen solche attacken?

Danke für eure hilfe!

Gruss Reto

[muemmel]

Hi und willkommen im Forum.

Also ich für meinen Teil deaktiviere Systemaufrufe und Funktionen zur Programmausführung in PHP gänzlich.

Dadurch sollte es verhindert werden, dass ein User einen Telnet-Daemon installiert. Für weitere Sicherheit kannst du ja bei suphp/PHP immer noch den SafeMode deaktivieren. Durch den SafeMode hast du u.a. den gleichen Effekt wie oben beschrieben. Programme und Prozesse können von PHP aus nur noch in einem bestimmten Verzeichnis gestartet werden. Wenn du dem User des VHosts nun die Schreibrechte dieses Verzeichnisses nimmst, dann sollte es sehr schwer sein einen Shell Daemon über PHP zu aktivieren.

An alle anderen User: Bitte korrigiert mich, falls ich mich im Bezug auf obige Ã?berlegungen irren sollte.

[phillux]

An alle anderen User: Bitte korrigiert mich, falls ich mich im Bezug auf obige Ã?berlegungen irren sollte.

Gerne

Für weitere Sicherheit kannst du ja bei suphp/PHP immer noch den SafeMode deaktivieren.

Du meinst wohl aktivieren?

Gruß, Phil

[Roger Wilco]

der einzige schutz der jetzt suphp bietet ist, dass die user nicht dateien von anderen user anschauen können.

Nein, das bietet das unterliegende System. SuPHP ist einzig und allein dazu da, dass Skripte im jeweiligen Benutzerkontext laufen. Wenn alle Benutzer in der gleichen Gruppe und die gesetzten Rechte ausreichend lasch sind, können sie trotzedem noch auf die Dateien anderer Benutzer zugreifen.

der angreifer kann dann irgendein telnet daemon raufladen und unter dem im vhost eingestellten benutzer ausführen.

Wer Skripte einsetzt, bei denen das möglich ist, hat eh verloren.

danach ein rootkit nachladen und den server rooten. oder liege ich da falsch?

Ist dein Kernel und dein Userland denn so veraltet, dass es bekannte und verbreitete Exploits dafür gibt?

wenn nein, dann nützt das ganze eigentlich auch nicht wirklich viel!?

In Bezug auf Sicherheit? Richtig. Aber dafür ist es ja auch nicht gedacht.

könnte man vielleicht mittels limits.conf was einstellen, dass der suphp benutzer keine terminalloginrechte hat oder was ähnliches?

Könnte man. Zwar nicht mit der limits.conf, aber es geht. Nur bringt dir das im Falle einer Codeinjection in ein PHP-Skript nichts.

oder sollte man hierfür strikte iptables regeln erstellen, die das verhindern?

Die was verhindern?

wie kann ich denn mein server bisschen anständig absichern gegen solche attacken?

Da gibts ein paar Möglichkeiten, z. B. keine Skripte mit bekannten Sicherheitslücken einsetzen, (bedingt) Hardened PHP, mod_security (um zumindest simple Versuche gleich zu verhindern), PHP deinstallieren...

[reto]

Danke für eure antworten.

Also ich für meinen Teil deaktiviere Systemaufrufe und Funktionen zur Programmausführung in PHP gänzlich.

Funktionieren denn so die meisten php scripte einwandfrei?
Wenn ja, sollte man dazu aber noch suphp dazu einsetzen, dass die user untereinander nicht dateien löschen können.

Wenn du dem User des VHosts nun die Schreibrechte dieses Verzeichnisses nimmst, dann sollte es sehr schwer sein einen Shell Daemon über PHP zu aktivieren.

Dann können aber phpscripte auch keine files mehr erstellen.

Wer Skripte einsetzt, bei denen das möglich ist, hat eh verloren.

Klar logisch. Jedoch sieht das in der praxis anders aus. Ein normaler user kann nicht verifizieren welche software sicher oder unsicher ist und es ist ihm eigentlich auch egal. Wenn du ihm verbietest, seine software deinem server zu installieren, dann wechselt er einfach zu einem anderen, der es ihm erlaubt. oder?

Ist dein Kernel und dein Userland denn so veraltet, dass es bekannte und verbreitete Exploits dafür gibt?

Nein. Wozu braucht man dann noch den GRSEC oder Pax patch, wenn der aktuelle kernel sicher ist? oder verstehe ich da was falsch?

Die was verhindern?

Dass der angreifer nicht auf den telnetd zugreifen kann.

Da gibts ein paar Möglichkeiten, z. B. keine Skripte mit bekannten Sicherheitslücken einsetzen, (bedingt) Hardened PHP, mod_security (um zumindest simple Versuche gleich zu verhindern), PHP deinstallieren...

mod_security ist interessant, jedoch gibt es einige probleme bei phpscripten die dann nicht mehr funktionieren.

hardened php klingt gut. schau ich mal an.

[captaincrunch]

Wozu braucht man dann noch den GRSEC oder Pax patch, wenn der aktuelle kernel sicher ist? oder verstehe ich da was falsch?

Ja, das siehst du falsch:
1. Ist PaX Bestandteil von GRSecurity.
2. Bietet diese Kombination bereits recht guten Schutz, die Vergangenheit (gar nicht mal so lange her) hat aber gezeigt, dass es diverse Male vorkam, dass auch diese Hilfsmittel nicht vor Programmierfehlern im Kernel schützen...und von denen gibt es leider immer noch zu viele.

[reto]

Also so wäre mein kernel einigermassen "sicher".
Konfigurieren muss man es aber sicher auch noch gut...

Wie machen denn das die grossen webhoster? Irgend eine passable lösung sollte es doch geben, damit keine rootkits auf dem server landen und ausgeführt werden können?
Oder haben die einfach einen sehr sicheren kernel mit dem oben genannten patch und kicken ab und zu die telnetd's weg?

[Roger Wilco]

1. Ist PaX Bestandteil von GRSecurity.

Seit wann? Man kann PAX durchaus auch ohne GrSecurity benutzen, oder in Kombination mit einer anderen Kernelerweiterung, z. B. RSBAC.
Das einzig gemeinsame ist die Domain (grsecurity.net und pax.grsecurity.net). ;)

Irgend eine passable lösung sollte es doch geben, damit keine rootkits auf dem server landen und ausgeführt werden können?

Verbiete einfach allen Programmen (die du nicht kontrollierst), sich an ein Netzwerkinterface bzw. einen Socket zu binden. Das geht z. B. mit grsecurity.

[reto]

Verbiete einfach allen Programmen (die du nicht kontrollierst), sich an ein Netzwerkinterface bzw. einen Socket zu binden. Das geht z. B. mit grsecurity.

Das macht sinn! Werde ich machen !

Jedoch könnte der angreifer immer noch mit einer phpshell oder einem phpscript das rootkit ausführen!?

Gibt es dagegen keinen Schutz ausser den Safemode?

Sorry für mein ständiges nachfragen, aber ich möchte halt wirklich mal klarheit.

[lord_pinhead]

Safemode und die Disabled_Funktions sind eigentlich recht nett dazu geeignet das ganze sicherer zu machen (gegen Scriptkiddies und Bots). suPHP ist in sofern nützlich wenn du für jeden User eine eigene Userid hast und der kann dann nur in seinen Verzeichniss hantieren. Aber das schützt nicht das jemand in diesen Benutzerkontext "arbeitet". Sicher, du bist vor Kiddieangriffen gut geschützt weil die wenigsten sowas wissen, aber jemand der gut ist lacht drüber. Erweiterungen wie GRsecurity, Pax, RSBAC oder gar NSALinux (bin ich kein Freund davon muss ich sagen, trau dem ganzen net) sind gute mittel das ganze relativ gut abzusichern. Aber wie CC schon gesagt hat, kann ein Programmierfehler der ein Buffer Overflow produzieren relativ leicht ausgenutzt werden da diese erweiterungen bei sowas nicht richtig greifen. Das du die Sockets sperrst ist nen guter Ansatz, allerdings musst du noch bedenken das der Kernel keinen Modulsupport mehr haben sollte (alles statisch) und ein kleines IDS im Hintergrund läuft das Dateisystemänderungen erkennt. Tripwire, Prelude und Samhain sind gute Ansätze. Das ganze ist aber viel arbeit, also lass dir lieber noch ein bischen Zeit mit dem bestellen bis du alles erstmal überblickst.

Aso, wie machen große Provider das ganze mit managed Server? Ganz einfach, die schützen die Server alleine schonmal durch die Netzwerktopilogie (Internet -> Router-> Bridge mit ein IDS -> Firewall -> Server). Die Kunden laufen in virtuellen Umgebungen ab und die Hoster nutzen auch solche Kernel Erweiterungen wie schon vorher beschrieben. Jedenfalls macht das hier ein lokaler hoster so den ich gut kenne, ob das jetzt auch Strato und Co. macht ist fraglich. Allerdings, wenn dort ein Server gehackt wird, kann der Inhalt schnell auf einen anderen Server gespiegelt werden und geht wieder online mit der IP des alten Servers, derweil wird der andere Server formatiert. Ausfallzeit wird dann als Systemcheck oder so angegeben, jedenfalls würd ich das an deren Stelle machen.

[mausgreck]

Jedoch könnte der angreifer immer noch mit einer phpshell oder einem phpscript das rootkit ausführen!?

Welches Rootkit!? Wenn du dich nicht darauf verlassen kannst/willst, dass Linux die Benutzer voneinander trennt, dann wechsle das Betriebssystem!

Und willst du dich wirklich darauf verlassen, dass deine User verantwortungsvoll mit Passwörtern umgehen? Da prophezeie ich dir ein hartes Erwachen in der Realität. In dem Moment, wo du Software wie PHP einsetzt *musst* du davon ausgehen, dass jemand beliebigen Code mit dessen Userrechten ausführen kann. Alles andere wäre sehr blauäugig.

[blnsnoopy26]

Hi,

Das gute bei suphp ist ja auch, das man jedem User eine eigene php.ini zur verfügung stellen kann, womit man z.b bei Kunde xy sagen kann der darf dies oder dies nicht und Kunde xyz darf nur das.

Ist ein nettes Feature worauf man zurück greifen sollte, wenn es um sicherheit geht. ist auch kein 100% schutz, weil sowas gibs ja nicht, aber man kann wieder etwas mehr ruhiger pennen :D

[captaincrunch]

Seit wann? Man kann PAX durchaus auch ohne GrSecurity benutzen, oder in Kombination mit einer anderen Kernelerweiterung, z. B. RSBAC.

OK, ich habe mich unklar ausgedrückt: ohne PaX ist GRSec nicht mehr GRSec. ;)

allerdings musst du noch bedenken das der Kernel keinen Modulsupport mehr haben sollte (alles statisch)

Ich frage mich, wieso sich das Gerücht, das ein staisch kompilierter Kernel "sicherer" (vor Rootkits) ist so lange hält. Spätestens seit Phrack 60 ist auch das Patchen eines statischen Kernels kein wirkliches Problem mehr.

[Joe User]

Spätestens seit Phrack 60 ist auch das Patchen eines statischen Kernels kein wirkliches Problem mehr.

Und Dank kexec und "execute in place" (e2fs) noch einfacher/unbemerkter...

[lord_pinhead]

allerdings musst du noch bedenken das der Kernel keinen Modulsupport mehr haben sollte (alles statisch)

Ich frage mich, wieso sich das Gerücht, das ein staisch kompilierter Kernel "sicherer" (vor Rootkits) ist so lange hält. Spätestens seit Phrack 60 ist auch das Patchen eines statischen Kernels kein wirkliches Problem mehr.

Du beziehst dich hierdrauf. Ok, aber das benötigt immernoch die Kernel Sourcen um zu funktionieren, dann sollte man die unten lassen und auch die config nicht mit auf der Kiste lassen. Das es möglich ist dürfte klar sein, aber das würde vorraussetzen das jemand sich auskennt. Die meisten cracks machen dumme Bots die eine kleine Backdoorshell installieren und der "Cracker" macht noch ein paar änderungen. Sobald allerdings jemand einen Login auf der Kiste hat ists eh schon zu spät. Da kann man nur beten das meine ACLs greifen und keine Backdoorshell sich öffnet.

[mausgreck]

Sobald allerdings jemand einen Login auf der Kiste hat ists eh schon zu spät.

Warum? Gibt es irgendeinen Hinweis, dass ein aktueller Kernel mit aktuellem Userspace gerootet werden kann? Und wie machen das die unzähligen Freeshell-Provider und Studenten-Server mit SSH account? I don't buy it.

[reto]

Warum? Gibt es irgendeinen Hinweis, dass ein aktueller Kernel mit aktuellem Userspace gerootet werden kann? Und wie machen das die unzähligen Freeshell-Provider und Studenten-Server mit SSH account? I don't buy it.

Also fahre ich ziemlich sicher, wenn ich immer den neusten kernel drauf habe!?

[Joe User]

Also fahre ich ziemlich sicher, wenn ich immer den neusten kernel drauf habe!?

Nein. Du fährst erst dann relativ sicher, wenn Du keinerlei Software, dazu zählen auch Scripte jeglicher Art, mit bekannten Bugs auf dem System hast...

[reto]

Danke für alle antworten! Jetzt verstehe ich das thema um einiges besser.