Abuse Mail - Gehackt worden

M

Morfio

Well-Known Member
Hallo zusammen,

ich habe heute eine Abuse-Mail bekommen, wir würden mit einem unserer FreeBSD-Server SYN-Floods auf deren IP durchführen.

Ich habe mir den betroffenen Server mal eben angesehen, netstat sagt:

Code: 
Active Internet connections
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
tcp4      0      0 static.40.147.47.ssh  ddos-guard.net.80      SYN_RCVD
tcp4      0      0 static.40.147.47.ftp  ddos-guard.net.80      SYN_RCVD
tcp4      0      0 static.40.147.47.ssh  ddos-guard.net.80      SYN_RCVD
tcp4      0      0 static.40.147.47.ftp  ddos-guard.net.80      SYN_RCVD
tcp4      0      0 static.40.147.47.http  162.213.155.167.32930  TIME_WAIT
tcp4      0      0 static.40.147.47.12549 ip-184-168-36-21.https FIN_WAIT_2
tcp4      0      0 static.40.147.47.http  162.213.155.167.56632  TIME_WAIT
tcp4      0    52 static.40.147.47.ssh  kobz-5f75db39.po.61724 ESTABLISHED
tcp4      0      0 static.40.147.47.64392 ip-184-168-36-21.https FIN_WAIT_2
tcp4      0      0 static.40.147.47.53456 ip-184-168-36-21.https FIN_WAIT_2
  p4      0      0 static.40.147.47.15204 ip-184-168-36-21.https FIN_WAIT_2
▽cp4      0      0 static.40.147.47.36845 ip-184-168-36-21.https FIN_WAIT_2
tcp4      0      0 static.40.147.47.49539 ip-184-168-36-21.https FIN_WAIT_2

Kann mir jemand erklären, was genau das bedeutet (dieses ddos-guard.net.80-Zeugs)?

Vielen Dank

Morfio
 
sockstat -4 sagt folgendes:

Code: 
root@book:~ # sockstat -4
USER    COMMAND    PID  FD PROTO  LOCAL ADDRESS        FOREIGN ADDRESS     
root    sshd      47912 4  tcp4  *:22                  *:*
thorsten sshd      47827 3  tcp4  78.47.147.40:22      95.117.219.57:61724
root    sshd      47824 3  tcp4  78.47.147.40:22      95.117.219.57:61724
root    sendmail  865  4  tcp4  *:25                  *:*
root    sendmail  865  6  tcp4  *:587                *:*
mysql    mysqld    855  10 tcp4  *:3306                *:*
root    syslogd    635  7  udp4  *:514                *:*
?        ?          ?    ?  tcp4  78.47.147.40:22      186.2.161.74:80
?        ?          ?    ?  tcp4  78.47.147.40:22      186.2.161.103:80
?        ?          ?    ?  tcp4  78.47.147.40:12549    184.168.36.21:443
 
Ddos guard ist wohl eine Ausweichserver wo man umgeleitet wird, wenn DDOS ausgeführt wird. Das soll wohl den Traffic von den eigentlichen Servern nehmen, denke ich. Das mit den Fragezeichen im sockstat-Output gefällt mir gar nicht. Da soll wohl was verschleiert werden, nämlich der Prozessname.
 
Die letzten 3 Prozesse in der sockstat-Ausgabe senden Pakete an die IP-Adressen 186.2.161.74, 186.2.161.74 und 184.168.36.21. Die ersten beiden Adressen von den Drei lösen auf ddos-guard.net auf. Das sind also die ersten 4 TCP-Verbindungen in deiner netstat-Ausgabe. Wenn du netstat den Parameter -n mitgibst, wird das deutlicher, denn dann führt keine Namensauflösung durch und beschränkt sich auf die rohen IP-Adressen. Kurz gesagt, dort laufen verschleierte Prozesse, die eine Unmenge SYN an ddos-guard.net schicken. Zu erkennen am State "SYN_RCVD".

