De DDoS-aanvallen die we de laatste paar jaar het vaakst zien in het wild worden uitgevoerd via botnets. Tienduizenden bots genereren elk requests, waardoor een server wordt overvallen door veel verzoeken tegelijkertijd.
De methode via memcached is een amplification-aanval die we zo'n vijf jaar geleden erg vaak zagen via kwetsbare DNS-servers. Bij zo'n aanval wordt een third party-server gevraagd om een grotere respons dan de originele vraag. Die grotere pakketjes worden vervolgens verstuurd naar een door de aanvaller gespecificeerd IP-adres.
Wat is een Memcached-DDoS?
Die third party-server wordt dus zelf niet geDDoSt, maar wordt ingezet als de uitvoerder van de aanval. En dat geldt nu dus ook voor kwetsbare servers met memchached, een servertool om databases in het werkgeheugen te cachen, zodat API's niet steeds dezelfde informatie opnieuw hoeven op te halen.
Lees ook: Internetkrakende DDoS-aanval komt er binnenkort aan
Memcached is te benaderen via UDP/11211, die de meeste serverbeheerders wel blokkeren. Maar een zoektocht op Shodan leerde dat er meer dan 80.000 van deze systemen te benaderen zijn via de openstaande poort.
Bij de meeste methodes levert een amplification pakketjes op die tien tot twintig keer groter zijn dan de originele request, maar bij de memcached-methode kunnen pakketjes enkele duizenden keren worden vergroot. Eén misbruikte memcached-server kan met een request van 1 MB daarom een golf opleveren van enkele tienduizenden Mbps of meer.
Enorme groei
Bij een aanval in februari werden 6000 servers ingezet, wat een verkeerspiek opleverde van 500 Gbps, meldde Cloudflare vorige week. GitHub was vorige week slachtoffer van een aanval met de memchached-DDoS-methode die pieken van 1,35 Tbps bereikte.
De methode werd in 2014 gepresenteerd op beveiligingscongres Black Hat (PDF), maar werd eind vorig jaar voor het eerst in het wild gesignaleerd. Na meldingen over de groei van memcached-amplification, steeg het relatief nieuwe type DDoS-aanval nog verder.
Poorten blokkeren
Vorige week rees het aantal aanvallen van enkele tientallen per dag rap naar honderden en momenteel zitten we op duizenden. Dat is nog steeds een fractie van het totale DDoS-verkeer, dus dit probleem heeft nog voldoende ruimte om te groeien.
Beveiligers verzochten vorige week dringend dat serverbeheerders memcached achter een firewall plaatsen, maar dat is geen goede kortetermijnstrategie met meer dan 80.000 kwetsbare servers en de huidige zeer snelle stijging in de hoeveelheid aanvallen, waardoor een groot probleem dreigt. Daarom worden providers en webhosters nu verzocht om de door memcached gebruikte UDP-poort (11211) te blokkeren.
Maar even los van meningsverschillen over defaults van memcached, ligt er een veel fundamenteler punt aan ten grondslag. Een punt dat CloudFlare al eens aangestipt heeft. Ontwikkelaars van services die communiceren via UDP, doen er goed aan om hun applicaties te herzien en ervoor te zorgen dat responses kleiner zijn dan de requests. Dat is een behoorlijk fundamenteel punt in de manier waarop UDP-services ontworpen zouden moeten worden, maar we zitten nog met veel legacy uit een tijd dat het internet een veel vriendelijker omgeving was. Die zet je ook niet even van de ene op de andere dag uit helaas.
Daarnaast is het interessant dat de providers waar het meeste UDP-verkeer vandaan kwam tijdens deze DDOS, VPS-hostingboeren waren. Op zich ben ik heel blij met de aanwezigheid van providers die het mogelijk maken om voor een schappelijk prijsje een echte server aan het internet te knopen. Resultaat is alleen wel een toestroom van ongetrainde niet-IT'ers die maar wat doen op zulke machientjes en dat gaat geheid fout. Deze VPS-providers zouden er goed aan doen om hun (virtuele) switchpoortjes eens wat beter in de gaten te houden.
Bij een default centos/rhel installatie staat de service niet aan na installatie. Dat moet nog handmatig gebeuren. Ook de default firewall configuratie geeft geen remote toegang tot memcached. De
ongetrainde niet-IT'er zal dit niet zo snel vinden denk ik. De meeste VPS-hostingboeren veranderen deze configuratie niet. Ik weet niet hoe het zit met die andere Linux distro's of Free/OpenBSD .
Problem lijkt meer te zitten bij de hosters die een Appliance aanbieden.
Je wordt op je wenken bediend. Ik kreeg net een mail van een van mijn cloud providers:
We have seen an increase of the Memcached DDoS attack method in our Network. To mitigate risk and increase your security, we have decided to actively block the port on our Network. The port that will be blocked is UDP 11211
Fijn, maar iets te reactief naar mijn smaak. Er is ook proactief het nodige te doen aan verdachte verkeerspatronen.
Na het zien van een toename is ook een beetje proactief toch? Afhankelijk van de integratie tijd
Duidelijk is dat wederom open source geen betere beveliging oplevert doordat er "meer ogen naar kijken". Dat blijkt uit alnglopende fouten zoals destijds Heartbleed (waarbij het chromebleed tooltje dat ik heb draaien nog steeds sites aanmerkt als onveilig!)
Het is dus essentieel dat alle breed ingezette open source basis tools een fatsoenlijke controle doorlopen. Daar zijn overigens ook de bedrijven die maar wat graag open source gebrukken, mede verantwoordelijk voor. Al blijkt dat sommige bedrijven wel veel open source consumeren (of daar zelfs hun basis OS op bouwen) in hun producten maar heel weing terug geven aan de community.
Eens met veel van je betoog, maar in relatie tot dit onderwerp sla je de plank echt mis.
Is naadloos van toepassing, juist op dit dossier.
Sinds 2014 is het probleem bekend gemaakt en niemand heeft de moeite genomen iets aan de code of instellingen te veranderen.
Waarom zouden ze ook?
Security is het voorkomen van problemen. Met een dermate naieve default instelling voorkom je niets maar nodig je uit. vervolgens wordt er helder een voorbeeld gegeven in 2014 maar niemand is dan zo slim om de bal op te pakken en het vrij simpele probleem te voorkomen. Ook degenen niet , die de fout aangetroffen hebben trouwens. Die zijn kennelijk meer bezig met naam maken als hacker op blackhat.
Heb je dat voorbeeld uit 2014 überhaupt wel gelezen eigenlijk??
Had je gezien dat daar zelfs specifiek de door mij genoemde CMS systemen als erg kwestbaar worden gezien door de keuze van de Memcache module.
Daar wees ik al eerder op.
Heerlijke bullshit weer. Heb je het artikel gelezen en *begrijp* je wat er staat?
Naar welke CVE verwijs je nu? en denk je echt dat al die ogen toegang hebben tot de configuratie van betrokken servers? Werkt dat met Microsoft software wel zo dan?
Het gaat trouwens over hoe werkt een ddos-aanval-via-memcached. Had je dat nog niet begrepen?
Je hebt dus kennelijk niet door hoe memcached werkt en hoe je die moet (zou moeten) instellen. Daarmee is wel voldoende aangetoond ;)
Je hebt alleen maar aangetoond dat je niet kan lezen of begrijoen
En daar ga je weer. Uber LL
Je hebt het meer ogen verhaal niet begrepen. Je kan de software gewoon veilig gebruiken. Het probleem zit in de configuratie die sommigen hebben. Je hebt geen vele ogen in die prive configuraties.
Je statement slaat de plank mis.
Je bent aan het winkelen in argumenten. Het veel ogen fabeltje slaat op de vermeende veiligheid van open source. Het UDP verhaal en de defaults vallen net zo goed onder dat veel ogen principe (het is tenslotte de default van de beschikbare software) maar staan ook los al bekend als potentieel nodeloos gevaar. Dat verwacht je dus niet als default in de 21e eeuw.
Is geen fabeltje en die beperkte ogen hadden het al lang gezien. Daarnaast als je bij die hostingboeren een CentOS Linux een image bestel zit memcached er helemaal niet in. Die moet je zelf installeren en dan ook nog handmatig aanzetten. Daarnaast staat UDP port 11211 vanaf het internet dicht. Dus ook de firewall config moet je zelf veranderen. Dat is een aardige drempel. Desalniettemin staat de memcached config default niet zo als het hoort. Ook onder windows heb je mensen die bv smb voor het internet openzetten. Ik heb je niet gehoord dat windows hierdoor onveiliger werd.
Je probeert een punt te maken dat er niet is.
Probeer nu eens een keer gewoon te discussieren. Geen wedstrijdje verplassen, geen gezeur over windows etc.. zou dat lukken?
We hoeven het niet eens te zijn, meningsvershcil mag gewoon. No problem.
En ja die vele ogen fabel is te gemakkelijk te weerleggen door een reeks van feiten.
Bewustzijn van fouten is stap een. ieder kiest zijn eigen oplossing.
Als de ‘vele ogen fabel’ door feiten worden weerlegt, zijn ‘vele ogen’ geen fabel maar feit.
Ik zie dat jullie eruit zijn. Mooi!
Drinks are on me
Je ctrol logica is weer onanavolgbaar. Het zou ook kunnen dat je het gewoon niet begijpt. De keus is aan jou ;)
Je mag volgende week je default privacy settings weer terug zetten :)
Is in een beheerde omgeving nog nooit nodig geweest ;)
Als je alles goed vindt niet nee:)
Zo te zien weet je niet waar je over praat ;)
Er staat trouwens not een uitdaging open.. komt daar nog iets op?
Jouw zelfgeschreven bigdata algoritme dat de identiteit achter Zorba gaat onthullen ;)
Klopt, een beetje beheerder implementeert dit gewoon zoals het hoort en loopt door. Zó moeilijk is het ook weer niet allemaal. Er zijn genoeg services waarbij het niet altijd opportuun is om de default te laten staan. Dat hoort erbij als je services beheert met een publiek IP adres eraan. Blijkt ook wel, want Memcached wordt op héél veel plekken gebruikt terwijl er maar 80.000 openstaan in Shodan blijkbaar.
Wat gaan we dan doen? Examens invoeren die je moet halen voordat je je computer aan het internet mag knopen? Ik hoop het niet.
En dat gebeurt ook gewoon.
Natuurlijk zijn ze dat niet. Die bedrijven zijn verantwoordelijk voor wat ze zelf doen, niet voor wat anderen doen.
Wat betreurenswaardig is, maar wel hun goed recht.
Wanneer je open source gebruikt of als basis van je OS gebruikt mag de community verwachten dat de verbeteringen gedeeld worden.Nu zie je bijv dat Google met Android een verbouwde linux kernel heeft, dat aanvult met allerlei onderdelen die vaak gebaseerd zijn op open source maar die niet vrij verkrijgbaar zijn of onder aanvullende licentie voorwaarden.
Dat bedrijven die open source gebrukken mede verantwoordelijk zijn voor de kwaliteit van de code lijkt me normaal en dat mag je verwachten.
Code controle gebeurt gewoonweg vel te weinig en pas wanneer men serieus de zaak onder de loep neemt blijken er telkens weer aanzienlijke kwetsbaarheden ( die al die ogen weer gemist hebben)
Heartbleed, SSL, etc.. er zijn voorbeelden genoeg.
Nee, het zou al voldoende zijn als hosters ervoor zorgden dat de aangeboden modules wel veilig zijn. Die 80K bestaan uit veel zakelijk opgezette omgevingen die dus niet veilig zijn/waren.
Dus naast bewustzijn dien je de klant ook tegen zichzelf te beschermen. Maar helaas, geld telt zwaarder dan security.
Reageer
Preview