Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

'Fintechbank' Bunq kampt sinds zondagmiddag met ddos-aanval - update

'Fintechbank' Bunq heeft sinds zondagmiddag last van een ddos-aanval. De bank werkt eraan om de aanval af te slaan en probeert de diensten gewoon werkend te houden. Op het moment van schrijven wil de site van de bank niet altijd laden en de app weigert soms ook dienst.

Bunq stelt zijn klanten op de hoogte via een support-topic en op Twitter. De aanval zou iets voor 1 uur 's middags begonnen zijn. Het is nog onbekend hoe groot de schaal van de aanval precies is en wie erachter zit.

In september had Bunq ook al een dag of twee te kampen met een ddos-aanval. Toen was de bank ook verminderd bereikbaar. De dader van die aanval heeft zich echter in de tussentijd aangegeven en de verschillen tussen die twee partijen lijken bijgelegd, dus het lijkt onwaarschijnlijk dat dezelfde persoon er ditmaal achter zit. Het bedrijf stelde destijds overigens 'over serieuze anti-ddos-apparatuur te beschikken' voor het filteren en afleiden van het verkeer.

Update, 17:20: Bunq-oprichter Ali Niknam laat telefonisch weten dat de hindernissen voor klanten anderhalf uur na het begin van de aanval verholpen waren, maar dat de aanval zelf op de achtergrond nog onverminderd doorgaat. Hoewel de apparatuur voor het afslaan van de ddos verder toereikend zou zijn, zorgde een bug in de FreeBSD-netwerkstack ervoor dat de aanval in die anderhalf uur toch een effect kon hebben omdat tijd nodig was om het verkeer om te leiden.

Door Mark Hendrikman

Nieuwsposter

19-11-2017 • 15:02

92 Linkedin Google+

Submitter: Danny.G

Reacties (92)

Wijzig sortering
"Het bedrijf stelde destijds overigens over 'serieuze' anti-ddos-apparatuur te beschikken voor het filteren en afleiden van het verkeer."

