'Ruim 80.000 open memcached-servers kunnen gebruikt worden voor ddos-aanvallen'

Onder meer Cloudflare waarschuwt dat het ddos-aanvallen heeft waargenomen die gebruikmaken van open memcached-servers voor zogenaamde amplification attacks. Er zouden in totaal 88.000 van dat soort servers via internet te benaderen zijn.

Zowel Cloudflare als het Duitse Link11 waarschuwen dat ze recentelijk aanvallen hebben waargenomen via open memcached-servers. Respectievelijk noemen ze daarbij pieken van 260Gbit/s en 400Gbit/s bij dit soort ddos-aanvallen. Deze vallen binnen de categorie van amplification attacks, waarbij de aanvaller een verzoek verstuurt namens het doelwit door het ip-adres te spoofen. Doordat de antwoorden groter zijn dan de verzoeken, kan een aanvaller met relatief weinig bandbreedte een grotere aanval op dat doelwit opzetten, aldus de bedrijven. In dit geval ondersteunen de memcached-servers udp via poort 11211.

Volgens Cloudflare zijn de antwoorden van de servers in de meeste gevallen 1400 bytes groot. In de praktijk zou een verzoek van 15 byte een antwoord van 750 kilobyte tot gevolg hebben, wat neerkomt op een factor van 50.000. De kwetsbare servers zouden voornamelijk in de VS, China en Europa staan bij grote hostingproviders als OVH en DigitalOcean. Bij de recentelijk gedetecteerde aanvallen zouden ongeveer 5700 servers zijn betrokken; een Shodan-zoekopdracht toont echter aan dat het totale aantal open memcached-servers op bijna 88.000 uitkomt, waarvan ongeveer 2600 in Nederland.

De bedrijven raden dan ook aan de servers te beveiligen. Cloudflare suggereert onder meer om udp uit te zetten als dit niet wordt gebruikt. Memcached is opensourcesoftware die volgens de makers ingezet kan worden om webapplicaties te versnellen door databaseverzoeken te minimaliseren met behulp van caching. Cisco Talos waarschuwde vorig jaar al voor een groot aantal via internet benaderbare memcached-servers. Volgens de ddos-monitoringdienst van beveiligingsbedrijf Qihoo 360 komen reflectieaanvallen via memcached nog lang niet zo vaak voor als via dns, respectievelijk met 0,3 en 41,6 procent van het totale aantal aanvallen van dit soort.

Reacties (37)

[borft]

Er lijkt mij in de praktijk sowieso geen enkele geldige reden om je memcache server voor het hele Internet open te zetten. In principen hoort die alleen maar bereikbaar te zijn over je interne netwerk. Een hoop prutsers dus!

[edit]
@RGAT daar heb je zeker een goed punt, dus dat is een maatregel die je als ISP zou kunnen nemen. Maar in principe kan binnenkomend verkeer naar een publieke server natuurlijk van elk legitieme IP komen. En dus is dat lijkt mij heel lastig te blokkeren.

Maar ik zou denken dat elke fatsoenlijke sysadmin, standaard al het inkomend verkeer blokkeert in de firewall, en alleen porten openzet met een goeie reden. Als je dat doet, dan ben je al niet meer kwetsbaar voor dit soort aanvallen.

[Reactie gewijzigd door borft op 22 juli 2024 22:11]

[RGAT]

Zou geen geldige reden zijn voor netwerken om IP adressen te spoofen, alles wat van achter de router komt maar een IP heeft buiten de range van die router zou de router niet moeten doorsturen.
Dan kap je amplification attacks direct al af, ongeacht verdere kwetsbaarheden...

[_JGC_]

Hoe wil je dat doen?

client -> router 1 -> router 2 -> server
Router 2 krijgt packet via router 1 van client gericht aan server. Hoe moet router 2 weten dat het IP gespoofd is? Route terug hoeft nml niet via hetzelfde pad te lopen.

[RGAT]

Daar is al e.a. voor zoals bcp38.
Elke router weet welke netwerken aan zijn 'binnenkant' zitten, die routert hij namelijk, dus als een router bijvoorbeeld 8/8 en 9/8 heeft (als voorbeeld) en een packet van 7.x.x.x komt binnen dan weet die router dat die niet legitiem is tenzij hij vanaf de internet kant komt, DROP dus.
Daarmee stop je spoofing al vrijwel volledig (als alle ISPs dat doen...), dit doe je dus niet aan de ontvangende kant maar de verzendende kant.

[Wim-Bart]

Ja en nee, door wijzigingen in netwerk kan een adres wat nu op interface 0 zit door de dynamiek straks opeens op interface 1 zitten. En dat kan geheel buiten je eigen infra om gebeuren. Je hebt daar geen invloed op. Niks zegt namelijk dat het internet verkeer van links naar rechts gaat, een defecte router in Amsterdam kan er voor zorgen dat verkeer opeens via Frankfurt gaat lopen en andersom. Wanneer je dan over meerdere providers gaat zit je dus met een issue.

[RGAT]

