Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Aantal open memcached-servers daalt door Nederlandse en internationale inzet

Verschillende partijen, waaronder Nederlandse onderzoekers, werken samen om het aantal open memcached-servers op internet terug te dringen. Onderzoeker Victor Gevers zegt dat er inmiddels ruim 51.000 servers zijn gemeld.

Gevers meldt dat er daarvan inmiddels meer dan 49.000 zijn gefilterd, waardoor ze niet meer voor ddos-aanvallen zijn te misbruiken. De onderzoeker, die als voorzitter verbonden is aan de GDI Foundation, zegt tegen Tweakers dat beheerders in sommige gevallen ook een bevestiging sturen dat een kwetsbare server is dichtgezet. Volgens Gevers was het advies bij de melding om de server achter een firewall te zetten. De meest recente scans, afhankelijk van welke methode wordt gebruikt, wijzen erop dat er nog ongeveer zesduizend kwetsbare servers te benaderen zijn.

Gevers zegt: "Ik wil graag opmerken dat voornamelijk de kleine isp's en beheerclubs heel snel en rap reageren. Gelukkig kennen we al heel veel organisaties van eerdere meldingen die we in de afgelopen jaren hebben gedaan. En ander voordeel is dat de isp niet per se de memcached-server (van hun klant) hoeft te updaten met een nieuwe versie. Het filteren van het verkeer is in principe een prima stap om misbruik tegen te gaan." Het nadeel zou echter weer zijn dat het filteren niet altijd even consequent gebeurt. "We zien dit voornamelijk terug als we dezelfde scan vanaf verschillende locaties in de wereld draaien; dan komen er verschillende resultaten terug. Dit maakt het monitoren van de gerapporteerde items en het ontdekken van nieuwe kwetsbare systemen een uitdaging."

Bij het scannen naar kwetsbare servers wordt uit verschillende hoeken hulp geboden. "We zijn nog steeds ons bereik aan het uitbreiden. Er komen steeds meer mensen die ons vps'en en hulp met het scannen aanbieden. Hoe meer informatie van uit verschillende invalshoeken des te beter we een beeld krijgen hoe het er voor staat." Gevers en de vrijwilligers van de GDI Foundation zijn niet de enigen die eraan werken zo veel mogelijk memcached-servers te beveiligen. De onderzoeker zegt dat er ook andere partijen mee bezig zijn, zoals Shadowserver en AbuseHub.

Het zal nog een tijd duren voordat alle servers beveiligd zijn, aldus Gevers. "Ik ben heel erg trots op de alle vrijwilligers die hier aan bijdragen. De race is nog niet gelopen omdat er nog genoeg open staat om een dreiging te zijn. De GDI Foundation zal niet stoppen totdat alle onveilige servers van het internet verdwenen zijn. Dus we zijn de komende tijd nog wel even bezig." Het is niet de eerste keer dat Gevers en consorten in actie komen om kwetsbare servers te beveiligen. Dat gebeurde bijvoorbeeld vorig jaar nog, waarbij werd gezocht naar servers die kwetsbaar waren voor EternalBlue.

Verschillende organisaties waarschuwden onlangs voor open memcached-servers, die voor krachtige ddos aanvallen in te zetten zijn via zogemaamde amplification attacks. Een dergelijke aanval trof GitHub recentelijk met 1,3Tbit/s aan verkeer. Memcached is opensourcesoftware die volgens de makers ingezet kan worden om webapplicaties te versnellen door databaseverzoeken te minimaliseren met behulp van caching.

Door

Nieuwsredacteur

37 Linkedin Google+

Reacties (37)

Wijzig sortering
Dit zal het vast een flink stuk moeilijker maken voor Dos'ers om hun aanvallen uit te voeren, al schijnt het middels gebruik van deze servers wel erg gemakkelijk te zijn om een flinke nekslag aan een website uit te delen.

