OVHcloud slaat record-ddos-aanval van 840 miljoen packets per seconde af

OVHcloud zegt dat het een van de grootste bekende ddos-aanvallen ooit heeft afgeslagen. De cloudprovider zegt een packetrateaanval te hebben gezien die piekte op 840 miljoen packets per second. Het bedrijf zegt dat er steeds vaker grote packetrateaanvallen voorkomen.

OVHcloud zag de aanval in april, maar noemt die nu pas in een blogpost over de opkomst van packetrate-ddos-aanvallen. Dat zijn aanvallen waarbij met name tcp-packets worden ingezet om een netwerk te overladen met voornamelijk kleine stukjes data, in tegenstelling tot veel andere ddos-aanvallen waarbij vaak grotere pakketten worden verstuurd. "Packetrateaanvallen zijn effectief omdat het vaak veel moeilijker is met veel kleine packets om te gaan dan met grotere pakketten in kleiner volume", schrijft OVHcloud. Het bedrijf zegt dat het de afgelopen maanden dergelijke aanvallen vaker ziet voorkomen, maar dat de meeste van die aanvallen niet boven de 100 miljoen packets per second, of mpps, uitkomen.

"We gingen van een paar van zulke aanvallen per week naar tientallen of zelfs honderden per week", zegt het bedrijf. "We hebben meerdere aanvallen van 500+ mpps in het begin van 2024 moeten afslaan, waaronder een die piekte op 620 mpps. In april ging het om een aanval van 840 mpps."

Volgens OVHcloud komen de packets uit die aanvallen van zo'n 5000 IP-adressen. Het bedrijf wijst naar MikroTik-routers die openbaar benaderd zijn en die volgens hen worden misbruikt door een botnet. Het is niet duidelijk of dat het Mirai-botnet is, dat een van de bekendste botnets is dat aanvallen van meerdere terabits per seconde aan data kan uitvoeren.

OHVcloud ddos

Door Tijs Hofmans

Nieuwscoördinator

05-07-2024 • 15:19

43

Submitter: wildhagen

Reacties (43)

Sorteer op:

Weergave:

Met andere woorden: RouterOS is niet te vertrouwen?
Ligt niet zozeer aan het OS natuurlijk, maar meer aan de beheerders van die routers die het admin-panel publiek beschikbaar stellen via het Internet. Dat zijn dan beheerders die niet heel slim bezig zijn, want dit soort panels stel je niet publiek beschikbaar doorgaans, conform best practices. Het et eerste wat je bij configureren van dit soort routers doet is die publieke access uitschakelen.

Idem voor het patchen van het lek (die patch is er immers gewoon) in die routers, dat doen veel beheerders helaas ook niet of nauwelijks. Dan zit je dus met vulnerable devices die óók nog eens een publiek toegankelijk admin panel hebben staan.

Ja, dan kan je net zo goed een bordje 'Please, hack me!!!' ophangen in neon-verlichting.

Dat is niet primair de fout van de router, of het OS erop, maar van de beheerder ervan. Die is laks met zijn beveiligings- en patch-beleid.

[Reactie gewijzigd door wildhagen op 22 juli 2024 23:23]

Uit de recente documentatie van MicroTik maak ik op dat de toegang tot het admin panel standaard geen wachtwoord heeft en ook geen geforceerde instelling van een wachtwoord eist bij het eerste en volgende gebruik. Dat voldoet wat mij betreft absoluut niet aan een behoorlijke minimale beveiliging door de leverancier.

Ook lees ik niet terug dat er beveiliging is tegen opportunistische aanvallen via het interne netwerk op de admin service. Terwijl de laatste versies van de firmware kennelijk op een deel geinstalleerd zijn en daarbij van de leverancier een stresstesttool meer mogelijkheden hebben gegeven om verkeer naar het internet flink uit te kunnen breiden.

Hoewel ik het er geheel mee eens ben dat de eigenaar een verantwoordelijkheid heeft het apparaat behoorlijk te configureren kunnen we natuurlijk niet net doen alsof de leverancier dan maar standaard wel gelegenheid mag geven voor te verwachten aanvallen.

