Nach Serverhänger alle Dateirechte geändert!

pastors · Beitrag von **pastors** » 30.01.2006 11:41:16

Hi,
unsere Firma betreibt einen Webserver mit Debian Sarge. Gestern abend blieb die Maschine stehen, totaler Ausfall. Heute morgen neu gebootet und da kamen schon die ersten ungereimheiten. Der Benutzer root kann sich nicht auf der Konsole einloggen und alle Dateirechte wurden auf 777 geändert.
Einloggen durch einen anderen Benutzer und einem anschließendem su und der root Akkount darf benutzt werden.
Was mich nun verwundert, wieso wurden alle Dateirechte geändert? Hat irgendjemand schon etwas ähnliches erlebt?

Mike

DeletedUserReAsG · Beitrag von **DeletedUserReAsG** » 30.01.2006 12:19:47

Paranoid wie ich bin, würde ich hier zunächst an ungebetene Gäste denken. Auf jeden Fall würde ich aber die relevanten Logs durchgehen, und dann, wenn mir da was unklar ist, in einem Forum fragen

cu

meandtheshell · Beitrag von **meandtheshell** » 30.01.2006 12:31:16

Zu 99% hattest du Besuch ...

Ein Debian dreht nicht durch und macht sich selbstständig.
Wie gut hast du den Server abgesichert? Eher weniger gut oder?

Ich würde da nicht lange überlegen - da sind sicher noch ein paar Eier die gelegt wurden.
Alles runter und Server mit einem Backup TOTAL neu aufsetzen.

markus

pastors · Beitrag von **pastors** » 30.01.2006 13:45:21

Hi,
oh weh. In den Standardlogs sind jedenfalls keine Einträge die auf einen Angriff hindeuten. Der Server ist eigentlich relativ gut gesichert. Nach außen ist nur der HTTP-Port offen. Die neusten Updates sind auch eingespielt.
Wie könnte ich nachträglich noch erkennen ob jemand auf dem System war?

Mike

HELLinG3R · Beitrag von **HELLinG3R** » 30.01.2006 14:16:05

ein schlecht gesicherter Apache (port 80) reicht aus, um einzubrechen.
Wenn dann die Kiste "intern" schlecht gesichert ist, zb Dateirechte nicht restriktiv genug gesetzt waren, oder jemand ein rootkit nach /tmp geschreiben hat oder, oder oder...
du siehst, es gibt viele Möglichkeiten.
Hast du ein IDS installiert (zb tripwire)? das würde weiteren Aufschluss geben, ob und was geändert wurde.
Ein guter angreifer verwischt auch seine Spuren im Logfile, solange du also auf der gleichen Kiste loggst, kannst du den logfiles nicht trauen.

startx · Beitrag von **startx** » 30.01.2006 14:26:54

Gestern abend blieb die Maschine stehen, totaler Ausfall.

wobei ein "guter" angreifer wohl nicht absichtlich das system zum halten bringt. wenn er root rechte bekommen hat gäbe es auch keinen grund die dateirechte auch 777 zu ändern.

wäre ein seltsamer freak, der zwar die logfiles und .bash-history löscht aber alle dateien world readable macht ...

Der Benutzer root kann sich nicht auf der Konsole einloggen ...
Einloggen durch einen anderen Benutzer und einem anschließendem su und der root Akkount darf benutzt werden

also ein remote login direkt für root sollte es ja eiegtnlich von haus aus nicht geben ... offensichtlich ist das passwort ja auch erhalten geblieben. merkwürdig.

was genau meinst du mit "ausfall". nicht erreichbar (ping) oder wirklich runtergefahren?

meandtheshell · Beitrag von **meandtheshell** » 30.01.2006 14:57:30

startx hat geschrieben: wobei ein "guter" angreifer wohl nicht absichtlich das system zum halten bringt. wenn er root rechte bekommen hat gäbe es auch keinen grund die dateirechte auch 777 zu ändern.

man kann es ganz einfach nicht sagen - das ist auch schon der haken ...

wäre ein seltsamer freak, der zwar die logfiles und .bash-history löscht aber alle dateien world readable macht ...

gibt es auch freaks die nicht seltsam sind

also ein remote login direkt für root sollte es ja eiegtnlich von haus aus nicht geben ...

richtig root login über ssh sollte man nicht erlauben

Möglich wäre natürlich auch das einer der Leute die regulären Zugriff über ssh auf den Server haben einfach Mist gebaut hat ...

ein

Code: Alles auswählen

chmod 777 -R /

abgesetzt hat oder ähnliches
dafür ist es am besten solche Dinge mittels sudoers zu unterbinden

markus

pastors · Beitrag von **pastors** » 30.01.2006 15:38:34

Hi,
danke für die Antworten. An einen Angriff glaube ich langsam nicht mehr. Denn wer macht sich die Mühe einen Rechner zu hacken und setzt anschließend die Dateirechte so offensichtlich?

Zum Rechnerausfall kann ich wenig sagen. Bis 23:07 wurde der syslog geschrieben und danach war die Maschine tot. Danach meldete Nagios den Ausfall der Maschine. Die Maschine war definitiv down also nicht nur Dienste abgeschaltet.

Die .bash_history zeigt nirgends ein chmod an. Auch wurden keine Dateien neu angelegt. Kann ich nachprüfen ob die .bash_history nachträglich geändert wurde?

Mike

herrchen · Beitrag von **herrchen** » 30.01.2006 15:53:34

pastors hat geschrieben:An einen Angriff glaube ich langsam nicht mehr

genau wie startx bin ich da auch skeptisch.

Bis 23:07 wurde der syslog geschrieben und danach war die Maschine tot.

gab es kurz vorher zugriffe auf den webserver?
hattest du schon einmal probleme mit dem filesystem? welches verwendest du?
ist die festplatte defekt? such doch mal im syslog der letzten zeit nach hdx/sdx ...
sonstige hardware? netzteil, RAM ...

trotzdem sollte der rechner *natürlich* von einem sauberen backup aufgesetzt werden.

herrchen

pastors · Beitrag von **pastors** » 30.01.2006 16:55:52

Hi,
bei den Server handelt es sich um einen IBM Bladeserver. Dieser wird eigentlich sehr gut vom IBM Director mit überwacht. Hardwaredefekte wie RAM und Festplatten kann ich ausschließen. In der auth.log waren in letzter zeit zwar häufiger versuchte Logins auf ssh aber ansonsten nichts außergewöhnliches.
Die Rechte hab ich Sicherheitshalber zurückgeseztz und nun klappt auch das root login wieder.
Das mit dem backup ist immer so eine Sache. Sollte der Server tatsächlich manipuliert sein, bringt mir ein zurückspielen des Backups evtl. nichts. Denn der Exploit könnte bereits über mehrere Wochen auf den Bändern sein.
So, nachdem ich alles wieder einigermaßen gerichtet habe, mache ich mir erstmal einen Hash übers Dateisystem (übrigends JFS und XFS). Die Dateien in /bin und /sbin habe ich ausgetauscht bzw. durch neu kompiliert.

Mal sehen was sich in nächster Zeit tut...

Mike