Onderwerp: NTP reflection...iemand reeds van gehoord?

Beste,

Als bijdrage aan het NTP project host ik een NTP server op al mijn servers. Nu kreeg ik daar vorige week een abusemelding in verband met mijn NOC vps:

Dear Abuse Department,

You received this email because your email is listed on the whois contact information of this IP.
Please be advised, our firewall detected a large DDOS flood, some traffic in this attack were originated from your network.
The IP in your network participated in this attack was 46.28.43.66. The device sending this traffic might be compromised or misused.

Please investigate into this issue and suspend any offensive devices ASAP.

Below are flow samples taken by our routers during a period of the attack, which including timestamp, duration of this sample, protocol, source IP and source port, destination IP and port, number of packets received, number of bytes received and
number of the flows received of this sample.

If you have any feedback or question, please feel free to reply
this email. We appreciate your effort on this matter.

NTP server owners: Please set rate limit, a lot of ddos attacks are now using NTP servers to reflect.

Time Zone is PST (GMT-8:00)
Date_flow_start Duration Proto
Src_IP_Addr:Port Dst_IP_Addr:Port Packet Bytes Flows
2013-11-03 22:38:23.436 65.400 17 46.28.43.66:123 - 162.218.48.78:80 292480 136880640 3

Network Operating Center
CNSERVERS LLC
+1.9713276731

Nu heb is deze VPS per direct uitgezet, en re-installed zonder NTP (voor alle zekerheid).


Echter... Nu blijk ik thuis (waar de eigenlijke servers staan) dezelfde problemen te hebben!
Zie bvb http://www.dcmerelbeke.be/feiten.html voor de statistiekjes. En dan moet ik nog vermelden dat dit een lijntje is met 25mbit down en 10mbit up. Hier staan momenteel een 5-tal servers te draaien op dat lijntje die allen NTP draaien. De servers op zich draaien nog wat vps'jes maar deze ip's zijn niet gekend als publieke NTP servers.

Iemand een idee hoe dit kan tegen gegaan worden? Behalve gewoon NTP uit zetten

NTP sterk beperken of in ieder geval een beperking in het aantal requests/uur/IP instellen kan al helpen. Het beste zou het zijn als iedereen BCP38 gaat forceren, maar dat zal wel niet gauw gaan gebeuren.

In de praktijk zijn de meeste tools die UDP gebruiken te misbruiken, voor NTP kun je overigens ook de reply per request beperken. Er zijn bepaalde verzoeken die een extreem "leuke" verhouding hebben tussen inkomend en uitgaand verkeer (gezien vanuit de aanvaller). Beperk het (voor zover dat kan) tot enkel de tijd terug geven zonder aanvullende informatie en je wordt al veel minder interessant om te misbruiken voor aanvallen.

Oorspronkelijk geplaatst door IT-worX

Beste,

Als bijdrage aan het NTP project host ik een NTP server op al mijn servers. Nu kreeg ik daar vorige week een abusemelding in verband met mijn NOC vps:

[knip abuse klacht]

Nu heb is deze VPS per direct uitgezet, en re-installed zonder NTP (voor alle zekerheid).

Echter... Nu blijk ik thuis (waar de eigenlijke servers staan) dezelfde problemen te hebben!
Zie bvb http://www.dcmerelbeke.be/feiten.html voor de statistiekjes. En dan moet ik nog vermelden dat dit een lijntje is met 25mbit down en 10mbit up. Hier staan momenteel een 5-tal servers te draaien op dat lijntje die allen NTP draaien. De servers op zich draaien nog wat vps'jes maar deze ip's zijn niet gekend als publieke NTP servers.

Iemand een idee hoe dit kan tegen gegaan worden? Behalve gewoon NTP uit zetten

Inderdaad geen publieke NTP service meer draaien.
Net zo min als je (meer) SMTP relay voor 'de wereld' kunt draaien, of open DNS resolvers, helaas.

Je kunt prima NTP draaien voor je eigen servers onderling, en syncen met internet time servers zonder dat je zelf voor de wereld timeserver bent.