Er bestaat volgens mij op dit moment geen grotere amplification attack dan deze memcached servers(correct me if i'm wrong) :

"15 bytes of request triggered 134KB of response. This is amplification factor of 10,000x! In practice we've seen a 15-byte request result in a 750kB response (that's a 51,200x amplification)," Cloudflare says.

bron:
https://thehackernews.com...d-amplification-ddos.html
En allemaal mogelijk omdat je zelf aan de ontvanger kunt vertellen wie je bent, en dan dus keihard liegen zonder controle zodat het antwoord naar slachtoffer gaan. En daarmee bedoel ik het spoofen van return IP adressen. Hopelijk bouwen we ooit een internet waar dat niet meer mogelijk is. Want die DDOS aanvallen die zijn zo eenvoudig uit te voeren tegenwoordig. En met IPv6 en IoT heb je meer apparaten om mee te kloten dan mensen in de wereld. Stel je voor dat de ze NOS uit de lucht ddosen tijdens de finale van het WK voetbal. :(
Een wereld zonder spoofing gaat nooit gebeuren, evenmin het ooit gaat gebeuren dat er een wereld zonder VPN zal bestaan, al acht ik de kans op dat laatste nog hoger.

Feit is dat het spoofen van ip en MAC adressen niet alleen nuttig is voor Denial of Service attacks maar ook gebruikt kan worden door hackers om hun ware identiteit te verhullen, en aangezien onze overheid de WIV heeft aangenomen waarin zij ook bevoegdheden krijgen tot ''terughacken'' zal het spoofen van ip en/of MAC adressen ook bij onze overheid dagelijkse praktijk worden.

Per slot van rekening is het wel erg praktisch als je als Nederlandse overheid bezig bent op de computers van een land in te breken dat de poging komt van een boliviaans of non routable ip adres 8)7 :Y)
Reverse Path Forwarding is een redelijke policy voor de meeste (edge) netwerken. Als dat universeel uitgerold wordt voorkomt het spoofing :)
Voor dit specifieke scenario zijn er al meerdere oplossingen; de memcached-server niet naar 'het internet' laten luisteren, de memcached-server niet eens een 'direct vanaf het internet te gebruiken ip' geven, firewalling die dat verkeer tegenhoudt, en vast nog wel een paar.

Als dat nu niet goed ingericht is, hoe groot is dan de kans dat RPF wel correct opgezet wordt bij de partijen waar het juist nu mis gaat? Het kan vast helpen om bij nieuwe typen aanvallen de misbruikmogelijkheden in te perken, maar net als andere beveiligingsmogelijkheden leunt het natuurlijk wel op een correcte implementatie binnen die netwerken.
In dit specifieke scenario ontstaat het probleem echt door misconfiguratie van bepaalde beheerders, dat staat buiten kijf. Er is een grote kans dat een open memcached-server ook (impliciet) een datalek is – zou het bij mijn gebruik snel zijn.

Om memcached aanvallen te voorkomen zou RPF universeel uitgerold moeten worden, je kan vanaf een netwerk achter een RPF-policy geen aanval meer starten. Het heeft geen zin om dit op weinig plekken te doen. Net zoals het filteren van memcached, dat werkt ook alleen wanneer er te weinig reflectors zijn. Bij DNS zijn open resolvers ook nog steeds een issue.

Het is wel een universele maatregel tegen reflected aanvallen waar je er maar weinig use cases mee blokkeert. En dit werkt voor hele netwerken. Als er DDOS (niet: DOS – een enkel machine zonder filter vindt je wel) op basis van reflectie plaatsvind lijkt mij dit een nuttige policy.

Dat je dit als consumenten ISP of budget-VPS/colo provider uitrolt lijkt mij haalbaar, je mag competent beheer verwachten van professionele organisaties :)

edit:
Als je een netwerk hebt met meerdere POP's dan zijn filters op inkomende filters aan jouw edge natuurlijk de beste oplossing. Dat omschrijft Cloudflare in een blog waar deze filters een keer downtime veroorzaakten