Het zal me niets verbazen als deze ddos-aanval komt door criminelen die gebruik proberen te maken van standaard mogelijkheden, in plaats van slechts gebrekkig beheer. Bijvoorbeeld via CSRF-aanval.
Uit de recente documentatie van MicroTik maak ik op dat de toegang tot het admin panel standaard geen wachtwoord heeft en ook geen geforceerde instelling van een wachtwoord eist bij het eerste en volgende gebruik. Dat voldoet wat mij betreft absoluut niet aan een behoorlijke minimale beveiliging door de leverancier.
Dit was vroeger het geval, maar sinds een aantal jaar staat er standaard gewoon een (willekeurig) wachtwoord op en krijg bij inloggen als eerste een melding om deze te wijzigen.
Heb je daar een bron voor? Want ik kom zowel in de security manual als recente blogposts het tegendeel tegen.

Als het tegenwoordig wel een willekeurig wachtwoord heeft zal dat helpen. Al stelt het me niet gerust als de documentatie dan kennelijk een aantal jaar achter zou lopen en dit er dus op kan wijzen dat dit nog niet standaard doorgevoerd is.

Daarbij is nog een probleem dat updaten niet zomaar gevolgen (zoals inbraak en toegang) door eerdere gebreken ongedaan maakt. Terwijl dit apparatuur is die jaren lang in gebruik kan zijn. En ook daar lijkt weinig duidelijkheid over.
Apparaten die met RouterOS v6 uit de fabriek zijn gekomen en de datacenter routers (zoals genoemd in het artikel) hebben standaard geen wachtwoord. Recent geproduceerde home routers met RouterOS v7 zijn voorzien van een sticker met willekeurig wachtwoord. Daar zullen de conflicterende berichten vandaan komen. In RouterOS v6.49 (06-10-2021) werd het verplicht om een leeg wachtwoord te veranderen bij de eerste keer inloggen.

Home routers komen met een standaard configuratie en firewall, maar datacenter routers (in het artikel) niet omdat daar de use-cases te uiteenlopend zijn. Het is dan aan de beheerder om hier een veilige configuratie in te zetten. Niet alleen een firewall, maar ook routing, DHCP, VPN, enz. Als die kennis onvoldoende aanwezig is... tsja... dan gaat het fout.

Bron: eigen ervaring als MikroTik consultant, de changelogs en de forums
Maar het apparaat wat jij beschrijft mag in Nederland niet eens verkocht worden.
op technische apparaten met standaard een remote login moet een niet statisch wachtwoord zitten.
De datacenter routers hebben geen configuratie, alleen een standaard statisch IP-adres 192.168.88.1 op ether1 of de poort gemarkeerd met "BOOT". Zonder aanvullende configuratie is alleen lokaal beheer mogelijk.
Ik heb zelf een Mikrotik en het is zeker geen apparaat voor beginners. Als je niet weet wat je doet is de kans zeer aannemelijk dat je zaken verkeerd configureert en open zet voor de buitenwereld.
Dan zou het prettig zijn dat Mikrotik zelf een template beschikbaar stelt waarmee bepaalde minimum beveiliging wordt ingeschakeld. Zoals bijvoorbeeld Security Defaults in Entra. En dat de Security Baseline ook wordt bijgewerkt met nieuwe technieken, zoals bijvoorbeeld phishing resistant.
Die hebben ze en deze staat in de docs: Default configurations. Even zoeken op het juiste model (bijv. hAP is een populaire home router), het script plakken in System -> Scripts en vervolgens uitvoeren.

Home routers zijn standaard voorzien van een veilige basisconfiguratie en firewall, maar je moet wel enige kennis hebben voordat je zelf aanpassingen maakt want anders zet je onbedoeld zaken open voor de buitenwereld.
Ik ben van mening dat Mikrotik eerder voor prosumers en bedrijven is.