Vraag me af hoe serieus dat spul is ;(
Minder serieus dan het botnet van de aanvallers blijkbaar. Zouden banken niet gewoon achter cloudflare kunnen?
Ali commentte daarover al na de vorige ddos-aanval:

"Using Cloudflare/Akamai is not a good idea since they would effectively be a Man-In-The-Middle and would be able to read all (financial) data passing through their systems."

Bron: https://together.bunq.com...k-to-normal#comment-16174
Aparte uitspraak.

TransIP is idd van dezelfde oprichter, maar weet niet of transIP ook zelf hun servers beheerd. Ik geloof dat ze vast kennis delen maar niet banken beheren. Voor bedrijf waar ik werk was er maar een ding waar we akami voor gebruiken...namelijk anti ddos. De enige fatsoenlijke oplossing waar gebruikers bijna niets merken. We zijn geen bank overigens. Dat punt snap ik wel dat je niet alle data wilt routeren. FreeBSD vind ik wel een aparte keuze hiervoor misschien.
Waarom is FreeBSD een aparte keuze? FreeBSD staat er nou juist om bekend erg geschikt te zijn voor zaken waarbij netwerkverkeer een cruciale rol speelt.

Niet voor niets wordt FreeBSD gebruikt door partijen als Whatsapp en Netflix waar netwerkverkeer een centrale rol speelt.
Whatsapp zegt waarom ze geen linux gebruiken:
Acton responded: "Linux is a beast of complexity. FreeBSD has the advantage of being a single distribution with an extraordinarily good ports collection."
Ease of deployment and maintenance dus.

Netflix zegt:
FreeBSD was selected for its balance of stability and features, a strong development community and staff expertise. All code improvements, feature additions, and bug fixes are contributed directly back to the open source community via the FreeBSD committers on our team. We also strive to stay at the front of the FreeBSD development process, allowing us to have a tight feedback loop with other community and partner developers. The result has been a positive open source ecosystem that lowers our development costs and multiplies the effectiveness of our efforts.
Community en stabiliteit, niks speciaals over netwerk.
"Using Cloudflare/Akamai is not a good idea since they would effectively be a Man-In-The-Middle and would be able to read all (financial) data passing through their systems."

Dat zou inhouden dat de encryptie getermineerd wordt bij Cloudflare en Akamai en weer opnieuw geencrypt worden als het vanuit CloudFlare / Akamai vertrekt naar bv een bank als deze zou kiezen om gebruik te maken van CloudFlare / Akamai.

Van Akamai heb ik vroeger begrepen dat zij zo goed konden zorgen voor anit-DDOS omdat zij heel maar dan ook heel veel capaciteit hebben. Inmiddels 30% van de totale internet capaciteit en daardoor moeilijk plat te krijgen zijn. De Man in the Middle theorie zou wijzen op een soort distributed load-balancer architectuur.
Dat zou inhouden dat de encryptie getermineerd wordt bij Cloudflare en Akamai en weer opnieuw geencrypt worden als het vanuit CloudFlare / Akamai vertrekt naar bv een bank als deze zou kiezen om gebruik te maken van CloudFlare / Akamai.
Dat klopt, dat is exact wat er gebeurd. Troy Hunt legt hier uit hoe CloudFlare werkt en waarom dit is.
Gebeurt hier op het werk ook denk ik. Hun proxy server decrypteert de traffic, filtert waar nodig, en encrypteert weer. In je browser blijf je mooi het groene slotje zien... :|
Zou kunnen, maar er spelen een aantal factoren mee. Ten eerste zijn ze nogal gerelateerd aan Trans-IP, dus vermoed dat ze zo veel mogelijk daarvan moeten gebruiken (logisch). Plus is Cloudflare een Amerikaans bedrijf, weet niet of je data via USA wilt laten lopen voor een bank.
Daarnaast is het in feite een MITM, en dan zou je je moeten afvragen in hoeverre je dat zou moeten willen bij iets dergelijks als een bank.
Cloudflare kan ook https traffic doorsturen zonder te decrypten, wel bij het duurste abonnement uiteraard

@herko_ter_horst ,

Je hebt gelijk, tijd voor een EU cdn!

[Reactie gewijzigd door GrooV op 20 november 2017 02:03]

Ben ik wel benieuwd hoe ze dat willen doen.

Uiteindelijk vertrouw je (o.b.v. het certificaat) de server waar je contact mee legt (d.w.z. de Cloudflare server). Volgens mij is het niet mogelijk te garanderen dat Cloudflare het verkeer niet kan inspecteren.

Ik zie dat ze adverteren met "Keyless SSL", waarbij de private key onder beheer blijft van de oorspronkelijke eigenaar en er geen Cloudflare key gebruikt wordt. Maar daar staat bij "Note: Keyless SSL requires that Cloudflare decrypt, inspect and re-encrypt traffic for transmission back to a customer’s origin."
Hoe? Door een IP range via Cloudflare te routeren, of door een range van Cloudflare gebruiken en hen destination NAT te laten doen.
Als de daadwerkelijke terminatie van de TLS verbinding gebeurt met systemen van Bunq dan kan Cloudflare niet het verkeer inspecteren zonder dat eindgebruikers dat kunnen weten. Het enige dat zo'n partij dan hoeft te doen is het filteren van IP verkeer.
Helemaal juist Karizma! Je kunt cloudflare niet gebruiken als je nog enige pretentie van privacy will bewaren.

Word nogal eens over het hoofd gezien.

@GrooV je moet wel onthouden dat ook encrypted traffic informatie verschaft. De afmetingen van plaatjes en webpagina's, de timings van heen en weer reacties, die zijn allemaal makkelijk na te volgen. Ook gebeurt het nogal eens dat encryptie helemaal niet zo veilig was, en dan heb je mooi wel al je data ge-vrijwilligt terwijl dat niet perse nodig was.
je moet wel onthouden dat ook encrypted traffic informatie verschaft. De afmetingen van plaatjes en webpagina's, de timings van heen en weer reacties, die zijn allemaal makkelijk na te volgen.
Alles wat je noemt geldt toch in op dezelfde manier of het gehost wordt door de bank zelf of een derde partij? De encryptie beschermt slechts de inhoud, maar maskeert niet dat de communicatie plaatsvindt.

Je zou zelfs kunnen stellen, dat wanneer de communicatie via een derde partij gaat (die naast banken ook andere zaken host) het moeilijker te achterhalen is of je als klant gebruik maakt van de bankdienst of een van de vele andere diensten die door dezelfde derde partij gehost worden. Daarnaast is bij bankieren volgens mij de inhoud (hoeveelheden geld en naar wie het toe moet / waar het vandaan komt) van belang, niet zozeer op welke tijdstippen je gaat internetbankieren.
Je ziet veel van de inhoud doordat de afmetingen van de pakketten zichtbaar zijn. Je kunt vaak iemands stappen door de site navolgen.

Dat is inderdaad ook bij banken e.d. vaak genegeerd.
Ben je gek? Even al je data aan cloudflare geven.

Doordat je de CDN van cloudflare gebruikt, geef je meer gegevens van je gebruikers weg, dan je lief is.
Als je HTTPS endpoint bij Cloudflare termineert, mogen ze die data niet gebruiken.
Het kan technisch wel, maar het mag niet. Dat staat in de overeenkomst die met Cloudflare afsluit.

Gelukkig kan je controleren of Cloudflare zich ook aan die afspraak houdt.
Dat kan hier: <oeps>
Dat hebben ze nog niet geregeld, en 1 ander ding ook nog niet.
Dus tot die tijd: onveilig.
Best wel slecht eigenlijk voor een partij die zo breed wordt gebruikt.
Toegang tot systemen of gegevens regel je dan ook nooit met afspraken maar met d.m.v.. technische maatregelen. Ik heb me ook best verbaasd hoeveel vertrouwen bedrijven en overheden hebben in Cloudflare. Bizar want indien een 'beveiligde' verbinding met een bank via Cloudflare verloopt is dat net zo veilig als bankzaken doen via een roque wifi accespoint.
Is niet alleen bij Cloudflare, elke CDN achtige oplossing bied dit tegenwoordig.

Maar idd, wij moeten er op vertrouwen dat zij niets met deze data doen.
Gezien cloudflare het HTTPS endpoint is denk ik dat je een goed punt hebt. Overigens is de API geen cdn maar een volwaardig endpoint.

[Reactie gewijzigd door Sloerie op 19 november 2017 15:24]

Hangt van de soort DDOS af. Als het puur om bandbreedte gaat dan is cloudflare een oplossing.

Calls naar een API moeten via cloudflare nog steeds bij een applicatieserver uitkomen. Als dat de bottleneck is tijdens de DDOS aanval dan zit de bottleneck er nog steeds.
... Zouden banken niet gewoon achter cloudflare kunnen?
In theorie wel, maar de vraag is of dat wenselijk is. Cloudflare is een Amerikaans bedrijf, bron: https://en.wikipedia.org/wiki/Cloudflare. De privacy wetging daar in de USA is anders dan in de EU. Hoe dan ook wordt er op privacy ingeleverd als er een derde partij tussen zit, ondanks het voordeel op DDOS bescherming.
Wordt inderdaad niet snel gebruikt door instellingen zoals een bank / waar gegevens iets belangrijker zijn.
Als ze je internetpijp dichtdrukken kan je nog zo veel Radware dozen hebben staan, maar er komt amper legitiem verkeer door je pijp heen. Bandbreedte bij een DDOS kost tegenwoordig geen flikker meer, maar een moeilijk dikke redundante internetpijp met SLA's is daarentegen enorm duur.
Je kan honderdduizenden euro aan apparatuur uitgeven. Als je eigen bandbreedte minder is dan wat de aanvallers op je afsturen maakt het niet uit. Verzafigd is verzadigd. De enige manier om DDoS aanvallen goed af te slaan is zien dat je meer bandbreedte hebt en zoveel mogelijk probeerd om ze zo ver mogelijk upstream te blokkeren.
Al dit soort spul staat/valt toch ook bij de configuratie? Een DDOS afslaan doe je door via een algoritme het 'goede' verkeer door te laten en de aanval te laten droppen.
Als een bron van een DDOS echter niet herkend wordt door het algoritme, dan wordt er niets tegen gehouden. Het steeds meer apparaten aan't internet, die allemaal deels lid worden van botnets etc, is de kans dat jouw configuratie waterdicht is steeds kleiner.
Bij de rabobank en andere banken was het technisch ook gewoon mogelijk de bron van het 'plaatje' bij inloggen na invoeren rekeningnummer, te DDOS'en. Hierdoor kwam er voor jou en mij zeg maar geen plaatje meer tevoorschijn die wel cruciaal genoeg was om mee in te kunnen loggen.

Het kost ook rekenkracht om te bepalen wat wel en niet goed verkeer is. En wanneer de aanvallers jouw volledige upstream volpompen dan heeft het weinig zin meer. Dan zijn al je services zo goed als onbereikbaar.
" de aanval te laten droppen."

Dat is juist het probleem. Je kan wel filteren bij de voordeur, maar het probleem is dat alle wegen naar je wijk al vol staan. Je moet dus de peering links aanpakken voor zover dat uberhaupt kan. Als het verkeer goed verdeeld is (of juist uit NL komt) dan wordt het des te moeilijker.
Mijn reactie was op Kazima, die zijn twijfels uitte over de 'serieuze apparatuur' die hier zou staan om ddos'en tegen te gaan. Ik probeer enkel aan te geven dat serieuze apparatuur nog geen garantie is op het afweren van een DDOS. Eerder andersom.

Alles in je netwerk + je netwerk naar buiten moet zwaar zijn uitgerust en super strak zijn afgeregeld, om berhaupt maar een kans te maken dit tegen te houden. Een goed uitgevoerde DDOS is zelfs dan nog bijna niet te stoppen.
Als je de mogelijkheid hebt om 10 dingen aan te kunnen, maar je krijgt er 2000..
Dan kun je een grotere verbinding gebruiken en betere hardware die 2000 aankan.

Dan heb je 2000 dingen die je aankan, tot iemand je 40,000 dingen geeft om te verwerken..

De grootste wint.
Bunq eigenaar is Ali Nikham, ook eigenaar van transip, een toch aardig grote hoster voor Nederlandse begrippen. Juist als hoster verwachtte ik dat ze meer dan welke andere bank dan ook weten hoe je ddos aanvallen afweert.
Bovendien met knuffelen van crimineel vraag je er gewoon om.
Ik ben (als bunq-klant) heel benieuwd wat je hier precies mee bedoelt @totaalgeenhard ?
Vorige keer hebben ze geen stappen ondernomen tegen degeen die hun aan het DDoSsen was.

In discussie daarover hier werd dat mijn mening me heel kwalijk genomen.

Zie ook mening van Ali Niknam eigenaar TransIP en Bunq:
Update, 17:20: Bunq-oprichter Ali Niknam laat telefonisch weten dat de hindernissen voor klanten anderhalf uur na het begin van de aanval verholpen waren, maar dat de aanval zelf op de achergrond nog onverminderd doorgaat. Hoewel de apparatuur voor het afslaan van de ddos verder toereikend zou zijn, zorgde een bug in de FreeBSD-netwerkstack ervoor dat de aanval in die anderhalf uur toch een effect kon hebben omdat tijd nodig was om het verkeer om te leiden.
Hij spreekt zichzelf tegen.

Als anti-ddos apparatuur toereikend is dan ga je niet plat. Sterker nog je ziet in je monitoring een piek en als het extreem is krijg je een melding.

Bug in FreeBSD-netwerkstack... wow... dus ze hebben een 0day gevonden en vanaf nu kan je een DoS doen ipv DDoS (dus niet flooden van resources van meerdere plekken) van alle freebsd gebaseerde systemen waaronder Apple en netwerk en security appliances.

Maar dit betekend dus dat of hun anti-ddos apparaat werkt op freebsd of hub server park.... en in dat laatate geval kwam verkeer dus ondanks counter measures nog steeds aan.

Ik denk dat hij er wijs aan doet om comminicatie afdeling er tussen te schuiven en technisch risico's gaat inperken.

Zeker als je van plan bent daders te gaan belonen met een rondleiding. (Kijk zo kun je het beter doen volgende keer)

Ps je kunt ook elders bankieren...

https://next.n26.com/en-eu/

[Reactie gewijzigd door totaalgeenhard op 20 november 2017 02:31]

Even krte reactie: Thanks voor de tip! Ga niet helemaal overstappen maar heb er wel wat aan.
Serieus? LOL.. na een normale regenbui staan de putten altijd minstens 3 dagen vol...
Maar die hebben geen blackbox-anti-flood er tussen hangen.

Of anti-flood as a service.
Een kind dat zichzelf aangeeft voor zijn fout een crimineel noemen? Crimineel ben je als je veroordeeld bent voor een misdrijf. Nu ben ik het ook niet bepaald eens met zijn aanpak maar ik ben blij dat de gemiddelde tweaker het je destijds kwalijk nam. Zo slecht is de wereld dus nog niet.
18 jaar noem jij een kind?

Over zijn bewezen mentale tekortkomingen kan ik niet oordelen, misschien dat je een punt hebt.

Als je iets crimineels gedaan hebt en je doet een mea culpa wil dat niet zeggen dat je geem crimineel bent.

Veroordeling is alleen formeel dat je bij vog als werkgever beetje geluk kan hebben dat ambtenaar denkt dat iemand een risico kan vormen.

Deze randdebiel blijft buitenschot.
Ik had begrepen 14 en reageerde ook met die leeftijd in mijn hoofd, maar ja ook een 18 jarige is een kind.
Ja natuurlijk. WHAT THE FUCK maakt het uit waar de tiener vandaan komt? Ik ben prima in staat een constructieve discussie te voeren maar hier houd het toch echt op bij mij. Ik weet genoeg.

Ik hoop stiekem nog dat je gewoon een domme uitspraak hebt gedaan waar je op een of andere manier spijt van hebt, maar zo niet, liever 50 iraanse ali's met een 'hard' dan 1 iemand zonder.
Bunq is zelf medeschuldig aan deze aanval. Bij de vorige hebben ze breed in de pers lopen uitventen dat de dader gepakt was en dat Ali zn barmhartige hand over zn hart gestreken had omdat de dader minderjarig was en Ali hem geen strafblad wilde geven.

Ten eerste geeft Ali dat strafblad niet, maar een rechter en is dat het gevolg van criminele activiteiten ontplooien. Ten tweede is er een bizar gevaarlijk precedent neergezet: als je minderjarig bent kan je redelijk straffeloos bunq aanvallen. Als je gepakt wordt kom je er af met een tour en shamesessie op de bunqer (bunq HQ) en wat vrijwilligerswerk.

Niet slim. Ik hoop van harte dat de dader dit keer weer opgespoord zal worden en er aangifte zal volgen. Ik verwacht van mijn bank dat ze cybercriminaliteit hard aanpakken en met wortel en tak zullen trachten uit te roeien. En anders ga ik terug naar de ING, daar betaal ik een stuk minder en nemen ze cybercriminaliteit wel serieus.
Ik begrijp uit jouw reactie dat je aanneemt dat deze aanval door een minderjarige wordt uitgevoerd?

Het is helaas realiteit dat de meeste banken tegenwoordig meerdere van dit soort aanvallen krijgen per jaar. Niet altijd uitgevoerd door 14-jarigen.

Wees gerust ING ligt er ook een paar dagen per jaar uit, het gras is helaas niet mooier aan de andere kant van de heuvel.
Nee dat neem ik niet aan. De vorige aanval werd blijkbaar door een minderjarige uitgevoerd en om die reden besloot Ali Niknam om geen aangifte te doen. Iets met zn toekomst niet verpesten.

Op het bunq forum zei Ali vanavond in een reactie op mij dat hij geloofd dat vergevingsgezindheid getuigd van moed. Dat is misschien wel zo, maar ik geloof dat het een gevaarlijk precedent maakt.
Ik vind het gevaarlijker om een kind zijn leven te ontnemen. Die kans zat er in. Die overweging heeft Ali moeten maken.

Had hij die kleuter laten branden dan was ik weg bij bunq. Ook die overweging heeft Ali moeten maken.

Wellicht heeft hij onder de streep uiteindelijk de verkeerde keuze gemaakt, wellicht niet.
Als hij echt minderjarig was dan viel hij onder jeugdrecht en dan vallen de straffen volgens mij wel mee.
Het betrof een 'kleuter' van 18. Gelukkig weet Ali dat je ook met 18 nog een kind bent zal ik maar zeggen. Iemand die net aan het leven begint alles ontnemen zou voor mij ook niet makkelijk zijn. De afweging is zo simpel niet als 'hij is jegens mij een fout begaan en dus moet branden'

[Reactie gewijzigd door TWeaKLeGeND op 20 november 2017 09:00]

Nou nou nou, aangifte doen is niet hetzelfde als iemand veroordelen tot de doodstraf.
Same difference, wel aangifte doen en van de rechter geen straf krijgen of geen aangifte doen maakt geen verschil in het afschrikeffect voor nu, alleen aan wel aangifte doen zit de kans van daadwerkelijk geruime tijd in de gevangenis terecht komen en een hoge boete en wellicht een veroordeling tot schadevergoeding. De aangifte heeft hele trajecten erna als gevolg, zal invloed hebben op schoolprestaties en de psyche van het ventje etc. Gaan we Ali echt kwalijk nemen dat hij dat niet wilde en over zijn hart heeft gestreken? Gaan we dat nu aanwijzen als reden dat er meer DDoSsen zijn? Ik vermoed dat elke bank dagelijks met aanvallen te maken heeft.

Ik zit er meer van te kijken dat een fintechbank onstaan bij een webhoster nog zo veel DDoS last heeft btw. Maar ik ben dan ook geen ddos of anti ddos expert.

[Reactie gewijzigd door TWeaKLeGeND op 20 november 2017 09:10]

Yep en ik vermoed dat grote jongens als ING hier keurig netjes aangifte van doen. Iets met "wie zijn billen brandt moet op de blaren zitten" en "bij nacht een man, bij dag een man".

In ieder geval vind ik het niet slim om de aanpak zo breed uit te venten. Je toont openlijk dat je toch geen aanklacht indient als de dader minderjarig is. Dus een minderjarige die zin heeft in een dosje denkt "ach, bij bunq kan het niet zo'n kwaad"... Als je op zo'n manier de boel af wil handelen (wat je goed recht is natuurlijk en misschien idd barmhartig onder bepaalde omstandigheden) dan kun je dat denk ik maar beter stil houden.
Tja, ik denk dat elk incident op zicht wordt bekeken. En dat vergeven krachtiger is dan straffen. Kansen zien in plaats van eenheidsworst. Maar je hebt gelijk, ieder bedrijf gaat er anders mee om.

Echte ondernemers zien kansen en als het goed is leren hackers van de fouten van anderen: Ali weet je te vinden als je aan zijn systemen komt...

Wellicht een nog veel krachtigere boodschap dan dat de politie je probeert op te sporen...

[Reactie gewijzigd door djwice op 20 november 2017 20:49]

Ik verwacht van mijn bank dat ze cybercriminaliteit hard aanpakken en met wortel en tak zullen trachten uit te roeien.
Dat is de taak van een bank niet. En wat wilde je dan? Een Joegoslaaf achter de dader aansturen zodat je zeker weet dat hij het nooit meer doet? Sommigen hier lijken op dit punt het perspectief een beetje verloren te hebben. Ik vind dit meer digitale baldadigheid, we hoeven niet meteen alle kwajongensstreken te juridiseren, iets dat toch al veel te veel gebeurt tegenwoordig.
Waar houdt digitale baldadigheid op en waar wordt het in jouw visie echte cybercriminaliteit?
Als hij zou inbreken en geld overmaken op andere rekeningen om dat in te pikken wordt het natuurlijk weer wat anders. Dit zie ik meer als ergens de ruiten ingooien - in principe natuurlijk strafbaar maar dat kan ook zonder politie opgelost worden.
DOS aanvallen mogen niet, als het OM wil vervolgen omdat iemand wetten heeft overtreden hebben ze daar geen aangifte voor nodig. Dat bunq hier geen zaak over is begonnen is inderdaad hun keus maar er had ook een strafzaak over kunnen zijn.

Voor meer informatie, lees meer over burgerlijk recht en strafrecht.
Als bunq geen aangifte doet en geen inzage geeft in met wie ze een gesprek heeft gehad, hoe moet het OM dan ruiken wie de dader was? Die kunnen bunq niet (zomaar) dwingen om inzage te geven in haar onderzoek en/of correspondentie.
Is er niet een protocol te verzinnen dat even doorgeeft aan alle routers upstream: "H, deze pakketjes naar deze host zijn DDOS, niet doorsturen aub!"
Dat werkt alleen als de data van een klein aantal hosts komt. Die eerste D in DDOS staat echter voor Distributed en dus komt de data van duizenden tot honderduizenden hosts. Het is lastig om dan te bepalen wie de DDOSer is en wie een echte klant.
Toch is het afweren van verkeer op basis van herkomst en content, naast een dikke internetpijp, de aangewezen manier om met een ddos om te gaan. Alleen heb je daar een dure infrastructuur voor nodig die alleen in geval van nood ook iets doet. Juist daar springen dienstverleners als cloudflare in bij: zij hebben een dikke pijp en een hoop apparatuur om juist dt te doen, zodat je als klant niet of veel minder geīmpacteerd wordt.
Een DDoS Attack hoeft ook niet groot te zijn en veel bandbreedte te hebben. Als je via layer 7 een API of applicatie aanvalt, is het vrij eenvoudig om diensten met een lage snelheid down te brengen. Dit komt vooral voor via udp. Op de server kun je specifieke packets filteren. (via iptables etc.) Dit probleem is redelijk aan het groeien en komt vaak voor op gamingservers.
Het probleem is dat bij de meeste DDOS het niet duidelijk is wat echte en wat "nep" pakketjes zijn.
Als de DDOS bijvoorbeeld duizenden keren per seconde pagina's opent, dan is er niet veel aan te doen.
Het bepalen van "Deze pakketjes zijn DDOS" kost al behoorlijk veel kracht. Als je dan van honderden hosts tegelijk moet gaan bepalen welke pakketjes DDOS zijn, en welke legetiem, dan kost dat zelfs zoveel kracht dat je alsnog gewoon down gaat.
Zoiets is er, met Flowspec kan je erg fijnmazig bepalen op welke manier je router met verkeer om moet gaan. Als je dan bv de Flowspecregels over een bepaalde DDOS deelt naar andere ISP's zouden die hetzelfde kunnen doen. Maar dan moet je al wel weten dat er een DDOS is, dus zal je ook goede detectiemogelijkheiden moeten hebben die je vertellen welk deel van je verkeer precies die DDOS bevat.

Daarna ontstaat een ander probleem: niemand gaat dit soort informatie van een andere partij zomaar accepteren en in zijn netwerk gebruiken, dan creer je namelijk weer een andere DOS mogelijkheid ;)