Een UDP gebaseerde service waarvan het antwoord veel groter is (of kan zijn) dan de vraag is helaas iets wat simpel als DDoS amplifier te misbruiken is.

Er wordt genoeg gescand naar allerhande open grut dat 'niet publiek gekend zijn' geen bescherming is; snmp,chargen of dns gebaseerde DDoS amplifiertjes (thuis routers) worden ook gevonden zonder dat ze publiek gelist zijn.

Oorspronkelijk geplaatst door Mark17

NTP sterk beperken of in ieder geval een beperking in het aantal requests/uur/IP instellen kan al helpen. Het beste zou het zijn als iedereen BCP38 gaat forceren, maar dat zal wel niet gauw gaan gebeuren.

In de praktijk zijn de meeste tools die UDP gebruiken te misbruiken, voor NTP kun je overigens ook de reply per request beperken. Er zijn bepaalde verzoeken die een extreem "leuke" verhouding hebben tussen inkomend en uitgaand verkeer (gezien vanuit de aanvaller). Beperk het (voor zover dat kan) tot enkel de tijd terug geven zonder aanvullende informatie en je wordt al veel minder interessant om te misbruiken voor aanvallen.

Mark17,
NTP stond op 1Gbit op pool.ntp.org, nu op 1mbit. Maar hoe kan ik het aantal requests/uur/IP instellen? In de standaard config van ntp zie ik dat niet meteen staan?

Via iptables kun je dit redelijk eenvoudig doen:

Code:

iptables -A INPUT -p udp --dport 123 -m state --state NEW -m limit --limit 6/minute --limit-burst 61 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -m limit --limit 6/minute --limit-burst 61 -j ACCEPT

Wat simpelweg wil zeggen dat er maar 6 packets per minuut toegelaten worden wanneer die zelfde verbinding de burst limiet van 61 packets per minuut bereikt. Uiteraard kun je "minute" vervangen door "second" en de packet waarden (6/61) invullen naar eigen limieten die je wenst.

Code:

iptables -A INPUT -p udp --syn --dport 123 -m connlimit --connlimit-above 1 -j REJECT --reject-with udp-reset

Wat simpelweg wil zeggen dat er maar 1 connectie per ip adres is toegestaan.

Uiteraard zijn er nog andere instellingen mogelijk tot het bvb beperken van X connectie per /24 /25 /30 /...

Code:

iptables  -A INPUT -p udp --syn --dport 123 -m connlimit --connlimit-above 20 --connlimit-mask 24 -j REJECT --reject-with udp-reset

Wat simpelweg wil zeggen dat er maar 20 connecties van een /24 afkomstig mogen zijn.


Hopelijk ben je er wat mee en helpt het om je DDoS abuse tegen te gaan.

Mijn dank is groot! Morgen eens proberen en zien wat dit geeft! Bedankt Dennis, ik hou jullie op de hoogte!

Ik heb NTP reflectie aanvallen zelf nog niet zo veel gezien, het vertrouwde recept blijft toch vaak dns / chargen / snmp. Het is sowieso raadzaam om op dit soort dingen te filteren gezien het zo eenvoudig is om te misbruiken.

Nog even een kleine aanvulling, maar dit kan ook handig zijn:

There are several ways, but having a basic 'restrict' statement in your
config like this will help mitigate this attack:

restrict default kod noquery nomodify notrap nopeer
restrict -6 default kod noquery nomodify notrap nopeer

I believe the key command is 'noquery' which means that the server can't
be queried for information (it does NOT affect the server's ability to
respond to time requests). However, the other options will also protect
your public time server.

http://newsgroups.derkeiler.com/Arch.../msg00153.html

Even een NTP server van ons gechecked en het lijkt erop dat debian met defaults gelukkig noquery doet, lokaal antwoord hij wel, maar remote niet. Ik heb inmiddels van meer mensen vernomen dat ze onder vuur liggen / hebben gelegen met dit soort attacks.

Oorspronkelijk geplaatst door Paulewk

Even een NTP server van ons gechecked en het lijkt erop dat debian met defaults gelukkig noquery doet, lokaal antwoord hij wel, maar remote niet. Ik heb inmiddels van meer mensen vernomen dat ze onder vuur liggen / hebben gelegen met dit soort attacks.

