Sperrung wegen DoS

Also langsam werd ich alt. Heute schaue ich auf mein Konto - was sehe ich. Die AE für die Sperrung wurde abgebucht. Ohne Rechnung, ohne Ankündigung ohne nichts. Laut AGB's ist eine Rechnung erforderlich.

Jetzt bleibt mir nur das Entziehen der Einzugsermächtigung und ein Hinweis an die Buchhaltung - oder sehe ich das falsch?
 
Hi,

ich hab jetzt echt nicht mehr alles gelesen aber Gott sei Dank bin ich weder Rechtsverdreher noch Buchhaltungsangestellter. :)

Zu den DoS-Attacken: Einige haben es hier erstmal schon richtig erkannt das Traffic nicht am IP Endpunkt gemessen wird sondern am Router direkt, das macht insofern Sinn, das Router fuer sowas konfigurierbare Mirroring Ports haben und in der Regel sowas mit wenig Hardwareaufwand exakt bestimmt werden kann.

Bei einer ausgehenden DoS-Attacke ist das relativ einfach, wenn wir den Server sperren wird der ja schon (vom Server aus gesehen) vor dem Router gesperrt, das heisst es kommt kein Traffic mehr zum Messen an.

Bei einer eingehenden DoS-Attacke ist das etwas schwieriger. Da geht es einem hauptsaechlich nicht um den Traffic der entsteht, sondern um das Problem das auch Router etwas mehr zutun haben, wenn ein paar mal 800 MBit fuer ein paar Stunden reinkommen. Bei solchen heftigen DoS-Attacken muss man in der Regel alle seine Carrier informieren, damit fuer die Ziel IP das Routing Announcement gestoppt wird. Der Server wird dann nur noch "pro Forma" gesperrt, damit der Kunde informiert wird. Selbst nach einer Entsperrung wird der erst wieder erreichbar, wenn das Routing fuer diese IP vom Carrier wieder eingeschaltet wird.

80% aller DoS-Attacken sind allerdings ausgehende und davon sind ueber 90% gehackte Webserver mit phpBB Exploits, normalen php Exploits, was man in /tmp dann schnell nachvollziehen kann. Der Rest verteilt sich auf IRC Server wo sich irgendein Skriptkiddie mit irgendeinem anderen angelegt hat. :)

PS: Bei einem root Server kann man das vermeiden, wenn man schon safe_mode off und co. benutzen will, weil man dumm ist. :) Man mountet /tmp einfach mit noexec, das verhindert zumindest die Ausfuehrung von diversen DoS-Tools in /tmp nach einem Hack ueber PHP :)

Nochwas anhand des Threads hier seh ich bei keinem, dass er "NICHT" selber Schuld gewesen waere, was seinen Uebertraffic angeht. Wenn ich falsch liege korrigiert mich.
 
Hi Leutz,

wo ich das gerade hier mal lese, was habt Ihr denn auf euern Servern laufen, das die anfällig sind für hacks?

Gruß
Sven
 
SvenH said:
wo ich das gerade hier mal lese, was habt Ihr denn auf euern Servern laufen, das die anfällig sind für hacks?
Click to expand...
Es gab zB mal einen Bug in der Forensoftware phpBB
mbroemme said:
Nochwas anhand des Threads hier seh ich bei keinem, dass er "NICHT" selber Schuld gewesen waere, was seinen Uebertraffic angeht. Wenn ich falsch liege korrigiert mich.
Click to expand...
Ich bleibe bei meinem Statement dass keine 80 GB über meine VE gegangen sind.
Die Intergenia AG hat jedenfalls einen Vserverkunden weniger. Es war noch nicht mal der schlechte Support, es waren mehr die 3 Euro pro GB die ich jetzt noch mehr als ungerechtfertigt finde.
 
Hi,

djrick said:
Es gab zB mal einen Bug in der Forensoftware phpBB