Op een wat minder fijne schaal wordt dit al wel her en der gedaan door gebruik van BGP communities voor het automatisch blackholen van verkeer. Dus als bunq bij deze attack bv weet dat het rotzooiverkeer allemaal uit bepaalde IP reeksen komt (als voorbeeld) zouden ze naar hun transitproviders kunnen sturen dat ze geen verkeer uit die reeksen meer willen ontvangen.

Maar dit soort technieken werken alleen goed als je zelf een flinke oprit naar Internet hebt, anders moet je met je transitleverancier gaan praten. Als je oprit helemaal vol is moet iemand verderop in het netwerk je gaan helpen.

[Reactie gewijzigd door Jheroun op 20 november 2017 13:09]

Fintech is a portmanteau (nl: tezamen gepakte verzameling) of financial technology that describes an emerging financial services sector in the 21st century. Originally, the term applied to technology applied to the back-end of established consumer and trade financial institutions.
Financial Technology (FinTech or fintech) is the new technology and innovation that aims to compete with traditional financial methods in the delivery of financial services.
...,
Denk post het even, want ik wist het niet.
Een klein stukje nuance dat de redactie gemist heeft: bunq geeft aan de DDOS aanval onder controle te hebben.

Dat tweakers bij grote partijen (exclusief bij de grootste ISP van Nederland) erg kritisch is is over downtime vind ik goed. Maar als wij in Nederland open communicatie over storingen/DDOS willen dan moet de media daar ook eerlijk over communiceren en de hele berichtgeving meenemen.
App werkt hier inderdaad wel

