“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 isn’t a big deal, our rule base is still pretty tight, and one addition isn’t going to cause us any compliance problems Then the next ticket comes in. “My IM client isn’t working anymore, it runs on TCP port 5150, please allow outbound access on this port.” A quick examination of the firewall logs reveals that it’s 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 isn’t just untidy, it’s insecure. I can recall many a pen test where I’ve 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, you’ll 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? You should never go shopping without a shopping list; otherwise you’ll 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 I’d expect to see. More importantly it’s 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! access-list 101 line 1 extended permit tcp any host 192.168.0.1 eq 3389 (hitcnt=1420) 0xadb3bee1 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 it’s quicker just to put any, it has the same effect after all.” Unfortunately, it’s this kind of thinking that leads to mistakes. First of all, there may be a network that the firewall admin isn’t aware of that doesn’t 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. access-list 101 line 2 extended permit ip host 192.168.0.1 host 10.0.0.1 (hitcnt=127) 0xfd904f62 In this example, the host 192.168.0.1 is allowed to contact the host 10.0.0.1 on any port. If you can’t 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. Let’s 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 you’ve 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 don’t see just anyone hanging around the car for the sake of it, because they’d 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 it’s unclear what a rule is doing, it should be investigated. If after an investigation it’s still unclear what it’s doing, the issue should be raised with senior management, and treated as an incident. Nine times out of ten it’ll 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 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. labfw01# show access-list access-list 101; 2 elements access-list 101 line 1 extended permit tcp any host 192.168.0.1 eq 3389 (hitcnt=12304) 0xadb3bee1 access-list 101 line 2 extended permit ip host 192.168.0.1 host 10.0.0.1 (hitcnt=7543) 0xfd904f62 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 aren’t “commented”. Something that makes a firewall audit around a million times easier (especially if you are auditing a client’s firewalls rather than your own), is having comments entered with each rule explaining in plain English exactly what it’s doing. Or at the very least, what it’s supposed to be doing. labfw01# access-list 102 remark – Permit HTTP access to web server labfw01# access-list 102 permit tcp any host 10.5.4.1 eq 80 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. labfw01# access-list 102 deny ip any any log 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; I’ll cover just a couple of them to give you an idea of what’s 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 Gateway’s security policy to an HTML or XML file. This may sound elementary, and it is, but it’s an extremely useful tool for reviewing a Check Point firewall configuration. CPDB2HTML can be obtained directly from Check Point at www.checkpoint.com. Nipper 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 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. It’s 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!
