Spamhaus waarschuwt voor ddos-aanvallen op snmp-servers

De Britse spambestrijder Spamhaus heeft laten weten dat het in december ddos-aanvallen heeft moeten verwerken van een relatief nieuw type. De aanvallers kozen voor een snmp-aanval waarbij het doel wordt overspoeld met udp-pakketjes.

Spamhaus stelt dat het een verschuiving signaleert in het type aanval op zijn website. In plaats van 'klassieke' dns amplification attacks, waarbij het dns-systeem wordt misbruikt, hebben de aanvallers van de spambestrijder recentelijk gekozen om het snmp-protocol te misbruiken. Ook via deze relatief nieuwe methode zijn zij in staat gebleken om een stroom udp-pakketjes met spoofed ip-adressen naar een doel te sturen. Omdat veel snmp-servers via dit type aanval met een relatief kleine aanvalsstroom op de knieën zijn te krijgen, en daarmee de achterliggende webservers onbereikbaar worden, kan een snmp-aanval een effectief wapen zijn.

Spamhaus is in de loop der jaren al diverse malen door ddos'ers op de korrel genomen. In de maand december kreeg het echter een snmp ddos-aanval te verwerken, die in omvang vergelijkbaar was met de grootste 'klassieke' ddos-aanval op zijn infrastructuur. In samenwerking met overheidsinstellingen en beveiligingsbedrijven zegt Spamhaus de aanvallen te hebben afgeslagen en inmiddels stappen te hebben ondernomen om de aanstichters te vinden.

Volgens Spamhaus kan een website zich wel degelijk goed wapenen tegen snmp-aanvallen. De verdedigingslinies moeten het liefst zo 'hoog mogelijk', dus ver weg van het doel, worden opgetrokken. Door met behulp van een firewall ip-pakketjes te filteren op mogelijk gespoofde adressen, via ingress- en egress-filtering, kunnen de meeste ddos-aanvallen al gepareerd worden. Spamhaus stelt echter dat webhosters er goed aan doen om een firewall voor hun snmp-server te plaatsen en toegang te beperken tot een klein aantal ip-adressen.

Reacties (31)

[wica]

In je firewall alleen maar verkeer van bepaalde IP's of range toe staan? Je wilt toch niet dat de hele wereld bij je snmp kan?

[Cybje]

Niet elk apparaat ondersteunt firewalling op SNMP. Uiteraard is het makkelijk te firewallen als je een normale server met een OS draait, maar vooral dingen als netwerkswitches, powerswitches, etc. ondersteunen het niet altijd. Vooral de netwerkswitches die semi-managed zijn, dus niet de volledig managed Cisco/Juniper/Brocade/whatever dingen.

Maar gezien het hier vooral over webservers lijkt te gaan, heb je inderdaad gelijk. Sterker nog, het liefst gooi je je SNMP dingen over een apart (V)LAN, omdat dat überhaupt alleen voor intern gebruik is.

[wica]

Apparaten die geen fw ondersteunen, hoor je de management interface niet direct aan internet te hangen.

[arjankoole]

Apparaten die geen fw ondersteunen, hoor je de management interface niet direct aan internet te hangen.

leuk, maar in praktijk niet altijd geheel haalbaar.

[]Byte[]

Niet altijd? Of gewoon uit luiheid te beroerd om een fatsoenlijk ontwerp te maken waarbij het WEL is afgeschermd?
Het is niet de óf het kan maar of de WIL er is om het te doen!
Als ik mij HP/Cisco/Juniper/Brocade/... rechtstreeks aan het internet gaat hangen moet ik niet piepen dat ie een keer te grazen genomen gaat worden.
Management beschikbaar stellen via internet is één grote NO-NO!
Als ik het echter zo configureer dat management maar via 1 poort kan en die vervolgens op een VLAN prop waar de rest van de wereld niet bij kan heb je dat obstakeltje alvast geslecht.

Helaas gebeurd het nog steeds veel te vaak dat commerciële belangen prevaleren boven veiligheid.
En als ze dan een keer voor de haaien gaan is het kommer en kwel klagen.

[arjankoole]

Jij pleegt de gevaarlijke aanname dat je de mogelijkheden hebt dat te doen bij een omgeving. Spamhaus kan dat wellicht niet.

Er zijn talloze hosting omgevingen bij ISP's wereldwijd waarbij je een publiek ip krijgt, en switchpoort, en een plek om je server op te hangen. Meer niet.

Wat nou ontwerp maken? D'r is geen ontwerp.

[Reactie gewijzigd door arjankoole op 22 juli 2024 20:37]

[Verwijderd]

zijn zij in staat gebleken om een stroom udp-pakketjes met spoofed ip-adressen naar een doel te sturen

Als de IP's gespoofed worden dan krijg je alsnog de volle laag.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 20:37]

