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

GitHub beschrijft ddos-aanval van 1,3Tbit/s via memcached-servers

GitHub was deze week negen minuten onbereikbaar dankzij een omvangrijke ddos-aanval die 1,3Tbit/s aan dataverkeer op de servers afvuurde. Verkeer werd afgewend op Akamai, dat spreekt van de grootste ddos die het bedrijf tot nu toe te verduren kreeg.

De aanval bereikte GitHub woensdag en was zo hevig dat de site direct onbereikbaar werd. De ddos was afkomstig van duizenden autonome systemen, die 126,9 miljoen datapakketjes voor een totale bandbreedte van 1,35Tbit/s op de servers afvuurden. Vijf minuten na het begin van de ddos, besloot de infrastructuur van GitHub automatisch om verkeer via het Prolexic-netwerk van Akamai te laten verlopen, dat beter bestand is tegen aanvallen van een dergelijke omvang. Negen minuten na het begin van de aanval was GitHub daarop weer bereikbaar.

Volgens Akamai ging het om de grootste aanval waar het tot nu toe mee te maken kreeg en was deze wat verkeer betreft meer dan dubbel zo groot ten opzichte van een aanval via het Mirai-botnet uit 2016. De aanval lijkt ook omvangrijker dan die op dns-provider Dyn, die eveneens in 2016 via het Mirai-botnet plaatsvond, en voor 1,2Tbit/s aan dataverkeer zorgde.

De aanval op GitHub betrof een zogenoemde memcached-aanval. Akamai beschreef dit soort aanvallen vorige maand. Het memcached-protocol is bedoeld voor het cachen van data om schijven en databases te ontlasten. Het is niet de bedoeling dat memcache van servers bereikbaar is via internet en er is dan ook geen authenticatie vereist om het te benaderen. Er zijn op dit moment echter tienduizenden memcached-systemen via internet aan te spreken, waardoor ze kwetsbaar zijn.

Aanvallers kunnen ip-adressen van udp-verkeer spoofen en verzoeken sturen naar de memcached-systemen, waarbij het antwoord van de servers groter van omvang is en door het spoofen de site van het doelwit bereikt. Dit zijn zogenoemde reflectie- en amplificatieaanvallen en Akamai verwacht dat aanvallers zich vaker op memcache gaan richten.

Door Olaf van Miltenburg

Nieuwscoördinator

02-03-2018 • 11:23

76 Linkedin Google+

Submitter: Bammerbom

Reacties (76)

Wijzig sortering
Dit kan dus bij iedere applicatie gebeuren die op een UDP poort draait en waarvan de response groter is dan de request (bij memcached was het 1700x volgens mij) hierdoor krijg je de amplification. De aanvaller heeft veel minder bytes nodig voor een request en laat de server dit vermenigvuldigen.

Dankzij UDP kan er een andere source ip addres worden meegegeven waardoor de applicatie haar response naar het slachtoffer stuurt.

Eerst was het DNS, toen SNMP, toen NTP en nu dus Memcached, who' next?

Wil je niet dat jouw server hier voor misbruik wordt? Gooi dan de poorten dicht op je firewall! Het is sowieso een goed idee om alleen poorten op te zetten voor verkeer dat ook daadwerkelijk over het internet moeten gaan.

[Reactie gewijzigd door GrooV op 2 maart 2018 11:43]

Helaas nog iets meer, namelijk 50.000x amplification

Source: https://blog.cloudflare.c...-attacks-from-port-11211/

Denk dat als je een lange key value op een server weet te vinden je dit zelfs nog groter kan maken

[Reactie gewijzigd door smiba op 2 maart 2018 13:45]

Een grotere key zorgt niet voor een grotere amplification (maar juist een kleinere), de key moet je immers ook meesturen in het request. Wat je wel kunt doen, is zelf een extra grote value setten.
Bedoelde ook value die dan opgehaald word, heb het aangepast :)
Het verschilt ook per server. Mijn honeypotserver reageert met 1234 bytes op een request van 7 bytes, wat "slechts" een amplificatie van 176x is
Denk dat als je een lange key value op een server weet te vinden je dit zelfs nog groter kan maken
Die hoef je niet eens te vinden, die kun je er zelf op zetten voor je begint.
Unicast reverse path verplichten.
uRPF verplichten gaat je in dit geval niet helpen, uRPF gebruik je namelijk alleen maar om verkeer over dezelfde interface terug te sturen als waar het verzoek vandaan komt. Of de Source/Reply host gespoofed is maakt dus niet uit zolang het maar over dezelfde interface de reply stuurt als waar het request vandaan komt.

Als je dus het request via de WAN interface binnen krijgt, moet de reply ook over de WAN interface naar buiten.

