Good News / Bad News with Win2K3 Web Edition

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.

9 Comments

  • I would bet that MS is assuming that a web server is going to be behind a physical firewall, as it should be... not directly connected to the internet.



    Personally, I think your crazy if you are relying on a software firewall, running on the same server... especially the built in ICF.

  • "I would bet that MS is assuming that a web server is going to be behind a physical firewall, as it should be... not directly connected to the internet."



    I don't buy this explanation, else why would the feature be included in the Standard Edition and the 32-bit version of the Enterprise Edition. Surely, if Microsoft's assumption is that a web server will be behind a hardware firewall, that assumption would go double for enterprise users.



    "Personally, I think your crazy if you are relying on a software firewall, running on the same server... especially the built in ICF."



    You may be right. Certainly, there's an element of risk involved. OTOH, I keep on top of patches in Microsoft products, and know how to ensure my OS is up-to-date. I can't really say the same about my router (though I'm sure I could figure out how, if I tried). The other thing about using my router as a firewall is that the configuration is considerably more complex, meaning it's more likely that I might make a mistake in configuration that would leave me vulnerable, or leave my servers and router unreachable (something I've done accidentally in the past...thank goodness for serial ports <g>). For me, it's a trade-off. I'm willing to trade the potential risk associated with a software firewall for the extreme simplicity of implementing it.



  • And for those of us who don't even HAVE a hardware firewall and can't even put one in (I can't really elaborate, but guess what, it happens), ICF is a great great thing to have since I've been using IPSEC rules previously. IPSEC is just a pain to work with for firewalling purposes though, especially since it's not stateful, but it can help some, and at least it's Group Policy manageable. I'm including workstations in on this point at the same time.



    Just pointing out that everyone has their own scenario, which is easy to forget when you're so entrenched in your own. 'Crazy' or not you have to do the best you can.



    Seems totally stupid for them to axe ICF like that, I'll be rooting for you ;) Strangely, the Web build of Win2k3 costs more for us than Standard does. Go figure. I'd probably have run into this myself otherwise.



    XP SP2's ICF improvements are great. I hope they end up in Win2k3 SP1 and that you get them on Web Edition! The best one is opening ports to the local subnet only. Yikes, how thoughtful of a simple toggle.

  • I suppose the other thought is that the web version has less enabled on it and requires less additional security. I read last year about a hacking competition that MS partook in, using standard win2k3 OS, NO FIREWALL, and best practices for security, the website was exposed to the net to be hacked. The result was not one exploit.



    The concern is when a new security flaw is found, how secure will your server be without the protection of a second layer.

  • "The concern is when a new security flaw is found, how secure will your server be without the protection of a second layer."



    Yup. I absolutely understand that concern. OTOH, what happens if a flaw is found in my router firmware? I don't have the option of automatic updates for that, so I would have to have heard about the flaw somehow, then my router manufacturer would've needed to provide a firmware update that resolves the issue, AND my ISP has to support said firmware update, AND I have to install the update without hosing my router (which can be a challenge). And once I've installed the firmware update, typically I would have to completely re-configure all of the firewall rules (at least if I had customized them).



    Now I would agree that a flaw in my router firmware is much less likely than a flaw somewhere in the OS. But the truth is that right now, unless there is a flaw in ICF, or in IIS, I'm in reasonably good shape, at least in terms of attacks from outside my network.



    I'm glad to hear about the competition results. I still wouldn't think about running any OS with no firewall at all, but the results make me feel a little better about my decision to use ICF. :-)

  • One of the other things to remember about Win2k3 Web Edition is that it was aimed as OEMs and hosting providers, and not at the average home user or small bizness hosting their own web sites.



    For the larger hosting centers and OEMs, hardware firewalls are going to be much more prevalent, and i think they probably took out ICF because it was unneeded. Just my $0.02 guess.



    >>

    Windows Server 2003, Web Edition, is available:



    To Microsoft customers with Enterprise and Select licensing agreements.

    To service providers with a service provider licensing agreement (SPLA).

    Through Microsoft original equipment manufacturers (OEMs) and System Builder partners.

    <<

  • I did some port scan runs with a tool called Advanced Administrative Tools, and didn't come up with anything worrisome. I did note that my SMTP and POP3 servers were displaying the server software name in their welcome messages, so I customized them to avoid giving anyone a free step towards hacking them. Other than that and port 80, I wasn't able to find anything available to attack.

  • Also, Scott Forsyth, who's one of the admin geeks over at OrcsWeb.com, came up with a solution for the incompatibility between RRAS and ICF.



    Turns out that RRAS includes a basic firewall that does effectively the same thing as ICF. To enable it:



    1. Once your VPN is set up and with the RRAS console open, right-click the General node under IP Routing and select New Routing Protocol...



    2. Select NAT/Basic Firewall from the list and click OK.



    3. Right-click the NAT/Basic Firewall node, and select Add New Interface...



    4. Select the NIC that connects to the external network, and click OK.



    5. In the Network Address Translation Properties dialog, select "Public interface connected to the internet" and check both checkboxes (NAT and firewall). Once that's done, some additional tabs will appear.



    6. You can now use the Services and Ports tab to enable the services you want to make available (if any) through the firewall.



    Note that because the machine I was configuring does not connect to my internal network, I did not configure an internal connection. You may need to do this if you want the NAT portion to function correctly.



    Note also that if you allowed the RRAS wizard to apply static packet filters on your external connection you will need to remove these if you want to allow traffic to some specific ports (such as port 80) where the response may not come back on the same port each time, because these filters are not stateful, they will block some of this traffic (which can, among other things, prevent you from being able to browse from that machine).



    Finally, a caveat: I'm still pretty new to the RRAS features of Windows Server 2003, so you should probably not use me as the only source of information on them. The above steps worked for me, and the port scan tests I ran looked pretty good. You, of course, may have a different setup, and end up with different results. So as with anything else security related...use with caution.

  • Ugh, I totally aggree with the fact that MS should have included the firewall in the 'Web Edition' as well.



    You would think they care about security nowadays.



    The argument somebody made that the box should be connected via a hardware firewall is nice, but is no good in my situation (and I expect many others) where the box is shipped to a co-loc who connects it direct to their switch, no firewall, no nothing to protect.



    And the argument somebody else made, that you don't need a firewall if you patch your system is only true if you run absolutly no administrative tools. I for one, control my servers remote with VNC and/or RemoteDesktop (TS). So the firewall is then crucial to protect those special ports, by only allowing access from IPs that I use. I've got some silly IPSec rules defined now, but it's a major pain in the *** to configure IPSec for a dynamic IP range that my cable modem might get (5 * 255 IPs possibilities).



    I used to use Kerio WinRoute Pro to protect my co-loc servers, which used to be Win2k servers. And priced at $149 it's reasonable, even if only used as a firewall solution. Except it seems Kerio is no longer expanding support on it towards Win2k3, so one is forced to buy the new WinRoute Firewall, which is priced at $299 and that is too much in my eyes.



    WinXP came with a firewall included, even if it was a simple inbound one, it's still very effective. The planned WinXP SP2 version will add outbound as well, which is good news for users, so there is extra protection for Trojans, SpyWare, etc. And I hope it will also allow for IP port ranges, like any other firewall solution offers.



    But that still doesn't explain why MS was ignorant enough to include the same WinXP firewall in all other Windows Server 2003 editions, except the one that is most likely to be connected to the internet.



    Well that's enough ranting...



    I'm going to ignore the fact that Kerio doesn't show support for Win2k3 and install a 30-day trial of WinRoute Pro on the box.



    Hope it works.....

Comments have been disabled for this content.