By Mike Buckley | Pre-Sales Consultant at Nettitude 

Firewalls have been around for many years in various shapes and sizes, from simple Access Control Lists, to full “Next-Gen” threat prevention and sandboxing. They have evolved to (mostly) embrace Cloud strategies and remain an important security tool, protecting important assets and securing workspaces. However, they are usually perceived as a necessary evil.

It can be common to encounter applications not working as they should be after a firewall has been implemented. By their very nature, Firewalls should be preventing a lot more traffic than they permit, and it can be a challenge to configure them correctly to allow this access whilst at the same time not reverting to an overly permissive policy. As a result, organisations can rush through the process, sending applications live with rules in place that are designed as a quick fix, rather than a long-standing solution.

In order to correctly onboard clients to NOC services, Nettitude’s Network Operations experts must examine the integrity of a firewall and its setup to ensure the basics are in place. In this blog post, we’ll take a look at the basics of configuring a firewall policy.

Starting with low-level firewall configuration

In order to create an effective firewall policy, we first need to check If the low-level configuration settings are correct. To do this, the following must be taken into consideration -

• • Anti-spoofing on network interfaces should be set by default and make sure that the network groups in that configuration match the static routes using those interfaces
  • Are all unnecessary services disabled? – looking at you Telnet and FTP
  • Check management access is only available on the correct interfaces, you do not want firewall policy management ports to be publicly available
  • Are available threat feeds configured and downloading signatures correctly?
  • Is the software up to date?

Configuring your Firewall policy

If we move onto the policy itself, firstly let’s assume we’re starting from scratch. The following should be taken into consideration -

• • Start with configuring management access, typically ensure encrypted management via SSH and HTTPS to preferably a single internal management interface. Then, test that access from other networks is not possible. Firewalls with thick client management consoles may require many more ports open.
  • Don’t think about using a “deny” rule unless there is explicit reason for it, any traffic being blocked should always be silently dropped, replaying with a “deny” reveals too much information in the reply.
  • Always insert a drop all at the end of the policy with logging on, prior to that if it’s applicable you can also insert a broadcast drop with no logs, just to preserve space and sanity.
  • If your software allows it, segregate the above rules into clearly labelled sections
  • Now you can start gathering information about what devices, networks and users require access to what. This is much simpler now that Firewalls can operate at the application layer.

Working with a pre-existing firewall configuration policy?

Looking at existing policies, there’s a common challenge – IT environments change, and with these changes come rule changes on the Firewall – usually to open up access to new services, either inbound or outbound.

However, the legacy rules remain in place, and over time this presents a risk that services may become exposed. This is something we commonly see in our Firewall reviews and is actually not that challenging to fix, it just requires time and patience. Most Firewalls use hit counters to highlight the busiest rules – these can be reset and monitored, and unused rules can be marked for deletion, disabled, and then finally removed.

The reverse is true for overly permissive rules like an “any any”. Nettitude consultants have experienced this many times – ‘how to remove this rule without causing a risk to the business application that is relying on it?’.

The approach is not one large encompassing one to try and implement all the rules that we think are required and then remove the “any any”. By far the easiest method to approach this is to implement the application rules above the “any any”, reset the hit count and monitor over a time period of days or weeks. This can be repeated as more rules are identified and implemented.

Eventually the only hits on the “any any” rule should be traffic that should be dropped, and the rule can be removed – all with appropriate testing of course! This approach broadly holds true over generally permissive rule-bases.

Further Firewall policy implementation considerations

The vast majority of network traffic is now encrypted, Firewall hardware and resources should be sized to allow for SSL decryption, if the Firewall isn’t inspecting the majority of traffic then all the advanced Threat Preventions are rendered useless and it’s essentially back to being a stateful packet filter.

Is the Firewall being monitored?

Either for availability and performance or log analysis via a SIEM tool which may highlight suspicious activity. If it is being monitored via SNMP ensure that appropriate strength community strings and authentication are used.

Is the Firewall close to performance capacity?

If the Firewall is close to performance capacity then placing the heavily used rules at the top of the policy can be beneficial, rules are checked sequentially and having the heaviest rules at the end means the Firewall is working unnecessarily hard to process traffic.

This is not an exhaustive list. Nettitude’s Consultants go into much more depth when performing reviews and building configuration as each environment is different; but the underlying principals remain the same.

Even in this “perimeter-less” world, a properly configured Firewall plays an important role in an organisation’s cybersecurity strategy. For more information on implementing your firewall policy, find out more on our website.