DDoS ABN-Amro

[Verwijderd]

Gisteravond 9-3-2018 was het weer zo ver, de ABN-Amro site inclusies mobiele app en iDeal lagen eruit door een DDoS aanval. Dit heeft uren geduurd en net kom ik erachter dat de ABN site wederom plat ligt. Nu begrijp ik heel goed dat dit een invloed van buitenaf is maar er moeten toch remedies zijn om dit of te voorkomen of zo'n aanval snel af te slaan. Dit laatste zou je kunnen doen door in samenwerking met de ISP al het verkeer vanaf buitenlandse ip's te blokkeren als een DDoS aan de gang is.

Nog los van alle beveiligingsproblemen waar we mee kampen, legt dit toch een bom onder het hele internet. We worden meer en meer verplicht om alles digitaal te doen, maar we zien ook meer en meer de keerzijde hiervan. We zijn afhankelijk geworden van digitale diensten, maar de betrouwbaarheid en veiligheid laat eigenlijk te wensen over. Als een tiener het al voor elkaar krijgt om sites van banken, belastingdienst e.d. uren plat te leggen, hoeveel schade kan een professional of een vijandelijke natie wel niet aanrichten. In mijn optiek wordt hier veel te weinig rekening mee gehouden en gaan we heel zwart/wit gezegd onze digitale ondergang tegemoet.

Hoe kijken mede tweakers hier tegen aan, en hoe kunnen belangrijke dienstverleners als banken zich hier tegen wapenen?

[pjot1]

Ik denk dat banken/overheden hier weinig tegen kunnen doen...

[Verwijderd]

pjot1 schreef op zaterdag 10 maart 2018 @ 11:36:
Ik denk dat banken/overheden hier weinig tegen kunnen doen...

Denk dat je dit meer op een niveau van ISP's en AMS-IX moet gaan aanpakken, buitenlandse ip's weren naar betreffende sites op het moment van DDoS aanvallen. Maar heb te weinig inzicht naar de mogelijkheden hiervan. Daarnaast zou er wereldwijd veel meer aan botnets gedaan moeten worden d.m.v. het afsluiten van internetverbindingen waarop apparaten actief zijn die onderdeel van een botnet zijn.

[Dexs]

ABN is weer onbereikbaar, waarschijnlijk weer een ddos aanval. Erg vervelend.
Ik snap dat de ABN er niet veel aan kan doen maar overweeg nu wel een nieuwe rekening te openen bij een andere bank. ABN is wel erg vaak doelwit van ddos aanvallen.

Verwijderd schreef op zaterdag 10 maart 2018 @ 11:41:
[...]


Denk dat je dit meer op een niveau van ISP's en AMS-IX moet gaan aanpakken, buitenlandse ip's weren naar betreffende sites op het moment van DDoS aanvallen. Maar heb te weinig inzicht naar de mogelijkheden hiervan. Daarnaast zou er wereldwijd veel meer aan botnets gedaan moeten worden d.m.v. het afsluiten van internetverbindingen waarop apparaten actief zijn die onderdeel van een botnet zijn.

Als ik de experts in nieuwsberichten kan geloven zit het grootste probleem in de iot apparaten die makkelijk te hacken zijn. Succes met al het verkeer van alle verschillende landen wegfilteren. Lijkt me erg lastig te bepalen wat een legitime connectie is en wat niet.

[ Voor 62% gewijzigd door Dexs op 10-03-2018 11:44 ]

[pjot1]

Dexs schreef op zaterdag 10 maart 2018 @ 11:41:
ABN is weer onbereikbaar, waarschijnlijk weer een ddos aanval. Erg vervelend.
Ik snap dat de ABN er niet veel aan kan doen maar overweeg nu wel een nieuwe rekening te openen bij een andere bank. ABN is wel erg vaak doelwit van ddos aanvallen.

Toch is ABN één van de grote banken met de minste storingen.

[Dexs]

pjot1 schreef op zaterdag 10 maart 2018 @ 11:44:
[...]


Toch is ABN één van de grote banken met de minste storingen.

Dat is niet helemaal (helemaal niet?) waar: https://www.nu.nl/interne...te-storingen-in-2017.html

