DNS-Amplification-Attacke gegen verschiedene DNS-Server im Gange

[Whistler]

Falls sich jemand in den letzten Tagen (auf von mir betreuten Systemen fing es am 6. Januar an) über Unmassen von DNS-Anfragen im Stil von

Jan 19 06:41:04 localhost named[6377]: client 69.50.142.110#53930: query (cache) './NS/IN' denied
Jan 19 06:41:13 localhost named[6377]: client 69.50.142.110#15557: query (cache) './NS/IN' denied
Jan 20 16:31:47 localhost named[6377]: client 66.230.160.1#32412: query (cache) './NS/IN' denied
Jan 20 16:31:59 localhost named[6377]: client 66.230.160.1#8478: query (cache) './NS/IN' denied

gewundert hat, es scheint gerade eine DDNS-Attacke gegen verschiedene Hoster im Gange zu sein.

Aktuelle Informationen findet man z.B. unter SANS Internet Storm Center; Cooperative Network Security Community - Internet Security - isc.

Hier mal eine Stellungnahme von einem der Opfer:

From: ISPrime Support <support@isprime.com>
Date: Tue, 20 Jan 2009 15:16:02 -0500 (EST)

Hello,

These are the result of a spoofed dns recursion attack against our servers. The actual packets in question (the ones reaching your servers) do NOT originate from our network as such there is no way for us to filter things from our end.

If you are receiving queries from 76.9.31.42/76.9.16.171 neither of these machines make legitimate outbound dns requests so an inbound filter of packets to udp/53 from either of these two sources is perfect.

If you are receiving queries from 66.230.128.15/66.230.160.1 these servers are authoritative nameservers. Please do not blackhole either of these IPs as they host many domains. However, these IPs do not make outbound DNS requests so filtering requests to your IPs from these ips with a destination port of 53 should block any illegitimate requests.

An ACL similar to:
access-list 110 deny udp host 66.230.160.1 neq 53 any eq 53
access-list 110 deny udp host 66.230.128.15 neq 53 any eq 53
Is what you want.

I would also suggest taking a look at the excellent CYMRU secure bind template (assuming you are running bind), to help you configure your nameservers so that you do not participate in this attack: http://www.cymru.com/Documents/secure-bind-template.html.

Thanks for your help in mitigating this attack against us.

Please let me know if I can be of further assistance.

ISPrime Support
support@isprime.com
ICQ: 136633378

 

[sebast]

Bin gerade am analysieren des Problems. Mit ISPrime habe ich auch schon gesprochen und die gleiche Mail bekommen. Bin ja froh, dass wenigstens einer Antwortet. Es sind aber auch viele Enduser (Firmen) mit statischen IP-Adressen davon betroffen. Vielleicht werde ich mal eine liste veröffentlichen.

 

[Whistler]

Meine Statistik der letzten Woche:

26%: 66.230.160.1
20%: 69.50.142.11
19%: 66.230.128.15
11%: 76.9.31.42
 8%: 76.9.16.171
 7%: 63.217.28.226
 3%: 69.50.137.175
 2%: 69.50.142.110

(und viel < 1%, was aber immer noch etliche tausend Requests sind).

Siehe auch news.admin.net-abuse.email und comp.protocols.dns.bind für die "Nummern des Tages".

Eine mögliche Gegenmaßnahme: comp.protocols.dns.bind: "denied NS/IN".

 

[sebast]

Naja, eigentlich ist es mir egal! Es beeinflusst nicht meinen DNS-Server, weil er auf diese Anfragen sowieso nicht antwortet und ein bind ist es auch nicht. Das einzige was nervig ist, ist mein großes Logfile was von ca. 10MB/pro Tag auf über 100MB angewachsen ist. Ah und es verbraucht nur unnötig Traffic