"uRPF as defined in RFC 3704 is an evolution of the concept that traffic from known invalid networks should not be accepted on interfaces from which they should never have originated. The original idea as seen in RFC 2827 was to block traffic on an interface if it is sourced from forged IP addresses. It is a reasonable assumption for many organizations to simply disallow propagation of private addresses on their networks unless they are explicitly in use. This is a great benefit to the Internet backbone as blocking packets from obviously bogus source addresses helps to cut down on IP address spoofing which is commonly used in DoS, DDoS, and network scanning to obfuscate the source of the scan."

Dit gaat dus alleen op als je bijvoorbeeld RFC1918 adressen spoofed op een WAN interface, maar dat doe je niet in een amplification attack dan pak je als Reply host gewoon een ander valide WAN adres.

[Reactie gewijzigd door ShadowBumble op 2 maart 2018 20:36]

Lees rfc3704 eens.

Het gaat niet over rfc1918 range.

Maar over ranges die niet uit je netwerk kunnen komen blokkeren.
De RFC1918 was een voorbeeld omdat dat hier de meeste aanspreekt. Dit heb ik overigens wel verduidelijkt.

Waar jij naar verwijst is de "strict mode" implementatie van uRPF, deploy je "strict mode" dan werk je inderdaad alleen met bekende netwerken. Dit zou alleen viable zijn als je "Strict Mode" uRPF zou implementeren tussen je PE en je CPE devices binnen dezelfde ISP. Als we over Inter-ISP communicatie praten (zoals Internet, Tier 3(ISP) <--> Tier 2(Exchange/IXP) <--> Tier 1(DFR)) is dit niet toepasbaar, aangezien je nooit weet op welke edge border van jouw netwerk een bepaalde route binnen komt.

Als je dus zoals jij stelt "uRPF verplichten" dat zou dan betekenen dat iedere Tier 3(ISP) en fully meshed point to point peering dient te hebben met alle andere Tier 3(ISP) en op iedere link uRPF inplementeren.

Strict uRPF is ideal when you want to check the traffic coming from a user with a single uplink. As the user has a single uplink, the only path to reach the user is through the provider edge (PE) router performing the uRPF check. If the source IP address of an incoming packet doesn’t match the reverse path, the user is obviously trying to spoof its source IP address.

Strict uRPF may drop legitimate packets of multihomed customers when the customer wants its upstream ISPs to prefer one of the uplinks, but sends the outbound packets over another uplink. It fares no better in any environment with asymmetrical routing (pretty common in the Internet core).

Loose uRPF will catch packets sent from dark address space, but won’t stop source IP address spoofing using legitimate globally-reachable IP addresses. It’s becoming quite useless in the IPv4 world (most of the available IPv4 space is advertised to the global Internet).

[Reactie gewijzigd door ShadowBumble op 2 maart 2018 21:05]

De oplossing om IP spoofing te voorkomen is dat alle acces ISP's zo diep mogelijk in hun netwerk ip source guard in combinatie met een techniek als DHCP snooping implementeren. Wij doen dit ook en dat voorkomt dat een klant een ander IP adres kan instellen dan hij van onze DHCP server krijgt.
Daarnaast zorg IP source guard ervoor dat alleen verkeer vanaf dit toegekende IP adres toegestaan wordt vanaf de poort van de klant. Met deze techniek is het onmogelijk om IP spoofing vanaf je verbinding te doen. Deze techniek wordt ook wel BCP38 genoemd.

Het grote probleem is dat er bepaalde access ISP's die het vertikken dit te implementeren. Dit zijn vaak de ISP's die veel klanten hebben die juist bij hun komen omdat ze geen IP spoofing protection hebben geimplementeerd.
Tijd voor internet 2, waar ISPs die lid zijn verplicht zijn om mee te werken aan dit soort dingen ... en al het verkeer van internet 1 lage prioriteit krijgt.

Zal overigens wel niet mogen ivm internet neutraliteit.
De oplossing om IP spoofing te voorkomen is dat alle acces ISP's zo diep mogelijk in hun netwerk ip source guard in combinatie met een techniek als DHCP snooping implementeren. Wij doen dit ook en dat voorkomt dat een klant een ander IP adres kan instellen dan hij van onze DHCP server krijgt.
Daarnaast zorg IP source guard ervoor dat alleen verkeer vanaf dit toegekende IP adres toegestaan wordt vanaf de poort van de klant. Met deze techniek is het onmogelijk om IP spoofing vanaf je verbinding te doen. Deze techniek wordt ook wel BCP38 genoemd.