Again, verzendende kant, niet de ontvangende kant, welke route het neemt is dus nadat het door de router van de verzendende ISP is gegaan.
Ik ken geen enkele ISP welke willekeurig reeksen van andere ISPs heeft, kan mij ook geen situatie voorstellen waar je met het een IP uit het netwerk van Google op een Microsoft netwerk zou willen zitten anders dan spoofen
Welke poort dat door gaat maakt overigens sowieso niets uit voor de router, zolang dat netwerk niet bij de router hoort laat die het niet naar buiten toe.
Die defecte router in Amsterdam heeft zijn eigen range, net zoals die in Frankfurt zijn eigen range heeft, als ze elkaars range gaan gebruiken loopt het mis of is er iemand aan het spoofen, beide wil je voorkomen.

[Wim-Bart]

Persoonlijk vind ik het belachelijk dat een hosting club dit niet eens zelf af vangt en dat die pakketten gewoon door de router heen komen. Pakketten met gespoofde IP adressen in de applicatie laag waarop een encryptie zit is een ander verhaal, die kan je niet versleutelen. Maar IP-heard spoofing zou gewoon standaard moeten zijn.

[Jay-v]

Dit is al jaren een probleem. ISP's hebben helaas geen incentive om dit te implementeren. Rate Limiting op de misbruikte server is vaak een oplossing.

[_-= Erikje =-_]

Dat doe je dus op de edge; router-1 in jouw verhaal weet welke IPs client naar buiten zou mogen sturen en kan dus zien of client niet een ander source IP spoofed; daarnaast is het netjes om op de edge van je eigen netwerk (naar bv iptransit of peering toe) te filteren op verkeer met alleen source IP uit je eigen netwerk

[Wim-Bart]

Je kan op de edge niet bepalen of een adres gespoofed is, je kan dat alleen op de Router waar de host zit die aan het spoofen is. Maar op het moment dat dat niet gebeurd kan ik gewoon een pakket sturen met daarin als source een totaal willekeurig IP Nummer. Het enige wat zou kunnen werken is wanneer je bijvoorbeeld met een hiërarchisch netwerk gaat werken waarbij iedere Router zegt "dat pakket kan nooit vanaf IP adres X komen, dus droppen". Maar aangezien een adres in range a.b.c.0/24 totaal ergens anders kan zijn dan IP adres in de range a.b.d.0/24 is het onmogelijk om dit wereldwijd te implementeren.

[Ayporos]

Ehh, maar het internet is toch hiërarchisch opgezet? ISP's kopen/bezitten toch blokken van bepaalde ranges welke ze dan aan hun cliënten toewijzen?

Hoe kan jij als ISP, een pakket ontvangen van een van jou aangesloten klanten wat dus via jou interne netwerk loopt, accepteren wanneer jij weet dat die cliënt X als (publiek) IP adres heeft maar de pakketten die van hem/haar afkomen een gespoofd adres Y hebben? Zulke pakketten zou bij de eerste beste router in het netwerk van de ISP (weet niet of dat al in de wijkkast gebeurt of pas verderop.. kan me voorstellen dat de eerste paar stappen domme switches zouden kunnen zijn?) al gedropt kunnen worden. Als jij mij verteld dat alle interne klanten van een ISP aan dezelfde switch/interface hangen als de interconnects naar andere ISP's dan zou dat echt het toppunt van onkunde zijn.

[Reactie gewijzigd door Ayporos op 22 juli 2024 22:11]

[Wim-Bart]

Dit hoeft niet altijd zo te zijn, je hebt carriers die alleen maar verkeer van A naar B brengen. En dit kan bijvoorbeeld door A -> W - > X -> Y -> Z - > B.

Stel nu is X kapot, dan kan het verkeer gaan van:
A -> W -> V -> Y -> Z-> B

Waarbij de inkomende interface van Y is verbonden met zowel Z als V maar V alleen maar Y kent en niet Z. Hierdoor zal het verkeer voor B uiteindelijk op de andere interface terecht komen van Y.

[PolarBear]

Maar je weet wel dat A alleen maar verkeer van versturen vanuit een bepaalde IP range. En dat is nou juist het punt.

[_-= Erikje =-_]

Dan heb je het over transit en zit je dus niet aan de edge. Ik refereer meer aan de bras kant, eerste hop in het isp netwerk achter de cpe. Daar wee je wel degelijk welke adressen je zou mogen verwachten van je klanten

[Ayporos]

Precies dit wat Erikje zegt. Kijk dat ISP's onderling allemaal met elkaar verbonden zijn is prima en dat snap ik.. maar een klant die aan de edge zit en dus met slechts één ISP verbonden is (nl. zijn eigen) zou enkel vanaf één IP adres (of reeks) pakketten kunnen versturen welke die betreffende ISP zélf aan die betreffende klant toegewezen heeft. Die 1e hop het internet op is dus cruciaal en de enige/beste plek om dit soort spoofing te ondervangen.

[mpol]

Deze discussie loopt al (tientallen) jaren, maar ik zie dit door niemand serieus opgepakt worden. Is het mogelijk dat als dit nu ingevoerd wordt, dat er heel veel applicaties en diensten stukgaan, en dat het daarom niet ingevoerd wordt?
Wanneer dit in een vroeger decennium was ingevoerd zou het nu vanzelfsprekend zijn, maar nu er al zoveel diensten op het internet draaien is dat wellicht anders.

