Over the last couple of days, I’ve been spending a good deal of time reviewing the security of the web sites I host. I run my sites on a server sitting on a fractional T1 in my office (I like to have physical access to my web server, which is why I don’t use a hosting service). Originally, my web server had been sitting behind my wireless router which simply passed all port 80 traffic to the public IP address to the web server. But I found that for a variety of reasons, I wanted more direct control over how traffic is routed to various sites that I host. So I moved the web machine from the wireless router to directly connect to the T1 router using its own IP address. The dilemma was that since I leave the T1 router relatively open (filtering NetBIOS ports, but not much else) and lock down traffic at the second router, connecting the web server directly would leave it open to port scans and attacks, right?
Wrong. Because the good news is that Windows Server 2003, which I’m using for the Web server, comes with the same Internet Connection Firewall that Windows XP provides. So it’s very easy to limit traffic to just the services you wish to provide access to, in my case HTTP.
So what’s the bad news? Well, there are a couple of shortcomings that I think are unfortunate. One is that it would appear (though I haven’t found any documentation to back this up) that ICF only works for the first IP address on a given network connection. I had originally tried configuring two IP addresses on the same NIC, and though I was able to ping both addresses (if I allowed ICMP echo in ICF…it’s disallowed by default), I could not connect to a web site on the second (higher number) of the two IPs. My solution was simply to add a second NIC, since I had one sitting around that I wasn’t using, and enable ICF on both. While this worked for my situation, it’s obviously not a scalable model. I’m not going to complain too much about this shortcoming, however, since it’s pretty clear that ICF was provided as a home/small business user solution. If I really wanted to have a bunch of IPs on this machine, I could use the more sophisticated filtering on my router, albeit at the cost of much more complicated configuration (and with it, more likelihood of making a mistake that leaves something open).
A more serious shortcoming, from my perspective, is that ICF is not included on Windows Server 2003, Web Edition. What’s up with that? Did Microsoft decide that Web servers require less security? Or is it simply that because Web Edition is substantially cheaper, ICF is one of the features that got cut? Either way, for a company that’s trying to convince people that it takes security seriously, the absence of a tool that can make that job much simpler is really a bad decision, in my opinion. Particularly since it seems to me that the very people who are most likely to buy the Web Edition are the same people who are least likely to be willing to spend money on additional hardware or software firewall solutions.
I hope that Microsoft will reconsider this decision and, through a Win2K3 service pack perhaps, add this feature back to the Web Edition, just as they’re planning to turn it on by default in XP. It’s hard enough for us developers (most of whom are poor-to-middling admins at best) to keep our machines secure. The last thing we need is to find security features crippled in certain OS versions. I’m sure there are other places Microsoft can look to remove features that will encourage folks to consider the Standard or above editions of Server 2003. Security shouldn’t be one of them.
UPDATE: I want to be clear that in terms of best practices, I would absolutely agree with those who've commented that a web server should ideally not connect directly to the Internet, and should be behind a hardware firewall, ideally with another firewall between it and any internal network it's connected to. There are, however, cases where what's ideal isn't practical. What's most important is that the solution you choose to use is selected with an understanding of the tradeoffs in terms of cost, risk, and difficulty of implementation, so that in the end you have a sufficient level of security for your purposes at an acceptable cost.