[Reactie gewijzigd door ANdrode op 19 november 2017 15:08]

Over smurf attack: Ik zou geen daderkennis publiceren op een publiek forum :+

En ik verwacht dat een aanval op de applicatielaag zit. Dat noemt men tegenwoordig ook DDOS ;). Doe je weinig tegen als jouw API structuur publiek is. Reversen voordat je een aanval doet is voor kiddo's teveel werk.

Ik benoem dat hoe T.net hierover publiceert op zijn best selectief is en dat hierdoor bedrijven die wel op communiceren schade lijden terwijl er mogelijk vrijwel geen customer impact is.

Ik ga er wel vanuit dat bunq een ander platform gebruikt dan TransIP. Ben het met je eens dat banken beter beschikbaar horen te zijn dan een budgethoster.
Bunq is van TransIP eigenaar/oprichter.

Zou mij verbazen als hij het elders zou hosten.....
Dat zou mij ook verbazen. Maar het is geen homogeen platform:
https://stat.ripe.net/wid...ghbours#w.resource=203096

Eigen AS met drie upstream providers. TransIP, Cogent, Hibernia. Laatste kende ik niet – maar is nu eigendom van GTT en gericht op financile sector (inclusief low latency/DDOS protection).

Wanneer nodig kunnen ze het verkeer dus snel (~minuten) van pad laten veranderen.

