Sicherheitslücken von Kunden - wie handelt Ihr das?

[thahool]

Ich habe einige Webserver, teilweise noch mit Confixx, manche mit Plesk, welche ich betreue und auch meine Kunden Ihre Website drüber hosten.

Diese Websites wurden zumeist von mir erstellt und sind sicherheitstechnisch eher unproblematisch, da es nur einfache HTML/PHP Seiten sind, mit wenig Skripten. Hier und da mal ein Gästebuch, Formmailer, ect. wo ich mal prüfen muss, aber ansonsten hält sich das in Grenzen.
Die Webserver selber: Nessus, rkhunter und tägliche Securitynews sind da meine Freunde :-D

Aber nun kommen erste Anfragen von Kunden die auch selber Ihre eigenen Projekte hosten wollen, darunter sind auch schon mal Portale wie phpNuke gewünscht worden. Bisher ist mir das noch nicht auf dem Server gekommen, aber wenn ich es nicht hoste dann geht der Kunde zum nächsten Hoster :(

* Wie macht Ihr das bei solch Sicherheitskritischen Skripten?
* Ich kann ja nicht täglich den Kundenwebspace nach solchen Gefahrenquellen absuchen (abgesehen davon dass ich das auch nicht darf)
* Wie machen die grossen Hoster wie 1&1 das? Die müssen sich ja auch vor Exploits schützen?

Wenn nur der Kundenaccount gehackt wird ist mir das ja egal, aber wenn durch phpNuke & Co Befehle mit Webserver Rechten auf meinen Servern ausgeführt werden, dann hab ich da was dagegen

Fragen über Fragen... vielleicht kann mir jemand weiterhelfen?
Danke!

[duergner]

Für PHP würde ich die Sachen einfach nicht als mod_php sonder mittels FastCGI einbinden. Dann die Dateirechte sauber setzen und es sollte passen für die gröbsten Sachen. Wenn du dann noch härtere Sachen haben willst, vielleicht noch SELinux. Ansonsten seh ich aber auch kein Problem darin, wenn der Hoster die Webverzeichnisse seiner Kunden regelmäßig screent auf veraltete Versionen. Ansonsten halt saubere AGBs damit du nicht für den Scheiß auch noch haftest.

[killerhorse]

Hallo,

Also ich verwende modsecurity. Funktioniert perfekt.

Wenn Du die Regeln nicht selbst schreiben willst gibts hier sehr umfangreiche Rulesets:
http://www.gotroot.com/downloads/ftp/mod_security/
In dem Unterverzeichnis apache2/ gibts dann z.B. ein vollständiges Ruleset für den Apache2 als archiv zum downloaden.
(Die Regeln auf der Seite werden übrigens fast täglich aktualisiert)

Weniger umfangreiche Regeln findest Du z.B. auch hier:
http://www.rootforum.org/forum/viewtopi ... ht=gotroot
Wobei es da passieren kann, dass einiges von modsecurity geblockt wir, was eigentlich erlaubt sein sollte, dafür sind diese Regeln (weil weniger umfangreich) nicht so Recourcenfressend.

Bei mir läuft allerdings der Apache auch mit den umfangreichen Regeln noch sehr schnell. (Kommt halt allgemein auf die Auslastung des Servers an)

MfG

Christian

[thahool]

Danke!!

modsecurity sieht sehr vielversprechend aus!
Werd ich mal probieren!!

:-D

[blnsnoopy26]

Hallo,

Also ich verwende modsecurity. Funktioniert perfekt.

Wenn Du die Regeln nicht selbst schreiben willst gibts hier sehr umfangreiche Rulesets:
http://www.gotroot.com/downloads/ftp/mod_security/
In dem Unterverzeichnis apache2/ gibts dann z.B. ein vollständiges Ruleset für den Apache2 als archiv zum downloaden.
(Die Regeln auf der Seite werden übrigens fast täglich aktualisiert)

Weniger umfangreiche Regeln findest Du z.B. auch hier:
http://www.rootforum.org/forum/viewtopi ... ht=gotroot
Wobei es da passieren kann, dass einiges von modsecurity geblockt wir, was eigentlich erlaubt sein sollte, dafür sind diese Regeln (weil weniger umfangreich) nicht so Recourcenfressend.

Bei mir läuft allerdings der Apache auch mit den umfangreichen Regeln noch sehr schnell. (Kommt halt allgemein auf die Auslastung des Servers an)

MfG

Christian

Welche Regeln verwendest du da genau von der gotroot seite?
Weil habe auch mal paar eingerichtet gehabt und das funktionierten ne menge formulare nicht mehr und selbst phpmyadmin hat sein dienst teilweise verweigert.

[killerhorse]

Hallo,

Verwende im Grunde alle. Das heisst:
http://www.gotroot.com/downloads/ftp/mo ... st.tar.bz2

Probleme mit Formularen konnte ich nicht beobachten. Was steht denn in den Logfiles welche Regel das Problem verursacht hat?

MfG

Christian

[paris]

also meiner meinung nac bist du etwas zu penibel mit scripten wie phpnuke...

es gibt dort nur recht selten exploits die so gefährlich sind das sie deinen server wirklich kritisch angreifen können und wie du selber sagst wirst du deinen kunden auch etwas freuraum lassen du kannst ihnen ja net sagen sie dürfen nur sachen einsetzen die du geschrieben hast dann wirst net viel erfolg haben.

also ich persönlich denke darüber vorsicht ist immer gut aber man darf was das angeht auch nicht so kleinlich sein

[lord_pinhead]

Wer selbst Kunden hostet sollte auch mal seine AGB etwas anpassen. Der Kunde ist verpflichtet seine Software auf den neusten Stand zu halten, dann bist du schonmal rechtlich aus der Sache etwas raus. Für den Rest kann ich mich nur dem hier gesagten anschliessen und dir noch GRSec empfehlen. Teste es ein bischen zuhause, dann dürftest du keine Probleme mit Scriptkiddies mehr haben. Wenn du noch lustig bist, kannst du noch mit nikto die Webseiten deiner Kunden provisorisch scannen, was aber nur relativ brauchbare ergebnisse liefert. http://osvdb.org/ wäre noch ein anlaufpunkt vielleicht.

[blnsnoopy26]

Hallo,

Verwende im Grunde alle. Das heisst:
http://www.gotroot.com/downloads/ftp/mo ... st.tar.bz2

Probleme mit Formularen konnte ich nicht beobachten. Was steht denn in den Logfiles welche Regel das Problem verursacht hat?

MfG

Christian

Ist lange her seit ich es mal versucht hatte, aber wenn das Problem noch einmal auftrit, dann sage ich diesbezüglch bescheid.

Werd es mal mit diesen Regeln versuche die auf dieser Webseite dort sind.

[Anonymous]

Ich habe derzeit mehr als 2000 Domains unter Aufsicht in unserer Colocation und dort sind etliche â??Scheunentoreâ?? von Kunden unter dem Vorwand des â??freien Shared Hostingsâ?? installiert.
Laut AGB sind die Installation von Scripts, die die Betriebssicherheit gefährden, untersagt.
Allerdings werden phpBB2 usw. trotzdem geduldet â?? auch wenn diese uralt sind.

Fällt ein Kunde einmal unangenehm auf, wird dieser abgemahnt.
Passiert nochmal etwas, was durch Ihn bedingt ist, wird er fristlos gekündigt und ihm die Supportarbeit in Rechnung gestellt.

[alexander newald]

Ansonsten könnte man noch den ganzen Indianer in ein chroot packen. Ohne solchen lustigen Sachen wie wget, links, lynx oder gcc. Dann PHP als CGI und suEXEC.

Ab und an ein Backup machen. Man kann trotz allem nicht verhindern, dass zumindest der Account von einer Webseite zerstümmelt wird (Dabei übrigens auch nicht das Backup der mySQL DBs vergessen)

[captaincrunch]

Muss ich mal wieder auf die Unzulänglichkeiten eines "normalen" chroot hinweisen? ;)

