Security Issues with Windows 2000 Datacenter?

alen asks: "The recent IIS security incidents got me thinking. Code Red and Nimda hit servers that weren't patched by their sys admins. If you get infected, you patch your server and end of story. But what if you're running Windows 2000 Datacenter Server? It's a customized solution that you can't change. All your service packs are customized by your vendor. What happens if you have a web or database server that needs to be patched immediately? Are you left out in the cold running unsecure software that you can't patch while you wait in line for your vendor to issue you a service pack or hotfix?" In a situation like this, the whole ball-o-wax resides with the vendor. If you have a good vendor who actually cares about customer satisfaction, these hotfixes will be available quickly. Would anyone out there actually recommend Datacenter for corporate environments?

"My company is currently looking to cluster our SQL 7 servers. We're considering Win2000 advanced server or datacenter. Around a month ago I sat in a meeting with our VP of IT, and the rest of the network admins I work with. Compaq tried to pitch their Windows 2000 Datacenter or Advanced Server solution. Here is the way the compaq people explained it:

You get datacenter only from an OEM. They look at the apps you're running and customize a solution for you in their lab. Every datacenter implementation is different, and every datacenter CD is different. Since we would be using an EMC SAN as our clustered storage system they said our implementation would take special customization. They would have to contact EMC engineers and work together. Once you deploy it, the OEM monitors it. And you can't install any service packs or anything without getting an OK from your OEM. Any service packs are customized for your enviroment. The SLA guarantees a 99.999% uptime or your money back. Part of your money at least. Datacenter isn't an OS, but a program in their words.

Now here is the problem. With Code Red and Nimda, how do you patch IIS running on datacenter in a timely manner? The reason IIS servers became infected was because the admins didn't patch them in the first place. So say a new worm comes out in a few months and it takes a few days for MS to create a hotfix. Datacenter admins can't install it until they get their customized copy from their OEM. And almost every 2000 server runs IIS for terminal server. It can take a few days and in the meantime your servers could be down. And I don't see the SLA covering a situation like this. Meanwhile you're explaining to your CEO how this $500K supposedly guaranteed solution is sitting dead in the water and you can't do a thing about.

Is there something I'm missing, or did Microsoft look over something like this? Especially when they are trying to push Datacenter as 'Big Iron'."

Comments

Datacenter

[fazil]

Keep these SQL apps behind the firewall.. turn off all IIS features on the sql boxes.. and at least Nimda should not be able to get at it. Any web interface would hopefully not use Datacenter, and use standard Advanced Server, which is easily patchable. If sql was available on the front line, well, they almost deserve it.

When you can't secure it, hide it.

[haruharaharu]

If you aren't allowed to patch your server, then you should isolate it behind a firewall of some sort, so that the chances of infection are minimized. This may not work well for IIS (beyond simply not running it), but it will serve you well in the general case.

Datacenter

[Nickodemus]

Is a locked down version of Windows. What happens when you lock it down? Well, intensive testing occurs first to determine what is being done with the box and what possible problems could arrise. Then those problems are solved. Also, only certain applications are certified to run on a datacenter box. The goal here is to achieve five nines. That is have this box up and running for 99.999% of the year. Without thorough testing of applications this level of availability would be impossible.

Part of what you get with a Datacenter purchase is a premier level of support. This includes a named engineer for support, and automatic escalation to the highest level for any support needs. It also includes any updates and or fixes on a priority basis - if you have a Datacenter server you get patches, updates, etc. before anyone else does.

Re:Datacenter?

[spongman]

yup, you shouldn't be running IIS and SQL Server one the same machine. Ideally, you'd run SQL Server alone on the big machine and have a cluster of load-balanced inexpensive boxes running stateless ASP/ISAPI pages connecting to the DB over the LAN. You'll be free to patch the IIS boxes as needed and you can put them in a DMZ for extra security.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Think firewall + watchdog functionality

[chabotc]

Put the datacenter server behind a firewall, preferably with some string matching functionality (ie watchdog).

the later iptables have a string-patch included, which allow you to target certain port/string combo's, with this it is easy to block worms from the webserver, as long as you know what request it makes.

exampple to block cmd.exe access (taken from my own internal firewall scripts, this will block nimda)

$IPTABLES -A INPUT -p tcp -i ! $INTERNAL --dport 80 -m limit \
--limit $LIMITLEVEL -m string --string "/cmd.exe" \
-m state --state ESTABLISHED -j LOG \
--log-level $LOGLEVEL \
--log-prefix "MS IIS cmd.exe usage:"

$IPTABLES -A INPUT -p tcp -o ! $INTERNAL --dport 80 -m limit \
--limit $LIMITLEVEL -m string --string "/cmd.exe" \
m state --state ESTABLISHED -j LOG \
--log-level $LOGLEVEL \
--log-prefix "MS IIS cmd.exe usage:"

$IPTABLES -A INPUT -p tcp -i ! $INTERNAL --dport 80 -m string \
--string "/cmd.exe" -m state --state ESTABLISHED\
-j REJECT --reject-with tcp-reset

$IPTABLES -A INPUT -p tcp -o ! $INTERNAL --dport 80 -m string \
--string "/cmd.exe" -m state --state ESTABLISHED\
-j REJECT --reject-with tcp-reset

If you wanted to block codered, filter on /default.ida, filtering on global.asa is also a good idea ;-) etc ..

(see iptables docs for more info)

G'luck