OVH Community, your new community space.

Webtropia nullrouted


kro
22.07.11, 08:50
strex wrote:
> Keine der ansässigen Anbieter haben Fast-IT gesperrt,


Wir auch nicht, lass dich vom reisserischen Titel des Threads nicht
beeindrucken. Wir sperren momentan ein /24 dieses Netzbetreibers bis dieser uns
die Regelung des Problems bei dessen Kunden bestaetigt.

strex
22.07.11, 00:13
Zitat Zitat von kro
d4f wrote:
> Die vom Administrator angegebene Loesungsmethode mittels Email an
> noc@ovh ist ja dann wohl falsch.


Hier nochmal das Zitat aus deinem ersten posting:
d4f wrote:
>> Um eine Deblockierung zu erhalten muss die Firma "fibre one networks" <===
>> die notwendigen Schritte unternehmen um die Angriffe aus seinem Netz zu
>> stoppen und danach eine Email an noc@ovh.net mit einer Auflistung aller
>> unternommenen Sicherheitsmassnahmen schicken damit sich das nicht
>> wiederholt.
Etwas Kritik muss ich dazu leider auch geben, auch wenn es mich nicht betrifft. Keine der ansässigen Anbieter haben Fast-IT gesperrt, weder S4Y noch 1&1 und Strato. Auch Hosteurope und andere routen korrekt auf die Netze. Warum fährt man ein solche Strategie? Wir haben doch in letzter Zeit gelernt, dass Netzneutralität höchstes Gebot ist auch wenn etwa Fast-IT über Peerings nur zwischen 20 und 50 Gbit/s transportiert. Oder wollt ihr mal eine komplette Sperrung aller Netz erleben, etwa durch die DTAG, weil ihr Warez Server hostet?

Stur schalten bringt doch nichts, setzt euch mit den Leuten in Verbindung und klärt das. Es ist ja auch ein Nachteil, wenn eure Server die anderen nicht erreicht. Eine Wiederholung kann nie ausgeschlossen werden, denn ersten Betreiben sie die Server nicht selbst und es gibt immer wieder Lücke die zur 0-Day Kategorie gehören und von Serverbetreiber oft nicht schnell gefixt werden kann. Was müsste ich tun wenn ich meine User nicht mehr erreiche? 50 Server mit mehr als 5 Gibt/s umziehen? Das finde ich nicht korrekt.

linux-user
21.07.11, 22:49
Also manchmal spielt ihr schon "Gott" hier. Sperrt bei Clouds den Mailversand,...
Ich finde das überhaupt nicht witzig wenn OVH ganze IP Bereiche sperrt.
Ich dachte ihr habt so eine gute Erkennung um einzelne IPs zu sperren.
Und schon mal dran gedacht das euren Kunden dadurch wichtige Emails
nicht zugestellt werden könnten und ich hoffe ihr habt eine gute Versicherung die
euren Kunden dann den entstandenen Schaden ersetzt.

kro
21.07.11, 21:24
d4f wrote:
> Die vom Administrator angegebene Loesungsmethode mittels Email an
> noc@ovh ist ja dann wohl falsch.


Hier nochmal das Zitat aus deinem ersten posting:
d4f wrote:
>> Um eine Deblockierung zu erhalten muss die Firma "fibre one networks" <===
>> die notwendigen Schritte unternehmen um die Angriffe aus seinem Netz zu
>> stoppen und danach eine Email an noc@ovh.net mit einer Auflistung aller
>> unternommenen Sicherheitsmassnahmen schicken damit sich das nicht
>> wiederholt.


d4f
21.07.11, 20:16
Zu deinem ganzen anderen Text: es gibt nichts, was aus
dem bisher geschriebenen nicht hervorgehen würde, lies dir das nochmal
entspannt durch.
TLDNR oder besteht seitens OVH keinerlei Interesse an Klarstellung und Loesung dieses Problemes?
Dies wird uebrigens auch von der neusten Support-Antwort seitens Webtropia bestaetigt;
Wir haben uns bereits mehrfach mit OVH in Kontakt gesetzt. Dort ignoriert man unsere Anfragen bezüglich Freischaltung des Netzes. Da diese "Sperrung" im OVH Netz stattfindet, haben wir keine Möglichkeit dies zu umgehen.
Die vom Administrator angegebene Loesungsmethode mittels Email an noc@ovh ist ja dann wohl falsch.