[Reactie gewijzigd door ANdrode op 13 maart 2018 09:04]

UDP is nou eenmaal een stuk sneller dan TCP juist omdat het 'fire and forget' is en het niet uitmaakt als er hier en daar een pakketje kwijt raakt, bijv bij online gaming.

Het probleem zit hem meer in kennis van zaken bij eindgebruikers en beheerders, die hun apparaten en/of servers niet goed beveiligen.

Standaard moet inkomend verkeer eigenlijk gewoon alles dicht staan, tenzij je kunt bewijzen dat je bekwaam genoeg bent.
Er zijn nog voldoende andere methodes en er worden regelmatig weer nieuwe gevonden. Zo is er nog NTP, DNS, SSDP etc.

Aanvallen zullen enkel groter en groter worden, het goede nieuws is wel dat de verdediging ook steeds beter wordt.
In principe zijn dit soort aanvallen alleen te doen met UDP gebaseerde protocollen/toepassingen. Dus de lijst is wel eindig.
Maar van een SYN/ACK aanval wordt je apparatuur ook niet blij. Veel lower end firewalls kunnen niet zoveel sessies (1000 of een veelvoud hiervan) open houden. Kleine partijen krijg je hiermee ook heel snel plat.
Bij een TCP reflection attack worden er geen nieuwe sessies gemaakt omdat er geen openstaande sessie is die bij de SYN/ACK hoort. En een stateful firewall hoort echt geen sessie aan te maken bij een losse SYN/ACK. Op basis van connection state kunnen de packets dus al worden gedropt.
UDP reflection attacks kunnen mogelijk verder komen dan een stateful firewall als een source port is gebruikt waarop een publiek bereikbare service draait.

De bandbreedte is bij dit soort aanvallen veel belangrijker. Legitiem verkeer wordt weggeconcurreerd. Er komt natuurlijk best wat CPU power bij kijken om 1.4 Mpps per binnenkomende Gbit/s te verwerken, maar dat is waar die apparaten in gespecialiseerd zijn. Een amplification attack is dan in praktijk veel effectiever.
Gezien wordpress zowat 40% van het internet beslaat, is het heel interessant deze websites te 'hacken' en toe te voegen aan een enorm botnet. Je wil niet weten hoeveel ruis en troep er dagelijks op sites tekeer gaan zoekend naar lekken op gebied van Wordpress. Enige verschil is dat bij memcached de boel eerst niet gekraakt moet worden zoals bij wordpress wel het geval is.
Is memcached zelf al aangepast zodat ie by default alleen op localhost luisterd?
Ja en nee. Het is opgelost door UDP volledig uit te schakelen:
https://github.com/memcac...4ef51f5814ef7ceb17d83d974

As reported, UDP amplification attacks have started to use insecure
internet-exposed memcached instances. UDP used to be a lot more popular as a
transport for memcached many years ago, but I'm not aware of many recent
users.

Ten years ago, the TCP connection overhead from many clients was relatively
high (dozens or hundreds per client server), but these days many clients are
batched, or user fewer processes, or simply anre't worried about it.

While changing the default to listen on localhost only would also help, the
true culprit is UDP. There are many more use cases for using memcached over
the network than there are for using the UDP protocol.
Ik snap niet waarom UDP nu ineens als "schuldige" wordt aangewezen. Dat is hetzelfde als dat jochie van 14 dat in jouw wijk folders bezorgt de schuld geven van al dat oud papier dat in je brievenbus beland, terwijl je dat gewoon zelf had kunnen voorkomen met een NEE/NEE sticker op de bus.

Als de aanvallers straks geen UDP amplification meer kunnen gebruiken dan verzinnen ze iets dat gebaseerd is op TCP. Een onbeveiligde en non-firewalled Memcashed server blijft een risico, welk transport protocol je ook gebruikt.
Ik denk niet dat er zo zeer een schuldige aangewezen wordt, hij sluit alleen de kwetsbaarheid uit door UDP als default uit te schakelen, zo heeft elke ontwikkelaar de vrijheid om zo'n keuze te nemen.

