Apache stürzte ab, Port dennoch belegt, rkhunter

F

Fr33z3m4n

New Member
Hi,

nachdem gestern mein Webserver (Apache) seltsamerweise ausgeschaltet war, jedoch etwas den Port 80 belegte, bin ich heute dabei, mir die Umstände anzuschauen.

Gestern konnte ich den Apache nur noch starten, nachdem ich den Prozess "usr/sbin/apache" beendet hatte.
Diesen Prozess kannte ich ja nunmal garnicht.

Heute fand ich dann eine Datei namens 80.txt in meinem /tmp Verzeichnis.
Dieses, so schien es mir zumindest, war eine Exploit-Datei.

Hab dann gleich mal den RootkitHunter laufen lassen.
Anbei das Log:

http://www.tbc-crew.de/rkhunter/rkhunter.log

Ist dort jetzt irgendwas schräg ?

LG
 
Hallo Thorsten,

tja dafür kann mich jetzt hier jeder Ohrfeigen :)

Wieso auch immer, habse natürlich gelöscht. Kam wieder der Geist "Bloß weg damit" bevor der Gedanke gesagt hat, ne Sichern.

Hab nur noch die Zeile am Ende der Datei in Erinnerung

[milw0rm.com] ....
 
Sry für Doppelpost, konnte nun in den Logs die Datei wiederfinden.


!! WARNUNG !!
!! BITTE NICHT OHNE VIRENSCANNER ÖFFNEN !!!!!!!!!!
hxxp://boo.ai/80.txt

Hab dann noch das folgendene im error_log des Apache gefunden.
perl: no process killed
--2010-06-01 13:00:47-- hxxp://boo.ai/80.txt
Resolving boo.ai... 89.40.168.177
Connecting to boo.ai|89.40.168.177|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17768 (17K) [text/plain]
Saving to: `/tmp/80.txt'

0K .......... ....... 100% 170K=0.1s

2010-06-01 13:00:48 (170 KB/s) - `/tmp/80.txt' saved [17768/17768]

kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
Click to expand...
 
Ist eine Remote Shell. Ohne ausführliche Analyse des Systems (insbesondere der Logs, auth.log, lastlog, access.log, etc.) lässt sich schwerlich sagen ob das System kompromittiert wurde, wenn jedoch schon Prozesse laufen die du vorher nie gesehen hast ist das natürlich schon sehr alarmierend, ebenso das Log von rkhunter (obwohl ich rkhunter und Konsorten nicht blind vertrauen würde, zu viele false positives)....aber alleine die Anzahl von Usern und Groups auf dem System ist schon sehr seltsam.
Interessant wären natürlich die Permissions der File gewesen (Owner www-data oder sogar root).

An deiner Stelle würde ich jedoch bis zur vollständigen Aufklärung den Server komplett runterfahren nachdem du alle nötigen Files zur Analyse auf dein lokales System heruntergeladen hast.

P.S. Check mal /usr/sbin/apache, Timestamp, etc.
 
Last edited by a moderator:
@bad_brain
Thx für deine Antwort.
Jedoch den Server runterfahren, ist derzeit für mich keine Option :( Leider.

Hab erstmal Root-Login verboten, sowie fail2ban eingerichtet.

Hast du vlt. Hilfreiche Ideen, wo ich nun am besten ansetzen kann ?
 
Wie ich schon sagte: Logs überprüfen.
Poste mal den Output von:
Code: 
ls -l /usr/sbin/apache
 
Jedoch den Server runterfahren, ist derzeit für mich keine Option :( Leider.
Click to expand...
Eeehm, es kann sehr gut angehen, dass er dich gerade im Hintergrund arm macht. Ob durch Traffickosten, Schadensersatzansprüche, Abmahnungen oder Bußgelder.

Den Server abzuschalten, ist genau die einzige Option für dich!

Und warum ist es keine Option? Gibt es nicht iwie die Möglichkeit, die Dienste vorrübergehend auszulagern/umzuziehen?
 
Läuft der Prozess noch? Falls ja per ps -A die PID des Prozesses herausfinden, danach ps <PID>.
Dann siehst du ja was den Prozess gestartet hat.

Kann mich jedoch der Warnung von Artimis nur anschliessen.
 
Ne der Prozess läuft nicht mehr.
Hatte den ja bereits gestern abend abgeschossen, weil er den Port 80 belegt hatte.
 
Naja, dann wären wir wieder bei der Analyse der Logs (im syslog solltest du wohl Einträge über den Start des Prozesses finden).
Falls du damit überfordert bist rate ich dir dringend jemanden damit zu beauftragen der Ahnung hat, den Server einfach mal auf gut Glück weiterlaufen zu lassen ist schwerst fahrlässig und kann zu den von Artimis angesprochenen Konsequenzen führen, und wir reden hier über Beträge die auch gerne mal zur Privatinsolvenz führen können wenns dicke kommt.
 
So,

update:

Danke an bad_brain der für mich meinen Server einer gründlichen Analyse unterzogen hat.
Aber aufgrund meines Löschens, konnte er keinerlei Schwachstelle finden.
Lediglich einen Kernel-error, sowie den Absturz des Apache konnte noch nachvollzogen werden.

Das lag aber wie gesagt nicht an Bad_Brain, sondern an mir, dass ich die besagten Dateien gelöscht habe.

Die weitere Vorgehensweise haben wir besprochen, und er hat mir einige Tipps in Richtung Sicherheit gegeben.

Ich kann bad_brain nur jedem Empfehlen :)
 
Oh, vielen Dank...:)
Hätte gerne mehr geholfen und die Sache 100% aufgeklärt, aber es gestaltete sich ja leider etwas schwierig ohne die "Beweismittel".

