Analytics
9/12/2013
03:57 AM
Dark Reading
Dark Reading
Quick Hits
50%
50%

Building And Maintaining Effective Firewall Configurations

The best firewalls in the world can still be misconfigured. Here are some tips for keeping yours up to snuff

[The following is excerpted from "Building and Maintaining Effective Firewall Configurations," a new report posted this week on Dark Reading's Perimeter Security Tech Center.]

Much of the innovation we're seeing in the perimeter security space today is happening in the areas of Web security and application intelligence, but advanced threats and intelligent malware aren't the only threat vectors you need to account for. Your entire perimeter security strategy must be built upon a strong foundation, and that starts with the execution of certain basic firewall configuration best practices. You can have the best intrusion-prevention system (IPS) and Web security tools on the planet, but if your firewall is misconfigured or mismanaged, then you are living in a house built on top of a sinkhole.

Proper configuration and management of your firewalls is a trivial exercise for the experienced firewall admin. But even the best among us can make the occasional mistake that can open up an attack vector. On the other end of the spectrum, less-seasoned firewall admins can open up gaping holes in their defenses without even knowing it.

Operational and management issues that create real security holes are only magnified when large teams of security pros are co-managing a large number of firewalls. If you're fortunate enough to be an experienced firewall admin wholly responsible for your farm of corporate firewalls, then consider yourself extremely lucky. But in most cases, the responsibility of managing a large number of firewalls spread across many sites is shared among a team of security pros. And as with any co-managed system, the more cooks in the kitchen, the greater the likelihood of errors, mistakes or misconfigurations in the broth.

All too often, we concentrate our time and effort on making sure our advanced security tools are doing an effective job. And all too often, we fail to pay attention to a crack in the foundation that can surface as a result of security policy misconfiguration. Here are some of the gotchas, tools and best practices that should be considered to ensure that your firewalls provide a strong foundation for the rest of your perimeter security strategy.

Rule-Based Configuration
Building and maintaining an effective firewall configuration starts with your rule base. Whether you're unpacking a firewall for the first time or pushing a new security policy to an existing firewall for the 1,000th time, the way in which you configure your firewall rules can help make you extremely secure or extremely insecure. It's easy for anyone to grasp the concept of what a firewall needs to do from a rule perspective, but implementation is key to avoiding gaping holes in your defenses. Even veteran firewall pros can make mistakes here, especially when trying to manage unfamiliar firewall platforms.

There are several basic best practices that should be used in the day-to-day management of your firewalls from a rule-based configuration perspective.

Don't lose track of your "deny-any" rule.
When you unpack a new firewall and start building a security policy from scratch, it's easy to visualize what hosts you're exposing to the Internet. However, that visualization gets infinitely more difficult when you have 300 rules in play.

Most enterprise-grade firewalls come with a "deny-any" rule base out of the box, and it's important not to lose track of it. The deny-any rule is commonly referred to as the "catch-all" rule because it ensures that any traffic not specifically allowed is dropped. Firewall admins can run into trouble when they set this action to "allow" and fail to set it back, or when they fail to see that the default action is set to allow. Even more likely: They configure an allow-any rule prior to reaching the catch-all rule, which defeats the whole purpose of the catch-all rule.

Beyond that, it's important not to be overly generous with the TCP/UDP services that you allow internal hosts access to on the Internet. If you are, then you're exposing your hosts to unnecessary risk of attack and/or malware infection.

To read more rules and tips for maintaining strong firewall configuration -- and for some easy-to-use controls you can add to your security policy -- download the free report.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Threat Intel Today
Threat Intel Today
The 397 respondents to our new survey buy into using intel to stay ahead of attackers: 85% say threat intelligence plays some role in their IT security strategies, and many of them subscribe to two or more third-party feeds; 10% leverage five or more.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-5426
Published: 2014-11-27
MatrikonOPC OPC Server for DNP3 1.2.3 and earlier allows remote attackers to cause a denial of service (unhandled exception and DNP3 process crash) via a crafted message.

CVE-2014-2037
Published: 2014-11-26
Openswan 2.6.40 allows remote attackers to cause a denial of service (NULL pointer dereference and IKE daemon restart) via IKEv2 packets that lack expected payloads. NOTE: this vulnerability exists because of an incomplete fix for CVE 2013-6466.

CVE-2014-6609
Published: 2014-11-26
The res_pjsip_pubsub module in Asterisk Open Source 12.x before 12.5.1 allows remote authenticated users to cause a denial of service (crash) via crafted headers in a SIP SUBSCRIBE request for an event package.

CVE-2014-6610
Published: 2014-11-26
Asterisk Open Source 11.x before 11.12.1 and 12.x before 12.5.1 and Certified Asterisk 11.6 before 11.6-cert6, when using the res_fax_spandsp module, allows remote authenticated users to cause a denial of service (crash) via an out of call message, which is not properly handled in the ReceiveFax dia...

CVE-2014-7141
Published: 2014-11-26
The pinger in Squid 3.x before 3.4.8 allows remote attackers to obtain sensitive information or cause a denial of service (out-of-bounds read and crash) via a crafted type in an (1) ICMP or (2) ICMP6 packet.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?