ABN is 3 keer zo lang onbereikbaar geweest dan de Rabo(nr2) in 2017

[ Voor 10% gewijzigd door Dexs op 10-03-2018 11:47 ]

[Verwijderd]

Dexs schreef op zaterdag 10 maart 2018 @ 11:46:
[...]


Dat is niet helemaal (helemaal niet?) waar: https://www.nu.nl/interne...te-storingen-in-2017.html

ABN is 3 keer zo lang onbereikbaar geweest dan de Rabo(nr2) in 2017

Neem aan dat je ook het laatste stukje over DDoS gelezen hebt in het nu.nl artikel? Het is ieder geval nu dus geen storing bij de ABN zelf maar een invloed van buitenaf. Dan blijft wel de vraag open, kunnen ze hier echt niks aan doen al dan niet met andere partijen of willen ze er niks aan doen of kost het teveel?

[pjot1]

Dexs schreef op zaterdag 10 maart 2018 @ 11:46:
[...]


Dat is niet helemaal (helemaal niet?) waar: https://www.nu.nl/interne...te-storingen-in-2017.html

ABN is 3 keer zo lang onbereikbaar geweest dan de Rabo(nr2) in 2017

Ddos is geen storing.

[ Voor 8% gewijzigd door pjot1 op 10-03-2018 11:54 ]

[pjot1]

Dexs schreef op zaterdag 10 maart 2018 @ 11:46:
[...]


Dat is niet helemaal (helemaal niet?) waar: https://www.nu.nl/interne...te-storingen-in-2017.html

ABN is 3 keer zo lang onbereikbaar geweest dan de Rabo(nr2) in 2017

Oeps dubbel...

[ Voor 4% gewijzigd door pjot1 op 10-03-2018 11:53 ]

[MAX3400]

Verwijderd schreef op zaterdag 10 maart 2018 @ 11:41:
[...]


Denk dat je dit meer op een niveau van ISP's en AMS-IX moet gaan aanpakken, buitenlandse ip's weren naar betreffende sites op het moment van DDoS aanvallen. Maar heb te weinig inzicht naar de mogelijkheden hiervan. Daarnaast zou er wereldwijd veel meer aan botnets gedaan moeten worden d.m.v. het afsluiten van internetverbindingen waarop apparaten actief zijn die onderdeel van een botnet zijn.

Geloof niet dat je helemaal doorhebt hoe het internet werkt?

Een botnet is juist een slapend leger van machines wat op een bepaald moment aktief wordt. Dit kunnen er veel zijn maar het kunnen er ook "een handje vol" zijn. Als deze machines inderdaad deelnemen aan een DDoS, is de allereerste stap: zorg dat het verkeer niet aankomt bij de ontvanger. Een botnet ontmantelen/blokkeren komt soms pas dagen, weken of nog langer nadat de machines misbruikt zijn.

Daarnaast, een beetje aanval is niet lastig en met 1000 IP's kan je een hele mooie amplification-attack uitvoeren. Als je weet dat er grofweg 4 miljard IPv4 adressen zijn en een bijna oneindig veelvoud aan IPv6 adressen, waarom denk je dat "het blokkeren op AMS-IX" een strak plan is? Sterker nog, als je 1000 botnet-machines gebruikt die fysiek in bijvoorbeeld Apeldoorn staan en het getroffen datacenter van ABN staat toevallig in Amersfoort, dan is er een zeeeeer grote kans dat de AMS-IX niet eens gebruikt wordt om het verkeer van Apeldoorn naar Amersfoort te sturen. Internet is, waar mogelijk, het verkeer van het minst aantal hops.

[Verwijderd]

MAX3400 schreef op zaterdag 10 maart 2018 @ 11:54:
[...]

Geloof niet dat je helemaal doorhebt hoe het internet werkt?

Een botnet is juist een slapend leger van machines wat op een bepaald moment aktief wordt. Dit kunnen er veel zijn maar het kunnen er ook "een handje vol" zijn. Als deze machines inderdaad deelnemen aan een DDoS, is de allereerste stap: zorg dat het verkeer niet aankomt bij de ontvanger. Een botnet ontmantelen/blokkeren komt soms pas dagen, weken of nog langer nadat de machines misbruikt zijn.

