Re: management interface accessability (was Re: Worm / UDP1434)
In message <20030126172907.GA31694@f00f.org>, Chris Wedgwood writes:
On Sun, Jan 26, 2003 at 01:37:16AM +0000, Paul Vixie wrote:
... If you are relying on their ACL's to protect your telnet and snmp access, but are otherwise allowing their management interfaces to hear traffic from the whole Internet, then you should turn in your badge and go back to bagging groceries or whatever it is you used to do.
Some would argue this should apply to those exposing MSSQL to the outside world such that it could even receive malicious port 1434 packets...
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. -- -------------------------------------------------------------------- jullrich@euclidian.com Collaborative Intrusion Detection join http://www.dshield.org
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. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
On Sun, Jan 26, 2003 at 12:08:07PM -0600, Rob Thomas wrote:
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.
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 -- strawberry@toth.org.uk http://www.toth.org.uk/~strawberry
On Sun, 26 Jan 2003, Chris Lloyd wrote:
On Sun, Jan 26, 2003 at 12:08:07PM -0600, Rob Thomas wrote:
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.
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!
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
On Sun, Jan 26, 2003 at 06:50:36PM +0000, Stephen J. Wilcox wrote:
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.
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 -- strawberry@toth.org.uk http://www.toth.org.uk/~strawberry
On Sun, 26 Jan 2003, Chris Lloyd wrote:
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.
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!
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.
On Sun, 26 Jan 2003, Rob Thomas wrote:
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.
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? ;) -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
On Sun, 26 Jan 2003, Rob Thomas wrote:
] 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. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
RT> Date: Sun, 26 Jan 2003 15:07:41 -0600 (CST) RT> From: Rob Thomas RT> This is yet another reason why I tell folks with firewalls RT> NOT to allow everything from the internal (often mistakenly RT> 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 -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
On Sun, 26 Jan 2003, Rob Thomas wrote:
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.
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
On Mon, 27 Jan 2003 alex@yuriev.com wrote:
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.
I forgot my smilies in the original post... it was a joke... I'll try not to do that again.
participants (9)
-
alex＠yuriev.com -
Chris Lloyd -
Christopher L. Morrow -
E.B. Dreger -
Iljitsch van Beijnum -
Johannes Ullrich -
Rob Thomas -
Stephen J. Wilcox -
Steven M. Bellovin