Uebrigens wurde nicht darauf eingegangen
- warum eine Abuse und Blockierung von /32 statt /24 nicht ausreichte
- warum OVH einen Anbieter nach einem Missbrauch durch Kunden selektiv blockiert.
- warum OVH in dieser Sache auf stur schaltet.
- warum mehr als die angegebene /24 Range blockiert ist.

Ich zitiere somit: " lies dir das nochmal entspannt durch."

Ich denke uebrigens dass in den mehr als 12 Monaten seit der Angriff durchgefuehrt wurde die entsprechenden Server bereits blockiert wurden

strex
21.07.11, 09:55
Jegliches Null-Routen von kompletten Netzen halte ich als sehr kritisch. Man muss mit den täglichen Angriffen leben, dieses Rauschen ist doch nur normal. Und jeder der einen Server besitzt sollte damit umgehen können. Und dazu gehört auch eine vernünftige Update-Strategie

kro
21.07.11, 09:44
d4f wrote:
> PS: Warum ist diese Blockierung nicht in eurem Abuse-Tester
> ersichtlich?


Wird gerade erforscht. Zu deinem ganzen anderen Text: es gibt nichts, was aus
dem bisher geschriebenen nicht hervorgehen würde, lies dir das nochmal
entspannt durch.

> Versprochen, dass automatisierte Meldungen, also im Fall eines
> kleinen/mittleren DDoS sowie einer neuen Welle an Exploits
> moeglicherweise schon ein paar, nicht als Spam abgelehnt werden?


Nein, schicke bitte nur relevante Logauszuege und keine Massenmails.

d4f
20.07.11, 22:59
Das erklaert imho noch immer nicht die Reaktion "mal eben" ein ganzes Rechenzentrum zu blockieren.
Moegliches Szenario: ueber die Luecke in PhpMyAdmin wird ein selbstverbreitender Schaedling hochgeladen welcher autonom weitere Opfer nach einer gegebenen Methode sucht. Sobald er Opfer gefunden hat, werden diese exploitet und das Spiel faengt von Vorne an.

Dass nun einige dieser missbrauchten Server bei Webtropia standen und ihr die nicht bei Erkennung des Angriffs blockieren konntet ist leider Pech fuer eure Kunden. Ist ein nullrouten eingehender Verbindungen durch das Updaten der Routing-Tabellen so schwerfaellig oder warum konnten diese IP's nicht einfach erkannt werden? Meines Wissens ist OVH ja im Erkennen ganz gut.
Warum reichte eine Abuse an den IP-Block Besitzer, also Fast-IT, nicht aus statt einem Rundumschlag?

Grundrauschen -also inklusive Exploitscans- ist im Internet was 'normales'. Wenn ihr alle externen IP-Ranges blockiert aus welcher Angriffe kommen habt ihr binnen kuerzester Zeit das OVH-net gegruendet. Isoliert, sicher und kaum erreichbar. (Ich glaube auf sowas hat China aber ein Patent...)
CXS und modsecurity geben mir nicht umsonst taeglich Horror-Benachrichtigungen ueber irgendwelche ausgenutzten Luecken in Joomla- und Wordpress-Plugins. Dass ein paar Server einen so grossen Schaden angerichtet haben ist wirklich schlecht, aber das waere wie die Telekom vom Internet zu kappen weil einige ihrer Kunden Viren auf dem Rechner haben. Der Schuldige sitzt aber froehlich in Hawaii mit paar Millionen mehr.

Dass Webtropia -anscheinend- ein schlechtereres oder nicht existentes Missbraucherkennungs-System hat ist schlecht fuer sie und gut fuer euch da ihr ein Marktvorteil habt.
Aber Hetzner zB reagiert auch auf UDP-Flood, Portscans und aehnliches auch recht langsam wenn bedenkt dass ich Systeme "heile machen" durfte die mehrere Tage ungestoert ddos-Attacken mit knapp 80Mbit raushauten.
Also warum Webtropia und nicht Hetzner?

Deren Support hat aber mehrmal darauf hingewiesen dass sie an einer Kontaktaufnahme zu euch interessiert seien - es also definitiv kein Anbieter ist der solche Sachen duldet. Leider haette OVH "auf stur" geschaltet und wuerde weitere Anfragen nicht beantworten (siehe meine Auszuege oben). Warum?

Ich kann aber zB auch nicht die Ip-Range 93.186.196.0 - 93.186.197.63 (wo zumindest .5 anpingbar ist) aus dem OVH-Netz erreichen es wurde also bedeutend mehr als "nur" ein /20 lahmgelegt. Warum?


