RootForum Community

Hi!

Hab mal ne Frage!

Laut meinem Hoster wurde von meinem Server aus eine Attacke (UDP Flooding port 65000) durchgeführt. ICH war es definitiv nicht!!!

Wie gehe ich jetzt am besten vor, um die Sicherheitslücke zu finden und zu beheben? In den Logs kann ich keine Anzeichen für einen Eindringling finden...

Was sollte ich am besten tun?

Gruß
exciler

Habe jetzt herausgefunden, dass es einem Angreifer über phpbb gelungen ist eine udp.pl in /tmp zu speichern :(

problem an der sache: das phpbb ist auf einem vhost eines kunden. ich habe also nicht die direkte kontrolle, ob bei meinen kunden immer die aktuellste version drauf ist.

wie kann ich denn sowas künftig sinnvoll verhindern? Habt ihr da ne idee?

wie konnte er die Datei denn da ausführen? War /tmp noexec gemounted?

flo.

flo wrote:wie konnte er die Datei denn da ausführen? War /tmp noexec gemounted?

Da es sich um ein Perlskript handelt, kann /tmp so viel mit noexec eingebunden sein, wie es will. Der Parameter ist eh mehr für ein warmes Gefühl in der Magengegend zuträglich als für die Sicherheit.

eben, die Frage ist halt wie ich das verhindern kann, ohne meine Kunden zu kontrollieren, weil ich kann ja nicht ausschließen, dass da irgendeiner ne alte version drauf macht, oder?!

Roger Wilco wrote:Da es sich um ein Perlskript handelt, kann /tmp so viel mit noexec eingebunden sein, wie es will. Der Parameter ist eh mehr für ein warmes Gefühl in der Magengegend zuträglich als für die Sicherheit.

ohne Worte - deshalb die Frage, wie er das da ausführen konnte ... ;-)

flo.

P.S.: Mir ist schon klar, daß es nicht die Ultima Ratio ist, /tmp auf noexec zu mounten, wenn gleichzeitig "exec" als php-Funktion erlaubt ist, ist der Interpreter schnell offen.

flo wrote:ohne Worte - deshalb die Frage, wie er das da ausführen konnte ... ;-)

Noch Fragen? ;)
Ob der Angreifer jetzt "./exploit.sh" oder "sh exploit.sh" ausführen muss, ist ihm sicherlich egal.
Das gleiche Spiel funktioniert mit einem beliebigen Interpreter (perl, python, ...) oder "echten" Binaries mit LD_PRELOAD.

Ist ja gut und schön... dass noexec keine besonders hohe sicherheit bietet ist mir klar, andererseits schadet es nicht, sofern es damit keine probleme gibt...

Aber das alles beantwortet meine eigentliche Frage nicht, habt ihr dazu auch keine Idee?

Roger Wilco wrote:Noch Fragen? ;)
Ob der Angreifer jetzt "./exploit.sh" oder "sh exploit.sh" ausführen muss, ist ihm sicherlich egal.

Dem Angreifer vielleicht, aber ich glaube, dem Pack ist noch mehr egal :-) ... ich weiß nicht, worum es Dir jetzt geht, aber die Frage des OP ist doch, wie man so etwas verhindern kann.
Wird das Ding nun direkt ausgeführt und steht mit "./udp.pl" in der Prozeßliste, fände ich das schon interessant, wie ein beliebiges Programm ausgeführt werden kann. Wird der Code in den Interpreter geschickt oder der Interpreter damit aufgerufen, könnte man das per Sperren der System-Calls in PHP umgehen ... oder ... oder ... oder.

Daß jemand eine Version des (z.B.) PHPBB auseinandernimmt, gezielt nach Schwachstellen durchforstet und dann per getrickstem fopen fremden Code einschleust, wäre ja auch möglich.

@exciler - was hast Du bis jetzt gemacht? Was ist bei Dir schon gesperrt/noch aktiv? PHP-Version? Apache? Safe-Mode aktiv? Pfadeinschränkungen? phptemp-Directory? Gesperrte Funktionen? mod_php oder CGI?