Ik had het anders gedaan, maar goed ik heb niet de capaciteit om zoiets als Memcached te maken, dus ik klaag niet. Als default alleen aan localhost hangen, klaar.
Ik denk niet dat er zo zeer een schuldige aangewezen wordt, hij sluit alleen de kwetsbaarheid uit door UDP als default uit te schakelen, zo heeft elke ontwikkelaar de vrijheid om zo'n keuze te nemen.
Dat is niet hoe ik de onderste alinea lees van jouw quote:
While changing the default to listen on localhost only would also help, the true culprit is UDP. There are many more use cases for using memcached over the network than there are for using the UDP protocol.
Misschien bedoelt hij UDP in de context van het gebruik door memcached, maar zo klinkt het niet, en bovendien is dat symptoombestreiding. Precies wat rbr320 ook zegt met zijn analogie van de krantenjongen.

[Reactie gewijzigd door .oisyn op 12 maart 2018 15:32]

en bovendien is dat symptoombestreiding.
Dat is niet helemaal waar.. TCP kun je niet (zo) gebruiken voor amplification.
Het voorbeeld klopt natuurlijk van geen kant . UDP is gewoon een verouderd protocol ja is een snelle manier van iets versturen maar , er zijn tegenwoordig tal van alternatieven die veel beter en veiliger zijn en ook veel minder overhead hebben dan TCP/IP .

UDP is je pakt een pakket gooit het over de schutting van de buurman heen klaar , iemand anders zijn probleem.
TCP/ip is hallo buurman ! halo buurman ! Ik heb een pakketje voor je. echt waar ?geef het maar . Alsjeblieft heb je het ontvangen? ja ik heb het ontvangen . Dank je wel buurman fijne dag , fijne dag buurman .

Er zijn zat alternatieve zeker onder Linux . Waar bij een beetje van communicatie zit bv RUDP of Google Quic (5% van het internet verkeer gaat via quic)
Buurman ik stuur je een pallet . Oké stuur maar. bedankt buurman Ik heb het ontvangen.

Zelf gebruik ik UDP verbinden nog dagelijks maar voor gesloten netwerken . Communicatie van meet apparatuur met PLCs is ideaal voor hele kleine cpus met een 256 kb programma en 1 mb aan ram
Netjes. Maar memcached gebruikt geen authenticatie toch? Dan heb je met een public TCP port nog steeds een probleem, al is het geen DDoS probleem meer.
De DDoS is dan niet mogelijk inderdaad. Het zou wel handig zijn om default op localhost te draaien, maar dan nog is het de taak van de sysadmin om dit goed in te richten. :)
We zeggen al 10 - 20 jaar dat het de taak van iemand (anders) is, maar dat werkt dus niet..
Dat lijkt me meer een config dingetje wat elke Linux distributie zal moeten shippen met hun packages. Als ik zo Ubuntu en Debian zie, is dat al lang geregeld gezien er standaard "-l 127.0.0.1" in de config file staat.
Dat lijkt me meer een config
Juist die gedachte is een van de oorzaken van dit probleem.. helaas is dat blijkbaar nog steeds niet duidelijk.

[Reactie gewijzigd door Olaf van der Spek op 12 maart 2018 13:59]

Ik bedoelde dat de ontwikkelaars van memcached geen invloed hebben op de default configs die met Linux distro's shippen.

Daarnaast ben ik van mening dat je je zooi gewoon goed moet regelen en dat de ontwikkelaar daar niet verantwoordelijk voor is, maar dat is een ander verhaal :)
Ik bedoelde dat de ontwikkelaars van memcached geen invloed hebben op de default configs die met Linux distro's shippen.
Dat is niet zo, ze hebben wel degelijk invloed. In ieder geval sommige distro's proberen zo min mogelijk af te wijken van upstream.
maar dat is een ander verhaal
Misschien moet je daar toch nog eens over nadenken. Het gaat er ook niet echt om wie er verantwoordelijk voor is, maar hoe we dit (met zijn allen) kunnen voorkomen.
> Dat is niet zo, ze hebben wel degelijk invloed. In ieder geval sommige distro's proberen zo min mogelijk af te wijken van upstream.

