1/29/14

Playing by the Rules: Performing Firewall Audits - InfoSec Institute

877.791.9571

Ho me Sc h edul e

C o n trib u to rs About

A rtic l es

M in i C o urses

D o wn l o ads

C o urses

Download & Resources

Sign up for our newsletter to get the latest updates.

View our FREE mini-courses!

SIGN UP NOW

SUBMIT

Discounted Boot Camps

SIGN UP NOW

Playing by the Rules: Performing Firewall Audits

21
Tw eet

32
Svia m i se

subm it

reddit

Anyone who has ever managed a firewall will know that all too often its a one way street. From the moment the device is plugged into the network, rules are added to allow traffic to flow between the required hosts and ports. We start out with the best of intentions, deploying the absolute minimum number of rules needed to keep things as tight as possible. All is well in the world of firewall management, but then
resources.infosecinstitute.com/firewall-audits/ 1/10

1/29/14

Playing by the Rules: Performing Firewall Audits - InfoSec Institute

we are hit with the first trouble ticket. Please allow my machine to contact server X on port 8081, I need this to test a new piece of software. No problem you say, you grab the source IP and allow it to talk to server X on 8081. This isnt a big deal, our rule base is still pretty tight, and one addition isnt going to cause us any compliance problems Then the next ticket comes in. My IM client isnt working anymore, it runs on TCP port 5150, please allow outbound access on this port. A quick examination of the firewall logs reveals that its indeed blocking port 5150 outbound, so you shove a rule in to allow it. You decide that more than one person will likely be using this client, and from the logs you see it requires access to a variety of servers on the outside. Begrudgingly, you add the rule that allows port 5150 outbound, from any source to any destination. Suddenly, your rule base is starting to take on an appearance akin to that of a piece of Swiss cheese. This trend continues over time and is mirrored across multiple firewalls in the organization. The rule base grows and gets more and more complex. Different administrators add different rules to address different issues. Rules overlap and cancel each other out, which in turn causes the performance of the firewall to degrade. Meanwhile, on the inside of the network, servers are decommissioned and their IP addresses are recycled. Unless someone thinks to tell the firewall admin, an old rule stays in place without being removed or amended. This is a huge problem, and unfortunately, a common one. Firewall administrators are always the first to hear about it when a rule is preventing something from working, but when that rule is no longer required radio silence. This isnt just untidy, its insecure. I can recall many a pen test where Ive stumbled across a machine that is unwittingly exposed the outside world thanks to sloppy firewall rules. The solution to this problem: performing regular firewall rule audits. If you have experience with PCI DSS, youll know that performing a firewall rule audit at least every six months is a requirement of the standard (requirement 1.1.6 to be precise). So what should you be looking for during an audit, and how do you go about looking for it? Of course a lot of the answer to that question depends on the number, complexity and type of firewalls you are auditing. It also depends on the budget you have available for tools to help speed up the process! What are we looking for?
resources.infosecinstitute.com/firewall-audits/ 2/10

1/29/14

Playing by the Rules: Performing Firewall Audits - InfoSec Institute