flo.

Die einzig wirksame Maßnahme ist meiner Meinung nach ein (möglichst externer) Paketfilter, der auf der einen Seite verhindert, dass ein eingeschleustes Script/Programm selbständig eine Verbindung nach außen aufbauen kann, oder auf der anderen Seite auf Verbindungsanfragen an einem Socket warten kann.

Hat allerdings den Nachteil, dass man mit "guten" Scripten auch nicht mehr so ohne weiteres mit Webservices kommunizieren, RSS-Feeds aggregieren, eMails abfragen/versenden... kann.

Abgesehen davon schützt diese Maßnahme nicht dagegen, dass jemand über Schwachstellen in vorhandenen Scripten mit dem Server kommuniziert, so ist je nach Schwachstellen auch so noch möglich z.B. verbotene Dateien hochzuladen und irgendwo zum Download anzubieten. Allerdings ist Mißbrauch als Proxy oder Zwischenstation für Angriffe IMO so nicht mehr ohne weiteres möglich - solange eben eine externe Firewall eingesetzt wird oder keine Sicherheitslücken zum Erlangen von Rootrechten vorhanden sind.

PHP: 4.4.1
Apache: 2.0.55

Safemode aktiv
PHP über mod_fastcgi

Gemacht hab ich bis jetzt:
- System neu aufgesetzt
- altes phpBB aktualisiert

Soweit so gut, aber was kann ich noch verbessern, damit ein user durch eine alte phpbb-version keinen schaden verursachen kann? Die "alte" Konfiguration war ja wie man sieht nicht sicher genug!

Eine externe Firewall/Paketfilter kann ich nicht aufsetzen. Könnte es höchstens intern tun, was würdet ihr da empfehlen? iptables?

Danke aber schonmal für eure Antworten

Also ich könnte ja mit iptables regeln erstellen, die per default jeden output droppen, außer dem den ich klar erlaube...

also port 80 bspw., nur hier sollte man dann vielleicht ein limit setzen, oder? also xx/second... aber was wären da gute werte ohne probleme mit dem apache zu bekommen, aber im falle einer solchen attacke von meinem server aus abzuschalten bevor alturo es tut?

du solltest dir ein paar buecher zum thema kaufen, und dich selber informieren, einen server aufzusetzen ist eine sache, ihn sicher zu machen eine andere, und wenn man kunden auf sonem ding hat, dann sollte man eigentlich wissen was zu tun ist....

Soweit so gut, aber was kann ich noch verbessern, damit ein user durch eine alte phpbb-version keinen schaden verursachen kann? Die "alte" Konfiguration war ja wie man sieht nicht sicher genug!

@-ec-: Nimm das jetzt bitte nicht persönlich, aber auf solche Antworten kann ich verzichten!

Ich habe bereits einige Bücher zu diesen Themen (auch gelesen). Ich habe auch seit etwa 5Jahren Erfahrung mit Root-Servern. Mittlerweile sind es 4 Stück. Aber nur auf dem einen hier laufen auch Kunden drauf. Und es bisher nie etwas passiert, trotz Angriffsversuchen! Das zeigt ja, dass meine Server nicht die unsichersten sind. Aber nun bin ich an einem Punkt an dem ich mit den Büchern die ich habe nicht weiterkomme und deshalb hier um Rat gefragt habe, weil ich der Meinung war, dass ich hier schneller an die Infos komme als weitere 10 Bücher zu lesen.

Die Frage ist ja auch, was ihr an meiner Stelle tun würdet und welche Erfahrungen ihr bereits gemacht habt. Wie iptables funktionieren, wie diese eingerichtet werden und welche Vor- und Nachteile diese haben weiß ich bzw. kann es hier nachlesen. Mir geht es einfach um Tipps und Ideen, denn Sicherheit ist meiner Meinung nach nur das Stückchen, was wir den Hackern voraus sind. Und da sind Ideen gefragt, wie man den Hackern wieder einen weiteren Schritt vorauseilen kann, denn die holen auf, und wenn wir keine neuen Ideen entwickeln, wird es irgendwann keine Sicherheit mehr geben, oder?!

