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.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.