Ich bleibe bei meinem Statement dass keine 80 GB über meine VE gegangen sind.
Die Intergenia AG hat jedenfalls einen Vserverkunden weniger. Es war noch nicht mal der schlechte Support, es waren mehr die 3 Euro pro GB die ich jetzt noch mehr als ungerechtfertigt finde.
Click to expand...

Einen Bug? :) Es gibt derzeit fuer das letzte aktuelle sogar noch einen funktionierenden Exploit. :)

Zu deinem Traffic: Es ist ja nicht so das nur wir den Traffic messen. Und wenn es mal zu einem Rechtsstreit kommt, glaubst du wir wuerden es darauf anlegen, wenn wir das nicht nachweisen koennten, wie der Traffic entstanden ist? Es gibt sicher einzelne Fallbeispiele wo die Trafficberechnung nicht stimmt, niemand ist perfekt. Wir hatten dieses Problem ja auch schon und haben das korrigiert. Allerdings gerade bei Virtuozzo ist die Trafficmessung redundant. Einmal wird am Mirrorport gemessen und man kann fuer die interne Statistik auch noch auf dem Hostsystem den VPS Traffic selber IP bassiert zaehlen.
 
Man mountet /tmp einfach mit noexec, das verhindert zumindest die Ausfuehrung von diversen DoS-Tools in /tmp nach einem Hack ueber PHP :)
Click to expand...
Bei vServern hat man nur eine virtuelle Platte und das loop back device funktioniert bei basic und max auch nicht und /tmp auf tmpfs zu mounten ist wegen dem Speicherverbrauch auch nicht sinnvoll. Außerdem sollte jedes weitergebildete Skriptkiddie das noexec per /lib/ld-linux.so.2 umgehen können. Aber da phpbb problemlos mit safe_mode=on funktioniert ist das eigentlich eh überflüssig...
Und wenn es mal zu einem Rechtsstreit kommt[...]Allerdings gerade bei Virtuozzo ist die Trafficmessung redundant.
Click to expand...
Gibt's eine Möglichkeit S4Y zu veranlassen die Werte miteinander zu vergleichen ohne das man einen Rechtsstreit anfängt?
 
HornOx said:
Bei vServern hat man nur eine virtuelle Platte und das loop back device funktioniert bei basic und max auch nicht und /tmp auf tmpfs zu mounten ist wegen dem Speicherverbrauch auch nicht sinnvoll. Außerdem sollte jedes weitergebildete Skriptkiddie das noexec per /lib/ld-linux.so.2 umgehen können. Aber da phpbb problemlos mit safe_mode=on funktioniert ist das eigentlich eh überflüssig...
Click to expand...

Hab ja auch erstmal nur dedizierte Server gemeint. :) Fuer Virtuozzo hab ich das als Feature Request auf der TODO. :)

Gibt's eine Möglichkeit S4Y zu veranlassen die Werte miteinander zu vergleichen ohne das man einen Rechtsstreit anfängt?
Click to expand...

Nein, das Accounting hab ich Anfangs benutzt, weil ich wissen wollte ob es mit unserem uebereinstimmt. Und das es das tut, verteil ich die Performance lieber auf Kunden.
 
Hi,

nebenbei, gerade wieder vSERVER gesperrt wegen DoS-Attacke. Die sieht dann folgendermaßen aus:

PID TTY STAT TIME COMMAND
12485 ? R 0:00 ps axf
1 ? S 0:51 init
20738 ? S 0:08 syslogd -m 0
21223 ? S 0:04 xinetd -stayalive -pidfile /var/run/xinetd.pid
21634 ? S 0:00 /bin/sh /usr/bin/safe_mysqld --defaults-file=/etc/my.cnf
22818 ? S 0:03 \_ /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking
22850 ? S 1:03 \_ /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking
23329 ? S 2:34 /usr/sbin/httpd
10306 ? S 0:01 \_ /usr/bin/perl /root/confixx/pipelog.pl
10851 ? S 0:00 \_ /usr/sbin/httpd
22369 ? S 0:00 \_ /usr/sbin/httpd
32549 ? S 0:00 \_ /usr/sbin/httpd
23715 ? S 0:09 crond
27169 ? S 0:00 ./19876
20001 ? S 0:00 \_ ./19876
20038 ttyp1 S 0:00 \_ sh -i
8898 ttyp1 R 2171:19 \_ ./stealth 69.56.171.131 80
14149 ? S 1:34 crond

