Xs4all kampt met grootschalige ddos-aanval

Xs4all ondervindt hinder van een grootschalige ddos-aanval. Sinds dinsdagmiddag hebben klanten moeite om webmail te benaderen en sites en andere diensten zijn ook beperkt bereikbaar. Volgens de provider is de aanval 'groter dan gebruikelijk'.

Vanaf dinsdagmiddag rond een uur of 1 maken abonnees van Xs4all melding van connectieproblemen. Onder andere webmail zou beperkt te bereiken zijn en ook diverse sites van de provider laden slecht of helemaal niet. Daarnaast kunnen klanten hun sites die ze bij Xs4all hosten niet bereiken. Na ongeveer een uur liet Xs4all weten dat de problemen voorbij leken en dat de systemen weer te benaderen waren. Niet lang daarna begonnen de systemen echter opnieuw slecht bereikbaar te worden.

"We kampen met een ddos-aanval en zijn druk bezig ip-adressen te blokkeren", vertelt Niels Huijbregts, woordvoerder van de internetaanbieder. Volgens hem heeft het bedrijf wel vaker te kampen met dergelijke aanvallen, maar is de huidige 'wel wat groter dan gebruikelijk', waardoor klanten er hinder van kunnen ondervinden. Aanvankelijk leek het bedrijf succesvol met het blokkeren van ip-adressen, maar de aanval bleek heviger dan verwacht. "We zijn nu in een kat-en-muis-spel verwikkeld. Het gaat om een grote reeks ip-adressen, afkomstig van veel verschillende landen en providers", aldus Huijbregts. Het blokkeren kost daarom veel tijd. Hij kon op het moment van schrijven niet aangeven wanneer de problemen voorbij zullen zijn. Niet bekend is wat de reden van de aanval is.

Reacties (183)

[J.S. Bach]

@ Tweakers.net Update van 15:46, problemen lijkt te zijn verholpen

[Anoniem: 329694]

Dit kan ik inderdaad verifiëren, begin van de middag probeerde ik mijn xs4all mail te openen waarop ik een SQL error kreeg te zien. Blijkbaar functioneerde de database toen niet naar behoren waardoor klanten die melding krijgen.

Na de update van 15:46 werkte Roundcube te vinden op https://roundcube.xs4all.nl/ weer!

[194673]

ik zat zomaar eens te denken, Moeten ISP's niet eens aan Source IP verification gaan doen? Dit zou een goed wapen zijn tegen DDoS aanvallen.

Meestal kan je bij een DDoS niets anders doen dan vroeg in het netwerk, op de boarder, het destination IP te "null-routen". Dit omdat de source IP adressen in een goed uitgevoerde DDoS aanval gespoofed zijn.

Als ISP's wereldwijd nou voor hun clients source IP verification uitvoeren dan kan een DDoS met gespoofde pakketten nooit het originele source netwerk verlaten.

DDoS aanvallen zonder gespoofde source adressen zijn dan makkelijker tegen te houden zonder de destination (target) te moeten null-routen (en dus onbereikbaar maken, het doel van de DDoS).

[aTmosh]

Moeten ISP's niet eens aan Source IP verification gaan doen?

Hier is al wel eens over nagedacht.
Er is sowieso te weinig informatie beschikbaar om iets over een oplossing te gaan roepen (hoeft ook niet, de admins bij XS4ALL zijn van dergelijke kaliber dat ik niet voor ze vrees ), maar voor het meeste laag 3 verkeer geldt dat correct geconfigureerde switches/routers al genoeg doen (TCP is b.v. bidirectioneel, UDP kun je bij volume droppen etc.); het toevoegen van een laag complexiteit is eerder een extra manier om geDoSd te kunnen worden (asymmetrische buffer/CPU gebruik).

Als het om een poort 80 aanval gaat vanuit een botnet met veel hosts dan kun je weinig anders doen dan timeouts verkorten, triggeren op herhaling/volume per (legitiem) IP, of statistische analyse op patronen die overeenkomen tussen grote groepen hosts en daarop grey/blacklisten. Naast dikkere pijpen/hardware natuurlijk, maar dat is alleen tot op zekere hoogte (economisch) effectief.

