Akamai ziet grootste ddos-aanval tot nu toe van 1,3 Tbps
Internetgigant Akamai heeft naar eigen zeggen de grootste ddos-aanval tot nu toe waargenomen met een omvang van 1,3 Tbps. Niet eerder zag Akamai een aanval waarbij zoveel dataverkeer werd verstuurd. De aanval, die twee keer groter was dan de recordaanval van het Mirai-botnet in september 2016 met 620 Gbps, was gericht tegen een softwareontwikkelingsbedrijf en maakte gebruik van memcached-servers.
Memcached is bedoeld om tijdelijk kleine hoeveelheden data op te slaan uit bijvoorbeeld databases om zo websites en webapplicaties sneller te maken. Wereldwijd zijn zo'n 100.000 publiek beschikbare memcached-systemen te vinden die middels ip-spoofing voor ddos-aanvallen zijn te gebruiken. Hierbij verstuurt een aanvaller gespoofte verzoeken met het ip-adres van de aan te vallen website naar de memcached-server. Doordat de antwoorden van de memcached-server veel groter zijn dan de verzoeken, kan een aanvaller met relatief weinig bandbreedte een grotere aanval op het doelwit uitvoeren. Dit word ook wel een amplificiatie-aanval genoemd.
In het geval van memcached is er sprake van een amplificatiefactor van meer dan 50.000. Een verzoek van 203 byte resulteert in een antwoord van 100 megabyte dat naar de aangevallen website wordt verstuurd. Vanwege de mogelijkheid om zulke grote aanvallen uit te voeren verwacht Akamai dat deze techniek bij veel meer aanvallen zal worden ingezet en er nog grotere aanvallen zullen plaatsvinden. Er is echter ook goed nieuws, zo stelt de internetgigant. Providers kunnen het verkeer op source-poort 11211 "rate limiten" en voorkomen dat verkeer hun netwerk betreedt of verlaat. Dit zal echter de nodige tijd in beslag nemen. Akamai werkt met andere industriepartners samen aan best practices om het memcached-probleem op te lossen.
Dan weten we in iedergeval waar die ddos aanvallen echt vandaan komen.
Ondanks dat dit filteren vrij simpel te doen is, wordt het nog te weinig toegepast.
Dan weten we in iedergeval waar die ddos aanvallen echt vandaan komen.
Ondanks dat dit filteren vrij simpel te doen is, wordt het nog te weinig toegepast.
Als ze gaan filteren gaan ze natuurlijk niet gebruikt worden voor zo'n aanvallen.
Je wilt het strenger maken zoals een politicus die het principe van het XY probleem niet kent.
Dat staat al fout in de bron. Maar als je verder doorzoekt is de originele bewering dat 203 byte 100MB kan genereren. Dus hebben ze òf die factor verkeerd berekend, òf die factor kwam uit een ander voorbeeld. (Dat dan niet de maximale versterking haalt)
Dan weten we in iedergeval waar die ddos aanvallen echt vandaan komen.
Ondanks dat dit filteren vrij simpel te doen is, wordt het nog te weinig toegepast.
Aan de ene kant willen we alle vrijheid op het internet, aan de andere wordt opgeroepen tot filteren.
Zie: https://tools.ietf.org/html/bcp38
Zie: https://tools.ietf.org/html/bcp38
ja ik heb dat inderdaad nooit echt begrepen waarom isps dit niet gewoonweg doen. zijn daar redenen voor te verzinnen?
https://www.agconnect.nl/artikel/ams-ix-heeft-oplossing-ddos-probleem-banken
ja ik heb dat inderdaad nooit echt begrepen waarom isps dit niet gewoonweg doen. zijn daar redenen voor te verzinnen?
Egoisme. Met BCP38 bescherm je ANDEREN tegen attacks. Als iedereen het doet is iedereen beschermd, maar het
zelf inrichten beschermt jezelf niet. Helaas redeneren veel bedrijven: we gaan zelf geen moeite doen (en risico lopen om
fouten te maken) als we er zelf niks aan hebben.
Dus 10.4 MB
Zie: https://tools.ietf.org/html/bcp38
ja ik heb dat inderdaad nooit echt begrepen waarom isps dit niet gewoonweg doen. zijn daar redenen voor te verzinnen?
De voornaamste reden is een combinatie van kennisgebrek (over nut/noodzaak, en mogelijkheden op de betreffende apparatuur), en een zeker risico op storingen _bij_ de ISP als het niet goed gedaan wordt of niet bijgehouden wordt.
Daarnaast ontbrak in vroeger tijden op apparatuur de features om het 'automatisch' te doen, of was er de terechte of onterechte vrees dat het veel overhead zou geven.
Je moet niet onderschatten hoe lang technische folklore kan blijven rondzingen, ook al bestaat het probleem al decennia niet meer. [denk : ethernet linkspeed hard instellen ]. Dergelijke folklore over overhead van packetfiltering kan ook heel lang rondzingen.
Een deel van de ISPs wordt gerund door mensen die nét genoeg weten om de boel draaiend te houden en vooral niks durven te veranderen - en niet eens _weten_ dat spoofing een probleem kan zijn.
BCP38 is technisch vrij makkelijk bij pure access providers, en verderop vrijwel onmogelijk .
Maar je moet de keus wel bewust maken en meenemen in je design en tooling.
ja ik heb dat inderdaad nooit echt begrepen waarom isps dit niet gewoonweg doen. zijn daar redenen voor te verzinnen?
Egoisme. Met BCP38 bescherm je ANDEREN tegen attacks. Als iedereen het doet is iedereen beschermd, maar het
zelf inrichten beschermt jezelf niet. Helaas redeneren veel bedrijven: we gaan zelf geen moeite doen (en risico lopen om
fouten te maken) als we er zelf niks aan hebben.
je beschermt ook jezelf of een klant in je eigen netwerk: stel je hebt een aantal IoT myranet zombies ter beschikking in een ISP netwerk en een target die ook in dat netwerk zit. met de memcached amplificatie servers in het eigen netwerk en daarbuiten, krijg je de target nog steeds DOSed. met BCP38 niet meer als je het goed per subnet ingress filterd. een vrij statische router configuratie die je slecht eenmalig in hoeft te stellen en zolang je IP space niet veranderd heb je bescherming.
Zie: https://tools.ietf.org/html/bcp38
ja ik heb dat inderdaad nooit echt begrepen waarom isps dit niet gewoonweg doen. zijn daar redenen voor te verzinnen?
Bijvoorbeeld technieken als AnyCast zijn dan niet meer mogelijk
Bijvoorbeeld technieken als AnyCast zijn dan niet meer mogelijk
waar die server gehost is, na overleg met de "eigenaar" van het adres uiteraard.
Ik denk dat we snel toe moeten naar de situatie waarbij je als je als access of hostiing provider geen BCP38 doet
als paria gezien wordt net zoals je 20 jaar geleden een paria werd als je een open relaying SMTP server had.
(terwijl dat voor die tijd heel normaal was om te hebben)
Zie: https://tools.ietf.org/html/bcp38
ja ik heb dat inderdaad nooit echt begrepen waarom isps dit niet gewoonweg doen. zijn daar redenen voor te verzinnen?
Bijvoorbeeld technieken als AnyCast zijn dan niet meer mogelijk
Dat is onzin.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