Und ich hab von sowas nicht nur einen am Tag :)
 
Ist das nicht der phpBB Exploid?
8898 ttyp1 R 2171:19 \_ ./stealth 69.56.171.131 80
Der SSF-Server wurde glaube ich mal über diesen Exploid gehackt und hatte auch diese steahl Datei...
 
Ein phpbb Exploit den man direkt auf dem Server starten müsste wär ja irgendwie witzlos ;) phpbb oder was auch immer das problem war wurde schon längst gehackt und "stealth" verwandelt den Rechner vermutlich in einen Zombie der an einem DRDoS Angriff teilnimmt.
btw, werden IP Packete mit gefälschtem Absender von den S4Y Routern eigentlich verworfen oder durchgelassen? Ich kenne keinen sinnvollen+legalen Einsatz von gefälschten IP Packeten und mit der Sperre wär der S4Y IP Bereich deutlich uninteressanter für Skriptkiddies (zumindest für die die DDOS Atacken machen wollen, vor Spamzombies nützt das nicht)
 
Hi,

bei dediziert wirft der Router die weg.

bei vSERVER werden die schon direkt vom Hostsystem verworfen und landen somit nichtmal im Accounting. :)
 
Ist ja alles schön und gut - jedoch hätte ich mir mehr Unterstützung seitens Server4You gewünscht. Als ich bei der Buchhaltung anrief wurde ich extrem "freundlich" abgewiesen - ohne mir helfen zu wollen. Hätte wäre wenn ... aber wenn man mir freundlich (was der Techniker teilweise tat!) erklärt hätte, was wie jetzt gemacht werden könnte - seitens Server und seitens Rechnungen, wäre der Schaden halb so gross gewesen. So hätte ich wenigstens das Gefühl gehabt, ich werde nicht im stich gelassen. Aber wie dem auch sei ...

Wie verfahre ich jetzt weiter? Möchte ich an die Logs, muss ich zahlen - was wiederum ohne Rechnung einfach von meinem Konto abgebucht wurd. Das ist ein Teufelskreis.
 
Langsam vermute ich so eine art Hinhaltetaktik. Ich komme nicht an die Logs, Geld wird ohne Rechnung abgebucht, daraufhin schreibe ich eine Mail, keine Antwort. Technischer Support meldet sich auch nicht mehr, Neuinstallation + Backup erfolgt auch nicht - trotz Zustimmung der 2 AE's.
 
mbroemme said:
PS: Bei einem root Server kann man das vermeiden, wenn man schon safe_mode off und co. benutzen will, weil man dumm ist. :) Man mountet /tmp einfach mit noexec, das verhindert zumindest die Ausfuehrung von diversen DoS-Tools in /tmp nach einem Hack ueber PHP :)

Nochwas anhand des Threads hier seh ich bei keinem, dass er "NICHT" selber Schuld gewesen waere, was seinen Uebertraffic angeht. Wenn ich falsch liege korrigiert mich.
Click to expand...


Hallo,

ich hab da eben was gefunden, bei dem sich mir die Haare aufgestellt haben....
http://www.joomlaportal.de/showthread.php?t=2906

Und dann wundern sich die Leute, wenn ihre vserver gesperrt werden...

Hier einer meiner Lieblingssprüche aus dem Thread:
Wenn man schon einen Haufen Geld bezahlt und noch nicht mal
der Safe Mode in der php.ini auf off steht.
Kann man sich das Geld gleich sparen.
Click to expand...
 
Wäre es in diesem Zusammenhang nicht einen gepinnten Post wert mit den Parametern und der Software, die ein hohes Risko bergen, bzw. in den genannten Fällen zum Hack führten?
 
