Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Operations

9/17/2015
10:35 AM
Kyle Wickert
Kyle Wickert
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

5 Most Common Firewall Configuration Mistakes

A misconfigured firewall can damage your organization in more ways than you think. Here's where to look for the holes.

As security threats become more and more advanced, managing your firewall configurations has never been more important. IT professionals spend much of their time worrying about flaws and vulnerabilities, but according to Gartner research, 95% of all firewall breaches are caused by misconfiguration, not flaws.

Firewalls are an essential part of your network security, and a misconfigured firewall can damage your organization and give easy access to an attacker. Yet misconfigurations are alarmingly common. In my work I come across lots of mistakes in firewall configurations. Below are five of the most common types that I encounter, along with advice on how you can avoid them.

1. Broad policy configurations
Firewalls are often set up with an open policy of allowing traffic from any source to any destination. This is because IT teams don’t know exactly what they need at the outset, and therefore start with broad rules and work backwards. However, the reality is that due to time pressures or simply not regarding it as a priority, they never get round to defining firewall policies. This leaves the network in a perpetually exposed state.

Organizations should follow the principle of least privilege – that is, giving the minimum level of privilege that the user or service needs to function normally, thereby limiting the potential damage caused by a breach. It’s also a good idea to regularly revisit your firewall policies to look at application usage trends and identify new applications being used on the network and what connectivity they require.  

2. Risky rogue services and management services
Services that are left running on the firewall that don’t need to be is another mistake I often find. Two of the main culprits are dynamic routing, which typically should not be enabled on security devices as best practice, and “rogue” DHCP servers on the network distributing IPs, which can potentially lead to availability issues as a result of IP conflicts. I’m also surprised to see the number of devices that are still managed using unencrypted protocols like telnet, despite the protocol being over 30 years old.

The answer to this problem is hardening devices and ensuring that configurations are compliant before the device is put into a production setting. This is something with which a lot of enterprises struggle. But by configuring your devices based on the function that you actually want them to fulfill and following the principle of least privileged access, you will improve security and reduce the chances of accidentally leaving a risky service running on your firewall.

3. Non-standard authentication mechanisms
During my work, I often find organizations that use routers that don’t follow the enterprise standard for authentication. For example, a large bank I worked with had all the devices in its primary data center controlled by a central authentication mechanism, but did not use the same mechanism at its remote office. By not enforcing corporate authentication standards, staff in the remote branch could access local accounts with weak passwords, and had a different limit on login failures before account lockout.

This scenario reduces security and creates more vectors for attackers, as it’s easier for them to access the corporate network via the remote office. Organizations should ensure that all remote offices follow the same central authentication mechanism as the rest of the company.

4. Test systems using production data
Companies tend to have good governance policies requiring that test systems should not connect to production systems and collect production data. But in practice, this is often not enforced because the people who are working in testing see production data as the most accurate way to test. The problem occurs because when you allow test systems to collect data from production, you’re likely to bring that data into an environment with a lower level of security. The data could be highly sensitive, and it could also be subject to regulatory compliance. So if you do use production data in a test environment, make sure that you use the correct security controls according to the classification of the data.

5. Log outputs from security devices 
The issue that I see more often than I should is organizations not analyzing log outputs from their security devices -- or without enough granularity. This is one of the biggest mistakes you can make in terms of network security; not only will you not be alerted when you’re under attack, but you’ll have little or no traceability when you’re investigating post-breach.

The excuse I often hear for not logging properly is that logging infrastructure is expensive, and hard to deploy, analyze, and maintain. However, the costs of being breached without being alerted or being able to trace the attack are surely far higher.

Enterprises need to look at the state of their firewall security and identify where holes might exist. By addressing these misconfiguration issues, organizations can quickly improve their overall security posture and dramatically reduce their risk of a breach.

Kyle joined AlgoSec in 2012, working first as a regional system engineer covering the central United States and eastern Canada region, and then as a lead solution architect of product & deployment. Prior to that he worked at Scotiabank for four years as an information ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
packetdude2
50%
50%
packetdude2,
User Rank: Strategist
9/18/2015 | 7:06:28 PM
Test data?
Using production data in test is definitely a no-no. But I'm not clear on how it is a "Firewall Configuration Mistake"!
7 Truths About BEC Scams
Ericka Chickowski, Contributing Writer,  6/13/2019
DNS Firewalls Could Prevent Billions in Losses to Cybercrime
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/13/2019
Can Your Patching Strategy Keep Up with the Demands of Open Source?
Tim Mackey, Principal Security Strategist, CyRC, at Synopsys,  6/18/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-3896
PUBLISHED: 2019-06-19
A double-free can happen in idr_remove_all() in lib/idr.c in the Linux kernel 2.6 branch. An unprivileged local attacker can use this flaw for a privilege escalation or for a system crash and a denial of service (DoS).
CVE-2019-3954
PUBLISHED: 2019-06-19
Stack-based buffer overflow in Advantech WebAccess/SCADA 8.4.0 allows a remote, unauthenticated attacker to execute arbitrary code by sending a crafted IOCTL 81024 RPC call.
CVE-2019-10085
PUBLISHED: 2019-06-19
In Apache Allura prior to 1.11.0, a vulnerability exists for stored XSS on the user dropdown selector when creating or editing tickets. The XSS executes when a user engages with that dropdown on that page.
CVE-2019-11038
PUBLISHED: 2019-06-19
When using gdImageCreateFromXbm() function of gd extension in versions 7.1.x below 7.1.30, 7.2.x below 7.2.19 and 7.3.x below 7.3.6, it is possible to supply data that will cause the function to use the value of uninitialized variable. This may lead to disclosing contents of the stack that has been ...
CVE-2019-11039
PUBLISHED: 2019-06-19
Function iconv_mime_decode_headers() in versions 7.1.x below 7.1.30, 7.2.x below 7.2.19 and 7.3.x below 7.3.6 may perform out-of-buffer read due to integer overflow when parsing MIME headers. This may lead to information disclosure or crash.