Server gesperrt - ausgehende DoS-Attacken

V

vipthommy

New Member
Hallo Leute,

heute wurde mein Server bei S4Y gesperrt. Grund: ausgehende DoS-Attacken im Routerlog.

Tja, was soll ich sagen. Hab mehrfach mit den Technikern und dem CC telefoniert. Jetzt habe ich es zumindest soweit geschafft, dass die meine 2 im Monat zur Verfügung stehenden Arbeitseinheiten (= 30min) nutzen, um eventuell die Sicherheitslücke zu finden bzw. ein rootkit oder.

Dummerweise habe ich in den Dingen nicht allzuviel Erfahrung. Mir ist nur wichtig, dass der Server baldmöglichst wieder läuft, weil einige Webseiten darauf liegen.

Hat wer ne Idee wie das passiert sein kann?

Installiert ist:
Linux Suse 10.1
PHP 5
Apache
MySql

Der SSH-Zugriff ist mit root nicht möglich und der Port ist nicht standard (extra mal umgelegt). Vermutlich also nicht über ssh gehackt.

Dummerweise sind die Patchstände etwas alt.

Was kann ich nun tun?
Die wollen mir den Server in den Recovery-Mode fahren. Wie kann ich dafür sorgen, dass die DoS-Attacken nach nem Neustart nicht weitergehen?
Gibts Tools die Schädlinge aufspüren für 10.1?

Für jeden Rat bin ich sehr dankbar!

Grüße
Tom
 
Hallo,
schlimme Sache erstmal. Die Logfiles werden wohl nicht mehr viel hergeben da die wahrscheinlich nach der Attacke geändert wurden. Die scripte zu finden die die Attacke auslösen wird auch nicht ganz so einfach sein. Am besten wird es sein wenn Du deinen Server von Grund auf neu installierst, die Pakete immer auf dem neusten Stand hältst. 100% Absicherung wird es nicht geben gegen Attacken, man kann es den Angreifern nur schwerer machen einzubrechen.
Der Angriff wurde wohl über PHP oder MySQL ausgeführt.
Hast Du ein Admin Paneel installiert ?
 