Und da das ganze ein produktiv-system ist möchte ich ungern mit verschiedenen configs "rumprobieren" sondern auf erfahrungswerte setzen. Dafür bin ich hier und nicht in irgendwelchen Büchern über die Theorie.

Das wollte ich nur mal klarstellen. Aussagen wie "Du solltest keinen Root-Server haben" sind bei vielen Leuten sicherlich richtig, aber eben nicht immer. Und ich würde mich als "fit genug" für einen Root-Server einschätzen... wie gesagt, 5 jahre ohne probs!

Naja, bis in letzte Konsequenz wird das hier (AFAIR) auch nie richtig diskutiert. Mir fehlen auch noch einige Ideen um wirklich sicher shared hosting betreiben zu können (bisher mache ich sowas nicht).

Man kann sich einiges von guten, großen Hostern abgucken. Allerdings haben dessen Systeme in der Regel nicht mehr viel mit einer Standard-Distribution gemeinsam, da steckt sehr viel Know How, Arbeit und Erfahrung hinter. Das lässt sich IMHO nicht mal eben aufholen. Domainfactory z.B. verwendet Gentoo auf den Shared Hosting Servern, nutzt allerdings nicht immer die Standard-Pakete aus Portage, sondern einen eigenen Overlay, und teilweise erheblich gepatchte Pakete (z.B. Apache...). Gentoo ist für sowas natürlich eine gute Basis.

Die Server der Hoster sind in der Regel von außen nur über FTP, HTTP und SSH erreichbar, andere Dienste sind nicht aktiviert oder nur über localhost erreichbar (z.B. MySQL). Trotzdem wird ein Paketfilter verwendet, um zu verhindern dass ein Angreifer über ein unsicheres Kundenscript eine bindshell oder sowas in der Art starten kann. Allerdings kann man dann immer noch einen Tunnel vom Server aus herstellen. Wenn man deshalb auch ausgehenden Verkehr filtert, wird das wie gesagt schnell problematisch mit Webservice Scripten der Kunden, Mail-Versand...

Das Haupteinfallstor für die Angriffe ist in der Regel der Apache bzw. unsichere Scripte. Entsprechend müssen ALLE Scripte unter der UserID des entsprechenden Kunden laufen, denn so sind - ordentlich vergebene Dateirechte vorausgesetzt - erstmal nur dessen Daten in Gefahr -> suExec, suPHP. (vergiss safe_mode)

Dann muss man sich fragen, was man den Kunden auf dem Server so alles erlauben will. Einfach binaries löschen bringt nichts wenn ein gcc da ist, und auch den wegzulassen bringt nichts da man einfach fertige binaries hochladen kann. Man muss also davon ausgehen, dass ein Angreifer potentiell _jeden_ Code mit den Rechten des Kunden ausführen kann. Jeder Versuch dies zu beschränken birgt das Risiko umgangen zu werden. Was man machen kann, ist Zugriff auf /proc zu verhindern, somit werden schonmal alle Tools die auf /proc zugreifen (top, ps, netcat, lsof...) mehr oder weniger nutzlos. Da kann sich der Angreifer auf den Kopf stellen, da kommt er auch nicht mit eigenen Programmen dran, da er nicht die Berechtigung hat /proc zu mounten.

Natürlich muss der Kernel und vor allem UID 0 Software aktuell gepatched sein, vielleicht noch Kernelpatches für proaktive Sicherheit verwenden (grsec, selinux...) - allerdings wäre es mir neu wenn sowas in der Regel verwendet würde. Viele kommen mit den Posix ACLs aus - oder verwenden noch nichtmal diese.

