As a consultant, I get to see a lot of different environments. It's also incumbent upon me to know Microsoft best practices, as well as real world best practices. There are two common configurations that I see constantly which really need to be addressed. Those two things are Windows Firewall and IPv6. In case this article becomes a victim of TL;DR, let me cut to the chase. Windows Firewall should be ON. And IPv6 should be ENABLED. The reasons why are just past the break.
Windows Firewall
It's a fact that there was a time when the Windows Server operating system did not have a firewall. And then it did have a firewall, and everyone turned it off. In part that was because most Windows sysadmins were not used to dealing with an OS firewall, and also in part because Microsoft didn't make it all that easy to use. That is no longer the case. Windows Server 2008 and 2012 make it simple and straightforward to configure your firewall, and also have a ton of canned rules to get you started. You can use the GUI or netsh, or PowerShell, or Group Policy. The management of Windows Firewall is not hard, and that excuse is no longer valid.
So why do people disable Windows Firewall now? The first reason I hear is that the servers are behind a firewall already, so there's no need to enable it. To that I have a few questions:
- Is the firewall between the server and all of your clients?
- Is the firewall between the server and all other servers?
- Is the firewall between the server and all other network ports?
If the answer is "No" to any of these questions, then Windows Firewall should be turned on. The name of the game here is defense in depth. If someone compromises your external firewall, then they still need to get through the local one. If someone jacks into your corporate network, they still need to compromise the Windows Firewall. If someone hacks one of your internal servers, they still don't have free reign on every other server. Additionally, if you plan to use IPSec, then you need to have Windows Firewall on anyway.
The second reason I hear is that Windows Firewall breaks application X, where application X could be any product you install on a server. My response to that is to ask what ports and protocols the application uses. This often ends in blank stares, or some hemming and hawing. If you are going to introduce a new application into your server environment, you should really know what it needs on the network side, especially if you plan to expose it to the internet. Your network or security guy is going to ask you these questions anyway. Wouldn't it be nice to already know the answer? Any application worth its salt should have a well documented set of ports that the application uses. If it doesn't, then you can turn to the netstat command or Network Monitor or Wireshark. Any of those should assist with learning what the application is actually trying to do to your network. Though, I'm going to go ahead and say that if the application documentation doesn't have ports and protocols, then you might want to rethink the whole install. Windows Firewall doesn't break your application, it forces you to understand your application better. And in the long run that's a much better scenario.
IPv6
I'll admit it. I find IPv6 nomenclature confusing. IPv4 seems much simpler in comparison. Plus, all I use is IPv4 on my network right? So why wouldn't I disable IPv6? It can't be up to any good, and I don't want it messing up my network with a bunch of pointless traffic. So I'm going to go into the properties of my network card and uncheck the IPv6 box. Boom!
Well the bad news is that you haven't disabled IPv6. In fact, IPv6 is baked pretty deep into the Microsoft stack. When you uncheck that box, all you are really doing is unbinding IPv6 from the NIC. This is bad news for two reasons. First, a lot of newer Microsoft products (Exchange 2013, Direct Access, IP-HTTPS) use IPv6 communication and will break if you unbind it from the NIC. I've run into this several times when an install of Exchange is acting oddly, and I go into the NIC properties and see that the IPv6 box is unchecked. Half the time that is part of the client's standard server template! The second reason it's a bad idea, is that until very recently, there was no programmatic way to recheck that box. If you unchecked that box on 300 servers and now suddenly need to recheck it because you are starting to use IPv6, well I hope you didn't have anything to do for the next few hours. Worse still, what if you've unbound IPv6 on 10,000 laptops and now you want to rollout Direct Access? There is a way to do it now, but it requires Windows 8 or Server 2012, which if you don't have, then it's clicky-macro time for you.
There is a way to totally disable IPv6 on Windows and you need to go into the registry to do it. Microsoft doesn't make it obvious or simple because they don't want you to do it! I'm not even going to put a link here. You can Google it for yourself if you're into breaking things for fun.
I have heard some concerns that leaving IPv6 enabled and bound will cause an increase in network traffic. The perception is that somehow your OS is going to send packets through both stacks every time for common protocols like DNS or Web traffic. Fortunately this is does not happen. Microsoft has committed to supporting the IPv6 stack and it tests all applications for compatibility. You know what Microsoft doesn't test for? The impact of disabling and unbinding IPv6. So if you get on a support call with Microsoft, they're probably going to tell you to enable and bind it as part of the troubleshooting process. That's what I would say too.
So in closing, when it comes to Windows Firewall and IPv6, leave them on! You'll be glad you did.
References:
http://blogs.technet.com/b/askpfeplat/archive/2013/06/17/ipv6-for-the-windows-administrator-why-you-need-to-care-about-ipv6.aspx
http://technet.microsoft.com/en-us/magazine/2009.07.cableguy.aspx
Labels: firewall, IPv6, Microsoft, networking, security, Windows Firewall, Windows Server 2008, Windows Server 2012