Daarnaast, een beetje aanval is niet lastig en met 1000 IP's kan je een hele mooie amplification-attack uitvoeren. Als je weet dat er grofweg 4 miljard IPv4 adressen zijn en een bijna oneindig veelvoud aan IPv6 adressen, waarom denk je dat "het blokkeren op AMS-IX" een strak plan is? Sterker nog, als je 1000 botnet-machines gebruikt die fysiek in bijvoorbeeld Apeldoorn staan en het getroffen datacenter van ABN staat toevallig in Amersfoort, dan is er een zeeeeer grote kans dat de AMS-IX niet eens gebruikt wordt om het verkeer van Apeldoorn naar Amersfoort te sturen. Internet is, waar mogelijk, het verkeer van het minst aantal hops.

Heb zeker wel een idee hoe internet werkt, en ik stel ook niet dat alles voorkomen kan worden. Als de bots in NL staan, ja dan ga je niet veel kunnen op AMS-IX, maar een provider zou dat mogelijk wel weer kunnen. We kunnen ook niks doen, maar dat is ook geen oplossing. En uiteraard het beste is om het bij de bron aan te pakken, en zorgen dat apparaten geen onderdeel van een botnet worden.

Maar om nog even mijn voorbeeld aan te halen van AMS-IX, stel er worden 1000 ip's vanuit het buitenland gebruikt om ABN aan te vallen, de site ligt plat. Blokkeer op dat moment op AMS-IX toegang vanuit het buitenland naar de ip's van de ABN, of anders doe dit bij de ISP. En dit hoeft niet voor elke site te gebeuren, je kan dit voorbehouden aan echt belangrijke sites zoals banken, overheidsinstellingen e.d.

[MAX3400]

Verwijderd schreef op zaterdag 10 maart 2018 @ 12:06:
[...]

...stel er worden 1000 ip's vanuit het buitenland gebruikt om ABN aan te vallen, de site ligt plat. Blokkeer op dat moment op AMS-IX toegang vanuit het buitenland naar de ip's van de ABN, of anders doe dit bij de ISP.

Een goede DDoS hoeft niet lang te duren en doordat botnets ook VPN-connecties gebruiken, is het niet direct mogelijk om de originating ISP aan te spreken. Sterker nog; jij en ik hebben 100% legaal de mogelijk om, bij enig inlezen, over 1 uur zomaar 200 verschillende IP's te "gebruiken" all over the world. Als we op elk IP een VPN-server installeren, heb ik dus 200 IP's die niet direct bij een ISP horen en waar het toezicht/acteren ook niet erg hoog op hoeft te zijn.

Andersom; het aantal connecties naar een groot knooppunt als AMS-IX is bizar hoog. Kijk naar de stats; er gaat tot 5Tbit over de infra. Voor een DDoS tegen de ABN heb je, pak 'm beet, zeer tijdelijk enkele Gbit aan traffic nodig. Ook hier weer; druppel op gloeiende plaat en amper te controleren. Ik durf zelfs te stellen; het aantal IP-adressen wat per seconde "lief" iets wil hebben van ABN t.o.v. het aantal IP-adressen wat "boos" iets wil van de ABN, heeft een dusdanige verhouding, dat als je alle traffic naar ABN blokkeert, meer dan 95% van al het legitieme verkeer ook geblokkeerd wordt.

[Dexs]

Verwijderd schreef op zaterdag 10 maart 2018 @ 11:51:
[...]


Neem aan dat je ook het laatste stukje over DDoS gelezen hebt in het nu.nl artikel? Het is ieder geval nu dus geen storing bij de ABN zelf maar een invloed van buitenaf. Dan blijft wel de vraag open, kunnen ze hier echt niks aan doen al dan niet met andere partijen of willen ze er niks aan doen of kost het teveel?

Jazeker, ik snap dat een bank niets kan doen aan een ddos aanval. Ik neem aan dat ze het niet zelf doen namelijk. Opvallend is wel dat de ABN bij uitstek het meeste last er van heeft. Zegt nog steeds niets over de ABN, maar ze staan wel hoog op de lijst van de aanvallers. Waarom wordt de ABN veel vaker/langer aangevallen dan andere banken?

