Here at Merit we are seeing large numbers of Code Red infected hosts. These hosts may be on our regional network MichNet or they may be elsewhere out on the greater Internet. It is the port scanning of random IP address that causes problems, because the scanning in turn is causing network problems due to heavy ARP loads when the local site routers ARP for what turn out to be unused IP addresses. This is an issue when there are large blocks of IP addresses behind a router. It is less of a problem when there is a relatively small number of IP addresses behind a router (say one class C worth). Are others seeing these sorts of problems? What strategies are there for dealing with this?
What we've come up with so far is blocking inbound (inbound to the site) port 80 traffic on the LAN interface of the local site router (so outbound over the LAN interface). This prevents the ARP problems. It also gives us some indication of which systems are infected. It has serious undesirable side effects (preventing legitimate Web access) and so we also have to reenable inbound port 80 access for specific IP addresses that we know are Web servers or otherwise not vulnerable to Code Red. None of this solves the problem in any real sense. It just keeps performance reasonable and buys us time to work on or get others folks to work on real solutions. To solve the Code Red problem seems to require patching the vulnerable hosts or taking the vulnerable or infected hosts offline.
How long is it going to take to get every Windows NT, Windows 2000, and Windows XP system patched? We may be at this for a long time. I am not looking forward to this.
Any ideas for other approaches to the problem?
-Jeff Ogden
Merit
Yes, a "helpful" virus targeting infected hosts, a list of which is
easily derived from your weblogs. (I'm not seriously suggesting this, but
it could be very effective.)
Patrick Greenwell writes:
How long is it going to take to get every Windows NT, Windows 2000, and Windows XP system patched? We may be at this for a long time. I am not looking forward to this.
Any ideas for other approaches to the problem?
Well this patch has been out for a month now so I would give it another 3 years before 75% of the machines are patched. I WISH I was kidding.
On a side note, it is rumored that Microsoft's own windowsupdate site was defaced. go figure.
] On a side note, it is rumored that Microsoft's own windowsupdate site was
] defaced. go figure.
http://www.smartguys.net/mshacked/
Jeff Ogden wrote:
is causing network problems due to heavy ARP loads when the local
site routers ARP for what turn out to be unused IP addresses. This
is an issue when there are large blocks of IP addresses behind a
router. It is less of a problem when there is a relatively small
number of IP addresses behind a router (say one class C worth). Are
others seeing these sorts of problems? What strategies are there for
dealing with this?
If addresses are contiguous, perhaps you could blackhole some of them
temporarily. It might be nice if there was a way to take a current ARP
table and freeze it. That is, mark all the entries as permanent, then
turn off ARP or dump destination IPs not in the ARP table into the bit
bucket. As long as the router continues to respond to ARP requests,
this might be a short term fix for that type of event.
John
Jeff Ogden wrote:
> is causing network problems due to heavy ARP loads when the local
> site routers ARP for what turn out to be unused IP addresses. This
> is an issue when there are large blocks of IP addresses behind a
> router. It is less of a problem when there is a relatively small
> number of IP addresses behind a router (say one class C worth). Are
> others seeing these sorts of problems? What strategies are there for
> dealing with this?
Use smaller subnets (possibly vlans etc) !
Steve