How to configure a firewall - 5 Easy to avoid errors [NETASQ]

Photo courtesy of John Palmer

People often ask me why I place so much importance on the initial configuration of a firewall. The reason is simple. According to Gartner, 95% of intrusions relating to firewalls are due to configuration errors (Gartner ID:G00208704). So anything that simplifies the setup process has the potential to significantly limit the risk of intrusions. 

Let’s take a look at some of the most easy-to-avoid configuration errors. Feel free to submit others by leaving comments on this article.

5. Connection errors
This may seem surprising, but it is a rather standard error. Plugging a cable into the wrong port, or making mistakes when connected to the management interface, and the security policy will immediately be wrong and generally lead to a network freeze. 

A few simple rules:

• If possible, use a color code for your cables according to zones
• Label your network cables using unambiguous names (e.g. “internal dmz”)
• Copy these names in a list (port 1 = WAN, etc.)
• Before mounting or configuring your firewall, take a photo of it J

Once it is connected, your firewall should allow you to view connected ports.

 

Firewall’s dashboard - only one connected port – does that seem right?

If your firewall allows it, the first thing to do once you are connected to the configuration interface, is to rename your interfaces so that the names will be the same as those you have given (on a NETASQ firewall, go to Network > Interfaces).

4. (Un)intentionally-disabled protection mechanisms
We already touched on it briefly in “The door is closed but what about the windows”  – most firewalls on the market, even if they claim to be “Next Generation”, do not enable any protection mechanisms in their default configuration. As a result, if no one thinks of enabling them, you will end up with a 90s-era firewall, but at a much higher price. Only after the first incident occurs will the unpleasant surprise be discovered. So think of browsing the intrusion prevention (IPS) menus or your firewall’s protection profiles. 

As for NETASQ firewalls, they use several protection profiles, which are active from the moment they leave production and which differ according to the nature of the traffic (see below).

Pre-defined protection profiles
(Application protection > Inspection profiles)

Traffic inspection is therefore already active when you receive your firewall. If nothing is specified in the Security inspection column in your security policy, the IPS mode will be applied.

 
 NETASQ filter policy with various levels of inspection

Often, protection mechanisms may be disabled in several areas of the configuration. You are therefore advised to carefully read through the documentation or to browse the various menus. On a NETASQ firewall, it is necessary to check, for example, that the inspection for a given protocol has not been disabled. In the menu Application Protection > Protocols and applications, you will find the following option on the IPS tab for each protocol (selected by default):

 

3. Unnecessary rules

Immediate display when there is an unnecessary rule

Unfortunately, not all firewalls warn you when a filter rule is unnecessary. However, adopting a few good habits will help you to optimize your policy:

• If your firewall allows it, measure the use of each filter rule to locate unnecessary rules
• Classify rules by scope of use (outgoing access, public servers, etc.).
• Filter the display of the policy by a source or by a destination to see whether several rules tally.

There are also filter policy management solutions that come at a fee. If you have any other tips, feel free to share them.

2. Permissions that are too wide ranging
The multiplication of appliances, including personal appliances (the growing “Bring Your Own Device” trend), has had the effect of removing the IP component of the filter policy bit by bit, to users’ detriment. Far from being reassuring, this trend generally leads to a very permissive filter policy. Are you sure that your filter policy does not contain any of these following errors?

• The source or destination field set to “Any”, when the Internet was actually intended
• A public holiday considered a workday
• Access to maintenance left open for way too long
• Access to all ports on a host
• Allowing any protocol or application on a given destination port

These wide-ranging permissions may backfire, not necessarily during a direct intrusion attempt, but because they allow bounces from your network. 

If you own a NETASQ firewall, the Internet object allows you to use “Any” in many cases, and gets rid of tricky situations.

For public holidays, there is a time object called “annual event” (Objects > time objects menu) that allows you to manage them correctly. The time objects called “Fixed events” are very useful for temporary maintenance access. 

1.       Neglecting the human factor
It cannot be said enough, but the human factor eventually determines the quality of a security policy. Forgetting to inform users is a common error that has many consequences. Users are very adept at bypassing a technical security policy that has been imposed on them against their will. Here are some of the errors caused between the chair and the keyboard:

• The absence of an IT charter
• Drastic and fickle restrictions, without any communication
• Torture by interposed passwords

Saying what you are going to do, explaining what you are doing and reminding others why you did it fully apply to protection measures.

The errors cited today are easy to avoid, as long as you remember to avoid them. What about you? Have you already witnessed configuration errors that could have had grave consequences? How do you recommend avoiding them? Do tell us your story.

Fuente: NETASQ Community Blog