Kein Zugriff mehr auf vserver

[Nuac15]

Hallo,
ich habe folgendes Problem. Ich komme mit den normalen Mitteln nicht mehr auf den vserver.
Ausgangslage:
Ping funktioniert nicht
Putty -> connection timed out
http -> Fehler: Verbindung unterbrochen

Grundlegende Dinge:
vserver bei proplay -> status webinterface online; restart ohne veränderung
rescue console lässt mich auf server
auth.log: => bruteforce? gehackt?
top => siehe Anhang

Backup vorhanden, aber lieber Fehlersuche damit nicht in 2 Wochen selbes Problem.

mangelnde Kenntnis von Linux und Fehlersuche. Weiteres Vorgehen?
Mittels ftp, scp komme ich über rescue console nicht an daten, daher leider keine kompletten logs ect downloadbar.

System:
debian-5.0-x86_32-minimal ip:46.4.150.227
apache2 als webserver
mysql und php
dazu leider ohne kontrolle von mir: teamspeakserver, forum, postfix(bin eigtl auch nur webadmin der eine internetseite dort hostet)


Jetzt erhoffe ich mir von euch Hinweise wie ich den Fehler finde, abstellen kann oder auch erstmal auf die Daten zugreifen kann.
Beste Grüße

Code: Alles auswählen

auth.log (mit vi geöffnet, leider nur den aktuellen Bildausschnitt kopieren können)
Dec 10 19:30:33 xyz sshd[4301]: Failed password for root from 111.223.89.202 port 49761 ssh2
Dec 10 19:30:36 xyz sshd[4303]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=111.223.89.202  user=root
Dec 10 19:30:38 xyz sshd[4303]: Failed password for root from 111.223.89.202 port 49902 ssh2
Dec 10 19:30:41 xyz sshd[4310]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=111.223.89.202  user=root
Dec 10 19:30:43 xyz sshd[4310]: Failed password for root from 111.223.89.202 port 50061 ssh2
Dec 10 19:30:45 xyz sshd[4312]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=111.223.89.202  user=root
Dec 10 19:30:48 xyz sshd[4312]: Failed password for root from 111.223.89.202 port 50220 ssh2
Dec 10 19:30:51 xyz sshd[4316]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=111.223.89.202  user=root
Dec 10 19:30:53 xyz sshd[4316]: Failed password for root from 111.223.89.202 port 50388 ssh2
Dec 10 19:30:56 xyz sshd[4318]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=111.223.89.202  user=root
Dec 10 19:30:58 xyz sshd[4318]: Failed password for root from 111.223.89.202 port

Code: Alles auswählen

top - 15:17:26 up 2 days, 17:36,  0 users,  load average: 0.06, 0.02, 0.00
Tasks:  28 total,   1 running,  27 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    786432k total,    67440k used,   718992k free,        0k buffers
Swap:   786432k total,       56k used,   786376k free,    37744k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  401 mysql     20   0  141m  17m 4752 S    0  2.3   0:35.12 mysqld
    1 root      20   0  2128  728  632 S    0  0.1   0:01.56 init
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd/33231
    3 root      20   0     0    0    0 S    0  0.0   0:00.00 khelper/33231
    4 root      20   0     0    0    0 S    0  0.0   0:00.00 rpciod/33231/0
    5 root      20   0     0    0    0 S    0  0.0   0:00.00 rpciod/33231/1
    6 root      20   0     0    0    0 S    0  0.0   0:00.00 rpciod/33231/2
    7 root      20   0     0    0    0 S    0  0.0   0:00.00 rpciod/33231/3
    8 root      20   0     0    0    0 S    0  0.0   0:00.00 rpciod/33231/4
    9 root      20   0     0    0    0 S    0  0.0   0:00.00 rpciod/33231/5
   10 root      20   0     0    0    0 S    0  0.0   0:00.00 rpciod/33231/6
   11 root      20   0     0    0    0 S    0  0.0   0:00.00 rpciod/33231/7
   12 root      20   0     0    0    0 S    0  0.0   0:00.00 nfsiod/33231
  313 root      20   0  3772 1524  812 S    0  0.2   0:00.24 syslog-ng
  324 root      20   0  5600 1104  720 S    0  0.1   0:00.00 sshd
  364 root      20   0  2648 1200 1016 S    0  0.2   0:00.00 mysqld_safe
  402 root      20   0  1768  560  492 S    0  0.1   0:00.00 logger
  637 root      20   0  5320 2576  864 S    0  0.3   0:00.00 proplay_resdaem
  721 root      20   0  5868  996  804 S    0  0.1   0:00.19 cron
  858 root      20   0 42788 8356 4776 S    0  1.1   0:05.84 apache2
  882 www-data  20   0 42788 4248  656 S    0  0.5   0:00.00 apache2
  883 www-data  20   0 42788 4232  640 S    0  0.5   0:00.00 apache2
  884 www-data  20   0 42788 4232  640 S    0  0.5   0:00.00 apache2
  885 www-data  20   0 42788 4232  640 S    0  0.5   0:00.00 apache2
  886 www-data  20   0 42788 4232  640 S    0  0.5   0:00.00 apache2
 3777 root      20   0 29164  728  472 S    0  0.1   0:00.02 vzctl
 3778 root      20   0  2940 1568 1260 S    0  0.2   0:00.00 bash
 3782 root      20   0  2432 1152  940 R    0  0.1   0:00.48 top