[Arnoud Engelfriet]

Dat helpt niet tegen de veel voorkomende DDoS aanval waarbij een groot botnet met gekaapte PC's wordt ingezet. Die gekaapte PC's hebben gewoon legitieme source IP adressen. En het is veel eenvoudiger om 100.000 gekaapte PC's te huren dan om IP-adressen te gaan zitten spoofen.

[194673]

Dat klopt, maar als je er vanuit kan gaan dat het merendeel van het internet aan Source IP verification doet, dan kunnen automatische appliances makkelijker over gaan tot het automatisch blokkeren van source IP adressen. Het spoofen is verder een fluitje van een cent als je toch al een machine geinfecteerd hebt met een client.

[robinverl]

Dat zou DPI vereisen wat weer niet is toegestaan lijkt me?!

[Keiichi]

Nee, DPI is als je voor bij L3 of L4 kijkt. Er wordt zoals elke router doet naar IP adres gekeken, in dit geval niet de destination, maar source, om te kijken of deze langs dezelfde interface waarop deze binnengekomen is ook terug te routeren valt.

Als dit laatste niet het geval is, gaat het vrijwel zeker om een gespoofed IP adres

[TVL]

Van de website van XS4ALL:
Ze geven aan dat de dienstverlening hersteld is maar kan nog steeds niet in het Service center. Webmail geeft aan dat de database unavailable is.

Als gevolg van een DDos aanval, zijn diverse XS4ALL
diensten momenteel verminderd bereikbaar. Het betreft
hier onder andere: www.xs4all.nl, het Service Centre,
Shared-Hosting en Email gerelateerde diensten.

Technici zijn op de hoogte en werken aan een oplossing
om het probleem zo snel mogelijk te verhelpen.

Onze excuses voor het ongemak.

[UPDATE 15:29]

Op dit moment is er nog niet veel meer te vermelden.
Er wordt door meerdere mensen gewerkt aan een oplossing.
Zodra er vorderingen zijn in het herstel van de dienstverlening,
dan zal dit zo spoedig mogelijk gecommuniceerd worden.

[UPDATE 15:46]

De dienstverlening lijkt hersteld. Technici zijn momenteel
druk met monitoren of er zich nieuwe problemen voordoen,
maar vooralsnog lijkt alles weer naar behoren te werken.

[Reactie gewijzigd door TVL op 22 juli 2024 14:15]

[Quincy5]

Ze zeggen idd dat het weer werkt, maar ik krijg zowel op roundcube als de gewone webmail nog steeds timeouts.

[defixje]

Pingen naar mail.xs4all.nl [194.109.6.40] met 32 byte gegevens:

Antwoord van 194.109.6.40: bytes=32 tijd=16 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=16 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=16 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=16 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=17 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=19 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=19 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=18 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=17 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=17 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=16 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=16 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=16 ms TTL=61
Antwoord van 194.109.6.40: bytes=32 tijd=16 ms TTL=61

Mijn pings (en die lopen nu nog) geven geen packet-loss meer aan hoor.

[Anoniem: 329694]

Misschien even je Cache van je webbrowser leeg maken Dat help in veel gevallen

[nutty]

Ach het is toch zo simpel.
ELKE server heeft zn max requests waarvan mag worden verwacht dat aanvragen binnen redelijke tijd beantwoord worden, naargelang het aantal aanvragen dit maximum te bovengaat,gaat de server er evenredig langer over doen om de requests af te handelen.
Of het de servers van Pietje puk op zolder ,het pentagon,xs4all,of de NASA betreft maakt geen zak uit,elk heeft zn breakpunt.

[Tenocticatl]

Noobvraag: je kunt een DDoS aanval alleen gebruiken om iets onbereikbaar te maken toch? Je kunt er niet mee 'inbreken' of zo op een systeem? Want dan slaat het idd niet echt ergens op om een isp aan te vallen.

[Anoniem: 447730]

Als je ergens hebt ingebroken kun je met een botnet je sporen wissen omdat alle logs vol raken.

[CUnknown]

Dat moet je wel hopen dat auto log rotation aanstaat. Anders loopt enkel de HDD vol en kan de bewuste logfile nog gelezen worden.

