Firewall aid - getting more than just a security box from your XTM

How some simple configuration best practice (developed in time) made my Watchguard firewall not only defend networks, but also helped to prevent security problems.

I’ve always been a supporter of the proactive problem approach rather than working when it’s too late. Viruses, network outages, connectivity issues or system crashes. It’s much better facing the problem before it’s too late. In other words, it’s better informing a Company or users that you’re going to reboot a system rather than waiting for them to report the issue. If you’re a service provider, this paradigm may change your service outsourcing success.

After installing over about 100 Watchguard devices I have developed a best practice I am following to set up the device, from the basic settings to the most specific rules within the policy manager. I will share the checklist in a near future within my blog if anyone is interested.
Once set up you probably might think everything will work fine and you can forget about your firewall. Whether it is quite near the truth, the Firebox System Manager can come handy to know what is going on your network. Let me expose two real life happenings that happened during my on field duty, with two different “unexpected” results.

During a default gateway migration we have replaced the existing network device with a XTM box. Within the migration I have set the common set of policies, which allowed the 90% of users to access the network resources right after the migration. Right after this process we have put under analysis the TCP-UDP default rule that allows all the traffic through the firewall which returned a malicious traffic within the network that caused heavy network outages or slowdowns.

The second case came up a couple of days ago and is strictly related to the DNS changer. Knowing well the DNS mechanism configuration in an Active Directory domain (or, anyways, any network) a typical deployment is described as in the following scheme.

 

The rule want clients to query the internal DNS (Active Directory), setting deployed by the DHCP server. The Domain Controller forwards requests to the ISPs DNS resolvers. An explicit proxy policy is defined in the firewall configuration that allows DNS queries from the Domain Controller(s) to the ISPs DNS resolvers.

After an infected client came into the network, the firewall started logging a set of denied DNS requests and the behavior started spreading. Before it was too late we could identify and solve the issue before it could tear down the entire network, causing serious problems.

The meaning of these two examples is pretty clear. A well configured firewall is a helpful tool that allows to define the baseline of the normal network behavior. Since all the traffic from and towards the Internet is inspected by this device, you can use its upper layer services also to audit the network applications commonly used by your device - for example - by using the Application Control and other layer 7 features. If you are defending custom exposed applications you can use the layer 7 logging to determine whether the application is “behaving” or compliant with RFCs, or also if a bug is found in your code you can simply create an exception to defend your systems before it is patched. Further if your firewall starts logging too much denied traffic, perhaps it’s a signal that something odd is happening on your network.

Asking someone to keep watching the firewall log might sound funny or a torture, depending on your mood, but a well configured firewall is a great help to understand if you are going to face an imminent networking problem or not. The log and report servers comes out extremely handy in this case, and allow a well organized behavior review on a periodic basis, while the messagging system allows a near real-time notification if determined conditions are met. Of course this is just a minor set of tools you should have. Perhaps if you are an MSSP you might consider adding more tools integrated to monitor your devices, like Nagios if you have a centralized infrastructure (or plan to have) or either the Watchguard Server. In any case, baselines are vital for the success (active or proactive) of your response team, which means you might consider developing serious best practices based on your own experience and knowledge of your Customer environments.

Just consider how many network devices you had a couple of years ago (one per user?) and how many hosts are connected to your network after the BYOD phenomenon, which can also bring up 2 or 3 devices per user making your network explode with an exponentially incrementing number of hosts to handle.