Am Freitag 30 Oktober 2009 14:41:19 schrieb Erik P. Roderwald: Hallo Erik,
On Freitag 30 Oktober 2009, Al Bogner wrote:
war's. Spuren findest Du keine mehr, wenn ich sauber gearbeitet habe. Der Angreifer hat aber immer noch den root-Zugang.
Somit muss ich mich fragen, wie er den root-Zugang erhalten hat. Ich schließe aus, dass er den private-Key erraten konnte. Login per user / pw ist nicht möglich. Also wäre Cross-Site-Scripting denkbar, oder er hat es über das Login beim VPS-Hoster geschafft. Das PW dort ist gut. Alle Pakete sind aktuell.
Oder er hatte Hardwarezugriff,
Ok, aber da bin ich mit einem VPS machtlos.
oder er hat einen (unbekannten) Fehler in einem Server ausgenutzt, oder Du hast irgendetwas übersehen.
Also bei den normalen Zugriffsmöglichkeiten, stehe ich etwas an. Vor allem wie der _erneut_ Zugriff bekommen kann. Login per PW geht nicht. Per ssh-key muss er irgendwo seinen Key hinterlassen, oder er hat meinen private-Key von meiner lokalen Maschine. Da könnte man überlegen wo man eine public-key zur Authentifizierung verstecken könnte.
Schicke mir doch mal die URL.
Mache ich gleich. Danke!
Dann mache ich mal einen Portscan
Da sollten nur 80 und 22 offen sein, wenn ich mit nmap nachschaue. nmap -d -sA -n -P0 -p 1-20000 a.b.c.d Starting Nmap 5.00 ( http://nmap.org ) at 2009-10-30 15:44 CET --------------- Timing report --------------- hostgroups: min 1, max 100000 rtt-timeouts: init 1000, min 100, max 10000 max-scan-delay: TCP 1000, UDP 1000, SCTP 1000 parallelism: min 0, max 0 max-retries: 10, host-timeout: 0 min-rate: 0, max-rate: 0 --------------------------------------------- NSE: Loaded 0 scripts for scanning. Initiating ACK Scan at 15:44 Scanning a.b.c.d [20000 ports] Packet capture filter (device eth1): dst host 192.168.178.100 and (icmp or ((tcp or udp or sctp) and (src host a.b.c.d))) ACK Scan Timing: About 15.02% done; ETC: 15:47 (0:02:55 remaining) ACK Scan Timing: About 33.20% done; ETC: 15:47 (0:02:03 remaining) ACK Scan Timing: About 54.27% done; ETC: 15:47 (0:01:17 remaining) ACK Scan Timing: About 78.41% done; ETC: 15:46 (0:00:33 remaining) Completed ACK Scan at 15:46, 155.43s elapsed (20000 total ports) Overall sending rates: 258.01 packets / s, 10320.38 bytes / s. Host a.b.c.d is up, received user-set (0.19s latency). Scanned at 2009-10-30 15:44:22 CET for 156s Interesting ports on a.b.c.d: Not shown: 19998 filtered ports Reason: 19998 no-responses PORT STATE SERVICE REASON 22/tcp unfiltered ssh reset 80/tcp unfiltered http reset Final times for host: srtt: 191058 rttvar: 16288 to: 256210 Read from /usr/share/nmap: nmap-services. Nmap done: 1 IP address (1 host up) scanned in 155.63 seconds Raw packets sent: 40101 (1.604MB) | Rcvd: 159 (8088B)
und schaue, wo man da überall rein kommt. Oder, oder, oder ... Wie das gemacht wurde, wirst Du vielleicht nie erfahren. Aber nach der Mail von google, dass eine Seite in einem public_html-Verzeichnis eines users, der gar nicht da ist, gefunden wurde, würde ich an Deiner Stelle von einem erfolgreichen Angriff einfach mal ausgehen und sofort entsprechende Maßnahmen einleiten.
Die Frage ist was "entsprechende Maßnahmen" sind, wenn nicht im entferntesten erkennbar ist, was ich da tun kann, dass es nicht mehr passiert. Ich kann nur trachten, dass alle Pakete aktuell sind. Als 1. Massnahme, habe ich die Eingabemöglichkieten auf den Homepages reduziert, d.h. Kommentare sind keine mehr möglich, hat sowieso keiner was geschrieben.
Alles weitere wird dann auf einer alleine stehenden Maschine untersucht.
Meine Sicherungen sind keine Vollbackups, enthalten aber eine Liste aller Dateien. Im Zweifelsfall ziehe ich eine Neuinstallation mit Restore der notwendigen Daten vor.
Soll das gerichtsverwertbar werden, dann sind viele Dinge zu beachten. Vor allem muss der Zustand des Servers auf einem nicht mehr veränderbaren Datenträger gesichert werden.
Das kann man vergessen.
Ich bin etwas ratlos, wie ich mich besser absichern soll.
Sicher ist nur eines: der Tod. Das ist leider auch in der IT nicht anders. :(
Ich setze den Rechner sofort neu auf, wenn klar ist, wo da wer reingekommen sein kann, Das ist die Antwort vom Hoster:
I am really unsure, if someone gained root-access.
It is highly unlikely. What is more likely is either: 1) somebody exploited a bug/feature in Drupal. 2) nothing is wrong - a false positive. #2 is most likely - many phishing reports turn our to be false positives. Since you were able to confirm the URL google thought was a phishing page doesn't exist, it is a false positive. ----
How often can be tried to login with a wrong username / password at the webinterface?
we can't disclose that information.
Can the login via the webinterface be diasbled?
not on purpose. Al -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org