Nicht falsch verstehen, aber es scheint wirklich als ob OVH aus "Rache" fuer die naechtliche Arbeit und den entstandenen Schaden den Hoster und nicht die Serverbesitzer oder den Autor verantwortlich machen will und dementsprechend nicht an einer Konfliktloesung interessiert ist.
Ich bin zufriedener Kunde beider (und paar anderer) Anbieter aber die fehlende Zugriffsmoeglichkeiten fuer rsync und Direktkopierung ist mehr als nur nervig; zumal wenn man keine direkte Schuld des Anbieters erkennen kann.

Wenn ihr wirklich was fuer die Sicherheit des Internets machen wollt, dann setzt euch fuer eine eu-weite Fuehrerscheinpflicht fuer Serveradministratoren ein. Dann wuerde man auf serversupportforum auch nicht alle 2 Tage (in den Sommerferen jeden Tag) Beitraege wie "Hilfe mein Server wurde gehackt!!!" und "wie kann man eigentlich von Sarge/Lenny updaten?" lesen.
Alternativ koenntet ihr euren Kunden Filterregeln aehnlich gotroot und Security-Scanner aehnlich cxs kostenfrei zur Verfuegung stellen. Ich zumindest brauch immer viel Redekunst um die 100$/Jahr anderen Serverbetreiber schmackhaft zu machen. 100$ kostet schon nur die Bandbreite durch einen Exploit...

Warum ist diese Blockierung nicht in eurem Abuse-Tester ersichtlich?

Wenn du Netze hast, von denen eine akute Gefahr ausgeht, bitte mit
entsprechenden Logauszuegen an abuse@ovh.net wenden.
Versprochen, dass automatisierte Meldungen, also im Fall eines kleinen/mittleren DDoS sowie einer neuen Welle an Exploits moeglicherweise schon ein paar, nicht als Spam abgelehnt werden?

kro
20.07.11, 22:18
d4f wrote:
> Mir war aufgefallen dass aus dem gesamten OVH-Netz (sei es Minicloud,
> OVH SP Server oder Kimsufi/Isgenug Server) aus allen Rechenzentren ein
> Zugriff auf die IP-Ranges des Fast-IT (webtropia) Rechenzentrums
> Duesseldorf 2 bidirektional nicht funktioniert.
> ...
>> Die IP ist aufgrund von Portscans auf das OVH Netz nullrouted.
>> Um eine Deblockierung zu erhalten muss die Firma "fibre one networks"
>> die notwendigen Schritte unternehmen um die Angriffe aus seinem Netz zu
>> stoppen und danach eine Email an noc@ovh.net mit einer Auflistung aller
>> unternommenen Sicherheitsmassnahmen schicken damit sich das nicht
>> wiederholt.


http://travaux.ovh.net/?do=details&id=4451 bzw dessen englische uebersetzung
http://status.ovh.co.uk/?do=details&id=376 enthalten alle Details.

Wie du dort siehst geht es dabei nicht nur um einen doofen portscan, sondern um
umfangreiche Angriffe auf unsere Infrastruktur und die Server unserer Kunden,
mitunter also EURE Server. In solchen Faellen eine Reaktion nicht nur des
momentanen Benutzers der IP, sondern des zustaendigen Netzbetreibers (siehe
whois) zu verlangen ist voellig legitim und eine ganz normale Vorgehensweise.

> Gleichzeitig ist es fast ironisch dass grosse Teile des russischen


Wenn du Netze hast, von denen eine akute Gefahr ausgeht, bitte mit
entsprechenden Logauszuegen an abuse@ovh.net wenden.

d4f
20.07.11, 20:31
Dies ist kein Hilfegesuche im eigentlichen Sinne sondern ein Hinweis an zukuenftige und bestehende OVH-Kunden.
Mir war aufgefallen dass aus dem gesamten OVH-Netz (sei es Minicloud, OVH SP Server oder Kimsufi/Isgenug Server) aus allen Rechenzentren ein Zugriff auf die IP-Ranges des Fast-IT (webtropia) Rechenzentrums Duesseldorf 2 bidirektional nicht funktioniert.

Naja dachte ich, Wartung und so. Dachte ich!
Paar Tage spaeter hab ich Webtropia kontaktiert um zu fragen ob es technische Probleme gaebe und ihnen entsprechende Traceroutes uebermittelt.
Die Support-Antwort war ernuechtigend:
leider nein, außer das ovh selbst jeden Kontakt bezüglich dieses Problems verweigert.