Het grote probleem is dat er bepaalde access ISP's die het vertikken dit te implementeren. Dit zijn vaak de ISP's die veel klanten hebben die juist bij hun komen omdat ze geen IP spoofing protection hebben geimplementeerd.
Ik mag je (helaas) geen punten geven maar volledig correct. Dit is overigens wel iets heel anders dan uRPF :) Ik vraag ik mij wel af bij zo’n implementatie op wereldwijde schaal hoe het dan met de ipv4 ranges zit die dagelijkse wijzigen van de grote Cloud providers zoals Azure en AWS. Die kopen en verkopen constant ipv4 blokken.
Die kan je dan gewoon behandelen als ISPs, met contractuele regels over due diligence om te voorkomen dat het al te vaak misgaat.
Het valt op zich wel mee hoe vaak grote partijen als AWS/Azure IP adressen kopen/verkopen. Verkopen zullen ze niet zo veel doen, maar kopen gebeurt wel. Je kan dat overigens allemaal inzien, omdat deze informatie publiekelijk beschikbaar is bij RIPE/ARIN.

Bij de configuratie van een interface op je switch/router kun je vaak aangeven of het inkomende verkeer gecontroleerd moet worden op source ip adres (ip verify source). Bij Cisco heet dit IP Source guard:
https://www.cisco.com/c/e.../guide/book/ipsrcgrd.html
Weet je wat titel is van rfc3704?

Je paste hier quotes zonder bron en zonder context.

Ik heb geen zin om het uit te leggen.
Tjah, en hoe ga je dat doen? We zijn ondertussen al 20 jaar bezig met IPv6 van de grond te krijgen en alsnog gaat het grootste deel van het internet over IPv4. Met een netwerk dat zo log is in verandering kan je dit echt niet op het netwerkniveau gaan oplossen.
Zo maar een gokje, gameservers? Daar kan je een UDP query request naar sturen om bv. playercount, map, server status etc. op te vragen. Ook hier stuur je een klein pakketje en krijg je een grote response. Gameservers zat die luisteren naar inkomende queries.
Die techniek is in het verleden al gebruikt om de gameservers zelf plat te leggen of om een DDOS uit te voeren: http://forums.warchest.co...rs-please-fix-the-exploit en http://forums.srcds.com/viewtopic/16710

[Reactie gewijzigd door azerty op 2 maart 2018 12:10]

ßsssssssssst........


Breng mensen niet op ideeën
Men moet steeds creatiever worden omdat men eigenlijk gebruik maakt van "lekken" met het gevolg dat deze "lekken" gefixt worden (duurt wel jaren) en men er niet meer gebruik van kan maken.
"Wil je niet dat jouw server hier voor misbruik wordt? Gooi dan de poorten dicht op je firewall! Het is sowieso een goed idee om alleen poorten op te zetten voor verkeer dat ook daadwerkelijk over het internet moeten gaan."

Dit lijkt me toch common sense. Treurig om te lezen dat mensen dus geen idee hebben waar ze mee bezig zijn.
Gameservers zijn over het algemeen ook een goede amplifier, denk aan call of duty, csgo, battlefield, etc. server. Vaak kun je met een kleine request een volledig scoreboard of andere uitgebreide info opvragen. Heb hier in het verleden toen ik zelf nog cod4 server draaide ook last van gehad.
Hoe kun je checken of die memcache bij je 'eigen' (gehuurde) server goed dichtgetimmerd is?
sudo nmap [EXTERNE IP] -p 11211 -sU -sS --script memcached-info

Zou als closed, filtered of open|filtered moeten verschijnen, dan is het goed.
Mocht er meer informatie bij komen en het gewoon op "open" staan ben je de sjaak.
Heb je -sS wel nodig? Dat is TCP Syn scan. Ik dacht dat memcached zuiver UDP draaide?
Je kan zonder, maar gezien je überhaupt niet wil dat je memcache public facing is voor tcp checken ook niet een onaangename extra

(Memcache doet ook tcp)

[Reactie gewijzigd door smiba op 4 maart 2018 17:06]

https://lzone.de/cheat-sheet/memcached

Als je de memcache server kan bereiken vanuit een netwerk waar dat niet de bedoeling is, dan heb je het genoemde probleem.
Kijk of je er vanaf huis/kantoor bij kan komen
Als je dat niet weet is het misschien slim om eens iemand in te huren om je server door te lichten. ;) Kan al voor een paar tientjes voor de basiszaken.

Dat terzijde: bekijk je memcached en firewall instellingen en je kan natuurlijk van buitenaf een verbinding proberen te maken met de memcached server op poort 11211. (Of de poort waarop je hem hebt ingesteld om op te luisteren, zie memcached configuratie. Men gaat vaak uit van de defaults maar het hoeft natuurlijk niet perse op die poort te staan en er zijn mensen die meerdere instances draaien op verschillende poorten; al zijn die over t algemeen ook slim genoeg om de boel te beveiligen.)

[Reactie gewijzigd door WhatsappHack op 2 maart 2018 11:47]

vanaf Internet een port scan doen. Maar eigenlijk moet je met bv iptables -L wel kunnen zien welk verkeer er doorgelaten wordt.