[Hunter23]

Direct inbreken kan inderdaad niet met een DDoS. Zoals Janglebyte zegt kun je wel de logs volpompen. Alleen ik denk dat je beter je sporen kunt wissen dan een DDoS uitvoeren. Zorgt alleen maar voor meer aandacht.

[dipje2]

Voor de duidelijkheid, het is niet alleen email dus. Hun co-location hosting in Amsterdam ligt ook 50%/50% plat.

Letterlijke antwoord aan de telefoon "het lijkt nu inderdaad te werken meneer, maar ik zou er niet vanuit gaan dat dat zo blijft. Nee, we kunnen geen enkele tijdsindicatie geven".

Lekker weer...

[wica]

Wat voor antwoord had je dan gewilt?
Als xs4all een zou weten wanneer de aanval afgelopen zou zijn, dan zou xs4all ook weten waar die vandaan komt en op wie die gericht was.

Als ik zo de meldingen bekijk, lijkt het er op, dat xs4all aangevallen wordt door middel van een botnetwerk. Als dit inderdaad het geval is. Kan xs4all op dit moment vrij weinig doen. En als een wilde IP's gaan blokken heeft niet zoveel zin, als je elke keer van andere adressen aangevangen wordt.

Ik ga er even vanuit, dat deze aanval niet op 1 IP gericht is, anders was het voor xs4all gemakkelijk op te lossen. Dus lijkt het er op dat het een bewuste actie tegen xs4all is.

[dipje2]

Dat als ze een bepaald percentage uptime beloven dit waard maken en dit al de 2e keer in 9 maanden is dat ze +/- 3 uur (of dus nog langer, laatste update om 17:11 nog steeds niet opgelost) uit de lucht zijn en dus gewoon hun SLA niet halen. De vorige keer was vanwege fout geconfigureerde routers.. C'mon.

Als je professionele hosting doet, is het toch logisch dat je hier een plan voor hebt? Je weet dat het makkelijk kan gebeuren als je aan cohosting doet, er hoeft maar 1 van je klanten een target te zijn en je hele netwerk krijgt het te verduren.

Dus nee, ik verwacht niet dat ze voorspellen wanneer een DDoS ophoudt, ik verwacht wel dat ze gewoon calamiteiten-plannen hebben waarin een uiterlijke tijd staat waarin de noodoplossing actief zou moeten zijn.

If anything, juist van XS4ALL had ik verwacht dat ze voorbereid zijn en weten waar ze mee bezig zijn.

[polthemol]

een ddos hou je niet zomaar tegen. En welke noodoplossing denk je dat technisch mogelijk is ? Nieuwe ipadressen uitdelen aan de klanten misschien ?

SLA is een hip modewoord, maar er zijn ook overmachtssituaties waardoor je onmogelijk je sla kunt halen.

En gezien wat ze hier naar buiten brengen gaat het een stuk verder dan 1 klant die wordt aangevallen en waar het hele netwerk het te verduren krijgt (wat simpel op te lossen is tijdelijk), hier lijkt eerder een heel groot stuk van het netwerk zelf het doelwit te zijn.

Dus misschien weten ze verdomd goed waar ze mee bezig zijn, maar snap jij niet helemaal hoe het technisch in elkaar zit en zit je maar wat met je sla te wapperen in de mening dat dat opeens wel iemand een geniale ingeving geeft ... Als jij met een systeem komt waarmee je dergelijke aanvallen perfect kunt afweren (dat is immers wat jij eist en meent dat ze moeten kunnen, liefst per direct) zou ik je willen adviseren hier meteen een patent op de nemen en je kunt de rest van je leven stoppen met werken (je kinderen en hun kinderen hoogstwaarschijnlijk ook trouwens).

[dipje2]

Don't get me wrong, ik sta hier niet met mijn SLA te wapperen .

Maar ook mijn klanten komen met vragen hoe dit kan, en waarom het zo lang duurt. Ik vertel ze hetzelfde maar ja, horeca ondernemers zijn nu eenmaal (meestal) niet het meest technisch aangelegd dus je krijgt een hoop onbegrip.