You should never go shopping without a shopping list; otherwise youll end up wandering round for hours comparing tins of beans. Trust me, it happens. The same is true of auditing firewalls. We need to have a clear goal of what we should be interested in. Rules that specify any source or destination. How much of an issue these rules are depends upon the position of the firewall. There is usually a perfectly acceptable reason for rules with any source or destination to be in an edge firewall. Allowing hosts to browse the internet; send or receive email and perform DNS lookups are just a few of those reasons. If however the firewall is internal, segregating different networks, perhaps in a cardholder data environment an any source or destination rule is not something Id expect to see. More importantly its something a PCI auditor would question. The reasoning behind that should be quite clear. If you implement a firewall to separate your networks, and then put a rule in that undoes all that effort, you must really like making work for yourself! a c c e s s l i s t1 0 1l i n e1e x t e n d e dp e r m i tt c pa n yh o s t 1 9 2 . 1 6 8 . 0 . 1e q3 3 8 9( h i t c n t = 1 4 2 0 )0 x a d b 3 b e e 1 This rule allows any source to contact 192.168.0.1 on TCP port 3389, commonly used for remote desktop connections. Some will try to justify an any source or destination rule by stating that the any destination is there because that server needs to talk to all networks in the environment, so rather than specifying them all its quicker just to put any, it has the same effect after all. Unfortunately, its this kind of thinking that leads to mistakes. First of all, there may be a network that the firewall admin isnt aware of that doesnt strictly need access to or from the host specified in the rule. Secondly, while it may have the desired effect at the time the rule is entered, a few months later, as new components are added to the network, the context of the any rule may change, and allow more open access than was originally intended. Rules that allow any service between two hosts. These are a definite red flag, regardless of the position of the firewall. Rules should adhere to the principle of least privilege. Of course, this means only giving an entity the minimum amount of access required to do its job properly. Why would a server in the DMZ require FTP access to an internal database server? This is all well and good for applications that use well known or registered TCP ports (FTP, SSH, HTTP etc.), but what do we do with those that use dynamic port ranges? This is the most common reason people shove an any service rule into a firewall. a c c e s s l i s t1 0 1l i n e2e x t e n d e dp e r m i ti ph o s t1 9 2 . 1 6 8 . 0 . 1
resources.infosecinstitute.com/firewall-audits/ 3/10

1/29/14

Playing by the Rules: Performing Firewall Audits - InfoSec Institute

h o s t1 0 . 0 . 0 . 1( h i t c n t = 1 2 7 )0 x f d 9 0 4 f 6 2 In this example, the host 192.168.0.1 is allowed to contact the host 10.0.0.1 on any port. If you cant pin down the rule to a specific port, you should try and do the next best thing restrict access to a range of ports used by the application. This could be 10,000 ports, but still, that is better than the full 65,355. Remember, the aim here is to reduce the attack surface as best we can. Rules that have no effect, either because they overlap or are cancelled out by a prior rule. Generally speaking, firewalls handle rules sequentially. They start at the top of the list and work their way down to the very end. Therefore, the order in which those rules are entered into the firewall is extremely important, and often an area of oversight. Lets take a look at an example of a case where a rule has been put in the wrong place, and as a result is doing little more than taking up disk space.

The intention in the above example is to deny internal users access to the cardholder data environment, while still allowing system admins remote desktop access. Unfortunately, because the rules have been entered in the wrong order, the second rule will have zero effect. The traffic will have already been dropped by the time the firewall gets around to processing it, and the poor system admins will be denied access. This example leads to inconvenience (for the system admins); however there are plenty of others out there that led to much more serious security problems. Rules that do not have a defined business purpose, or are unused (zero hit count). If youve ever seen a motor racing team bring their car in for a pit stop, you will have likely marveled at how quickly they can refuel and change tires. This is possible because everyone in the pit crew has a specific job to do, and they do it. You dont see just anyone hanging around the car for the sake of it, because theyd likely get in the way and slow things down. Firewalls should be like a pit crew. Every single rule needs to be doing something to justify being there in the first place. If its unclear what a rule is doing, it should be investigated. If after an investigation its still unclear what its doing, the issue should be raised with senior management, and treated as an incident. Nine times out of ten itll turn out that the mysterious rule is a harmless hangover from a legacy system or configuration, but it could also be harboring something more sinister. One way of finding out if a rule is actually doing something is to take a look at the hit
resources.infosecinstitute.com/firewall-audits/ 4/10

1/29/14

Playing by the Rules: Performing Firewall Audits - InfoSec Institute