pjot1 schreef op zaterdag 10 maart 2018 @ 11:52:
[...]


Ddos is geen storing.

Klopt, maar het artikel lijkt ddos aanvallen wel mee te nemen in de downtime van de bank.

[ Voor 13% gewijzigd door Dexs op 10-03-2018 12:28 ]

[Verwijderd]

MAX3400 schreef op zaterdag 10 maart 2018 @ 12:15:
[...]

Een goede DDoS hoeft niet lang te duren en doordat botnets ook VPN-connecties gebruiken, is het niet direct mogelijk om de originating ISP aan te spreken. Sterker nog; jij en ik hebben 100% legaal de mogelijk om, bij enig inlezen, over 1 uur zomaar 200 verschillende IP's te "gebruiken" all over the world. Als we op elk IP een VPN-server installeren, heb ik dus 200 IP's die niet direct bij een ISP horen en waar het toezicht/acteren ook niet erg hoog op hoeft te zijn.

Andersom; het aantal connecties naar een groot knooppunt als AMS-IX is bizar hoog. Kijk naar de stats; er gaat tot 5Tbit over de infra. Voor een DDoS tegen de ABN heb je, pak 'm beet, zeer tijdelijk enkele Gbit aan traffic nodig. Ook hier weer; druppel op gloeiende plaat en amper te controleren. Ik durf zelfs te stellen; het aantal IP-adressen wat per seconde "lief" iets wil hebben van ABN t.o.v. het aantal IP-adressen wat "boos" iets wil van de ABN, heeft een dusdanige verhouding, dat als je alle traffic naar ABN blokkeert, meer dan 95% van al het legitieme verkeer ook geblokkeerd wordt.

Begrijp wat je bedoeld, maar op het moment dat je bij een aanval alle buitenlandse ip's blokkeert richting de abn site, dan zou dat kunnen helpen. Ja je blokkeert dan ook legitiem verkeer, maar als de site anders plat zou liggen kwamen die legitieme bezoekers er ook al niet. De bezoekers uit NL met dus een NL ip zouden er dan wel bij kunnen.

[ Voor 65% gewijzigd door Verwijderd op 10-03-2018 12:28 ]

[Firesphere]

Het maakt niet uit wat de aanval is, het feit dat IP-spoofing mogelijk is, is het zwakste punt in het hele internet.

Als dat opgelost wordt, is de tijd van anonieme DDoS voorbij. https://blog.cloudflare.c...f-large-ddos-ip-spoofing/

Zolang network layers het toestaan om variabelen aan te passen zonder consequenties, zullen we moeten leren leven met deze situaties. Leuk? Nee. Nodig? Nee.

[MAX3400]

@Verwijderd het zou een stuk slimmer zijn, maar weer iets met regelgeving en/of concurrentie: alle banken gooien hun infra in dezelfde datacenters, zeg even 4 lokaties, en aangesloten op dus 4 verschillende IX. Deze 4 lokaties via GLSB aan elkaar koppelen. En op de RIPE-blocks van de banken een andere oplossing loslaten zoals CloudFlare-achtige zaken.

Het eerste voordeel wat je hebt (of kan realiseren); zodra er ongewenst verkeer wordt aangeboden aan bank A, zal CloudFlare hier al iets aan afvangen. Door het verkeer zsm te routeren naar datacenter 1 (dus legitiem doorlaten door de ABN bijvoorbeeld), zal alleen datacenter 1 last hebben en kan de rest van het verkeer naar DC2 t/m DC4 doorgang vinden.

Verder werken de banken dus gedeeltelijk samen; de rest heeft "automagisch" meteen een blacklist van de IP's die ongewenst verkeer aanbieden en zijn dus niet ook direct offline als er van die IP's verkeer naar hun wordt gestuurd. Bot gezegd een dynamische "drop traffic" rule en klaar.

Maar ja, ik ben ook maar een simpele ICT'er die absoluut niet weet hoe e.e.a. in elkaar steekt

