Security Incidents mailing list archives
DNS smurf attacks
From: patrick () PINE NL (Patrick Oonk)
Date: Thu, 6 Jul 2000 22:03:05 +0200
Hi, It has come to my attention that at least one big DNS smurf attack to several hosts is going on for a few days. In tcpdump it looks similar to this (queries for .) 18:39:05.755227 spoofed.victim.com.1026 > amplifier.domain.com: 28951+ NS? . (17) 18:39:05.758876 amplifier.domain.com > spoofed.victim.com.1026: 28951 13/0/13 NS B.ROOT- (436) 18:39:05.763445 spoofed.victim.com.1026 > amplifier.domain.com: 28951+ NS? . (17) 18:39:05.765469 amplifier.domain.com > spoofed.victim.com.1026: 28951 13/0/13 NS A.ROOT- (436) 18:39:07.493528 spoofed.victim.com.1026 > amplifier.domain.com: 28951+ NS? . (17) 18:39:07.497075 amplifier.domain.com > spoofed.victim.com.1026: 28951 13/0/13 NS J.ROOT- (436) 18:39:07.504368 spoofed.victim.com.1026 > amplifier.domain.com: 28951+ NS? . (17) 18:39:07.506410 amplifier.domain.com > spoofed.victim.com.1026: 28951 13/0/13 NS H.ROOT-(436) The problem of this kind of attacks is that it attacks using one of the most important services running the net. We should start treating DNS as we did to mailservers: stop unauthorized relaying e.g. recursive DNS lookups from untrusted sources. This is described in AUSCERT AL-1999.004: http://www.ciac.org/ciac/bulletins/j-063.shtml. This advisory is almost a year old. Note that a more elegant solution is to make an acl containing networks or hosts that are allowed to do recursive queries in your named.conf (Bind 8). acl "recurs-allowed" { 192.168.0.0/24; #example, 10.0.0.0/8; #insert your trusted networks/hosts here } allow-recursion { recurs-allowed; }; Note that if you do this you will still allow access to BIND version number requests and zone transfer requests. This can be solved with in the following way: acl "trusted-transfer-hosts" { 192.168.0.0/24; #example, 10.0.0.0/8; #insert your trusted networks/hosts here } allow-transfer { trusted-transfer-hosts; }; The method to block version.bind requests is described in the aboved mentioned AUSCERT document. There seems to be no way to block this in MS-DNS. I suggest users of this software to bug Microsoft about this. As soon as you changed this you MIGHT see messages like this in your syslog (amongst others): Jul 5 20:45:25 myserver named[162]: unapproved query from [1.2.3.4].1026 for "." You might also see messages like Jul 5 12:48:00 server named[26863]: unapproved query from [213.x.x.x].59271 for "version.bind" from 128.9.160.57 and 198.32.4.13 Don't worry, these are caused by Bill Manning's yearly survey of the distribution of the in.addr-arpa domain, of which you can read at http://www.isi.edu/~bmanning/in-addr-audit.html. I wrote this all to my best of knowledge, please correct me if I made any mistakes. Patrick -- Patrick Oonk - PO1-6BONE - patrick () pine nl - www.pine.nl/~patrick Pine Internet - PAT31337-RIPE - PGPkeyID BE7497F1 - XOIP+31208723350 Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://security.nl PGP fingerprint A6 12 66 7F 22 84 1B E5 73 8C 99 F7 17 7B A3 98 Excuse of the day: system needs to be rebooted
Current thread:
- DNS smurf attacks Patrick Oonk (Jul 06)