ICMP verkeer naar bunq toe (traceroute) wordt, afhankelijk van het pad (wel: transip, niet: hibernia), gefilterd. Traceroute naar transip is mogelijk. Zie ook https://atlas.ripe.net/measurements/10260178/
Wanneer nodig kunnen ze het verkeer dus snel (~minuten) van pad laten veranderen.
Millisecondes. Als het redundant is opgezet.

Bij reguliere banken draaien bedrijfskritische in redudante datacenter op een KM of meer afstand met het idee dat DC vernietigd kan worden en er binnen 100ms volledig (liefst zonder sessie verlies) doorgewerkt kan worden op andere dc. Klant merkt dit niet of amper.

Maar het gaat bij DDoS om hoeveelheid en samenwerk netwerk ivn terug tracen en null routen buiten Nederland. Als verkeer Nederland niet flood maakt het voor Nederlandse gebruikers niet uit dat er een DDoS gaande is.
Milliseconden – nadat een medewerker reageert ;)

Bij een DDoS puur op volume kan je upstream filteren. En zoals je terecht noemt zou je daar in Nederland geen last van moeten hebben (zoals je bij die Atlas probe measurement ziet lopen de meeste paden vanuit NL naar bunq via private peering of KPN).

Als het op applicatieniveau zit en verspreid is over veel IP's (IoT) wordt het lastiger. Maar je kan altijd SSL termination naar de edge locaties van een wereldwijd verspreid netwerk verplaatsen, zodat je decentraal kan filteren, i.p.v. dat in je eigen datacentrum te houden.