[alexander newald]

kannst, musste aber nicht - Ausserdem hat es trotzdem Sinn, da man dort sicher sein kann, dass nur die wirklich benötigten Programme drin sind - Schliesslich muss man die vorher dort hineinkopieren.

[captaincrunch]

Es geht nicht darum, wovon du ausgehen kannst, sondern eher darum, dass selbst das dümmste Scriptkid heutzutage innerhalb von zwei Minuten deinen "Schutz" aushebelt. Da er dann auf dem "echten" System ist, kannst du dir definitiv nicht mehr sicher sein.

Wenn du meinst es macht Sinn: bitte, ich möchte deine Seifenblase nicht zerplatzen lassen.

[alexander newald]

Wobei ich hoffe, mit einem Chroot nur mit PHP als CGI und Perl, beide mit suEXEC, ohne zusätzliche Programme wie wget, lynx, links eine weitere Barriere zu haben.

[captaincrunch]

Die nächste Lücke in einem Dienst / einer Applikation (siehe phpBB, PHPNuke und Co.) kommt bestimmt. Ein potentieller Angreifer hat die Möglichkeit, über eine solche Lücke (wenn auch) als unprivilegierter User in den chroot zu gelangen. Kombiniert mit ein bis zwei anderen Tricks, und weiteren Angriffspunkten ist es dann ein sehr einfaches, aus dem chroot auszubrechen.

[alexander newald]

Benötige ich da aber nicht eine uid 0 im chroot und die uid des unprivilegierter User ausserhalb der chroot?

[captaincrunch]

Teilweise richtig. Daher die Aussage "kombiniert mit ein bis zwei anderen tricks". ;)

Wie kommst du darauf, dass man die UID des Users außerhalb des chroot braucht?

[alexander newald]

Also sollte das ganze, kombiniert mit den oben Genanntem, kein Modul Support im Kernel und grSecurity doch ganz hilfreich sein.

Wobei man nicht verhindern kann, dass jemand z.B. ein Perl Skript programmiert und auf seinen Account ablegt, mit dem er dann eine Shell simuliert. Auf bezahltem Webhosting vielleicht eher unproblematisch, auf kostenlose wohl eher schon.

[captaincrunch]

Ã?ber die Sicherheit des fehlendes Modulsupports streiten sich die Geister. Ich halt's für sinnlos. Sofern wir dann jetzt von den zusätzlichen Maßnahmen reden, die GRSecurity einem chroot mit auf den Weg gibt, sind meine Bedenken auch erheblich kleiner.

[alexander newald]

Habe ich grSec vergessen zu erwähnen?

[captaincrunch]

In deinem ersten Beitrag weiter oben schon. Da konnte ich mir die Korinthenkackerei nicht verkneifen. ;)