Aan de andere kant, als je dit moet vragen, dan vraag ik me af of je wel genoeg kennis hebt om zelf een server te beheren ;)
Antwoord je memcache op een IP dat niet 127.0.0.1 is?
netstat -tulpn niet op 0.0.0.0: memcached port

firewall-cmd --list-ports
kunt alsnog listenen op 10.x.x.x 192.168.x.x oid met DMZ/port forwarding dan ben je alsnog niet beveiligd..

AUB beter nadenken voordat zulke statements geplaatst worden (niet mensen laten denken dat ze veilig zijn terwijl dat mogelijk niet zo is).

[Reactie gewijzigd door grasmanek94 op 2 maart 2018 12:02]

Hoe kun je je memcache beveiligen? Of zijn dit speciale servers die niet goed zijn ingesteld en heb je hier geen last van met een simpele webserver?

[Reactie gewijzigd door henk1994 op 2 maart 2018 11:28]

Dit is niet een gevalletje van "beter" beveiligen.. Dit is gewoon een kwestie van geen beveiliging hebben draaien. Als je memcached openstaat op het WAN/internet dan heeft de beheerder niks meer gedaan dan een simpele "yum install memcached" en that's it.
Is dat de beheerder zijn schuld of de makers van het programma.

Als een programma standaard in lockdown staat ( local only ) = veilig.
Als een programma standaard open als een zeef staat... En dan verwacht je dat al wie memcache installeert weet dat het standaard open staat.

Draai geen memcache maar ik wist het totaal niet dat memcache in standaard configuratie van buiten te benaderen is.
De schuld van de beheerder wat mij betreft. Als je niet weet hoe de software werkt en wat het doet en wat erbij komt kijken, dan moet je er niet mee gaan spelen. Iedereen maakt foutjes natuurlijk of vergeet wel eens iets of ziet iets over t hoofd/wist iets niets, maar bij memcached is het vrij algemene kennis en het staat in bijna alle guides en docs wel vermeld... Dan is ‘t pure luiheid imho.

Op die manier kan je anders trouwens elke beveiligingsstap die je moet nemen wel gaan beschouwen als “fout van de ontwikkelaar”... Niets ervan. ;)

[Reactie gewijzigd door WhatsappHack op 2 maart 2018 11:51]

Ik heb even voor de fun op memcached hun website zitten te rondneuzen...

https://memcached.org/
-> Niets vermeld

https://memcached.org/about
-> Je ziet dat er communicatie is maar niets vermeld dat memcached standaard open staat.

https://memcached.org/downloads
-> Niets vermeld

-> We gaan dieper

https://github.com/memcached/memcached/wiki/Install
-> Niets vermeld

Ga de andere linken effen na...

https://github.com/memcac...ed/wiki/ConfiguringServer
-> Pas als je 2 pagina's diep bent, zie het het volgende in gewone text tussen de "wall of text":

By default memcached listens on TCP and UDP ports, both 11211. -l allows you to bind to specific interfaces or IP addresses. Memcached does not spend much, if any, effort in ensuring its defensibility from random internet connections. So you must not expose memcached directly to the internet, or otherwise any untrusted users. Using SASL authentication here helps, but should not be totally trusted.

Valt bijna niet eens op als ik eerlijk mag zijn.

-> Idem met de Wiki links...

Zo goed als geen informatie dat de boel standaard open staat. Ook niets vermeld van hoe de boel standaard af te sluiten.
Iedereen maakt foutjes natuurlijk of vergeet wel eens iets of ziet iets over t hoofd/wist iets niets, maar bij memcached is het vrij algemene kennis en het staat in bijna alle guides en docs wel vermeld... Dan is ‘t pure luiheid imho.
M.a.w je noemt iedereen een lui dat niet wisten dat de boel standaard open staat. Leuk ...

> het staat in bijna alle guides en docs wel vermeld
Om effen verder te gaan op je commentaar. Ik heb voor de fun even de basis guides gelezen op de eerste hits dat Google aanleverd. Weet je hoeveel vermelden dat memcached van buiten te benaderen is in standaard configuratie. Exact 1! Van de 10 guides. M.a.w, ik riek hier enorm veel bullshit dat sommige mensen verkopen.

En ik durf gerust mijn eigen hand omhoog te steken met de zeggen. "ik wist het ook niet". De meeste applicaties waarmee ik werk staan standaard dicht. Ik kan je andere software tonen waar het DUIDELIJK in VET geschreven staat direct in de installatie text. Maar blijkbaar niet eens op memcached hun eigen install guide. Zelf na het zoeken op de ontwikkelaars hun eigen website, is het verdoemt goed verstopt!

Als ik dit vergelijk met bepaalde andere software, waar je expliciet moet aangeven --insecure of gedwongen word om de config aan te passen om publiek toegankelijk te zijn of waar men met certificaten werkt voor het draaien in clusters of je specifiek --join of --host or andere instellingen moet aangeven.