count. The hit count is the number of times a packet transiting the firewall has matched a particular rule. How you determine the hit count depends on the platform you are working with. l a b f w 0 1 #s h o wa c c e s s l i s t a c c e s s l i s t1 0 1 ;2e l e m e n t s a c c e s s l i s t1 0 1l i n e1e x t e n d e dp e r m i tt c pa n yh o s t 1 9 2 . 1 6 8 . 0 . 1e q3 3 8 9( h i t c n t = 1 2 3 0 4 )0 x a d b 3 b e e 1 a c c e s s l i s t1 0 1l i n e2e x t e n d e dp e r m i ti ph o s t1 9 2 . 1 6 8 . 0 . 1 h o s t1 0 . 0 . 0 . 1( h i t c n t = 7 5 4 3 )0 x f d 9 0 4 f 6 2 The show access-list command on this Cisco PIX displays the access lists in use on the firewall and the hit count for each rule. Rules that arent commented. Something that makes a firewall audit around a million times easier (especially if you are auditing a clients firewalls rather than your own), is having comments entered with each rule explaining in plain English exactly what its doing. Or at the very least, what its supposed to be doing. l a b f w 0 1 #a c c e s s l i s t1 0 2r e m a r kP e r m i tH T T Pa c c e s st o w e bs e r v e r l a b f w 0 1 #a c c e s s l i s t1 0 2p e r m i tt c pa n yh o s t1 0 . 5 . 4 . 1e q 8 0 Adding a remark (comment) to an ACL Lack of an explicit cleanup rule. Not as mission critical as it once was, thanks to the majority of modern day firewalls now implementing a deny by default ethos, but still something to be on the lookout for. The lack of a cleanup or deny everything else rule at the end of an access control list could allow any traffic not matched by a rule in the firewall to pass unhindered. This would be a very bad thing, as it would allow more access to a host than intended. Even if your firewall does drop unmatched traffic by default, it will most likely not be recording this in a log file. This could hinder troubleshooting and investigation efforts, and is another valid reason for having an explicit cleanup rule in place. l a b f w 0 1 #a c c e s s l i s t1 0 2d e n yi pa n ya n yl o g
resources.infosecinstitute.com/firewall-audits/ 5/10

1/29/14

Playing by the Rules: Performing Firewall Audits - InfoSec Institute

A traditional clean up rule notice the addition of log, to ensure that all dropped packets are recorded. So now that we know what we are looking for, we should probably start looking. This is a fairly straightforward task if we have only a couple of firewalls to audit, with a few dozen rules in each. If this is the case, we can just ask for a copy of the rules or running configuration, and study them by hand without getting too much of a headache. But life is never normally that simple, and frequently audits require the review of many firewalls with long and complex rule bases. If this is the case, you may need to call on tools to help automate the audit process. There are many tools and utilities out there that can help with this type of work; Ill cover just a couple of them to give you an idea of whats out there, but is by no means an extensive list. CPDB2HTML CPDB2HTML (Check Point Database to HTML) is a free tool produced by Check Point Software. Known as the Web Visualization Tool, essentially it dumps the contents of a Check Point Security Gateways security policy to an HTML or XML file. This may sound elementary, and it is, but its an extremely useful tool for reviewing a Check Point firewall configuration. CPDB2HTML can be obtained directly from Check Point at www.checkpoint.com. Nipper

Want to learn more?? The InfoSec Institute CISSP Training course trains and prepares you to pass the premier security certification, the CISSP. Professionals that hold the CISSP have demonstrated that they have deep knowledge of all 10 Common Body of Knowledge Domains, and have the necessary skills to provide leadership in the creation and operational duties of enterprise wide information security programs. InfoSec Institute's proprietary CISSP certification courseware materials are always up to date and synchronized with the latest ISC2 exam objectives. Our industry leading course curriculum combined with our award-winning CISSP training provided by expert instructors delivers the platform you need in order to pass the CISSP exam with flying colors. You will leave the InfoSec Institute CISSP Boot Camp with the knowledge and domain expertise to successfully pass the CISSP exam the first time you take it. Some benefits of the
resources.infosecinstitute.com/firewall-audits/ 6/10

1/29/14

Playing by the Rules: Performing Firewall Audits - InfoSec Institute

CISSP Boot Camp are: Dual Certification - CISSP and ISSEP/ISSMP/ISSAP We have cultivated a strong reputation for getting at the secrets of the CISSP certification exam Our materials are always updated with the latest information on the exam objectives: This is NOT a Common Body of Knowledge review-it is intense, successful preparation for CISSP certification. We focus on preparing you for the CISSP certification exam through drill sessions, review of the entire Common Body of Knowledge, and practical question and answer scenarios, all following a high-energy seminar approach.

VIEW CISSP TRAINING