[McKaamos]

Verwijderd schreef op zaterdag 10 maart 2018 @ 12:27:
[...]


Begrijp wat je bedoeld, maar op het moment dat je bij een aanval alle buitenlandse ip's blokkeert richting de abn site, dan zou dat kunnen helpen. Ja je blokkeert dan ook legitiem verkeer, maar als de site anders plat zou liggen kwamen die legitieme bezoekers er ook al niet. De bezoekers uit NL met dus een NL ip zouden er dan wel bij kunnen.

Ik vind het wel grappig dat je zomaar de aanname maakt dat IP adressen blokkeren een simpele optie is.

Dat klinkt wel simpel, maar dat is het niet.
Als je dat gaat doen, moet je allereerst die IP adressen zien te identificeren. Dat kost tijd om te doen.
Dan moet er een lijst worden gedistribueerd naar alle knooppunten die in jouw buurt liggen. Die lijst verandert om de haverklap, want we praten over DDoS en over de mogelijkheid om van allerlei IP adressen te komen.
Dan moeten die lijsten op de routers van de knooppunten terecht komen om dingen te blokkeren. Mensenwerk en kost tijd.
De routers moeten dan alle traffic controleren en dus voor ieder packet in de lijst kijken. Die lijst is duizenden IP adressen lang, en voegt veel extra verwerkingstijd toe per packet. Die routers zijn na 2 minuten roodgloeiend en alle traffic die er langs komt vertraagt significant of raakt in time-out.
Hoe langer de lijst is, hoe meer rekenkracht het kost om per packet een match te doen.

Voor een klein aanvalletje vanaf 100 vaste IP adressen is het nog wel te doen. Maak er een paar duizend van die steeds wisselen, en het is onmogelijk bij te houden.
Dus nee, IP adresjes blokkeren is een praktische nachtmerrie om te moeten doen bij een DDoS aanval.

MAX3400 schreef op zaterdag 10 maart 2018 @ 12:36:
@Verwijderd het zou een stuk slimmer zijn, maar weer iets met regelgeving en/of concurrentie: alle banken gooien hun infra in dezelfde datacenters, zeg even 4 lokaties, en aangesloten op dus 4 verschillende IX. Deze 4 lokaties via GLSB aan elkaar koppelen. En op de RIPE-blocks van de banken een andere oplossing loslaten zoals CloudFlare-achtige zaken.

Het eerste voordeel wat je hebt (of kan realiseren); zodra er ongewenst verkeer wordt aangeboden aan bank A, zal CloudFlare hier al iets aan afvangen. Door het verkeer zsm te routeren naar datacenter 1 (dus legitiem doorlaten door de ABN bijvoorbeeld), zal alleen datacenter 1 last hebben en kan de rest van het verkeer naar DC2 t/m DC4 doorgang vinden.

Verder werken de banken dus gedeeltelijk samen; de rest heeft "automagisch" meteen een blacklist van de IP's die ongewenst verkeer aanbieden en zijn dus niet ook direct offline als er van die IP's verkeer naar hun wordt gestuurd. Bot gezegd een dynamische "drop traffic" rule en klaar.

Maar ja, ik ben ook maar een simpele ICT'er die absoluut niet weet hoe e.e.a. in elkaar steekt

Je beschrijft best wel heel sterk wat Cloudflare doet.
Gewoon een huge-ass serverpark (of naja, loadbalancer park in hun geval, op basis van NginX) ergens voor zetten met een ontiegelijke overcapaciteit aan bandbreedte.

Sodemieter je een DDoS tegen een Cloudflare-beschermde website aan, dan moet je eerst zien dat je hun overcapaciteit ziet vol te blaffen én ook nog alle hot-spare bijschakelende loadbalancers/proxies over de rooie te laten gaan.

Banken kunnen dat in princiepe ook doen als ze samen in een datacenter gaan zitten en zorgen dat ze:
1) Ontiegelijke overcapcaiteit hebben aan bandbreedte
2) Voldoende schaalbare loadbalancers (evt met hot-spares e.d.) op de rand van het netwerk parkeren.
3) Een simpel te managen systeem hebben om IP adres-blacklists te distribueren naar alle loadbalancers.