Dat kan kloppen, bij ubuntu staat het ook default in de config, weet alleen niet meer of het default enabled was of je enkel de # moest verwijderen. Maar op mijn publieke servers staan die regels ook al vanaf dag 1 in de config en ik gebruik zowel ubuntu als centos voor publieke ntpd servers. Wel beide compiled van source dus het zou kunnen dat het daar gewoon ook default zo is.

Hier merk ik overigens niet veel van die attacks, maar dat kan natuurlijk ook komen omdat mijn hardware firewalls de ddos packets op beide locaties al tegenhouden voor ze uberhaut toekomen op de ntpd servers.

Even hier op terug komen (was even druk, dus NTP staat gewoon uit op dit moment).
Gewoon noquery erin gooien, ntpd terug aan zetten en het zou opgelost moeten zijn zeggen jullie dan? Of ben ik mis?
Ik kan uiteraard gewoon stoppen met NTP te draaien voor de hele wereld, maar dat is (zoals met veel dingen) toch niet de bedoeling er van? Als iedereen zo denkt tja dan stop je beter met NTP denk ik dan?

Oorspronkelijk geplaatst door IT-worX

Even hier op terug komen (was even druk, dus NTP staat gewoon uit op dit moment).
Gewoon noquery erin gooien, ntpd terug aan zetten en het zou opgelost moeten zijn zeggen jullie dan? Of ben ik mis?
Ik kan uiteraard gewoon stoppen met NTP te draaien voor de hele wereld, maar dat is (zoals met veel dingen) toch niet de bedoeling er van? Als iedereen zo denkt tja dan stop je beter met NTP denk ik dan?

Een publieke service runnen is geen 'kleine moeite - even daemon installeren en nooit meer naar omkijken' meer.
Als je het wilt doen zul je er dus tijd en een moeite in moeten _blijven_ investeren, en niet alleen in actie komen als je een probleem mede veroorzaakt hebt en de klachten naar je toe komen.
Dat is al een dik decennium zo voor open mailrelays, dat is iets korter zo voor publieke DNS resolvers, en nog iets korter voor publieke NTP servers.

Dat betekend gebruik monitoren, limieten instellen , in actie komen als je afwijkend gedrag op je monitoring ziet (nee, dat is niet alleen 'proces not running', dat zijn ook verkeerspieken), van te voren proberen te bedenken wat er mis zou kunnen gaan en die features uitzetten, en inschrijven op mailinglisten waar andere operators van zo'n service aanwezig zijn.
(ik zie ntp reflection op een ntp.org mailing list uit 2011 ...)

Wil of kun je dat niet, dan is het opzetten van zo'n publieke dienst geen 'kleine positieve bijdrage' aan 'het internet' ,maar een netto een negatieve bijdrage.
Jammer maar helaas.

Misschien dat die 'noquery' voldoende oplossing is voor dit ene soort probleem, (niet uitgezocht) maar denken dat je daarmee nergens naar om hoeft te kijken is echt niet verstandig.

Er zijn een aantal services die hetzelfde 'probleem' hebben als DNS mbt reflection of amplification attacks..

Chargen is er een van .. En zo ook SNMP ...

Deze services moet je of sterke ratelimits op zetten of helemaal dichtzetten en alleen voor je eigen ip raanges open zetten.

Oorspronkelijk geplaatst door Rubra

Er zijn een aantal services die hetzelfde 'probleem' hebben als DNS mbt reflection of amplification attacks..

Chargen is er een van .. En zo ook SNMP ...

Deze services moet je of sterke ratelimits op zetten of helemaal dichtzetten en alleen voor je eigen ip raanges open zetten.

Die zeker, maar dat zijn toch al services die je gewoon niet publiek bereikbaar moet hebben. (Van chargen is het nut sowieso twijfelachtig).

Ik ken best begrijpen dat iemand graag een beetje wil bijdragen an het algemeen belang door een publieke ntp pool server te draaien, en dat is dus helaas geen zero maintenance keuze (meer).