De doorsnee consument is helemaal niet op zoek naar dit niveau van configuratie. Die wil gewoon zo'n ding inpluggen, wifi instellen en heel misschien es een keer een poort forwarden.
maar meer aan de beheerders van die routers die het admin-panel publiek beschikbaar stellen via het Internet.
Waarom is dat überhaupt mogelijk?
Dat is niet primair de fout van de router, of het OS erop, maar van de beheerder ervan. Die is laks met zijn beveiligings- en patch-beleid.
Jij hebt het keer op keer over wiens fout het was in plaats van over wie had wat kunnen doen om het te voorkomen.

[Reactie gewijzigd door Olaf van der Spek op 22 juli 2024 23:23]

Ik vind eerder dat jij de verantwoordelijkheid bij de verkeerde legt. Het is niet aan de fabrikant om dit te voorkomen omdat er scenario's zijn waarin je dit kan gebruiken. Helemaal bij RouterOS.

Je leest het misschien alsof het één vinkje is waar je dit mee aanzet maar dit zal een ongelukkige NAT/Firewallregel zijn geweest die per ongeluk is aangezet.
Je leest het misschien alsof het één vinkje is waar je dit mee aanzet maar dit zal een ongelukkige NAT/Firewallregel zijn geweest die per ongeluk is aangezet.
Dat zou nog kunnen als het om enkele devices ging.