Er gaat geen kwaad woord van mij (of mijn baas) richting XS4all hierover, mede omdat ik juist snap dat het lastig is je hier tegen te verdedigen.

Maar zeg nou zelf, dan moet je toch ook niet beloven dat een storing binnen een minimum tijd verholpen is en dat het maar maximaal een _x_ keer zal gebeuren per jaar.
(Ja, dit zou beteken dat alle SLA's eigenlijk niet na te leven zijn, besef ik me donders goed).

Wat hier wel lastig maakt is dat je vanuit XS4all berichten krijgt als "nee hoor, co-location heeft er geen last van". "oh ja, toch wel zie ik nu". "alles is opgelost, het werkt weer". "oh nee, toch niet. we krijgen een 2nd wave". "Alles werkt nu echt". "oh nee, toch niet. Niet de juiste backup routers ingezet", etc..

Een kort maar eerlijk antwoord "we kunnen er niks tegen doen dus het kan wel eens tot 18:00 of later gaan duren" maakt het voor kleine bedrijfjes als waar ik voor werk duidelijk dat je moet gaan zoeken naar je eigen oplossing indien mogelijk.

Snel backups zetten op een server in ons eigen pand die ongeveer net genoeg bandbreedte heeft, en de DNS records aanpassen is snel en simpel gedaan, maar het duurt even voordat de DNS changes bij klanten zijn. Dus ik wil zoiets niet hoeven doen als er goede kans is dat het binnen een uur weer opgelost is.
Gemixte communicatie vanuit de helpdesk van xs4all zorgt voor verwarring, waardoor ik ook niet weet wat ik nu moet .

[polthemol]

je kunt er geen echte tijd op plakken. Als de aanvallen daarbij in waves kwamen is het niet in te schatten of het echt definitief gedaan is. Het is een uur stil, dingen komen weer online en ze geven je netjes de melding dat het gedaan lijkt te zijn, om meteen daarna de volgende lading attacks binnen te krijgen.

Dit is gewoon nare zooi, waartegen je je moeilijk kunt verdedigen. Daarbij is het ook altijd moeilijk in deze situaties om goede informatie te krijgen (vanuit helpdesk oogpunt) omdat er vaker meerdere mensen en oplosgroepen mee aan de slag zijn en je dus bergen informatie te verwerken krijgt die soms ook haaks op elkaar staat.

En het beloven van het oplossen van een storing is dus wat ik bedoel met sla wapperen Niet alle storingen los je op binnen x minuten. En je kunt ook niet garanderen dat je maar x aantal ddosses te verwerken krijgt binnen een jaar. Hier kun je simpelweg helemaal niets aan doen buiten wat kunstgrepen toepassen als het gebeurt in de hoop dat je het daarmee wat minder erg maakt. (en die beloftes: dat is toch wat de klant eist, ookal zijn ze niet waar te maken ... )

[wica]

Maar ook mijn klanten komen met vragen hoe dit kan, en waarom het zo lang duurt. Ik vertel ze hetzelfde maar ja, horeca ondernemers zijn nu eenmaal (meestal) niet het meest technisch aangelegd dus je krijgt een hoop onbegrip.

Dit type probleem hoor ik vaker bij kleine bedrijven. Echter komt dit door dat deze bedrijven vaak een beperkt aantal servers hebben (ivm de kosten) En niet serieus gekeken wordt naar een uitval optie.

Dit probleem zullen veel vaker tegen komen. Aangezien de meeste website's maar bij 1 provider draaien. En niet gebruik maken van meerdere providers.

/reclame moment
Klanten die de eis stellen altijd beschikbaar te zijn, adviseer ik ook meerdere providers te gebruiken. Ik zorg vervolgens wel voor de correcte afhandeling van het verkeer. Voordeel, er kan altijd een provider uitvallen, terwijl de dienst door blijft draaien.

[Anoniem: 394438]

SLA is een hip modewoord, maar er zijn ook overmachtssituaties waardoor je onmogelijk je sla kunt halen.

Met dressing?

Kun je misschien ook uitleggen wat SLA is? Doet me denken aan een idioot met een slaschaal in z'n handen.

[polthemol]

service level agreement. In het kort een document waarin je afspraken vastlegt, bv. hoeveel storingen mogen voorkomen in x tijd, hoeveel procent beschikbaarheid, wat er moet gebeuren bij een storingen, hoe je omgaat met verzoeken, wat wel en wat niet binnen support valt en vaker ook wat overmacht is (waardoor in bepaalde situaties die afspraken bijvoorbeeld niet gelden).

[hackerhater]

http://en.wikipedia.org/wiki/Service-level_agreement

[dcm360]

Je hebt blijkbaar het idee dat het met goede voorbereiding mogelijk is om een DDOS af te slaan. Helaas is er zeker geen generieke oplossing om een DDOS te weren, praktisch gezien is het een grote ongecontroleerde stroom data die op het netwerk afkomt.

[Boudewijn]

Mijn colocated dozen hangen in DC2 (dus de strozzilaan) en zijn prima te bereiken. Gelukkig.

[YakuzA]

wat verwacht je dan?

"Ja meneer, de DDOS'ers hebben beloofd om over 20 minuten te stoppen\hebben beloofd onze 2e colo locatie niet te DDOS'en."

[densoN]

Vrij normaal tijdens een calamiteit lijkt me.

[johnny2000]

Moet gelijk denken aan hun motto "Internet ook als internet het niet doet" of iets in die strekking

[Pmf1971]

Alleen als je service plus hebt en de UMTS stick aangesloten op en geconfigureerd hebt in de fritzbox.

En dan nog valt ie alleen terug op umts als er geen linesync is. Dat is er dus bij de meesten wel, alleen geen of weinig dataverkeer.

[johnwoo]

En dan nog valt ie alleen terug op umts als er geen linesync is. Dat is er dus bij de meesten wel, alleen geen of weinig dataverkeer.

Die linesync is natuurlijk vrij eenvoudig om zeep te helpen om het ding naar UMTS te forceren... Stekker eruit en klaar

Dan nog is de vraag of dat UMTS verkeer ook over het XS4ALL netwerk dat onder vuur ligt moet, of dat ze dat extern door de mobiele telecomprovider laten regelen.

[Reactie gewijzigd door johnwoo op 22 juli 2024 14:15]

[sfc1971]

Je bedoelt, door hun moederbedrijf, KPN?

Goh, wie zou XS4ALL, dochter van KPN nu inschakelen voor mobiel verkeer? En zouden ze dat is ISP met nul ervaring zelf gaan doen of dat misschien aan een beetje goed bevriende expert op dit gebied sinds het prille begin? Zouden ze erzo eentje kennen?

Is een beetje alsof je vraagt wie bij Coca Cola de fris verzorgt in de Kantine.

[Gutteguttegut]

Of je steekt de UMTS stick gewoon los in je computer

[Anoniem: 126717]

Het gaat ook niet over verbindingen. Die zijn gewoon in de lucht. Voor de zekerheid heb ik even op mijn modem gekeken, en "Internet, IPv6 connected since 05.04.2012, 03:47 o'clock, XS4ALL, IPv6 prefix: "

Het gaat om de site zelf.

[Perkouw]

Erg vervelend als je door zo'n ddos ineens niet bij je mail kan, hoop dat ze het snel op weten te lossen. Misschien kan tweakers een helpende hand bieden ? Haha.

Wat zou iemand hiermee willen bereiken vraag je jezelf dan af, ga wat nuttigs doen met je kennis/tijd blijkbaar is dat voldoende aanwezig.

[zxcvb]

Tweakers.net lag er een paar dagen geleden zelf een kwartiertje helemaal uit door een DDOS aanval...

[Uthog]

Of het nou Xs4all is of niet. Waarom ga je uberhaut een ISP Ddos' en je hebt er uiteindelijk alleen de klanten mee die er niks mee te maken hebben.

[Anoniem: 19339]

Waarom ga je uberhaut een ISP Ddos' en je hebt er uiteindelijk alleen de klanten mee die er niks mee te maken hebben.

Misschien is het doelwit juist een van hun klanten (die iets gehost heeft bij Xs4all), en is de provider in dit geval degene die er "niets mee te maken" heeft?