[thegve]

Dan zul je wel eerst moeten weten welke IP's je dan specifiek moet spoofen. Tenzij de hackers inside informatie hebben lijkt me dat ook lastig.

[arjankoole]

In je firewall alleen maar verkeer van bepaalde IP's of range toe staan? Je wilt toch niet dat de hele wereld bij je snmp kan?

Dat is een interessante vraag ja. Op z'n minst heb je er een locale firewall of ACL voor hangen. Maar het artikel maakt natuurlijk wel specifiek melding van gespoofte IP adressen, daardoor kan je makkelijk door rudimentaire filters heen komen ( 127.0.0.1 wordt meestal altijd allowed, bijvoorbeeld ).

[dasiro]

127.0.0.1 wordt meestal altijd allowed, bijvoorbeeld

toch nooit als die van buiten komt ?? da's gewoon om problemen vragen

[arjankoole]

[...]


toch nooit als die van buiten komt ?? da's gewoon om problemen vragen

als de firewall op dezelfde machine draait (bijvoorbeeld ipfw, PF, ipchains/tables/whatever) is dat verschil niet altijd geheel duidelijk. Soms kan localhost verkeer over de ethernet interface komen, en niet alleen over de loopback.


Wat jij schetst is een stuk duidelijker te detecteren als je een firewall machine er voor hebt draaien, maar dat is nog lang niet altijd geval.

[zvbhvb]

En dan nog met een te makkelijke community string is vragen om problemen.

[arjankoole]

En dan nog met een te makkelijke community string is vragen om problemen.

community string maakt bij deze aanval niet uit. Een werkende poort 161 is voldoende.

[Cornelisjuh]

Even een vraag voor die Tweakers hier, als je je IP Adres Spoofed dan is het toch niet meer mogelijk om verkeer terug te ontvangen ? Aangezien de servers response proberen terug te sturen naar een spoofed IP adres. Hoe weten de aanvallers dan of de aanval succesvol is ?

[raymonvdm]

Ik denk door het feit dat de host ineens niet meer reageerd op webserver verzoeken (poort 80/443) Oplossing is eenvoudig denk ik door te zorgen dat SNMP alleen actief is op de interface waar je hem gebruikt en dat dan natuurlijk niet doen op je publieke interface.

[Reactie gewijzigd door raymonvdm op 22 juli 2024 20:37]

[Verwijderd]

Je hoeft zelf geen pakketjes terug te krijgen om te zien of de aanval effectief is, gewoon kijken of de website down is.

[efari]

de aanvallers sturen (met duizenden tegelijk) pakketjes naar heel veel andere servers (dus niet naar de server van het slachtoffer) met als gespoofd IP dat van het slachtoffer

op die manier zullen (honderd)duizenden onwetende servers willen contact maken met je slachtoffer, zonder dat die daar ernstige load van ondervinden, maar je slachtoffer wel

[C7RL]

SNMP is (meestal uitgezonder V3) UDP verkeer en behoeft niet altijd een response tekrijgen bij bijvoorbeeld een SNMP-TRAP naar een server (poort 162). Ik denk dat het daarom gaat en niet bij SNMP-GET (poort 161) om bijvoorbeeld infomatie uit te lezen van een device. Het zou kunnen zijn dat de SNMP server (BV HP Openview) een PUBLIC IP-adres heeft en dat deze door in mijn ogen een configuratie fout van buiten bereikbaar is. Je zou in dat geval de mogelijkheid hebben om SNMP-TRAP pakketten te spoofen met IP adressen die in hun netwerk worden gebruikt (spoofen). Ik kan maar één reden bedenken waarom ze die SNMP server geen private adres geven en dat is om routerings problemen te voorkomen omdat men bv op meerdere plekken al private space in gebruikt heeft. Ik weet dat een groot bedrijf dat begint met A en eindigt met ORIGIN ook deze truuk moet uithalen omdat men anders wereldwijd niet meer kan beheren. Heeft je SNMP server een Private space adres dan moet de beheerder zowieso ergens een NAT maken van buiten naar binnen om connectie mogelijk te maken, maar je staat nooit iedereen toe.

[Gaffel]

Het spoofen van IP adressen in deze tijd is toch verschikkelijk moeilijk en te makkelijk alsnog traceerbaar?

Voor de rest lijkt het me lastig als je SNMP aan wilt bieden naar buiten toe om dan alleen een bepaalde IP-range toe te staan, je sluit dan toch mensen buiten lijkt me..

Zou je niet met Karma kunnen werken, indien er te veel aanvragen / seconde zijn gaat je karma naar negatief en mag/kun je minder requests doen omdat de rest alsnog geblocked wordt door een firewall..
Dit zou evt. niet werken met spoofed IP's, omdat je steeds andere IP's te zien krijgt.