[TRex]

mangelnde Kenntnis von Linux und Fehlersuche. Weiteres Vorgehen?

Diese beiden Missstände beheben. Ohne Logs können wir hier nämlich auch nichts machen (und du auch nicht, also erstmal lernen, wie man Dateien betrachtet).

[Nuac15]

Dateien betrachten mittels vi funktioniert schon, aber mir ist leider nicht klar wie ich den gesamten Inhalt vernünftig kopieren kann um ihn hier zu posten. Welche logs wären denn von Interesse?

[TRex]

Code: Alles auswählen

grep "Accepted" /var/log/auth.log

Code: Alles auswählen

Dec 15 06:21:22 odin sshd[23454]: Accepted password for root from 92.202.92.4 port 33062 ssh2

So könnte das beispielsweise aussehen. Das werden natürlich noch mehr Zeilen, aber das sollte zumindest in das Terminal passen. So sieht ein erfolgreicher Login aus. Anhand der IP solltest du dann herausfinden können, ob das wenigstens dein Provider ist (und ob du das warst). Wenn du das nicht warst, ist dein Passwort wohl zu einfach und du kannst in Folge die Maschine und dein Passwort als kompromittiert betrachten (auch für andere Dienste - ich spreche aus nicht eigener Erfahrung). Allerdings kann ein Angreifer mit root-Rechten seinen Zugriff schon kaschieren, dann siehst du nix.

Unter Umständen interessant sind Webserverlogs, falls irgendein PHP-Script als Einfallstor gedient hat. In dem Fall könnte man mit etwas Glück sogar davon ausgehen, dass der Angreifer keinen Schreibzugriff auf die Logs hatte und die Ursache noch drin steht. Die bräuchte man dann aber schon komplett.

[Nuac15]

Vielen Dank, ja sind Zugriffe drauf die auf ein automatisches durchprobieren deuten. Siehe unten.
Wie bekomme ich denn komplette logs ausgelesen, wenn ich ausschließlich per Kosole drauf komme? bzw wie bringe ich den Server wieder so hin, dass ich mich über den normalen Weg einlogen kann?
Passwort war eigtl vergleichweise sicher, 8stellig, Kombination aus Groß, Kleinbuchstaben und Zahlen.

36858

[TRex]

Das sind erfolgreiche Zugriffe (darum "Accepted"). Ich hab das mal whois auf die IPs losgelassen:

Code: Alles auswählen

grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' auth.tmp.txt | sort -u | while read ip; do whois $ip; done > auth.whois.txt

Da kommen dann so Sachen drin vor:

Mir Telematiki Ltd (RU)
OVH Hosting Limited (intern?)
OVH ISP aus verschiedenen Ländern
TR-TURKCELL-INTERNET
NETDIRECT-NET (Leaseweb Germany GmbH)
Deutsche Telekom AG
ServerClub Inc. (US)

Die Einträge sind aber auch recht alt, hast du das Ende des Logfiles kopiert oder den Anfang?

Vielleicht hast du ja user mit Root-Zugriff dort, die sich aus Russland und Türkei einloggen (tor?). Die Zugriffe von anderen Hostern könnten zB auch gekaperte Maschinen sein. Das musst aber du alles selbst bewerten. Wenn du derjenige mit der Verantwortung fürs Rettungssystem bist, gehört dir ja wohl der Server, und du solltest wissen, was darauf läuft und wer Zugriff hat.

Wie du ohne SSH oder vergleichbare Dienste an ganze Dateien kommst, weiß ich nun leider auch nicht.

Du könntest nun auch noch schauen, ob irgendwas verkonfiguiert ist. Wenn außer dir noch andere regulären Rootzugriff haben, war das vielleicht bloß der Versuch, eine Firewall zu konfigurieren. Die üblichen Verdächtigen, die an einem Server "Ports freischalten" wollen, stehen in der Hackordnung noch unter dir. So Leuten gibt man dann aber auch keinen Rootzugriff.

[Nuac15]