Das wirkliche Interessante sind hier zwei Dinge:
- Sockstat kann dem Socket keinen Prozess zuweisen. Es gibt legitime Fälle, in denen das passieren kann. Aber hier sehen wir fast sicher keinen davon.
- netstat hat Darstellungsfehler in der Ausgabe. Die vorletzten beiden Zeilen sehen am Anfang fischig aus.
Das bedeutet zumindest mit einer gewissen Wahrscheinlichkeit, dass jemand entweder deine sockstat und netstat Binaries ausgetauscht hat, eine Lib die beide nutzen (libkvm evtl.) oder der Kernel inkonsistent ist. Das würde heißen, dass jemand den Kernelspeicher manipuliert hat. All das ist nichts mehr, was ein dummes Scriptkiddie macht, dafür bedarf es schon eines intelligenteren Kiddies. Alternativ könnte auch sshd spinnen.
Wenn ich mal blind raten darf, würde ich auf das im Moment mal wieder umgehende Ebury-Rootkit [1] tippen. Es infiziert neuerdings auch im größeren Stil Free- und OpenBSD-Systeme. Die Angreifer haben es dir installiert, damit nun freien Zugang zum Server und weitere Schadsoftware nachgezogen. Pech gehabt, aber kommt vor.

Die Frage ist, was machst du nun? Die Kiste sichern (zur Post Mortem Analyse), plattmachen und reinstallieren ist Pflicht. Denn was auch immer man dir untergeschoben hat, bekommst du anders kaum sicher mehr raus. Nur wäre es interessant herauszufinden, wie der Angreifer es überhaupt schaffen konnte, das Rootkit oder was auch immer da Ärger macht auf die Kiste zu bekommen. Er muss dafür Zugang erlangt haben. Und die Liste ist lang. Erratenes oder abhanden gekommenes Passwort. Exploid in sshd oder einer beliebigen anderen Anwendung. Krimineller Kollege... Der Phantasie sind da keine Grenzen gesetzt.

1: http://www.bsdforen.de/threads/das-ebury-rootkit.30893/
 
Nach der Neuinstallation nicht vergessen komplett alle Passwörter auszuwechseln und niemals wieder zu benutzen.
 
Und alle SSH-Keys, an die der Angreifer gekommen sein könnte, zu löschen. Von allen Kisten, auf den sie genutzt wurden.
 
Aus dem Grund generiere ich auf jedem Rechner eigene SSH-Keys. Dann muss man bloß den Public-Key löschen aber nicht überall neue PKs einführen.
 
Ich habe den Server gestern noch vom Netz genommen. So, wie es momentan aussieht, wurde eine Lücke in Wordpress ausgenutzt.
 
Das mit dem Fragezeichen sehe ich häufig.
Wenn noch ein State offen ist (FINWAIT), solange bleibt der Eintrag im sockstat sichtbar, obwohl das Socket bereits geschlossen wurde.
Wenn eine Lücke im WP ausgenutzt wurde, hast du dir die Arbeit zum Neuaufsetzen umsonst gemacht.

Schaut euch mal das whois zu ddos-guard.net genauer an, in Russlang registriert, Privacy protected, usw...
Für mich suspekt.

Rob
 
Wenn bei dir eingebrochen wurde und dir dein privater Schlüssel geklaut wurde, kann man damit überall einbrechen, wo dein öffentlicher Schlüssel hinterlegt ist. Daher muss von allen solchen Systemen der öffentliche Schlüssel gelöscht werden.
 
Speichert ihr eure privaten Schlüssel auf dem Server?
Ich nicht und wenn ich 100%ig ausschließen kann das der entwendet wurde tausche ich die auch nicht.
 
Ähm was? Die privaten Schlüssel liegen auf den Clients. Die Public Keys sind auf den Servern und müssen von dort gelöscht werden, wenn der private Schlüssel kompromittiert wurde.
 
Schon klar, deswegen schrieb ich ja auch "[...] wenn ich 100%ig ausschließen kann das der [private Schlüssel] entwendet wurde [...]".
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben