Therein lies the rub. I'm curious -- every medium or large company I'm
aware of had Code Red on the inside of the firewalls. What happened
this time? Did it get inside? If so, has anyone analyzed how?
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls" book)
Therein lies the rub. I'm curious -- every medium or large company I'm
aware of had Code Red on the inside of the firewalls. What happened
this time? Did it get inside? If so, has anyone analyzed how?
I haven't seen any wide spread behind the firewall exposure so far.
I think unlike code red / nimda, there are a few factors that
help:
- most people with firewall block 1434. This is not true for port 80,
as the web server is usually intended for the public.
- the worm is memory resident. Road warriors that are infected at home
or while traveling are unlikely to introduce this worm into the company
LAN as they come to work on Monday.
- this worm only uses port 1434 UDP. Nimda made it past a lot of firewalls
and NAT devices by spreading via e-mail and web clients.
Hi, NANOGers.
] - the worm is memory resident. Road warriors that are infected at home
] or while traveling are unlikely to introduce this worm into the company
] LAN as they come to work on Monday.
Just a point here: Many road warriors are work-at-home folks who have
their computers on 24x7. They may be infected, and will fire up their
VPN tunnels Monday morning. This may introduce the worm into the chewy
center of many corporate networks. Hopefully folks have put the proper
filters in place on their VPN access points.
Thanks,
Rob.
Personally, I think it's unlikely the situation will get worse on Monday
because of people starting work. The first reason is that you can only get
infected if you're running SQL server (or MSDE) at home and someone sends you
one of the special packets. The second reason is that you, if you're infected,
send the packets to random IP addresses, and not only do you have to randomly
choose an address on the corporate LAN, but it has to be a machine running
SQL server. To my mind the probability of all these things being the case
is microscopic!
- Chris
My observation was that the target IPs are not random and that local IPs were
hit more often (same /16 more than /8 more than all /0) .. a la Codered.
STeve
The worm calls gettickcount to get a pseudorandom seed, and always uses that
seed to create random addresses. It's possible the random address generator
isn't very good and creates addresses that are too similar.
Check out
http://www.eeye.com/html/Research/Flash/AL20030125.html
- Chris
The worm prefers addresses "close to home" and sends out tens of
thousands of packets per second. Depending on the preference for local
addresses a single infected host could infect an entire /16 in a few
seconds, and a /8 in less than an hour. The entire internet takes less
than a week if the random address generator doesn't re-hit the same
addresses.
One interesting aspect of this worm is that it seems capable of passing
through all kinds of barriers. After two infected machines were cleaned
up and filters were in place, I still saw one or two copies of the worm
coming in addressed to the subnet broadcast addresses on interfaces
facing the local network. Finding out how exactly the worm (ab)used
broadcast and multicast addresses is going to be fertile ground for
research.
Wait, but isn't your corporate network 'secure' cause its got a super kewl
firewall infront of it??
] Wait, but isn't your corporate network 'secure' cause its got a super kewl
] firewall infront of it??
HAHAHA! Would that be the stateful firewall that filled up and fell
over due to all the worm probes? 
or the one that steathily permitted udp 1434 from the outside world 
Hey, Chris.
] or the one that steathily permitted udp 1434 from the outside world
Yeah.
This is yet another reason why I tell folks with firewalls NOT to allow
everything from the internal (often mistakenly labelled "trusted") net
to the external nets.
Thanks,
Rob.
Date: Sun, 26 Jan 2003 15:07:41 -0600 (CST)
From: Rob Thomas
This is yet another reason why I tell folks with firewalls
NOT to allow everything from the internal (often mistakenly
labelled "trusted") net to the external nets.
Too true. However, when a company president gets upset because
his kid couldn't play Quake over the network, ports magically
begin to open...
FWIW, it might be good to clarify the "stateful" remark a bit:
Keeping state on all outbound traffic could cause a problem.
However,
check-state
deny udp from any 1434 to any 1434
allow udp from any 1434 to any keep-state
deny udp from any to any 1434
works nicely for blocking the worm.
Eddy
The unfortunate but required security precautions are that you really
should filter as low down in the network as possible, this allows the most
granular filtering as possible. Much of that could be accomplished with
simple router acls.
Filtering as close to the end hosts allows you to explicitly permit/deny
traffic to the services required without as many compromises on acl length
or granularity.
Note, it may require some automation of the acl deployment or management
of the acls could become 'complex' 
> their computers on 24x7. They may be infected, and will fire up their
> VPN tunnels Monday morning. This may introduce the worm into the chewy
> center of many corporate networks. Hopefully folks have put the proper
> filters in place on their VPN access points.Wait, but isn't your corporate network 'secure' cause its got a super kewl
firewall infront of it??
The problem is not firewall. The firewall is a tool to implement a security
policy. If the security policy is wrong, a firewall wont help you. In fact,
the best demonstration of a firewall is a Cat5 cable. Working cable is a
firewall with Allow:Any security policy. Cut in two, the cable is a firewall
implementing Allow:None security policy.
Alex
I forgot my smilies in the original post... it was a joke... I'll try not
to do that again.