Hallo,
das ist das komplette Ergebniss zur Suche.
Alter kommt hin, ist letztes Wochenende. Am Dienstag wurde bemerkt, dass kein zugriff mehr möglich ist.
Hatte aber noch nicht ernsthaft Zeit, daher erst jetzt die Threaderöffnung. Seit Dienstag gab es dann auch keine Versuche mehr...außer meine zugriffe über Rescue Console, wobei ich da dann auch das root Passwort geändert habe.

Zugriff haben nur 3 Leute, die aber alle jegliche Aktivität verneint haben in der letzten Woche. Server gehört einem Kameraden, der allerdings komplett keine Ahnung hat und die Geschichte nur finanziert. Ich selbst habe auf dem Server dann AMP installiert um ihn als Webserver zu nutzen.

Ich tippe also auf einen Bruteforceangriff aufgrund der kurzen Zeitabstände der irgendwann erfolgreich war. Versuche einer Firewallinstallation sind nicht bekannt, auch kein Fail2ban oder ähnliches.

Was kann der potentielle Eindringling verkonfiguriert haben, das komplett kein Zugriff mehr möglich ist? Für ein folgendes Neuaufsetzen werden die Zugriffsrechte wohl auch neu vergeben und dann von Anfang an mit einem(!) Admin nur die notwendigen Rechte verteilt.
Welche Konfigurationen könnten also verstellt sein?

[TRex]

Welche Konfigurationen könnten also verstellt sein?

Prinzipiell alle.

Sicher dir alle Konfigurationen und vergleich dann mit diff die Abweichungen zur Neuinstallation (die wohl definitiv ansteht). Was sich geändert hat, siehst du dann ja...und du weißt auch, was du geändert haben willst.

[Nuac15]

Und da waren wieder meine paar Probleme Wie sichere ich Konfigdateien, wenn ich keinen richtigen Zugriff habe?
Anyone else?

[rendegast]

rescue console lässt mich auf server

Auch Offline-Zugriff auf den heruntergefahrenen Server geht? (-> Image-Erstellung)
Und von der rescue-Konsole ein lokaler Login?
Dann könnte den ssh-Logins ein Strich durch die Rechnung gemacht werden
/etc/passwd
/etc/shadow
die Benutzer lustig umbenennen, zBsp

Code: Alles auswählen

root:x:0:0:root:/root:/bin/bash
->
root_asdfaerfaerfa:x:0:0:root:/root:/bin/bash

Und in shadow die Paßworthashes abändern.

Einen paßwortlosen root hinzufügen

Code: Alles auswählen

root_rescue_1234abcdXY::0:0:root:/root_rescue:/bin/bash

und dazu ein separates Homeverzeichnis /root_rescue/ anlegen.
/etc/rcX.d/ und /etc/rc.local aufräumen, insbesondere /etc/init.d/networking deaktivieren: 'chmod 644'
Dann könnte mit diesem rescue-Root (lokal) eingeloggt werden.

Den Kernel / initrd kontrollieren und gegebenenfalls gegen zuhause sauber erstellte austauschen.

Ist nicht superprofessionell, aber die Angreifer haben ja auch nicht ihre logins verschleiert.
Könnte ja auch in gewissem Sinne gutartig sein,
indem sie Dich damit auf irgendeinen Fehler aufmerksam machen wollen?
(ZBsp. die Regelmäßigkeit des fremden logins ala "Hallo, da ist was, hallo!")



Aber da war ja was:

auf den vserver.

Auf den Kernel gibt es dann gar keinen Zugriff?
Vielleicht war der (Provider-)Kernel das Einfallsloch?
Dann wären auch andere Guests auf diesem Server betroffen/gefährdet:
Meldung an den Provider, damit der die Maschine "hart" abschaltet? -> forensische Images usw.
Anzeige erstatten, um eventuellen Schadenersatzforderungen / Abmahnungen zBsp. wegen fortgesetzter Fahrlässigkeit zu begegnen.

Wenn es denn am Host-System liegt, Providerwechsel in Betracht ziehen?

[Nuac15]

Danke für deine Hilfe. Ja aufgrund des vservers kein Offlinezugriff. Komme beim Login nichtmal dazu einen Nutzernamen einzugeben, vorher schon connection timed out.
Provider ist informiert, hoffe das es da keine weiteren Probleme gibt.
Dann werde ich heut abend doch mal alles neu machen...man hat ja sonst nix zu tuen.

Beste Grüße

[dufty]

Wäre es möglich, statt debian 5 nicht gleich debian 6 (squeeze) zu nehmen?
Security patches und so ...

[Nuac15]

Hallo vielen Dank nochmal an alle Helfer.
Jup wird dann zeitnah komplett neu gemacht. Inklusive Debian 6.

Beste Grüße