Ich fände es darüber hinaus interessant, wenn ein Hosting-Anbieter seinen Kunden eine zumindest rudimentäre Liste zur Hand gibt, um gehostete Server (dediziert/VSERVER) abzusichern.

Aus eigener Erfahrung weiß ich, dass Benutzer/Kunden durchaus gewillt sind, auf Empfehlungen zu hören, wenn man ihnen diese in einer leicht zugreifbaren und verständlichen Form zur Verfügung stellt. Da z.B. VSERVER ohnehin mit einem Grundpaket an Software-Paketen wie PHP kommt, wäre es doch für beide Seiten vorteilhaft, wenn man den Kunden über wenigstens die wichtigsten (sicherheitsrelevanten) Einstellungen informiert. Auch andere Kunden (wie ich! ;)) haben Vorteile davon, wenn die Hosting-"Nachbarn" halbwegs abgesicherte Server verwenden.

Als Beispiel:
- "Wir empfehlen Ihnen aus Sicherheitsgründen bei der Verwendung von PHP die Aktivierung des sog. safe_mode und die Deaktivierung von register_globals. Siehe Artikel XYZ."
- "Aus Sicherheitsgründen empfehlen wir für PHP-basierte Forumsoftware nicht den Einsatz von phpBB, sondern stattdessen <VBulletin, IPB, SMF,...>""

Oder auch:
- "Sie sind dafür verantwortlich, die auf Ihrem Server eingesetzte Software zu aktualisieren und abzusichern. Hinweis für VSERVER SUSE Kunden: Es gibt ein bekanntes Problem mit VSERVER SUSE 9.0 und der Verwendung des Yast Online Updates (YOU)..." :)


Wenn laut mbroemme ca. 70% der bei S4Y aufgetretenen DoS-Attacken auf phpBB-Exploits oder andere PHP-Schwachstellen zurückzuführen sind, so hätten IMHO doch beide Seiten einen definitiven Vorteil von einer solch simplen Maßnahme.

Selbst wenn ein Kunde diese Ratschläge bewusst oder unbewusst beim ersten DoS-Vorfall nicht befolgt hat, kann man ihn seitens S4Y wenigstens danach auf die o.g. Informationen hinweisen. Von sinnvollen Default-Einstellungen ganz zu schweigen (nicht, dass es in diesem Bereich nicht schon welche gibt).
 
Last edited by a moderator:
Elegantly said:
Als Beispiel:
- "Wir empfehlen Ihnen aus Sicherheitsgründen bei der Verwendung von PHP die Aktivierung des sog. safe_mode und die Deaktivierung von register_globals. Siehe Artikel XYZ."
Click to expand...

Bin ich prinzipiell auch fuer, allerdings haben wir dann das Problem (bedenke immer wir haben nicht nur 100 Kunden) dass das Supportteam mit Fragen ueberhaeuft wird, was das ist, wie man wenn man das anschaltet seine Software noch zum laufen bekommt und und und...

Elegantly said:
- "Aus Sicherheitsgründen empfehlen wir für PHP-basierte Forumsoftware nicht den Einsatz von phpBB, sondern stattdessen <VBulletin, IPB, SMF,...>""
Click to expand...

Das geht so gut wie garnicht, weil wenn der Kunde dann gehackt wird und wir ihm VBulletin oder sonst etwas empfohlen haben, sind wir womoeglich noch haftbar.

Elegantly said:
Oder auch:
- "Sie sind dafür verantwortlich, die auf Ihrem Server eingesetzte Software zu aktualisieren und abzusichern. Hinweis für VSERVER SUSE Kunden: Es gibt ein bekanntes Problem mit VSERVER SUSE 9.0 und der Verwendung des Yast Online Updates (YOU)..." :)
Click to expand...

Hier muss ich sowieso nochmal was ansprechen. Ich wuerd naemlich ganz gern die Paketlisten jeder verwendeten Distribution mit auf die Webseiten stellen, andere Anbieter tun dies ja auch. :)
 
You must log in or register to reply here.
Back
Top