The name comes from network infrastructure parser, which should give you an idea of how it works. You feed it a copy of the running configuration from the device you are auditing (and it supports a great deal of devices including Cisco, Juniper, F5, Dell, Brocade and Checkpoint), wait about half a second and watch as it produces an extremely detailed report.

In addition to studying the rules in an access control list, Nipper also takes a look at the general configuration of the target device, to make sure it is up to scratch. The pricing of Nipper makes it an attractive option for consultants. A free trial is available from https://www.titania-security.com/. Firemon Security Manager Firemon Security Manager is a full blown suite for keeping tabs on exactly what your firewalls are up to at any given movement. It allows you to map out traffic flows, track changes to device configuration, and suggests ways to simplify a rule base. One of the very best features of Firemon is its ability to crack open a rule that allows any service to pass and see exactly which services are being used. This gives the firewall admin a great opportunity to remove the offending any statement, and
resources.infosecinstitute.com/firewall-audits/ 7/10

1/29/14

Playing by the Rules: Performing Firewall Audits - InfoSec Institute

tighten things up a touch.

This is certainly a tool that is more likely to be owned and operated by the client than an auditor or consultant, but the data it produces provides value on a daily basis, not just at audit time. Conclusion So there you have it, a quick guide to performing firewall audits, and just a couple of the tools that can help you along the way. Its important to remember that sometimes the mere presence of a firewall can create a false sense of security. The reality is that unless they are properly maintained and reviewed, firewalls can become nothing more than an extra hop along the way. Take care of your firewalls and they will take care of you!

By Mike Sheward | June 15th, 2012 | General Security, Management, Compliance, & Auditing | 2 Comments

Share This Story, Choose Your Platform!

About the Author: Mike Sheward

Mike Sheward is a network security engineer for a software-as-a-service provider based in Seattle, as well as a researcher at the InfoSec Institute. He began his career
resources.infosecinstitute.com/firewall-audits/ 8/10

1/29/14

Playing by the Rules: Performing Firewall Audits - InfoSec Institute

as a network engineer working for various British government departments. During this time he developed a passion for security and started on a path that led him to a full-time security role with a private organization. Mike has performed penetration testing for a wide range of public and private sector clients, has been involved in a number of digital forensics investigations and has delivered security training to fellow IT professionals.

2 Comments
Gina Mayfield June 16, 2012 at 5:21 pm - Reply

Great article, I totally agree with you most companies do a good job of rationalizing the need for added rules or opening ports but neglect to review or audit firewall configurations. Thanks so much.

Cristiano June 27, 2012 at 5:32 am - Reply

why not Next gen Firewall ? able to check the Application and NOT the port .

Leave A Comment

Name (required)

Email (required)

Website

Comment...

POST COMMENT

3 one =

resources.infosecinstitute.com/firewall-audits/

9/10

1/29/14

Playing by the Rules: Performing Firewall Audits - InfoSec Institute

ARCHIVES Select Month POPULAR SEARCH TERMS

agile android

RECENT POSTS
Web Services Penetration Testing, Part 6: Fuzzing Parameters with Burp Free CISSP Training and Study Guide Reinventing Threat Intelligence A Close Look at the NSA Monitor Catalog Server Hacking IOS Application Security Part 28 Patching IOS Application with Hopper Improving the Human Firewall Session Randomness Analysis with Burp Suite Sequencer Dejan Kosutic on Business Continuity and Disaster Preparedness IOS Application Security Part 27 Setting up a mobile pentesting environment with IOS 7 Jailbreak ECC: A Case for Mobile Encryption

SEARCH THIS SITE Search ...

LIKE US ON F ACEBOOK = = STAY UP TO DATE InfoSec Institute

Svia m i se 8.039

application security App Security

bootcamp ccna
certifications CISA CISM

CISSP compliance crackme

ethical hacking exploit
development

feature featured
security

forensics general

hacking how-to
human resources infosecdocs

interview iphone IT
Auditing java linux

malware management
nmap penetration

reverse engineering
reversing scada

testing

security security
awareness social media sql

injection TOR training video vulnerabilities

vulnerability wapt
wordpress

Copyright 2012 - InfoSec Institute | All Rights Reserved

resources.infosecinstitute.com/firewall-audits/

10/10