Die Logs waren zumindest alle sauber, auch sonst fanden sich keine Hinweise auf eine Kompromittierung, die Remote Shell lag wahrscheinlich schon länger in /tmp, nur ein einziger Zugriffsversuch konnte gefunden werden der jedoch nicht erfolgreich war. Der Absturz des Apache war vermutlich durch ein Systemupdate bedingt das relativ zeitgleich durchgeführt wurde, zur selben Zeit fanden sich auch die Hinweise auf auf die Kernelprobleme.

Also wie gesagt das System erst einmal "auf Bewährung" laufen lassen und die Logs in Auge behalten da sich der Verdacht der Kompromittierung leider nur zu 99% beseitigen liess....;)
 
Allein dass das Skript auf Port 80/tcp lief, würde mir schwere Kopfschmerzen bereiten.

Das bedeutet entweder, dass der Apache httpd in der eingesetzten Version einen schweren Bug enthält, so dass beliebige Socket-Deskriptoren übernommen werden können, oder dass der Angreifer Root-Rechte hatte.

An die privilegierten Ports <1024 können sich normalerweise nur Programme binden, die unter der UID 0 (root) gestartet oder denen die Capability CAP_NET_BIND_SERVICE gegeben wurde.
 
Naja, das Problem ist eben dass es keinerlei Hinweise (mehr) gibt, also konnte ich nur die Informationen nutzen die noch vorhanden waren (sprich Logs, Prozesse checken, etc.)....und dort waren keinerlei Auffälligkeiten zu finden (bis auf die 2 Einträge mit der 80.txt File, der 2. Eintrag war ein missglückter Zugriffsversuch über http, danach kam nichts mehr).
Natürlich wäre es auch denkbar dass der Angreifer die Logs gesäubert hat, dann wären aber wohl auch die 2 Einträge nicht mehr vorhanden, natürlich insofern 80.txt überhaupt etwas mit dem eigentlichen Angriff zu tun hatte oder schon eine Folge einer erfolgreichen Kompromittierung war.

Den laufenden suspekten Prozess per ps zu checken um zu sehen was ihn gestartet hat sowie die Attribute von 80.txt einsehen zu können wäre natürlich äusserst hilfreich gewesen....besser gesagt hätten diese den eindeutigen Beweis einer Kompromittierung erbracht (oder eben keiner Kompromittierung).

Deshalb auch mein Hinweis den Server erst einmal auf "Bewährung" laufen zu lassen und alles genau im Auge zu behalten. Für mich selbst hat die Sache auch einen faden Beigeschmack, aber in der Situation war leider eine komplette Aufklärung nicht möglich und ich konnte in einigen Aspekten nur spekulieren.
 
Last edited by a moderator:
Entschuldigt bitte,

aber im Zweifel, ist das System kompromitiert und muss zwingend neu aufgesetzt werden. Und zwar aus auschliesslich vertrauenswürdeigen Quellen.
Danach muss jeder Dienst / Webseite etc. gewissenhaft gepürft werden um es eventuell wieder online zu nehmen.

Eine Lücke gab es mit Sicherheit und diese ist nach meiner Befürchtung, nicht gestopft.
 
bad_brain said:
Ist eine Remote Shell.
Click to expand...

Das Script ist per se keine Remote shell.
Das was es allerdings ermöglicht, spricht dafür, dem System nicht mehr zu vertrauen und sofort zu sichern, danach vom Netz zu nehmen um die Sicherung im LAN einer forensischen Untersuchung zu unterziehen.

Wie aber zuvor schon gesagt, jede "webseite" etc. muss vor dem wieder online nehmen genaustens analysiert werden.

BTW: Und die ggf. alte nicht mehr supportete Distribution darf auch nicht mehr verwendet werden.
 
You must log in or register to reply here.
Back
Top