Wl een totaal andere architectuur dan een hostingpartij die vooral PoP's in n stad heeft gewend is ;)
n.a.v. de update: Een bug in de netwerk-stack /kan/ je natuurlijk nu pas ontdekken [zeker als je custom patches hebt] en dan zal het om een klassieke DDoS gaan. Type pakket maakt /niet echt/ uit.

In ieder geval geen layer 7 aanval zijn zoals ik had verwacht
Bunq, de bank die zich als voor de mensen presenteerde. Was goedkoop en dee niks met je geld. Na een korte tijd van goedkoop zijn werd deze enkele malen duurder dan een traditionele bankrekening bij een "niet voor mensen bank".

Ik ben dus niet geraakt dat Bunq is geraakt door een DDOS aanval.
Bunq is nog steeds gratis voor bestaande klanten hoor.
Ik heb zelf een Bunq rekening, maar alleen om te kunnen handelen op Bl3p. (Mijn betaalrekening en spaargeld staan daar niet)
bl3p doe ik via mijn normale bankrekening, wat is het voordeel van bunq met bl3p?
In het begin had je een bunq rekening nodig om te kunnen handelen op bl3p. Het kan zijn dat dat inmiddels niet meer nodig is.
Blijkbaar is dat anders nu, want ik heb gebruik hiervoor mijn ING. Nu je het zegt, er daagt mij wil iets dat dat nodig was.
Ook voor nieuwe. Je kan gewoon een gratis pakket nemen, dan heb je alleen geen bankpas en geen API toegang.
Ik ook niet, maar ik ga om andere redenen nooit over naar Bunq, neem bijvoorbeeld de klantenservice mogelijkheden.. dat is eigenlijk 0%... wel betalen.. maar in feite geen klantenservice hebben... lekker handig.
Je kan ze gewoon mailen en ze reageren behoorlijk rap. Een klantenservice over de mail is in mijn optiek alleen onprettig tot je weet dat ze snel reageren.
Wat je wil. Ik vind contact, op wat voor manier dan ook, het belangrijkst.
En dan liever mailen dan bellen - heb wel wat beters doen dan in de wachtstand staan.

Heb ze zojuist nadat ik dit bericht geplaatst had gemaild - ik moest nog wat vragen.
Had 19 minuten later reactie. Op zondagavond. Ik klaag niet...
De klantenservice van bunq is in mijn beleving 24x7 bereikbaar, via chat en mail. Maar je hebt gelijk, je kunt ze niet bellen en dat steekt een bepaalde groep gebruikers en potentiele gebruikers.

Het argument van Ali tegen telefonisch contact is voornamelijk security: via de telefoon authenticeren is lastiger dan via de App. Ik vind het zelf een nogal zwak argument. Tuurlijk is de gemiddelde implementatie van de gemiddelde bank (mag ik ter verificatie uw postcode en geboortedatum of moeders meisjesnaam?) zo lek als een mandje en vaak met simpele social engineering te achterhalen. Maar als je kijkt naar hoe Paypal en Apple dit oplossen: daar genereer je in de secure online omgeving een tijdelijke support token die je vervolgens aan de telefoon kunt gebruiken om te authenticeren en/of tijdelijk toegang te geven tot je gegevens. Dat zou bunq ook kunnen doen...

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True