[ Voor 36% gewijzigd door McKaamos op 10-03-2018 12:43 ]

[MAX3400]

McKaamos schreef op zaterdag 10 maart 2018 @ 12:36:

Banken kunnen dat in princiepe ook doen als ze samen in een datacenter gaan zitten en zorgen dat ze:
1) Ontiegelijke overcapcaiteit hebben aan bandbreedte
2) Voldoende schaalbare loadbalancers (evt met hot-spares e.d.) op de rand van het netwerk parkeren.

Yup maar punt 1 is lastig; als bedrijf wil je graag je eigen IP-ranges aan de buitenkant. Die kan je niet zomaar "combineren" met andere bedrijven op dezelfde bandbreedte. Het "LAN -> WAN" trunken van hun bandbreedte is geen eenvoudige oplossing ondanks dat het inderdaad zou helpen als "WAN -> LAN" een zo groot mogelijke downstream heeft om het aantal malformed/illegal packets te kunnen huisvesten.

Ach, als we de oplossing hadden/hebben, zaten we niet op GoT hierover te babbelen maar hadden we het al verkocht aan elke bank ter wereld en zaten we met een biertje op een zonniger plekje te mijmeren over de goede oude tijd dat DDoS nog wel eens voor kwam

Een simpel te managen systeem hebben om IP adres-blacklists te distribueren naar alle loadbalancers.

Dat is toch impliciet besloten in een goede loadbalancer? Ze weten van elkaar wat er gaande is en pakken taken, rules en andere zaken over als eentje ermee kapt?

[ Voor 11% gewijzigd door MAX3400 op 10-03-2018 12:47 ]

[McKaamos]

MAX3400 schreef op zaterdag 10 maart 2018 @ 12:44:
[...]

Yup maar punt 1 is lastig; als bedrijf wil je graag je eigen IP-ranges aan de buitenkant. Die kan je niet zomaar "combineren" met andere bedrijven op dezelfde bandbreedte. Het "LAN -> WAN" trunken van hun bandbreedte is geen eenvoudige oplossing ondanks dat het inderdaad zou helpen als "WAN -> LAN" een zo groot mogelijke downstream heeft om het aantal malformed/illegal packets te kunnen huisvesten.

Ach, als we de oplossing hadden/hebben, zaten we niet op GoT hierover te babbelen maar hadden we het al verkocht aan elke bank ter wereld en zaten we met een biertje op een zonniger plekje te mijmeren over de goede oude tijd dat DDoS nog wel eens voor kwam

Ohh dat kan ook wel. Je kan meerdere IP's aan een interface hangen, dus je zou je eigen adressen op een gezamelijke loadbalancer kunnen zetten. Dat is niet zo'n groot issue eigenlijk.

Probleem is dat banken dan moeten samenwerken. Dat is meer een politiek spelletje dan fysieke onmogelijkheid.
Je kijkt gewoon voor een deel bij elkaar in de keuken en je leert dus wat over je concurentie.
Traffic is potentieel voor alle deelnemers inzichtelijk, dus je geeft gewoon geheimen bloot. Dat wil men niet.

Dat is toch impliciet besloten in een goede loadbalancer? Ze weten van elkaar wat er gaande is en pakken taken, rules en andere zaken over als eentje ermee kapt?

Niet per definitie. Dat moet wel ingericht zijn. Inclusief detectie systemen e.d.
Daar gaat meer tijd en werk in zitten dan je verwacht.
Niet onmogelijk, en in de praktijk ook best gangbaar als je wat gekwalificeerd personeel hebt zitten die dat kan inrichten.

[ Voor 14% gewijzigd door McKaamos op 10-03-2018 12:50 ]

[Dexs]

Zou je niet een systeem kunnen gebruiken dat automatisch een uitwijklocatie inzet bij een aanval waarbij alle inkomende verbindingen tijdens de aanval tijdelijk geblokkeerd worden op de uitwijk? Dan kunnen klanten die tijdens de aanval hebben in proberen te loggen ook niets op de uitwijk, maar kan de rest van het land iig snel weer verder. De aanvallers moeten dan nieuwe ips gebruiken om de aanval door te kunnen zetten.
Waarschijnlijk denk ik te simpel...