[Cybje]

Spoofen blijft vaak wel mogelijk. Zolang de routers waar je langs gaat het verkeer gewoon doorlaten (en dat gebeurt vaak wel), kun je gewoon spoofen.

Maar om wat voor reden zou je anderen SNMP toegang willen geven? Daar heeft echt niemand iets aan. Wat zou bijvoorbeeld mijn moeder met de interfaceinformatie van de Cisco switch van een ISP moeten?

[Gaffel]

Nee lijkt me ook niet geschikt idd voor iedereen,
maar het lijkt me dat je als beheerder van een netwerk ook niet constant hetzelfde IP hebt. en natuurlijk kun je best een VPN openen en alsnog inloggen.

Daarnaast kan ik ook op mijn VPS/Dedicated server SNMP aanzetten en alles uitlezen, maar voorlopig heb ik geen zin om VPN te draaien en heb ik ook geen dedicated firewall draaien, dus staat alles nog open. Gelukkig heb ik geen SNMP aan hoeven zetten, mijn server is vooral een " just play around" apparaat.

Ik las dat SNMP op port 161 draait, dus daar kun je met een firewall dan wel mooi op filteren zodat een bepaalde IP range alleen toegang krijgt.
Ik wil alleen aangeven dat niet iedereen dit dus doet of de noodzaak hiervan inziet.

[Cybje]

Meestal lees je niet rechtstreeks SNMP data uit, maar doe je dat vanaf een losse server met een monitoringpakket, waarmee je dan weer statistieken maakt en dat je vanuit de SNMP data waarschuwingen genereert. Vaak heeft zo'n server gewoon een vast IP en dan logt de beheerder vanaf huis in met een gebruikersnaam/wachtwoord op die server. Het maakt dan weinig uit als het IP van de beheerder wijzigt.

Als je toch rechtstreeks SNMP wilt uitlezen en je bent te lui om het te beveiligen met een VPN, of om soms je IP te wijzigen in de firewall, ben je mijn inziens een slechte systeembeheerder. Dit soort dingen goed beveiligen is onderdeel van je werk.

[C7RL]

Routeren gaat op basis van Destination IP adres en het source adres wordt gespoofed. Waar het vandaan komt lijkt dan ook van intern te komen, in ieder geval zullen ze dat proberen. De router of FW zonder anti-spoof policy/acl kan dan het verkeer doorlaten.

[itlee]

sja,...wie gaat snmp nou open zetten zonder knappe firewall regels?
of gewoon helemaal uitzetten en zorgen dat je management gewoon over een ipsec tunnel heen lopen.

Dan heb je hier geen last van.

[arjankoole]

sja,...wie gaat snmp nou open zetten zonder knappe firewall regels?
of gewoon helemaal uitzetten en zorgen dat je management gewoon over een ipsec tunnel heen lopen.

Dan heb je hier geen last van.

diverse servers waar ik wat mee doe hebben een publiek IP adres direct op hun netwerk interface. Daar hangt dus geen firewall voor. Zo werken veel hosting omgevingen bij ISP's. Op het systeem zelf zijn wel diverse beveiligingen actief, maar dat betekend wel een stuk meer opletten dan een default to deny aan de voorkant die per definitie alles tegenhoudt.

[Reactie gewijzigd door arjankoole op 22 juli 2024 20:37]

[wildcheese]

Eh..als ze een publiek IP addres op de server hebben betekent het nog niet dat er geen firewall voor zit. Alleen dat de firewall die ervoor zit geen NAT doet. In de meeste datacenters wordt het verkeer standaard via een firewall afgewikkeld

[Kabouterplop01]

Tenzij het om een kwetsbaarheid gaat, ofeen provider die bijvoorbeeld een modem gebruikt en vergeet snmp dicht te zetten, of dit gebruikt om bepaalde stats uit te lezen, zonder dat de provider een management adres gebruikt, welke over het algemeen deel van een private reeks is.
Behoorlijk heftig effect lijkt me: snmpwalk naar een host xn en de output naar het gespoofde target.
@arjenkoole: ik zie de clue nog niet bij :"Alleen een werkende poort 161 is voldoende"

[Reactie gewijzigd door Kabouterplop01 op 22 juli 2024 20:37]

[C7RL]

Ik zou bijna zeggen de maatregelen genoemd in het bericht als "dubbel post" willen bestempelen . DNS en SNMP met hoofdletters net als IP en (D)DOS dit zijn afkortingen.

[Jack Flushell]

Spel- en tikfoutjes - en dus *geen* andere foutjes - deel 41

[C7RL]

Oh sorry ja ik ben er al weer een poosje uitgeweest....

[xiphoid]

7 maanden oud nieuws, maar ik kan me voorstellen dat die grijze jassen dit nu pas iets over te horen krijgen.