Echter, als je de uitleg van OVHcloud leest van hun blogpost:
In order to understand which kind of routers were involved, we recovered the 3,000 IPs involved in the attack. Past investigations shown approximately 700 IPs identified as MikroTik routers and exposing the port TCP/8291.
(op https://blog.ovhcloud.com...n-core-routers-turn-evil/)

Dan lijkt het me toch statistisch erg onwaarschijnlijk dat exact diezelfde firewall regel bij 700 routers, die verspreid over de hele wereld staan bij meerdere bedrijven, ten eerste aangemaakt en ten tweede enabled is op de externe/publieke firewall van de betrokken bedrijven waarvan de MicroTik-routers bij deze aanval betrokken zijn.

[Reactie gewijzigd door wildhagen op 22 juli 2024 23:23]

Ik snap je punt maar helaas is het niet zo simpel als je stelt.
Ik heb zelf ook meerdere Mikrotik routers die ik gebruik als internet toegangspunt en dus ook de hoofd firewall zijn.
Omdat RouterOS zo enorm uitgebreid is, is het ook erg makkelijk om een situatie over het hoofd te zien. Je kunt werken interfaces, (dynamic) lists, IP's en nog veel meer, maak een foutje in je list of vergeet een interface te koppelen aan je firewall regel en daar ga je al de mist in. Daarnaast heb je niet alleen opties voor NAT firewall zoals meeste thuis routers maar ook voor andere firewall opties zoals mangle, filtering en raw. Omdat je zoveel kunt inregelen en je helemaal kan uitleven moet je wel goed het geheel overzien om geen fouten te maken.

Uiteraard blijft het dom om de admin interface en andere beheer poorten open te zetten naar het internet zonder extra maatregelen, dat is vragen om problemen. Uit ervaring die ik met Mikrotik heb is de admin internface standaard niet benaderbaar vanaf de WAN kant en is het dus een configuratie fout van de beheerder.
Vreemd dat OVH specifiek de CCR modellen van Mikrotik noemt, mogelijk zit daar een andere default config in of misschien een bug waardoor beheerders het niet doorhebben?

Het zou mooi zijn als OVH de ISP's een lijst kan aanleveren van hun klanten waarbij dit gebeurt en dat de ISP de klant hier vervolgens over informeert dat de aansluiting waarschijnlijk wordt misbruikt met tips om dit te voorkomen (er vanuit gaande dat het immers onbewust is). Daarmee bedoel ik dat de ISP de informatie controleert en doorspeelt naar de eind gebruiker en niet zoals bijvoorbeeld stichting Brein wenst om ook de klant gegevens in handen te krijgen.
Zie het als een abuse mail adres die webhosts vaak ook aanbieden voor dit soort doeleinden.

[Reactie gewijzigd door bastiaansmit199 op 22 juli 2024 23:23]

Wat ik begrijp aan dat mirai botnet, is het malware is dat apparaten op het netwerk van de geinfecteerde machine probeert te annexeren. Hier kom je dus op de LAN poorten van de routers terecht.
Dus van binnenuit worden de routers ingezet als bot node.
Home / Residential routers van MikroTik zijn standaard voorzien van een basis firewall configuratie. De datacenter / core routers uit het artikel zijn dit standaard niet, omdat deze veelal forwarding doen voor o.a. ISP's en een firewall dan niet wenselijk is en/of vertragend werkt (met uitzondering van de management laag uiteraard). Het is de taak van de beheerder om hier een veilige configuratie in te zetten en als die kennis ontbreekt... tsja... dan krijg je dit.

[Reactie gewijzigd door Great-Force op 22 juli 2024 23:23]

Bij de instellingen van de admin interfaces zelf zitten ook instellingen om te beperken welke IP's kunnen verbinden met deze interfaces. Ik gebruik dit als een extra laag samen de firewall om te beperken wie/wat er kan verbinden met de admin-interfaces.
Als jij een wagen koopt en laat je de die open en de sleutels op de zetel liggen, en dan wordt hij gestolen, dan is dat toch jouw fout en niet de fout van de constructeur van de wagen ?

Ik ben het ermee eens dat ze dat beter niet open zouden zetten en iets willekeurig's op elk toestel zetten. Maar zo zijn er genoeg dingen die een default wachtwoord krijgen ... en waarbij 90% dat niet gaat wijzigen of de manual zelfs lezen. Dus waar ligt de fout dan ? Willekeurig is moeilijker omdat je bij elk product een andere code moet zetten en kost veel meer tijd en geld. Een default is dan al vlug een optie ... en dat is net hetzelfde als gewoon niks instellen
Als jij een wagen koopt en laat je de die open en de sleutels op de zetel liggen, en dan wordt hij gestolen,
Auto’s die jij nu koopt gaan vanzelf op slot als je ver genoeg weg bent of na x tijd. Dus je vergelijk gaat mank.

[Reactie gewijzigd door CrankyGamerOG op 22 juli 2024 23:23]

Als je de sleutel laat liggen gaat die wagen ook niet volledig sluiten hoor ... Weet ik uit ervaring omdat ik meerdere malen hier thuis al mijn sleutels in de wagen vergeten ben. Er zal geen alarm afgaan hoor. Want de sleutel is aanwezig
Uit het artikel:
Since we still don’t know what kind of vulnerability has been leveraged to compromise these device models, we can’t say yet whether other CCR models could be compromised as well or not. Nonetheless, exposing the administration panel on the Internet remains a big risk for the security of the device though.
Vooral het administration panel exposen is niet te vertrouwen, lijkt me... straf....
Zolang je firewall goed ingesteld staat is er niets aan de hand. Alleen bij RouterOS kan je sneller een fout maken dan bij Fritzbox of Draytek
Ze hebben er een patch voor gemaakt maar dat betekend blijkbaar niet dat iedereen die dingen ook echt update.
Eigenlijk zou de service provider ze van het internet af moeten knikkeren, of de service provider zelf moet eraf. Spoofen is niet mogelijk met een service provider die zijn werk doet.
Eigenlijk zou de service provider ze van het internet af moeten knikkeren, of de service provider zelf moet eraf. Spoofen is niet mogelijk met een service provider die zijn werk doet.
Dat die veel providers ook. Zeker in Nederland krijg je bij het minste vermoeden al een quarantaine melding van je provider. Maar het is in andere landen niet altijd zo goed geregeld.
Klein beetje hypocriet. Ik zie nl. best veel netwerk scans vanuit OHV.
Komen die van OVH zelf, of van hun klanten vanaf een bij OVHcloud gehoste server? Want daar heeft OVH uiteraard geen directe invloed op.

Daarnaast is er nogal een verschil tussen een netwerkscan (die in principe legitiem kan zijn, denk aan pen-tests etc), of een DDoS-aanval zoals deze (die per definitie niet legitiem is).

En ik vermoed dat je het bij een reguliere netwerkscan niet over 840 miljoen packets per seconde hebt...

Dat is dus een beetje appels met peren vergelijken op die manier.
Vandaar dat ik “klein beetje” zei. Natuurlijk is een kwaadwillende netwerkscan wat anders dan ddos. Ik had er een smiley achter moeten zetten, zoiets 8-) .
?
Scannen is toch wat anders dan met terabits over je router heen walsen.
Joh, echt? Maar beiden zijn een abuse waard. En daar reageert OVH niet op, net als Linode e.a.
Ik snap de hypocrisie niet. OVH zou het in dat geval zelf doen, maar dat doen zij niet dat doen enkele gebruikers. Mijn ervaring is dat er best wel wordt geluisterd door OVH naar abuse klachten.
Ik zei ook “klein beetje”. En mijn ervaring met abuse klachten bij OVH is anders. Geen reactie.
Eigenlijk zou elke router fabrikant by default toegang via de WAN side moeten blokkeren...
en als de beheerder / gebruiker er wel bij wil komen via de WAN side dat je niet met 1 simpel vinkje plaatsen hem open kan zetten....

