Barrages of Packet Errors

Thu Jul 1 06:25:33 UTC 2004

Hopefully this is not an off-topic posting. I've scanned a variety of groups looking to see if anyone else has encountered a similar problem, to no avail, and I simply thought this might be the most appropriate place to post an inquiry.

I'm not a service provider, simply a small business operator with a few servers, providing business clients with mostly standard web and email type services. A couple of nights ago my systems started experiencing a sharp increase in DNS traffic generating a new flavor of error messages. I'd like to know if anyone else out there noticed similar DNS errors in the past couple of days.

The barrage first hit at roughly 9:15pm (Mountain Std Time) on June 28th and lasted only a few minutes.  It repeated again at 9:25pm, and then again at roughly 9:38pm, and a 4th round at 10:06pm. I fired up ethereal shortly after the 4th battery in the hopes of capturing additional data, but there was no further activity, and I shut ethereal down the next morning (June 29th). However, later in the morning of the 29th the problem resurfaced, first at roughly 10am, then at 11:00am, 11:30am, and a final blast at 11:45am. Unfortunately I wasn't around during those barrages, so again I missed the opportunity to collect additional information - I only noticed it had happened while reviewing the server logs later that afternoon. The errors haven't re-occurred since.

The error messages are all the same (other than the inbound IP address causing the errors). The error message is as follows:
  "DNS Server encountered bad packet from 192.5.6.30. Packet processing leads beyond packet length."  

After extracting and sorting the error messages from the server log, I noticed the errors were associated with about 3 dozen IP addresses. The list of IP's associated with the packets that were generating the errors is as follows:

128.63.2.53 = h.root-servers.net
128.9.0.107 = ns1.isi.edu
152.163.159.234 = dns-01.icq.net
192.112.36.4 = g.root-servers.net
192.12.94.32 = aloe.arin.net
192.203.230.10 = e.root-servers.net
192.228.79.201 = b.root-servers.net
192.26.92.30 = c.gtld-servers.net
192.33.14.30 = b.gtld-servers.net
192.33.4.12 = c.root-servers.net
192.35.51.32 = dill.arin.net
192.36.148.17 = i.root-servers.net
192.42.93.30 = g.gtld-servers.net
192.5.5.241 = f.root-servers.net
192.5.6.30 = a.gtld-servers.net
192.5.6.32 = a3.nstld.com
192.54.112.30 = h.gtld-servers.net
192.58.128.30 = j.root-servers.net
193.0.14.129 = k.root-servers.net
193.205.245.8 = dns2.nic.it
198.32.64.12 = l.root-servers.net
198.41.0.4 = a.root-servers.net
198.96.180.33 = ns1.bmo.com
198.96.183.6 = ns2.bmo.com
199.191.128.105 = cbru.br.ns.els-gms.att.net
199.191.145.136 = macu.ma.mt.np.els-gms.att.net
202.12.27.33 = m.root-servers.net
204.152.185.196 = west-pub.mail-abuse.org
205.188.157.232 = dns-02.ns.aol.com
205.188.157.234 = dns-02.icq.net
209.182.216.75 = ns1.gnac.net
209.237.237.10 = dns1-public.alexa.com
209.47.26.190 = ns.uunet.ca
216.239.34.10 = ns2.google.com
216.239.38.10 = ns4.google.com
35.9.116.13 = serv1.cl.msu.edu
64.4.240.70 = ns1.nix.paypal.com
64.4.240.71 = ns2.nix.paypal.com
64.4.244.70 = ns1.sc5.paypal.com
64.4.244.71 = ns2.sc5.paypal.com

I never assume anything happens "by chance" when it comes to anomalies in any of my systems log files, particularly when it's something brand new (I've never encountered this particular error in the past 7 years or so, so it set bells ringing to examine the problem more closely) (and there was nothing different or non-normal in the way of user activity or other processing, etc. at any time prior to or during these 'events'). My initial guess is it's someone trying out some new attack vector attempting to exploit yet another buffer overflow problem in windoze, but the strange thing is that the IP's are all (with the exception of a couple) associated with top-level domain servers (or am I mistaken in that assessment?). I'm not a network specialist by any stretch of the imagination, my skill-sets are in other areas, so I'm afraid I haven't much else to add in the way of information about this problem. I'm just looking to bring it to the attention of those who do have the knowledge/experience in this area in case it's a problem of some significance where forewarning may prove useful to others.

Thank you.

Brian Pederson
Chief Technology Officer
TeamWorx Productions Ltd.