Veel mensen in mijn mening installeren memcached niets als cluster maar als speedboost op een single machine. Dan is deze default open setup gewoon de meeste domme standaard instelling dat ik in jaren gezien heb van ontwikkelaars.

Als ontwikkelaar hun software niet standaard beveiligd releasen, dan moeten de fanboys hier ook niet afkomen dat de eind gebruiker het maar moesten weten. Want ik heb zojuist aangetoond dat op hun eigen website, het goed begraven zit. Dat de meeste guides dat ik gezien heb, gewoon geen woord spreken over de open instelling.

En om eerlijk te zijn, welke idioten releasen een programma met puur open setting zoals dat! Sorry als ik het zeg maar die commentaar van je en sfranken is duidelijk mis. Klinkt mij als "victim blaming" omdat ze niet genoeg hun best deden in jullie ogen. Terwijl het duidelijk slecht aangegeven is in zelf de ontwikkelaars hun website.


Ter Info:

https://github.com/memcached/memcached/issues/348
https://github.com/memcached/memcached/wiki/ReleaseNotes156

Vanaf nu zal memcached standaard de UDP poort gesloten hebben. O kijk ... blijkbaar wanneer er iets misloopt dan kunnen ze wel de boel afsluiten.
Ehmm... Nee, natuurlijk gaan ze dat niet op hun homepage of downloadpage zetten. :/
Dat is een beetje onzinnig en het slaat nergens op dat je dat zou verwachten. ;)
Het eerste dat je doet als je meer wilt weten is de handleiding lezen. Als je je baan serieus neemt tenminste. En dat is waar het heel duidelijk en helder beschreven staat. :) Dit soort zaken staan altijd in de handleiding. Een fabrikant van een magnetron zet ook niet de hele waslijst aan wat er wel en niet in mag op de doos, dat staat ook gewoon in de handleiding beschreven. Dat is heel normaal.

Zoals je zelf al gevonden had staat het kraakhelder beschreven op:
https://github.com/memcached/memcached/wiki/ConfiguringServe
En hoe kom je daar? Je klikt op memcached.org op "Wiki" boven in of onderin op het in koeienletters groot geschreven "Need more information? Check out (and give feedback on!) The Wiki" en vervolgens klik je in de inhoudsopgave op "Configuring a Server". Nou, dat koste wel 2 klikjes. :P 3 als je ook nog meteen naar "Networking" wilt springen. Ja dat is echt heel diep weggestopt en kost echt superveel moeite. :X

Dat is imho dus helemaal niet moeilijk te vinden gezien er meerdere keren rechtstreeks naar de documentatie wordt gelinkt vanaf de homepage... Er is ook geen sprake van een wall of text en het staat er heel helder beschreven. Dus: ja, als je het al veel teveel moeite vindt om 1 A4'tje aan tekst te lezen met betrekking tot hoe je het moet installeren en instellen en wat de aanbevelingen zijn, dan ben je wat mij betreft inderdaad heel erg lui... Excusez moi.

Handleidingen zijn er om te negeren, maar niet in een productieomgeving en als je weet dat het een tool is waar gevoelige data in kan komen te staan. Als je het dan al teveel moeite vindt om 2 minuten de tijd te nemen om wat pagina's uit de documentatie te lezen en het serieus al "diep weggestopt" vindt terwijl het meteen bij "Configuring Server" verschijnt, ja dan beschouw ik dat als luiheid. Sorry. Ik vind er niets "verstopt" aan. Het staat er kraakhelder en duidelijk. Als het je niet opvalt, dan lees je het gewoon niet. Dat kan je de ontwikkelaars niet kwalijk nemen.

Even goede vrienden hoor, je moet het zelf weten hoe je het doet en of je even de handleiding wilt lezen om zeker te zijn dat alles goed zit - maar schuif alsjeblieft niet je eigen gebrek aan inzet af alsof het de schuld van de ontwikkelaar is als het vervolgens niet correct geconfigureerd blijkt. :S
RTFM is hier heel duidelijk van toepassing.


Dat terzijde snap ik sowieso niet waarom mensen alle poorten openzetten zodat dit sneller een probleem is... Waarom? Zet gewoon standaard alle poorten dicht en zet uitsluitend open wat je nodig hebt. Helpt ook dit soort situaties mede te voorkomen, en is gewoon best-practice. Maarja, als het al teveel moeite is om de documentatie van de software te lezen dan zal een firewall installeren en instellen waarschijnlijk ook al teveel gevraagd zijn. :P

[Reactie gewijzigd door WhatsappHack op 2 maart 2018 17:55]