maar 2.. 1tje bijwijze bij het wachtwoord beheer en 1tje bij general of WAN settings..
Nog niet zo lang geleden wat het bij F5's ook prijs. Raar maar waar, maar een F5 had (heeft?) standaard geen ACL op de beheersinterface voor niet RFC1918 adressen 8)7 Wetende dat het zowat de meest geavanceerde applicatie proxy/firewalls zijn, ik viel achterover.
Bij de meest geavanceerde apparatuur wordt ook verwacht dat een kundige admin het geheel beheerd.

Het minimale vind ik dat als je zo een apparaat online gooit je nagaat of het geheel hoed dicht staat, door bijvoorbeeld zelf een portscan tegen de IPs uit te voeren.

Maar ja, er zullen zat beheerders zijn die dat niet doen.
Net daarom dat je als vendor beter de slimste bent... veronderstellingen zijn de basis van veel problemen tegenwoordig.
Het eerste Nederlandse woord met drie d's achter elkaar... "recordddos” :D

[Reactie gewijzigd door jj71 op 22 juli 2024 23:23]

Wat een prestatie zowel voor OVH als het wereldwijde infrastructuur. Vet dat OVH hier tegen voorbereid is, maar het is eerst door van alles heen gegaan om überhaupt bij OVH aan te komen.
Ik las in de gelinkte blog dat ze ook attacks zien met terabits/s aan data, lastig voor te stellen hoeveel dat nu is.

Als OVH klant krijg ik wel eens een mailtje als een van mijn services wordt aangevallen door een ddos, mijn servers zijn geen specifiek groot target (gelukkig), maar ze hebben de aanvallen altijd kunnen mitigaten.
En dat met ddos bescherming die inclusief komt met de services, net zoals bij vele andere hosting bedrijven.
Voor mij een van de redenen om weg te blijven van serverless and providers gebaseerd op bandwidth; de horror verhalen die ik op twitter zie langskomen over giga rekeningen bij cloudflare en vercel bij users die niet goed hun limiet hebben ingesteld, of users die wel hun limiet goed hebben ingesteld en waarvan hun service gewoon uitgeschakeld worden... Ik moet er niet aan denken.
Ik blijf wel lekker bij dedi boxjes.
Ik snap niet dat je met een 5000 tal routers aan dat soort aantallen geraakt. Zouden er niet groot deel servers tussen zitten? Of moet ik eerder denken aan commerciele MicroTik routers die voor grote kantoren of datacenters gebruikt worden?
Het is eenvoudiger dan dat je denkt, het helpt natuurlijk ook niet dat ze op het Youtube kanaal van Mikrotik zelf uitleggen hoe je een DDOS met een van hun routers moet doen.
Dat het eenvoudig is geloof ik best. Mijn vraag gaat over de kracht van zo'n aanval en waar die kracht vandaan komt.

Op dit item kan niet meer gereageerd worden.