So one of the questions people have upon moving to SBS 2008 and SBS 2011 is why they need to have a firewall enabled on the server and workstations if you have a firewall on the external edge.  I mean after all that’s all you need to really protect you right?  Right?  I mean it wasn’t there on SBS 2003?

Yeah and that server was built 9 years ago when the Internet was a different place.   An external firewall protects you from the edge but the internal firewalls you have inside the office protects you inside the office as well as limits exposure.

The firewall on workstations and servers blocks ports inbound.  To have a nicely (and securely) set up network you want only those ports that are authorized to be open inbound.  Should you have any changes in that firewall profile, it’s one sign of tampering, malware or other intrusions.  On a default SBS 2008 and SBS 2011, the server has a series of ports open in order to have file and sharing traffic, Exchange traffic etc.  Should another inbound hole in the Windows Frewall with Advances security on the local computer be set and YOU didn’t set it, it’s a good forensic trail to start investigating.

Same on the workstation side.

If you’ve got the firewall controlled by the group policies of SBS 2011 standard,  anytime you see a firewal port that is not grayed out (that’s the clue it’s been built by the group policy of the server), and pokes holes in the firewall profiles of the domain/home and public, you might want to make sure you know exactly what application built that hole.


If you didn’t approve it, you don’t recognize it as an authorized app on that workstation, it’s a place to start when understanding how things wiggled into your system.

Ensuring that you leave the firewalls on inside your network, and can document what you authorized, means should something happen in that firm, you may have more forensic evidence for investigation. 

Now let’s get into historical reasons why firewalls and only authorized ports are a good thing.  Many years ago there was Slammer and Blaster.  Slammer in particular nailed people with open SQL server ports, many times open TO THE OUTSIDE when they shouldn’t have been.  If we would have had firewalls on the inside of our offices and SQL apps that had no business talking outside that firewall were blocked from being open, SQL slammer would have hurt a lot lot less.

And finally lets talk about the vendor issue.  I see many people just turn off the firewall because they have an application that needs ports open.  I WANT you to know exactly what ports are open on that firewall for that application.  Because I’ve seen some vendors demand an insane amount of ports open.  If the vendor is on the ball, they will tell you a list of applications to build firewall rules for NOT ports.  If you use applications in the firewall rule, when the application is not in use, the port will close.  If you build rules with port numbers they won’t close.  Some vendors even have networking diagnostic tools to help

But the vendors that just tell you to shut off the firewall, go back to them and ASK them specifically what ports or what application exceptions need to be built.  If they don’t know, that’s a sign that they aren’t security aware, aren’t making sure their application is coded well.  Use this as the litmus test for these vendors.  If they can’t tell you the ports and application exceptions in an on premise solution, you going to trust them with a cloud solution?  Seriously?

Bottom line you have approximately 65000 tcp/udp ports ready and willing to be talking to anything.  Don’t make it easy for that system to get into trouble.

Comments are closed.

Post Navigation