Ein weiterer Baustein ist die Überwachung der Server, ich gehe mal davon aus, dass erfahrene Hoster dies teilweise automatisiert machen, und die entsprechend erfahrenen Admins finden im Fall der Fälle auch recht schnell die Schwachstelle. Vielleicht scannen sie sogar die Verzeichnisse der Kunden nach bekanntermaßen unsicherer Software...

Wie gesagt, wirklich ordentliches shared hosting zu betreiben ist IMHO ne ganze Ecke schwieriger als nen Server zu mieten und ein bisschen zu konfigurieren so dass es überhaupt irgendwie funktioniert... Ich kenne nur wenige Hoster von dessen Qualität ich wirklich überzeugt bin!

Keine Ahnung was die Jungs da noch so machen, vielleicht hat da ja einer von Euch noch gute Ideen? Vor allem muss man ja verhindern, dass der Angreifer...

1. ... seine Rechte erweitern kann -> aktuelles System, proaktive Sicherheit, ACLs - noch was? Was setzen große Hoster hiervon ein? So akuell ist die Software nicht immer, vermutlich nur gepatched wenn wirklich eigene Software betroffen wäre, aber von Kernelpatches(grsec, selinux) habe ich in diesem Zusammenhang noch nichts gehört

2. ... Verbindungen nach außen aufbauen kann (DOS, Tunnel, Angriffe...), aber wie soll das gehen, ohne die Kunden in ihren Möglichkeiten zu beschneiden?

3. ... Überhaupt eigenen Code auf dem Server ausführen kann? Kann man das überhaupt verhindern? Ich denke nicht solange der User unter dem Scripte laufen, in ein Verzeichnis schreiben kann. Bringt es was bei PHP die Funktionen zur Ausführung von Shellkommandos zu verbieten? Ich glaube nicht, da man sich nicht sicher sein kann, dass Befehle auch über irgendeine Extension ausgeführt werden können oder vergleichbares. Abgesehen davon, wenn man CGI Skripte erlauben will (und das erlauben die meisten 'guten' Hoster) - hat man diesbezüglich sowieso verloren. Es können in irgendwelchen Perl/CGI Scripten genau so viele Sicherheitslücken stecken wie in PHP Scripten (http://www.heise.de/security/news/meldung/62744).

Warum sollte man den Zugriff auf /proc beschränken, wenn man davon ausgeht dass ein Angreifer mit seinen Rechten eh nicht viel anfangen kann? Nur für Zeitgewinnung, Erschwerung oder gibt es wohl andere Gründe?

Gibt es weitere sinnvolle, vergleichbare Maßnahmen?

edit: etwas erweitert ;-)

Ich habe ja auch Kunden auf meinen Servern - und bei denen sind einerseits Leute dabei, die nur HTML-Seiten haben oder von mir gebaute Seiten oder solche, die Ihre Seite per gekauftem und supportetem CMS betreuen - also fallen bei mir die meisten der üblichen Eingangstore weg.

Ich habe auf dem alten Rechner mod_php am Laufen, safe_mode teilweise aus, grsec-Kernel, jeweils aktuellste Versionen der Dienste und darunter ein woody.

Der neue Rechner hat für jeden "Kunden" eine eigene Instanz mit der sich der User in seinem Apache austoben kann und ein Proxy, der die Anfragen an die User-Instanzen weiterschiebt und zur Filterung mod_security benutzt. Dazu laufen die Userinstanzen unter dem jeweils eigenen Kundenkonto mit der Gruppe des Kunden, so daß ich die Filesystempermissions dichter machen kann als vorher. Das war mir eigentlich bei der Sache am wichtigsten, die Idee für das Setup kam mir mit den Artikeln über den Wegfall des Safe_mode in den neueren PHP-Versionen, die noch kommen. Mit meinen knapp 30 Webseiten rechne ich dann mit einer quasi-Auslastung des Rechners, es ist relativ ressourcenfressend.