Eigenlijk moet de eindgebruiker het wel weten. Zeker bij systemen in productie, die rechtstreeks op het internet hangen, mag ik hopen dat de beheerder weet waar hij/zij mee bezig is en dat de firewall goed is opgezet. En daarmee bedoel ik: alle poorten toe en enkel die poorten open die noodzakelijk zijn.

Zelfs als de software zelf wel in de nodige config voorziet om enkel lokaal te luisteren, ga jij daar van uit gaan en hopen dat het veilig is? 1 slechte bug in de software is dan voldoende om opnieuw kwetsbaar te zijn terwijl je net denkt dat je, zonder dat je je firewall hebt opgezet, toch veilig bent.
Beveiliging is altijd een kwestie van lagen. Je komt daar zelf eigenlijk ook al mee: als er een bug is dan kan je opeens onveilig zijn. Maar dat geld natuurlijk net zo goed als de handleidingen, het besturingsysteem, enzovoort.

Ik vind ook dat je van een ontwikkelaar of systeembeheerder moet kunnen verwachten dat de firewall opgezet is en dat de servers correct geconfigureerd zijn. Maar dat betekend niet dat je de beveiligingsinstellingen ergens kan wegstoppen in de documentatie. Het feit dat e.g. Windows ook standaard services bind aan alle netwerkadapters helpt ook niet. En daar memcached specifiek geprogrammeerd is als server zou het ook duidelijk moeten weergeven op welke poorten het actief is zodat het niet makkelijk vergeten wordt + waarschuwing als het draait op poorten die hiervoor niet bedoeld zijn.

Dus is het memcached of de ontwikkelaar? Wel als memcached de documentatie en applicatie niet security aware heeft gemaakt dan draagt memcached zeker wat verantwoordelijkheid. Maar dat ontslaat degene die memcached configureerd niet van de verantwoordelijkheid om de security te testen en de firewall te configureren. Lijkt me dat beiden verantwoordelijk zijn.
Ik ben het gedeeltelijk wel met je eens om het niet zomaar een 'fout' van de ontwikkelaar te noemen, maar beveiliging begint juist wel bij de ontwikkelaar en daarmee ook de standaard configuratie. Als je je software standaard 'dicht' zet dwing je beheerders bewust na te denken, hopelijk dan, om alleen aan of open te zetten wat nodig is. Vandaag de dag geen vreemde instelling om je software met die instelling te maken en standaard te configureren.
Verplicht cursusje bij elk verkocht keukenmes?
Met certificaat natuurlijk zodat je voor je 2e mes geen uren kwijt bent.

Nee, geen enkele schuld heeft die ontwikkelaar. Sterker nog, ik zou me beledigd voelen.

[Reactie gewijzigd door FraterFenantius op 2 maart 2018 17:46]

Waarom zou je een cursus moeten volgen bij het kopen van een keukenmes?

Ik zeg duidelijk dat je de schuld niet zomaar bij de ontwikkelaar kan leggen, dus waarom jij dan met de vergelijking komt dat je bij het kopen van een keukenmes een cursus zou moeten volgen snap ik niet helemaal.
Ten eerste begint beveiliging weldegelijk bij de ontwikkelaars, die maken de code het is wel zo handig als deze beveiling als uitgangspunt nemen, zeker met serversoftware, helemaal met software icm met internet. Daarbij vind ik persoonlijk het helemaal geen rare instelling om de standaard configuratie en beveiliging bij de ontwikkelaars te leggen, die maken immers de software dus standaard beveiling als je het pakket installeert vind ik geen vreemde gedachte, daarmee dwing je beheerder bewust dingen aan of open te zetten en dat kan alleen maar ten goede uitpakken.

Over windows heeft men ook genoeg geklaagd dat die standaard zoweel services en poorten openzette, daar hoorde je nooit commentaar over als 'cursus bij het kopen van een windows'.
Of hoe zou je het vinden als firewalls standaard alles open zetten? Nee, ook daar vind men het normaal als de firewall standaard dicht staat en de beheerder bewust dingen open zet.
Dus waarom het nu zo vreemd is om te stellen dat de standaard configuratie van een stuk software als memcached beter dicht kan staan ontgaat mij eigenlijk...
Ik heb je relaas gelezen en het was gewoon komisch.
..
Jij leest die handleidingen op zoek naar een waarschuwing met een vooringenomen mening.
Blijkbaar begrijp je niet eens wat ik schrijf. Volgens mij ben jij degene die met een vooringenomen mening mijn reactie leest en het daardoor niet eens begrijp of ziet wat ik precies schrijft. En dan noem jij mijn reactie komisch..kijk eens in de spiegel nadat je mijn reactie nog een begrijpend probeer te lezen.
//end moddergooien