Last edited by a moderator:
Danke für die schnelle Antwort. Ein neuaufsetzen ist nicht so einfach aus derzeit zeitlichen Gründen :(

Es ist confixx und phpmyadmin drauf.
 
Neuinstallieren, lernen und patchen. Alles andere hilft eh nicht, sonst wird der Zustand immer wieder eintreten.
 
Tja, Antwort vom Support...

Hallo Herr xxx,

leider habe ich schlechte Neuigkeiten. Ihr System wurde kompromitiert, d.h. es wurde elementare und häufig benutzte Basisprogramme ausgetauscht und vor Überschreibung gesichert. Ich denke, daß ich den Einbruch auf den 22.6.2009 um die 17:54 Uhr datieren kann. Es war mir nicht möglich, die Lücke zu finden, über die der Einbruch und die Kompromitierung stattfand. Die interessantesten Logdateien reichen leider nicht soweit zurück und die Verbleibenen zeigen keine wirklichen Auffälligkeiten. Da für die Aktion root-Rechte erforderlich waren, muß es jedoch eine gravierende Lücke gewesen, die mögliche durch fehlende Updates entstand. Ferner ist nicht auszuschließen, daß der Einbrecher durch die erlangten Root-Rechte seine Spuren verwischt hat. Anbei Auszüge, die die Kompromitierung zeigen:

----
root@echoxxx:/mnt/bin# lsattr | grep ia
s---ia------------ ./netstat
s---ia------------ ./ps
s---ia------------ ./ls

root@echoxxx:/mnt/sbin# lsattr | grep ia
s---ia------------ ./ifconfig
s---ia------------ ./ttyload
s---ia------------ ./ttymon

root@echoxxx:/mnt/srv/www# stat /mnt/bin/ps
File: `/mnt/bin/ps'
Size: 62920 Blocks: 136 IO Block: 4096 regular file
Device: 901h/2305d Inode: 5652489 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 122/ UNKNOWN) Gid: ( 114/ UNKNOWN)
Access: 2009-08-13 18:13:13.000000000 +0000
Modify: 2006-04-23 03:16:53.000000000 +0000
Change: 2009-06-22 17:54:38.000000000 +0000
----

Ich kann Ihnen daher nur dringend raten, eine Datensicherung aller wichtigen Daten vorzunehmen und das System neuzuinstallieren. Ich rate ferner davon ab, dieses System nochmal normal hochzufahren.
Click to expand...

Mist aber auch... Neuinstallation.
 
Naja, das Problem ist, das du - ohne Ahnung von DER Materie ( DDos ) zu haben - nicht wirklich das Problem ausfindig machen kannst, es gibt so unglaublich viele möglichkeiten einen Server für DDos zu nutzen, da ist das hacken und verstecken von tools nur die umständlichste...

Es ist wirklich - auch vom Zeittechnischen - her, das einfachste, den Server direkt neu aufzusetzen und wie gesagt sich mit der Thematik Absicherung zu befassen :)

Außerdem würde ich dir empfehlen wirklich in Regelmäßigen Abständen in die Logs zu schauen, ob derartiges nochmal auftreten sollte, damit die entsprecheneden Ports geschlossen bzw der Root erstmal vom Netz getrennt werden kann...

Ist zwar doof, für die Webseiten, die drauf laufen, aber dafür lernt man ja... Nur gibt halt immer einen faden nachgeschmack bei der ganzen Aktion...
 
Da will ich mich mal anschließen ohne der große Experte zu sein. Aber du wirst auf jeden Fall mehr Zeit benötigen, dein kaputtes System Datei für Datei zu überprüfen und zu reparieren als ein neues System aufzubauen

Alternativ kannst du Daten wie Webseiten, Datenbanken, etc. runtersichern und den Server mit den automatisch angefertigten Backups in einen Zustand (weit) vor den 22.06. zu versetzen. So erhältst du dein ursprüngliches System zurück. Du musst dann (nur) noch die seitdem veränderten Daten auf den Server zurücksichern. VORSICHT: Damit sicherst du auch die Lücke zurück, die der Angreifer genutzt hat, d.h. der Server wird innerhalb kürzester Zeit wieder angegriffen werden, d.h. du musst die logs intensiv überwachen, bzw. vorab die Versionsstände aller eingesetzten Apps (auch php Apps) aktualisieren. Es ist eine ****** arbeit.:D
 
Bringt es eigentlich etwas den SSH Port von 22 Abzuändern?

Es gibt so gute Port-Such-Tools mittlerweile die alle Ports einer Maschine abfragen, und einem sogar Anzeigen können Welcher Dienst auf dem Port läuft (html,php,mysql,ssh,ftp...) etc...

Grüße

Basti
 
bAsTiaN1985 said:
Bringt es eigentlich etwas den SSH Port von 22 Abzuändern?
Click to expand...
Der einzige Vorteil besteht darin, dass die Log-Dateien kleiner werden, da die täglichen Einbruchsversuche (brute-force attac) auf dem Standardport nicht mehr vorkommen. Wer wirklich den ssh-Port finden will, lässt sich durch so etwas natürlich nicht abhalten.

Dass ich den ganzen Müll nicht mehr in den Log-Dateien habe, ist mir jedoch den Extraaufwand wert. ;)
 
Falls du der Einzige bist, der per SSH auf den Server zugreift, kannst du mit Iptables den Zugriff nur von dem IP-Netz deines ISP zulassen. Das ist sehr hilfreich.
Außerdem lohnt es sich, sich mal mit Portknocking auseinander zu setzen. Google mal knockd. Damit geht der Port nur auf, wenn vorher angeklopft wird.
 
Portknocking ist schon eine tolle Sache. Aber mir ist der Aufwand dafür zu hoch und die Wahrscheinlichkeit, dass man sich im Fehlerfall selber aussperrt.
Außerdem ist das SSH-Protokoll sehr sicher, wenn der Dienst richtig konfiguriert ist. Wann gab es da den letzten Exploit?
Die Wahrscheinlichkeit, dass jemand über ein PHP-Script einbricht, ist um Größenordnungen höher.
 
Ja man sollte die Sachen vorher lokal Testen und evtl. eine Zeitlang eine 2. Instanz von SSH fahren, über die man zur Not noch Zugriff bekommt.
Auf der anderen Seite ist die Recovery Console bei den meisten Anbietern in so einem Falle der beste Freund, damit sind ungewollte Änderungen meisten schnell rückgängig gemacht.
Portknocking kann darüber hinaus ja nicht nur zur Absicherung von SSH, sondern zum Ausführen von nahezu jedem beliebigen Code verwendet werden. Damit lassen sich dann schon lustige Dinge machen.
 
You must log in or register to reply here.
Back
Top