[ Voor 9% gewijzigd door Dexs op 10-03-2018 12:56 ]

[McKaamos]

Dexs schreef op zaterdag 10 maart 2018 @ 12:55:
Zou je niet een systeem kunnen gebruiken dat automatisch een uitwijklocatie inzet bij een aanval waarbij alle inkomende verbindingen tijdens de aanval tijdelijk geblokkeerd worden op de uitwijk? Dan kunnen klanten die tijdens de aanval hebben in proberen te loggen ook niets op de uitwijk, maar kan de rest van het land iig snel weer verder. De aanvallers moeten dan nieuwe ips gebruiken om de aanval door te kunnen zetten.
Waarschijnlijk denk ik te simpel...

Dat kan, maar hoe bepaal je dan welk verkeer uitwijkt en welk verkeer niet?
Je hebt nogsteeds een enorme overcapaciteit aan inkomende bandbreedte nodig en een griezelig grote lading aan routers en loadbalancers om al die traffic te filteren, zodat het legitieme verkeer naar de uitwijklokatie gaat.
En hoe bepaal je wat legitiem is als de IP adressen om de haverklap wisselen?

De enige oplossing is gewoon niet ondergesneeuwd raken.
Daarom doen clubs zoals Cloudflare het zo goed. Gewoon ontiegelijke overcapaciteit hebben zodat je klant niet ondergesneeuwd raakt in 'foute' traffic.

Uitwijklokaties zijn nuttig voor uitval van je primaire datacenter. Stel dat er brand uitbreekt ofzo.
Of een graafmachine knaagt door alle kabels die je datacenter in gaan.

Firesphere schreef op zaterdag 10 maart 2018 @ 12:32:
Het maakt niet uit wat de aanval is, het feit dat IP-spoofing mogelijk is, is het zwakste punt in het hele internet.

Als dat opgelost wordt, is de tijd van anonieme DDoS voorbij. https://blog.cloudflare.c...f-large-ddos-ip-spoofing/

Zolang network layers het toestaan om variabelen aan te passen zonder consequenties, zullen we moeten leren leven met deze situaties. Leuk? Nee. Nodig? Nee.

Wat je beschrijft is inderdaad een oplossing. Maargoed, we zitten ook al heel lang te wachten tot IPv6 groot wordt. Een dergelijke aanpassing aan infra moet backwards compatible zijn en is daarom ongelofelijk moeilijk om er door te krijgen op grote schaal.

Maargoed, stel dat we dat voor elkaar krijgen. Dan zijn Amplification/Reflection aanvallen verleden tijd.
Dan hebben we nogsteeds de aanvalsmogelijkheden op hogere OSI layers niet opgelost.
Denk b.v. aan Slow Loris. Puur gericht op Apache HTTPD, maar er zullen allicht andere soortgelijke methoden toepasbaar zijn op andere server software.

Slow Loris is in essentie een legitieme HTTP/HTTPS verbinding, waarbij je tergend langzaam bytes stuurt, zodat je een actieve sessie blijft houden.
De server zit constant te wachten op data en kan niet verder werken, en elke nieuwe verbinding die wordt gelegd is een nieuwe sessie.
De server kan maar een beperkte hoeveelheid gelijktijdige sessies aan. Op het gegeven moment zit er gewoon meer rekenwerk in het bijhouden van sessies dan in het daadwerkelijk uitserveren van een webpagina.
Op dat moment raakt je server onbereikbaar.

Lulligste is dat je al die sessies vanaf een mobieltje zou kunnen starten en bijhouden. Je hebt nauwelijks rekenkracht en bandbreedte nodig.
En het is verschrikkelijk moeilijk om te filteren.

Andere implementatie is RUDY. Een POST request doen en constant een druppeltje data sturen.
En de server zit maar te wachten tot de transactie afgerond is zodat de POST request eindelijk verwerkt kan worden. Tot die tijd hangt het in het RAM.
Doe je dat met genoeg clients, dan klapt de server onderuit wegens RAM tekort, als hij niet al onderuit is gegaan wegens teveel open sessies.