Dat zal best, maar voor memcached shippen veel distro's een eigen config file mee: https://anonscm.debian.or...ree/debian/memcached.conf .
voor mod_pagespeed heb je bv ook de optie om memcached in te zetten met de volgende command:
pagespeed MemcachedServers "127.0.0.1:11211"

zou je daar dan ook de -l bij moeten plaatsen?
Nee, de -l is een command line switch die tegen memcached zegt dat 'ie moet luisteren op localhost en niet op iets anders.

pagespeed MemcachedServers "127.0.0.1:11211" zegt alleen tegen mod_pagespeed dat 'ie naar memcached moet connecten via 127.0.0.1:11211 . Dit kan natuurlijk ook 10.0.13.37:11211 zijn als je intern een dedicated memcached bak hebt draaien bijvoorbeeld.
Memcached draai je meestal op een aparte host, zij het binnen het subnet / vlan / resource group / security group waarin ook de applicatieservers van je website draaien. De port binden aan de loopback adapter is geen oplossing.
Memcached draai je meestal op een aparte host, zij het binnen het subnet / vlan / resource group / security group waarin ook de applicatieservers van je website draaien.
Het is jammer dat Linux (Windows vast ook niet) niet iets heeft waarmee de port automatisch wordt beperkt tot het subnet.
De port binden aan de loopback adapter is geen oplossing.
Het had een deel van het huidige probleem voorkomen, toch?

[Reactie gewijzigd door Olaf van der Spek op 12 maart 2018 14:01]

[...]

Het is jammer dat Linux (Windows vast ook niet) niet iets heeft waarmee de port automatisch wordt beperkt tot het subnet.
Dat kan wel, dat regel je in beide OS-en namelijk in de firewall. Dit is niet iets dat je op applicatie niveau gaat regelen
[...]

Het had een deel van het huidige probleem voorkomen, toch?
Nee want de beheerder die niet goed na denkt over de inrichting van zijn memcached servers wijzigt in de configuratie met hetzelfde gemak deze instelling van "localhost" naar "*", waarmee memcached weer luistert alle ethernetpoorten.
Op RedHat family versie 6+ was dit standaard al zo.
Alleen poort 22 (SSH) / TCP staat default open in de firewall, de rest is gewoon "uit".

Helaas zijn er genoeg beheerders die niet weten of 'hun' applicatie nou tcp of udp draait en zetten daarom beiden maar open in de firewall.
Dat is wel een oplossing. Dit forceert de verantwoordelijke om zelf te bepalen vanaf welke ip-adressen de server bereikbaar moet zijn.

Hierbij kan dan niet standaard een configuratie fout de oorzaak zijn, maar is het een bewuste keuze van de gebruiker.
Opt-in / Opt-out verhaal.
# Specify which IP address to listen on. The default is to listen on all IP addresses
# This parameter is one of the only security measures that memcached has, so make sure
# it's listening on a firewalled interface.
-l 127.0.0.1

Die setting bepaalt dus alleen maar welke interface gebruikt wordt. Als je de memcached server vanaf andere machines moet kunnen benaderen dan kun je niks anders dan die interface aan zetten.
Zoals de omschrijving al aangeeft, je zult zelf nog voor firewalling moeten zorgen
Een mooi initiatief welke zijn vruchten begint af te werpen. Helaas ook een actie die herhaalt moet blijven worden wanneer nieuwe kwetsbaarheden aan het licht komen.
Denk dat het afnemen van memcached-servers mede komt doordat veel op redis zijn overgestapt. Niet zeggend dat de andere beter is. ;)

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S9 Google Pixel 2 Far Cry 5 Microsoft Xbox One X Apple iPhone 8

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True

*