Mit dem Mailverhalten meiner User habe ich da teilweise mehr Probleme - was die da anstellen, ist teilweise schon DDoS ... aber hier steige ich dann auf ein System mit mehr Plattenplatz um, dann geht das auch.

Mir ist übrigens selber vor ein paar Jahren mal ein IRC-Bouncer installiert worden - ausgeführt direkt im "/tmp". Der Rechner war zum Glück nur eine Testmaschine und ist auch komplett vergessen worden - der stand halt rum.

flo.

woher nehmt ihr eigentlich alle die Sicherheit das eure Server noch nie kompromittiert wurden? ein erfolgreicher angriff ist ein unerkannter angriff. und ueber sowas sollte man sich eigentlich gedanken machen _bevor_ man kunden auf seinen server laesst...

@-ec-: Nimm das jetzt bitte nicht persönlich, aber auf solche Antworten kann ich verzichten!

Ich habe bereits einige Bücher zu diesen Themen (auch gelesen). Ich habe auch seit etwa 5Jahren Erfahrung mit Root-Servern. Mittlerweile sind es 4 Stück. Aber nur auf dem einen hier laufen auch Kunden drauf. Und es bisher nie etwas passiert, trotz Angriffsversuchen! Das zeigt ja, dass meine Server nicht die unsichersten sind. Aber nun bin ich an einem Punkt an dem ich mit den Büchern die ich habe nicht weiterkomme und deshalb hier um Rat gefragt habe, weil ich der Meinung war, dass ich hier schneller an die Infos komme als weitere 10 Bücher zu lesen.

Die Frage ist ja auch, was ihr an meiner Stelle tun würdet und welche Erfahrungen ihr bereits gemacht habt. Wie iptables funktionieren, wie diese eingerichtet werden und welche Vor- und Nachteile diese haben weiß ich bzw. kann es hier nachlesen. Mir geht es einfach um Tipps und Ideen, denn Sicherheit ist meiner Meinung nach nur das Stückchen, was wir den Hackern voraus sind. Und da sind Ideen gefragt, wie man den Hackern wieder einen weiteren Schritt vorauseilen kann, denn die holen auf, und wenn wir keine neuen Ideen entwickeln, wird es irgendwann keine Sicherheit mehr geben, oder?!

Und da das ganze ein produktiv-system ist möchte ich ungern mit verschiedenen configs "rumprobieren" sondern auf erfahrungswerte setzen. Dafür bin ich hier und nicht in irgendwelchen Büchern über die Theorie.

Das wollte ich nur mal klarstellen. Aussagen wie "Du solltest keinen Root-Server haben" sind bei vielen Leuten sicherlich richtig, aber eben nicht immer. Und ich würde mich als "fit genug" für einen Root-Server einschätzen... wie gesagt, 5 jahre ohne probs!

das mit den 5 jahren ohne erfolgreichen angriff kann ja auch nicht stimmen: :-D

Laut meinem Hoster wurde von meinem Server aus eine Attacke (UDP Flooding port 65000) durchgeführt. ICH war es definitiv nicht!!!

-ec- wrote:woher nehmt ihr eigentlich alle die Sicherheit das eure Server noch nie kompromittiert wurden? ein erfolgreicher angriff ist ein unerkannter angriff. und ueber sowas sollte man sich eigentlich gedanken machen _bevor_ man kunden auf seinen server laesst...

Sieh hier mal die Relation - wer sich einbildet, ein Hochsicherheitsrechenzentrum auf verteilten Rootservern zu realisieren, hat irgendetwas nicht verstanden.

Der Großteil aller "mein Server wurde gehackt"-Kandidaten war Ziel von groß angelegten, automatischen Hacks - wir reden hier nciht davon, daß es jemandem mit Sachverstand und krimineller Energie darum geht, wertvolle Daten von wertvollen Servern zu ziehen. Die meisten Exploits werden dazu benutzt, andere Rechner zu scannen und/oder Mails oder Viren durch die Gegend zu ballern - das ohne Rücksicht auf Verluste möglichst viel in möglichst kurzer Zeit.

