Jeff Ogden wrote:
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?
Reports from our monitoring systems saw the CPU usage jump by somewhere
between 150-200% for our core routers today; our current theory is that
much of this was caused by excessively short and rapid flows from the
probing, causing a lot of new paths to be learned (and rapidly discarded),
rather than being able to just switch it through.
Reports from our monitoring systems saw the CPU usage jump by somewhere
> between 150-200% for our core routers today
I just got off the phone with the TAC about this, and received the
following _preliminary_ advice:
1) If it's not enabled, turn on CEF, to move some of the packet-forwarding
load off the processor and into hardware. For some reason, a lot of
this traffic is being process-switched, as evidenced by high "IP
Input" cpu loads.
2) If you can, put in an ACL which prohibits port-80 traffic destined _to
the interfaces of the router itself_. Since the destination IP
addresses of the packets which constitute the attack itself are
random, many of them will be addressed to your routers, rather than to
hosts, and those will _always_ be process switched, if they're not
blocked by an inbound ACL.
It goes without saying that you should have a "no http server" line in any
production router.
-Bill
Web servers that were hit beginning this morning at 11:26:41 EDT have not seen another attempt since 19:49:53.
I'm wondering if this because it was coming up on 00:00:00 GMT 20-July-2001.
According to the PC-Cillin write up, the 100-thread scan only takes place if the system date is less than 20, but if it's 20-28, it launches it's DOS attack at www1.whitehouse.gov
Does anybody really know yet what payloads this thing is carrying?
Does anybody really know yet what payloads this thing is carrying?
eeye had a breakdown of what it does a couple of days back:
Steve
One of our downstreams with a /20 had not nullrouted their /20, so any
nets not in use bounced back to us via their default route. This caused
approx 4-8 megabit of traffic on their line due to all the scanning. After
our customer put in a null route for their /20, the traffic problem
ceased.
The ping-pong routing was causing his 2600 to use a lot of cpu. I do
expect most people to null route their nets, but if someone hasn't, this
can cause problems due to scanning.