OVH blockiert das Netz hier, warum ist uns nicht bekannt. Kontaktieren Sie bitte OVH diesbezüglich.
Nun, zwei Anbieter haben technische Probleme und der Kunde muss sie aussitzen. Also schrieb ich mal OVH Frankreich an und fragte um eine Stellungnahme. Die Antwort vom Support war erstaunt:
Je ne constate pas de blocage de cette IP 85.114.129.xxx de notre coté :
http://abuse.ovh.net/index.php?args=...cked&todo=host
--DEUTSCH--
Ich kann keine Blockierung der IP IP 85.114.129.xxx auf unserer Seite erkennen
Er versprach aber sich um die Sache zu bekuemmern und oeffnete ein Notfall-Ticket fuer mich an die Administratoren.

Ich gab das wiederum an Webtropia weiter, welche mir -bevor der Administrator von OVH antwortete- bereits ein interessantes Statement abgab:
wir haben in dieser Angelegenheit bereits alles was in unseren Bereich des Möglichen liegt untersucht. Es liegt hier eine Blockade seitens OVH vor. Das wurde von deren Seite seinerzeit eingeräumt, jedoch schaltet man dort auf stur. Wir bedauern, dass es dadruch für Sie zu Problemen kommt.
Hmm interessant, das klingt nach ISP-Krieg. Die Antwort die kurz darauf von OVH eintrudelte bestaetigte diese:

l'ip est nullroutée suite à des scans de ports sur le
réseau OVH,
Pour obtenir un déblocage, la société "fibre one
networks" doit faire le nécessaire pour arrêter les
attaques depuis son réseau puis envoyer un mail à
noc@ovh.net indiquant les protections mises en place pour
que ça ne se reproduise pas.
---DEUTSCH----
Die IP ist aufgrund von Portscans auf das OVH Netz nullrouted.
Um eine Deblockierung zu erhalten muss die Firma "fibre one networks" die notwendigen Schritte unternehmen um die Angriffe aus seinem Netz zu stoppen und danach eine Email an noc@ovh.net mit einer Auflistung aller unternommenen Sicherheitsmassnahmen schicken damit sich das nicht wiederholt.
Ok _DAS_ ist interessant. Abgesehen davon dass es nicht eine IP sondern ein ganzes Rechenzentrum ist welches blockiert wird (und nur ein Rechenzentrum, nicht ein ganzer Anbieter!) hat, scheint OVH also willkuerlich Konkurrenten zu blockieren aus deren Netz portscans reinkommen. IP-basiertes nullrouten und abuse-melden zuviel Aufwand? Skurril ist dass OVH selbst lange Zeit in Warez- und Szene-Foren als fuer C&C-Server und Fileserver ideal aufgrund langer Abuse-Zeiten und Traffic-Flat gehandelt wurde, aber die Konkurrenten trotz dieser 'interessanten' Vergangenheit keine Blockierungen eingesetzt haben.
Reicht es jetzt ein paar Hetzner-Server an zu mieten und ein Portscan mit erkennungs-ausweichenden Paketen zu schicken um RZ11 aus dem OVH-Netz unerreichbar zu machen?

Gleichzeitig ist es fast ironisch dass grosse Teile des russischen Wahome-RZ (afaik Hoster fuer das beruechtigte Heihachi) nicht blockiert sind waehrend bei SpamHaus PBL ganz geziele Worte fuer das Netz findet:
Hosting and routing for well known cybercriminals who use malware to infect the computers of thousands of Russian citizens.
This has been going on for years. Listed 2008-Oct-03 and there has been a nearly endless parade of the world's worst internet abusers hosted here and in the other IP space they route via their ASN.
Interessant, und was sagt OVH?
ping 92.241.160.3
PING 92.241.160.3 (92.241.160.3) 56(84) bytes of data.
64 bytes from 92.241.160.3: icmp_req=1 ttl=57 time=76.6 ms
64 bytes from 92.241.160.3: icmp_req=2 ttl=57 time=77.6 ms
Auch interessant...

Nebenbei bemerkt ist ein nicht unerheblicher Teil des Spams und der Angriffsversuche auf von mir verwaltete Server aus dem OVH Netz, vielleicht sollte ich mal Hetzner bitten OVH zu nullrouten