Ik zeg nergens dat ik de schuld bij de ontwikkelaar leg, ik zeg alleen maar dat ik vind dat de ontwikkelaar beveiliging in gedachte moet nemen met het maken van de software en dat deze ontwikkelaar in mijn opinie misschien de standaard configuratie van zijn software nog eens zou kunnen bekijken, maar dat is puur mijn mening, ik zeg nergens dat het moet of dat ik hem ergens schuldig aan houdt, dat is wat jij mij toebedeelt en in de mond legt!
Mijn firewall hoef ik niet dicht te zetten voor memcached. Die staat al dicht.
Joh, hiermee onderbouw je alleen maar stelling, standaard beveiliging out-of-the-box. En toch spreek je mij erop aan als ik stel dat de makers van memcached hun standaard configuratie misschien eens moeten bekijken om misbruik te voorkomen door lakse beheerders. 8)7
Die ontwikkelaars zijn terecht niet bezig hiermee
Dus dat ontwikkelaars niet met beveiliging van hun eigen software bezig zijn vind jij terecht? Dat vind ik dus onzin, als ontwikkelaar kan je best nadenken over de beveiling van je software en hoe je dit standaard instelt. Wat je ook doet, laat het een weloverwogen keuze zijn.
Als jij met een standaard beveiling kan voorkomen dat je software misbruikt wordt dan denk ik dat het zeker het overdenken waard is wat je doet. Het is laksheid en naiviteit als je niet kan of wil overdenken wat de standaard configuratie van je software voor gevolgen kan hebben.
"Waarom zou je een cursus moeten volgen bij het kopen van een keukenmes?"
Nee, natuurlijk hoeft dat niet.
Ook geen handleiding met allerlei aanwijzingen om dom gedrag te voorkomen.
Zoals ook hier. Ze hoeven zoiets niet te noemen.
Ik zeg ook nergens dat het moet, het zou alleen verstandiger zijn, dat is wat ik zeg. Maar uit je relaas is al gebleken dat je dat niet eens begrepen hebt uit mijn verhaal.
De ontwikkelaars van memcache maken die software niet voor mensen die van toeten noch blazen weten.
Dat kan wel zo zijn, maar dat weerhoudt mensen met minder verstand van deze software er blijkbaar niet van om deze software te gebruiken. Het feit dat meer dan 80.000 memcached servers aan het internet hangen die niet goed beveiligd zijn en vanaf het internet bereikbaar zijn bewijst dat je je eigen stelling niet zomaar voor lief kan nemen en daarop kan vertrouwen.
nieuws: 'Ruim 80.000 open memcached-servers kunnen gebruikt worden voor ddos-...
Echt een hele rare houding heb je naar hen.
Jip, stellen dat beveiling out-of-the-box misschien een goede aanpak is is inderdaad een rare houding naar de ontwikkelaars van software. 8)7 De afgelopen 10+? jaar is dit ook helemaal geen belangrijk item geweest om het internet veiliger te maken... of toch wel?
Maar hier komen we toch niet uit.
Jij gaat je mening niet veranderen en ik ook niet, zeker niet door wat ik hier allemaal schrijf.
Misschien dat een gebeurtenis in de toekomst je misschien op andere gedachten brengt.
Volgens mij leggen onze verschillen helemaal niet zo ver uit elkaar, dat is iets wat jij er van maakt omdat je niet goed kan/wil begrijpen wat ik precies zeg en er zelf allerlei dingen bij verzint die ik helemaal niet zeg.
Het is natuurlijk eigenlijk de fout van de boeven achter de ddos.
Professionals zeggen dan ook altijd tegen juniors: RTFM.
Beheerder zijn schuld, want het staat bij Memcached zeer goed gedocumenteerd. Iedereen die begrijpend kan lezen had dat dus kunnen en moeten weten.
Inderdaad....
Klinkklare onzin om maar een fractie van de schuld af te wentelen op de ontwikkelaar van memcache.

Al het inkomend verkeer standaard dicht en enkel poorten openzetten naar daemons die ook echt naar het Internet moeten kunnen luisteren.
Zo is het ook wel begrijpelijk dat al die VPS subnets overal op blocklists staan.

Er zullen binnenkort wel VPS's komen waarbij de firewall door de leverancier wordt beheerd. Zo'n beetje iedereen die ls kan typen denkt dat ze een linux server kunnen beheren.
Heel simpel: gewoon alleen op 127.0.0.1 laten draaien in plaats van op alle interfaces.
Gaat niet werken met een Memcached cluster....
VLAN voor je Memcached cluster
Wat bedoel je met cluster ? Die dingen repliceren namelijk niet, dus als je gewoon een server met memcached-only bedoelt doe je even wat firewalling.
Klopt, maarja iemand die een cluster heeft draaien....

Daarbij ga je niet vanuit dat die zo incompetent is dat de memcached server,
vanaf buitenaf onbeveiligd benaderbaar heeft ;)
Dat zei ik ook, maar blijkbaar zijn er O.S. die het dan toch nog op je publieke interface gooien. Wist ik tot een paar minuten geleden ook niet.
Ruben van Staveren