Das andere Extrem, daß sich irgendeine Hackgruppe Deinen Rechner aussucht und den knackt ... kann passieren, dafür gibt es Backups. Hundertprozentige Sicherheit ist nicht machbar, außer Du ruft bei Deinem Provider an und sagst ihm, er möchte doch bitte das Netzwerkinterface abstecken.

@ec: Davon abgesehen find ich Deinen Ton gegenüber anderen Postern etwas zu ruppig.

flo.

@-ec-: Also deine letzte Aussage verstehe ich nich! Wieso kann das mit den 5 Jahren nicht stimmen?! JETZT stimmt es natürlich nicht mehr, aber bis zu diesem Angriff stimmte es ^^

Also weißt du, ich bin in dieses Forum gekommen um Hilfe zu bekommen und keine Aussagen vom Stil "Ich erklär dir mal warum ich dir nicht helfen werde". Vielleicht solltest du mal genauer lesen und deine Einstellung gegenüber Personen verändern, die möglicherweise etwas weniger Ahnung haben (oder von denen du es denkst) als du...

In jedem Fall danke ich allen (auch -ec-) für eure kurze Info, wenn mir jetzt noch jemand was über meine Iptables-Überlegung sagt, bin ich glücklich :-D . Habt ihr sowas schonmal gemacht und welche werte habt ihr so genommen?

exciler wrote:In jedem Fall danke ich allen (auch -ec-) für eure kurze Info, wenn mir jetzt noch jemand was über meine Iptables-Überlegung sagt, bin ich glücklich :-D . Habt ihr sowas schonmal gemacht und welche werte habt ihr so genommen?

Das ist auf jeden Fall eine gute Idee, wenn Du keinen externen Paketfilter hast, aber leider kann ich nichts wesentliches dazu beitragen. :-(

flo.

Wenn du 4 Rootserver administrierst würde da schon eine Colo rausspringen mit zugriff auf einer externen Firewall, dann kannst du dir relativ sicher sein das niemand so schnell die Regelwerke löscht. Wenn du die Firewall als Bridge konfigurierst dürfte da nicht mal mehr ein loginversuch kommen, allerdings hast du dann auch nur noch einen lokalen Zugriff (oder via Serieller Konsole). Aber wäre mir egal wenn ich in der nähe der Colo wohne ;)

Anyway, wenn du nur Rooties hast bleibt halt einfach nur die iptables Variante und beten das keiner so intelligent ist ein iptables -F abzusetzen (iptables würde ich via GRSec aber sperren) oder noch besser, ein Shellcode dafür zu nutzen.

Was auch eine überlegung wäre, warum steckst du die Kunden (sofern du welche hast) nicht einfach in eine XEN Domain, das ganze ist wirklich einfach und die sollen halt einfach nur eine Einrichtungsgebühr zahlen für die IP (nating ist bei mehreren Kunden etwas schwierig, bin auf keinen grünen Zweig gekommen bisher) und dein Wirtsrechner hat nur die SSH laufen, abgeschirmt durch ein Portknocker. Dann würden die iptables was bringen da nur du zugriff auf die Bridge hast und regeln erstellen kannst die IP unabhänging sind. Verbunden mit GRSec (leider noch keine Praxisversuche mit GRSec/XEN) dürfte jede XEN Domain bei anständiger einrichtung (suPHP etc. das weißt ja schon) so gut wie unknackbar sein. Ich sage so gut wie, es ist alles knackbar, aber nicht durch standard Exploits von Kindern.

Die spässe mit Kunden auf einen Rechner sind immer schlecht, vor allem was die Sicherheit angeht. Das ganze über Virtualisierung zu lösen wäre das beste und einfachste. XEN ist nur ein Beispiel für viele lösungen, vielleicht ist das ein denkanstoß für dich.

MFG
Lord Pinhead