A good summary Jochem would be for folks to tune the firewall and ensure permissions/allowable IP list...
I know one of our enviroments runs machines with no patches and very screwed up management approach... Meaning things are far from right, even though we tell them about it all the time... However, we have a firebox II sitting in front locked down fairly good... The worm didn't effect the environment nor have any of the previous security items... In your environment you point out the user base... 8000... agreeable... large base for things... Tune the firewall and restrict traffic there ... allowing like port 80 in and out disbaling all other services and ports, except those in a defined list of authrozied servers.... That is how I would stab the issue.. -p Paris Lundis Founder Areaindex, L.L.C. http://www.areaindex.com http://www.pubcrawler.com 412-292-3135 [finding the future in the past, passing the future in the present] [connecting people, places and things] -----Original Message----- From: Jochem van Dieten <[EMAIL PROTECTED]> Date: Mon, 27 Jan 2003 00:18:00 +0100 Subject: Re: SQL Worm > Paris Lundis wrote: > > > > It would seem that having a local university private subnet would > be a > > good solution.. and also this would cut down on people running un- > > authorized servers... > > Why would servers be unauthorized? If you have a CS department you > *want* people to run servers (as long as they secure them). Where do > you > think I run all my stuff ;-) > > > > On the router side or NAT you could do port translation and make > things > > further "burried"... > > How are you going to do NAT for 8000 computers in student dorms if at > the same time you want those people to be able to run servers? > > > > In our environments to eliminate this sort of problem, we issue a > dual > > IP... the private ip range say 192.168.1.xxx or one of the other 3 > > permissible private ranges goes along to the user along with their > > public IP... > > > > Any App server needing to talk to the database must do so on the > local > > IP segment otherwise it won't work... > > Dual IP's won't fix this scenario. Just imagine somebody running a > testserver in a dorm on with both a public and a private IP. He gets > infected through the public one, yet he passes the infection on > through > the private one. > > > But to get back on topic, the thing I don't understand about this MS > SQL > Server worm, why would a MS SQL Server have UDP allowed in the local > firewall in the first place (regardless of IP restrictions)? I find > it > hard to imagine some part of the wire protocol being dependent on > UDP, > and from what I read it is mainly for troubleshooting (much like the > HTTP TRACE command ;-) we have been hearing from lately). > > Jochem > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
