chattr weg

D

DavidW

Grünschnabel
Hallo Zusammen,

unser Server (Debian 5) wurde durch einen externen Administrator für uns umkonfiguriert. Zu diesem Zweck wurde das root-PW auf ein einfaches Passwort für 2 Tage gesetzt. Und genau dann passierte es. Der Server wurde nachts gehackt und ein Cronjob startet nun jede Minute 2 neu installierte Dateien. Leider sind diese 2 Dateien, sowie die /ec/crontab höchstwahrscheinlich durch chattr +i geschützt worden, denn die Dateien lassen sich als root nicht mehr bearbeiten bzw. löschen.

Die Datei /usr/bin/chattr wurde leider ebenfalls gelöscht. Ich habe per SCP von einer anderen Maschinie die Binary kopiert und getestet, jedoch ohne Erfolg. Wie kann ich am Besten fortfahren? Kann ich auf eine sichere Art ext2fs neu installieren?

Bitte um Hilfe.

Vielen Dank,
David
 
Neu aufsetzen. Das ist der einzig sichere Weg, einen kompromittierten Server wieder vertrauenswürdig zu machen.
 
Die Dateien müssen nicht durch chattr geschützt worden sein und sind es vermutlich auch nicht. Die meisten Rootkits nutzen Kernel-Trojaner um Dateien vor der Löschung zu schützen. Daher dem Rat von Schard folgen.
 
Hallo Zusammen,

danke für die Antworten.
Wenn es passiert, dann richtig. Das ist unser Livesystem, sprich unser Produktivsystem in der Hochphase des Jahres. Ein Neuaufsetzen ist aktuell nicht möglich. Ich überlege heute Nacht, wenn weniger Kunden aktiv sind, den Rescue Modus zu starten und ggf. darüber die Dateien zu entfernen. Leider weiß ich nicht, ob das überhaupt möglich ist und ob wir heute Nacht ein paar ruhige Minuten finden. Unser FailOver Server hat einen HW Schaden und ist ein paar Tage offline. Lief 2 Jahre und wurde noch nie benötigt. Kaum fällt er aus, kommen Probleme auf dem Hauptsystem.

Es handelt sich hierbei um diesen Hack (f Opyum Team):
http://6d6fireball.com/rpg/server-hacked/

Dort werden die Dateien /bin/i /bin/f und /etc/crontab per chattr -i bearbeitet und anschließend gelöscht bzw. bearbeitet.

Selbst wenn ich den Cronjob, der jede Minute gestartet wird versuche zu entfernen, kommt ein Fehler wegen fehlenden Rechten....

Ein "locate chattr" liefert ein Ergebnis unter "usr/bin/chattr".
Gebe ich "ls -al /usr/bin/chattr" wird nichts mehr gefunden. Die Datei war also gestern noch da. Heute morgen stand der Fremdzugriff statt.

Um die Anzahl der Prozesse und Systemleistung so gering wie möglich zu halten, kille ich jede Minute die Schadsoftware. rkhunter fand übrigens nichts auffälliges, trotz vorherigem DB-Update.

Noch weitere Vorschläge um erstmal das Problem in den Griff zu kriegen? In ein paar Wochen ist eine Neuinstallation mit Sicherheit sinnvoll, um ggf. weitere Schwachsellen zu beseitigen.

Danke im voraus,
David
 
Die Kiste Rescue booten und neu aufsetzen mehr kann man dazu nicht sagen und wenn da eine Firma dranhängt dann habt ihr einfach zu billig eingekauft. So einfach. Die Kiste ist hoffnungslos verseucht und die bekommst du auch nicht mehr hin und wenn du einen deut an Verantwortungsbewusstseinhast dann fährst du diesen Schrotthaufen auf der Stelle runter.
 
Setze dir irgendwo mit VirtualBox eine VM mit der gleichen Debian-Version auf, hole dir da die chattr-Binary raus und kopiere sie per scp/sftp auf den Server. Alternativ kannst du die Attribute auch mit einem Rettungssystem wieder ändern.

Dennoch kann auch ich nur dazu raten den Rechner neu aufzusetzen. Wenn rkhunter trotz eines offensichtlich vorhandenen Rootkits nichts findet, kannst du mit Sicherheit nicht nachvollziehen was alles im System verändert wurde, es sei denn du hast ein Vollbackup mit dem du den aktuellen Zustand vergleichen kannst. Aber dann könntest du die entfernten Dateien auch einfach aus dem Backup nehmen.
 
Neu aufsetzen, alles andere ist unverantwortlich, auch gegenüber euren Kunden.

Und beim nächsten mal nehmt keyfiles für ssh zugänge von externen, dann müsst ihr keine sicherheitslücken ins system reißen.
 

Ähnliche Themen

Crontab und Scripts - Problem

Zugriff auf Samba Fileserver Freigaben verweigert(Samba 4 Active Directory Domäne)

Samba Datentransfer bricht ab

Service oder Screen überwachen und ggf. Neustarten?!

CentOS VM boot verändern und Netzwerksettings von Share laden

Zurück
Oben