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 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
