Also bevor ich selber so nen Server betreibe wüde ich doch mal ganz gerne wissen wodurch die Idioten denn so reinkommen.
Sehr weise Entscheidung, kann ich dich nur beglückwünschen zu!
Du scheinst da leider eine Ausnahme zu sein, wenn ich mich hier im Forum so umsehe...
Immer wieder gerne gesehen ist wohl postnuke, kennt wer noch weitere "problematische" PHP-Projekte die ähnlich unsicher sind?
http://www.google.com/search?q=myegallery+exploit
Dazu sollten sich auch gecrackte Rechner mit der Boardsuche finden lassen.
Und auch bei Postnuke verstehe ich es nicht wirklich - selbst wenn das löcherig ist wie ein Schweizerkäse. Wenn PHP/Apache unter einem eigenen User laufen, dann kann man mit noch so tollen Tricks ja nicht mehr machen als eben dieser User. Oder irre ich mich hier?
Nein, du irrst nicht, das ist völlig korrekt. Problem ist folgendes:
Allgemein: Mehrere Sicherheitslücken addieren sich.
Beispiel: Remote User Exploit (d.h. man kann von einem entfernten Rechner aus, beliebigen Code auf dem Zielrechner mit den Rechten eines bestimmten, unprivilegierten Users ausführen) plus Local Root Exploit (d.h. ein Lokaler User kann beliebigen Code als root ausführen) ergeben zusammen halt einen Remote Root Exploit, d.h. man kann von Remote aus Root werden (wenn auch in mehreren Schritten...).
Hat man also ein unsicheres PHP- oder sonstiges Webscript und, sagen wir mal einen ungepatchten Kernel mit der do_brk() und/oder mremap() Lücke, ist es schon geschehen... Das ist es, was hier auch oft im Forum nachzulesen ist, wenn in den Apachen-Logs plötzlich wget- oder lynx-Befehle auftauchen: Jemand konnte von Remote als User wget aufrufen und damit den Kernel-Exploit laden, danach dann compilieren (BTW: Auch wenn man auf der Kiste keinen Compiler hat, schützt das nicht immer, man könnte ja auch fertig kompilierte Binaries per wget laden...) und ausführen.
Ich habe eigentlich noch nie gehört, dass in shared-Hosting-Server von Providern entsprechend eingebrochen wird(wird sicher schon passiert sein, aber bei root-servern hört man das ja dauernd). Aber da installieren Kunden sicher auch postnuke...
So ist es. Das wichtigste in solchen Umgebungen, wo fremde Leute irgendwelche ausführbaren Programme oder Skripte nutzen können ist, dass man _sämtliche_ Skripte (also nicht nur PHP, auch Perl, C und alles, was ausgeführt wird) nicht unter der UID des Apachen, sondern unter der UID des jeweiligen Benutzers (= Eigentümer) der Datei ausführen lässt. Stichworte suPHP, PHP als CGI, suEXEC und andere "CGI Wrapper".
Gut, und was gibt es sonst? eigentlich ja nur noch remote-exploits, aber die sind doch wohl sehr selten, oder? Das heißt nur wenn jemand alte Versionen mit bekannten Sicherheitslücken einsetzt könnte das jemand ausnutzen.
Ja. Oder jemand hat halt gerade eine neue unbekannte Lücke gefunden. Zum Glück finden solche Lücken meist "White Hats", d.h. gutgesinnte Leute und die Software wird gefixed, bevor es überhaupt bekannt wird oder zumindest bevor jemand einen Exploit für die Lücke schreiben kann. Manchmal jedoch finden auch die "Black Hats", also die "bösen" Leute eine Lücke zuerst: Siehe der Einbruch auf diverse Debian-, GNU- etc. -Kisten durch die do_brk() Lücke im Linux-Kernel.
@all:
wenn die Logs weg sind, wie soll man dann überhaupt noch drauf kommen wie die kiddies reingekommen sind? Ich meine, wenn man was falsch konfiguriert, macht man es ja weil man eben nicht weiß dass es falsch ist.
Ja, das ist in der Tat ein unlösbares Problem. Selbst wenn man noch Logs hat, kann man diesen nicht mehr vertrauen, wenn die Kiste erst mal gerooted wurde. Das einzige, was hier Hilfe schaffen kann, sind die diversen Arten von Remote-Logging, d.h. zusätzlich zu den lokalen Logs werden in Echtzeit alle Logs auch auf einem entfernten Rechner mitgeschrieben. Solange dieser dann noch nicht gecrackt ist, hat man dort noch Logs, denen man vertrauen kann.
Noch meine ganz persönliche Meinung zu Kernel-Patches wie GRSecurity, RSBAC, PAX und Co.:
Ich bin der Meinung, dass man auch ohne solche Dinge einen Rechner "sicher genug" konfigurieren kann - vorausgesetzt, man hat den dazu nötigen Clue. Mein Rootserver z.B. hat den ganz normalen Standard-Kernel von Debian und ist auch noch nicht gecrackt worden.
Womit ich nicht sagen will, dass ich solche Patches für sinnlos halte. Im Gegenteil: Wie hier von einigen Leuten schon erklärt wurde, können sie entscheidend dazu beitragen, ein System "noch" sicherer zu machen. Es ist aber mit Sicherheit der falsche Weg, wenn man sich denkt: Prima, jetzt habe ich Patch X,Y und Z und jetzt bin ich ganz sicher. Unter Umständen macht man sich nämlich ohne solche Patches _noch_ mehr Gedanken über eine gute und sichere Konfiguration der Kiste.
Greetings, Dominik
PS: Fritz hat Recht: Endlich mal jemand, der "smart questions" stellt, danke! :)
