Windows 2003 Server and the Patchlab

I decided that the windows 2003 server would host all the services a standard server should; DNS, DHCP, WINS etc. Those were fairly trivial to install and set up from the CD. I only wanted to offer those services to my patch lab which I wanted to keep seperate from the real network, as I would be throwing malware around and wouldn't want to contaminate anything I shouldn't. Normally I would bind the virtual machines on the loopback device, but Windows wouldn't let me do this. It seemed I would need a firewall. I bound another IP (192.168.0.1, standard unroutable) to the machine's NIC and had a go with the windows firewall. It allows a default deny or default allow with specific allow or deny rules respectivley. However it falls severely short in that it does not differentiate between ingress and egress traffic and has no support for subnet specific rules. This set me on my quest for a real firewall. I needed a proper enterprise level packet filtering firewall that supported windows 2003 server and not a host based application firewall like Kerio personal edition, that was also free (as in beer). Most of the offerings in this range cost money and I didn't feel like going the illegal software route. So I head on over to tucows and downloaded a few of the offerings there. I tried about three of them before setteling on Trlokom's OmniVPN. This was fairly easy to use and was far easier to understand coming from an IPtables mind set. I set up all the rules and additionally locked the acutal box down as by default services like daytime, echo, chargen, etc. are left wide open. I firewalled the 192.168 network off from the real world completely and went about configuring the services. Navigating the configurations for most of the services was completely non-intuitive and I was never quite sure what I should be right-clicking on. Luckily the Windows help was actually quite helpfull. I eventually got the services using the 192.168.0.1 address.

Later that evening/morning I got a call from the IT department asking if I was running a DHCP server. I said I was but that it shouldn't be accessible. Evidently OmniVPN's default deny didn't include anything other than TCP or UDP. In addition the DHCP server appears to have no option to disable dynamic lease allocation and static mappings can only be used in addition. It seemed my two fail safes had failed.

I then spoke to Jody from our IT department and he reccomended Visnetic Firewall from Deerfield, which I never got around to using. Then after some ultimate frisbee and while eating dinner I had a flash of inspiration: The machine I am using has two NIC's one of which isn't being used. Why don't I just bind the virtual machine's to the second NIC and set it as 192.168.0.1. This seems completely obvious now, and evidently staying up all night does have an affect on my thinking. However, when I tried to do this I saw why I had not done it before.

I changed the settings for the other NIC to the 192.168 range and removed them from the original NIC. I then reconfigured all the services to listen on my new NIC. At this point I discovered two things. The services either would not bind to the new NIC (most of them didn't display it as an option, hence my failure to think of this the night before) as it did not have a network cable plugged in or they would bind but fail for the same reason. I then went on a double click rampage, checked all the options, checked the help, googled for it and came up with nothing. There seemed to be no way to make a NIC active if it thought the network cable was unplugged. Coming from a unix background this seemed very stupid behaviour. Then I came up with a plan: I made my own physical loopback device.

I got hold of a CAT 5, UTP cable and plugged one end into the second NIC. I then cut the remaining crimped end off and wired transmit + to recieve - and transmit - to recieve +. Immediately after connecting the last two wires windows said a cable was plugged in and almost everything started working. I couldn't believe it. I had made my own loopback device which was emulating the exact behaviour the normal loopback device should be providing. This is a very poor show on Microsoft's behalf.

After my exciting geeky success I checked if everything was working. My virtual machines were DHCP'ing happily and pinging just as happily, however DNS wasn't working. It gave me a generic error about the service already running which was plainly not true. I once again went on a double click adventure and tried changine the server's DNS settings thinking those could be causing a conflict, then I tried deleting the whole DNS server and starting again ... blah blah blah blah. Eventually I uninstalled the DNS component and reinstalled it. At this point everything worked fine, aaah the tried and true Microsoft soultion, "You should re-install.".

Everything is now up and running, including my SUS server and I am about to embark on some exciting patch testing. I was quite dissapointed with many of the features of a supposedly enterprise level server operating system, however I fully admit many of the errors could be my own doing. Microsoft definitely gets points for ease of use. Setting the services up was a breeze, but configuring the specifics of it became quite difficult. I realised that when I set something up on a unix machine I usually take time to read at least the entire example configuration file and large parts of the man page. On the windows server most of that is hidden and many default choices are made for you with the help usually being a last resort, and so many of my problems may have stemmed from there.

All in all I learnt quite a bit about the windows way, and will never, ever, use a windows server as the point of entry into a network under my control. :)