En ja, dat is uiteraard ook wel weer tegen te werken met een goed geconfigureerde server, maar het levert ook collateral damage op. Legitiem trage clients (mobieltje in het buitengebied of met slecht bereik?) worden dan gewoon afgekapt, wat klachten oplevert. Dus daar wil je niet te strict mee worden.

Dus stel dat de huidige DDoS methoden buiten gebruik gesteld kunnen worden, dan komen er écht wel nieuwe methoden die de werking van software exploiten om een server op z'n knieën te dwingen.
Het is gewoon wishfull thinking dat je de problemen oplost met een stricter transport protocol.

Edit:
Leuk kijkvoer.

[ Voor 68% gewijzigd door McKaamos op 10-03-2018 14:12 ]

[Thralas]

McKaamos schreef op zaterdag 10 maart 2018 @ 12:59:
Dat kan, maar hoe bepaal je dan welk verkeer uitwijkt en welk verkeer niet?

Op ASN. Dat is volgens mij dan ook de enige 'best effort' mitigatie tegen een fatsoenlijke DDoS.

Als je directe peerings hebt met de providers waar 90% van je internetbankierverkeer vandaan komt dan kun je bulk van de DDoS droppen met een (veel) beperktere impact op je services. Bijvoorbeeld Ziggo/Liberty Global en KPN.

Maargoed, stel dat we dat voor elkaar krijgen. Dan zijn Amplification/Reflection aanvallen verleden tijd.
Dan hebben we nogsteeds de aanvalsmogelijkheden op hogere OSI layers niet opgelost.

Dat blijft altijd een probleem. Maar dat is heel wat anders dan het feit dat momenteel iedere puber een bank kan platleggen met 0,0% technische kennis en enkel z'n zakgeld.

[Verwijderd]

Thralas schreef op zaterdag 10 maart 2018 @ 14:57:
[...]


Op ASN. Dat is volgens mij dan ook de enige 'best effort' mitigatie tegen een fatsoenlijke DDoS.

Als je directe peerings hebt met de providers waar 90% van je internetbankierverkeer vandaan komt dan kun je bulk van de DDoS droppen met een (veel) beperktere impact op je services. Bijvoorbeeld Ziggo/Liberty Global en KPN.


[...]


Dat blijft altijd een probleem. Maar dat is heel wat anders dan het feit dat momenteel iedere puber een bank kan platleggen met 0,0% technische kennis en enkel z'n zakgeld.

Wat je hier zegt vind ik eigenlijk best een goede oplossing voor belangrijke sites zoals banken. ISP's in Nederland krijgen direct peers, op het moment van een DDoS krijgen alleen nog deze directe peers toegang,
Het enige waar je dan nog voor moet zorgen is dat al het overige verkeer dat buiten de directe peers omgaat geweigerd moet worden, liefst bij ISP waar de bank is aangesloten.

In het geval dat een DDoS wordt opgezet over de directe peers, weet je wel waar je apparaten die onderdeel van het bot zijn moet zoeken, en kan dat in samenwerking met de NL ISP aangepast worden.

[Opi]

Volgens mij dekt het Trusted Networks Initiative de ideeën die hier genoemd worden. Dit initatief is uiteindelijk gestrand, maar meer informatie is o.a. hier te vinden.

[Thralas]

Opi schreef op maandag 12 maart 2018 @ 14:56:
Volgens mij dekt het Trusted Networks Initiative de ideeën die hier genoemd worden. Dit initatief is uiteindelijk gestrand, maar meer informatie is o.a. hier te vinden.

Blijkbaar was dit recentelijk ook nog in het nieuws: nieuws: AMS-IX wil Trusted Network Initiative na ddos-aanvallen nieuw leven i...

Met eronder een aantal interessante reacties van netwerkbeheerders met IX-kennis.

[ByteDelight]

Blijkbaar is het weer raak, al zeker een uur niet mogelijk website te bezoeken of smartphone-app te gebruiken.
Wel een realistische boodschap als je de site probeert te bereiken nu.

[ Voor 32% gewijzigd door ByteDelight op 24-05-2018 12:53 ]