Edit: ik denk heel simpel aan proxy's en VPN-diensten, maar er is vast meer te bedenken.

[Reactie gewijzigd door mpol op 22 juli 2024 22:11]

[_-= Erikje =-_]

Er zijn ISPs genoeg die dat standaard doen (uRPF) maar met name in de hosting wereld gebeurd het een stuk minder en deze aanvallen komen ook grotendeels uit die kant. Er is wat dat betreft ook niets verplicht oid

[RoestVrijStaal]

Als memcached niet open en bloot op het internet hoeft te draaien, kunnen de devs ervan beter niet detectie inbouwen (een simpele ping naar de website van memcached bijvoorbeeld) en als blijkt dat het bloot draait volledig dienst weigeren?

[borft]

nee, dat is de andere kant op. De check die jij voorstelt test of de server die memcached draait naar buiten kan verbinden.

Ansich is er niet per se iets mis met memcached die op een publieke interface luistert (ik zou het niet aanraden, maar OK), maar dan moet je inkomend verkeer filteren, en alleen gewhiteliste IP's toelaten. Ook dan heb je dit probleem niet.

Desalniettemin, memcached moet gewoon niet op een publieke interface luisteren, nergens goed voor!

[WhatsappHack]

*trekt wit weg* Waarom zou je in hemelsnaam memcached opengooien?
Daar is het niet bepaald voor ontworpen imho en is an sich veelal al een behoorlijk beveiligingslek. Knettergek.

[borft]

+1

Een niet versleutelde dienst, die geen authenticatie laag heeft, direct aan het Internet hangen zonder netwerkfiltering is gekkenwerk! Ik vermoed dat er met die machines nog veel meer mis is.

[Verwijderd]

Als je alleen maar je websites in memcached heb staan en deze wilt benaderen zie ik niet zo'n lek. Je kan er altijd nog een memcached server naast gooien op een andere poort waarin je beveiligde items bewaard (die dan wel alleen lokaal te benaderen is...)

[svenk91]

Als ze die servers kunnen mappen kunnen ze misschien ook al die servers voor korte tijd weigeren als de start van een ddos wordt gedecteerd? Het is een pleistermiddel maar die caching heeft ook een nut natuurlijk en wil je ook niet lastiger maken.

[Iblies]

Wie zou dat moeten weigeren? Er is eerder geopperd om providers bij te betrekken,
en daar is wel wat voor te zeggen.


In veel gevallen gaat het om achterhaalde hardware/software die om wat voor reden niet goed is bijgewerkt en op internet is aangesloten. Alleen hoe wil je dat gaat bolwerken. Je zult de mensen wel eerst willen aanspreken,
maar dat zal in technische termen zijn met vb mac-adres, maar aangezien het gros digibeet vraag ik me of dat zal wel werken zonder veel poeha.

[svenk91]

Bedrijven als cloudfare / hosting bedrijven.

[ViperXL]

Ik weet dat Hetzner bijvoorbeeld zijn klant waarschuwt als je een open memcached server hebt, zij scannen hier blijkbaar actief op.
Het zou niet mogen maar snap ook niet dat deze memcached servers verbindingen van buitenaf accepteren, als dat nodig is zou het toch op z'n minst in een VLAN of achter firewall moeten hangen. Maar een configuratie fout is snel gemaakt natuurlijk, OF je hebt developers die gewoon ff je firewall uitschakelen

[Tivoler]

Buiten het feit dat je een Memcached server sowieso niet publiek wil draaien snap ik al helemaal niet dat men gewoon de basic config gebruikt.

SASLAuthProtocol is toch wel standaard vandaag de dag zodat je ook niet een dev hebt die intern even een productie cache server plat kan leggen.

[Verwijderd]

Developers horen niet aan productiesystemen te kunnen komen. Als dat wel gebeurt heb je eerst organisatorische issues om op te lossen.

[Tivoler]

Een open server is een open server, dus te benaderen. Heeft niets met een dev te maken, wel met iemand die zo handig is die server even op te snorren via poortscan/whatever.

[ipsec]

Ik werk bij een hostingbedrijf en toevallig hebben wij van de week 2 VM’s van klanten gehad die allebei lekker meededen aan een aanval.

Deze deden samen +/- 5Gbit aan traffic, zo rap kan het gaan :-)

[hackerhater]

Ik neem aan dat ze nu offline zijn?

[ipsec]

In elk geval niet meer te misbruiken nu.

[Game-Freak]

Het Shodan rapport: https://www.shodan.io/report/N7ttll7J

[totaalgeenhard]

80.000 maar?

Meeste Apache servers hebben memcache als module mee gecompiled.

[Ventieldopje]

Een memcached module (client) is wat anders dan een memcached server natuurlijk

[borft]

en dan nog, het feit dat een module beschikbaar is, betekent niet dat ie ook aanstaat (afgezien dat het hier zoals gezegd niet om een client gaat maar om de server)