Which has an interesting side effect on @freebsd jails, where for convenience binds for the loopback address gets the jail ip & interface. This is how I inadvertently exposed my memcache to the world. Always firewall
Om overlast te beperken kun je ook op de router via UDP source of destination port 11211 dicht zetten... Lees ook eens https://blogs.akamai.com/...p-reflection-attacks.html

[Reactie gewijzigd door UvAkid op 2 maart 2018 11:34]

Je kan nog beter alle poorten dichtzetten behalve de poorten die je daadwerkelijk verkeer van buitenaf wilt laten accepteren. Eventueel voor bepaalde vertrouwde en/of interne IP’s een uitzondering toevoegen zodat die wel alle poorten kunnen benaderen.

[Reactie gewijzigd door WhatsappHack op 2 maart 2018 11:41]

Indien mogelijk kun je de servers alleen lokaal laten luisteren, een aantal van deze servers staan ook naar 'buiten' te luisteren,

Zie: https://blog.cloudflare.c...-attacks-from-port-11211/ bij "Let's fix it up"

[Reactie gewijzigd door Woesjah op 2 maart 2018 11:32]

Door memcache achter een firewall te zetten. En als dat niet kan authentication te gebruiken. (zie https://github.com/memcached/memcached/wiki/SASLAuthProtocol)

[Reactie gewijzigd door teunw op 2 maart 2018 11:30]

Firewall, firewall en nog eens firewall
Een simpele webserver gaat normaal gezien zo geen service draaien.

Om jezelf te beschermen is het eigenlijk heel eenvoudig: laat geen verkeer vanaf het internet toe. Zo'n service moet alleen bereikbaar zijn voor de webserver(s), en dus een vast IP (of een vaste range) die je kan filteren met een firewall. Als het een lokale webserver is kan je memcached normaal gezien ook alleen lokaal (vanaf dezelfde server) benaderbaar maken, dat maakt het nog eenvoudiger.

Een heel groot deel van de servers die voor zo'n aanval gebruikt werden zijn imo toegankelijk omdat een beheerder lui/onbekwaam geweest is.
Je kunt het vrij simpel in de configuratie van je Memcache service instellen (in memcached.conf) als je wil dat Memcache alleen vanaf je server zelf te benaderen is.

Als je wil dat Memcache alleen vanaf bepaalde externe IP adressen te bereiken is dan stel je dat in je firewall in. Net zoals voor elke andere service die je draait. Daar zijn firewalls voor bedoeld.
Vind de bandbreedte van 1Tbit/s erg moeilijk voor te stellen. Hoe staat deze in verhouding met DDOS'en van de afgelopen jaren? Nemen de volumes toe? En hoe nemen die toe?

Iemand een idee?

Van Github staan er wel wat dingen in het artikel en van het afgelopen jaar. ben benieuwd wat de trend is de afgelopen jaren. Is het exponentieel?

[Reactie gewijzigd door armageddon_2k1 op 2 maart 2018 11:37]

Het is dus niet nieuw, wat ook in het artikel staat:
Volgens Akamai ging het om de grootste aanval waar het tot nu toe mee te maken kreeg en was deze wat verkeer betreft meer dan dubbel zo groot ten opzichte van een aanval via het Mirai-botnet uit 2016. De aanval lijkt ook omvangrijker dan die op dns-provider Dyn, die eveneens in 2016 via het Mirai-botnet plaatsvond, en voor 1,2Tbit/s aan dataverkeer zorgde.
De DdoS-aanvallen die stukken kleiner zijn qua capaciteit zijn veel populairder lijkt mij, omdat je dat als het ware 'gewoon' kunt huren.
Is Jelle weer vrij?
Iemand heeft weer 40euro uitgegeven aan een webstresser :P
Dit is de vraag die op de één of andere manier niemand stelt. Want waarom wordt Github aangevallen? Er moet ergens een motief achter zitten.
Waarom moet er een motief zijn? Heb jij in heel je leven nog nooit iets zomaar gedaan? Voor de fun?
Als je weet dat er gevolgen aan zitten dan ben je over het algemeen wel voorzichtig, ook al is het maar voor de fun. Github aanvallen leidt zeker tot reacties, dus ik denk dat er meer achter zit (maar dat hoeft niet specifiek met github te maken te hebben).
Misschien is Github zelf niet de (uiteindelijke) target, maar een test om te kijken hoeveel bandbreedte ze konden genereren.
Weet iemand of er ook DDOS aanvallen op sourceforge.net zijn? De laatste paar dagen kan ik projecten op de website nauwelijks bereiken. Ben er een lange tijd niet geweest, dus weet niet of dit normaal is....

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

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