How do people typically perform security audits of firewalls?

Question

In my days as a pentester, we used to use tools like Nipper, combined with manual analysis, to perform audits of firewall configurations. However, in my current company we have many different firewalls and network devices, and I was wondering how people typically will audit their firewalls for security.

Note - I am not asking for specific product recommendations, though throwing out vendor names never hurts, what I am really asking for here is how people approach the task of performing audits.

To my thinking, the ideal solution would be some form of unified management for firewalls, which would allow the networking team to do all of their day to day operations, but also support change management controls, security audits, compliance reviews, and more.

Answer 1

I usually look firstly at the network diagrams and how the network is or should be configured. This will give me an idea of where is the perimeter, the internal networks, the functional segments and so on. I then look at what are the devices - brand, model - used to manage the environment, whether they are enterprise class and have functionality to unify the management. This should give me an indication of how much I can see centrally versus how much time I'll need to go through individual systems.

I'll look at the basic management of the firewall - firmware updates and version, user management, syslog and NTP configurations. Then I'll look at the rules.

Ideally rules will be justified/explained with a comment or link to a change control. There will be a valid source, destination with specific protocols for most rules - there will be very few instances of 'any'. Secure protocols will be used where possible, HTTPS, SFTP and justified if not. Redundant rules and objects will be disabled or removed. Application and operations teams will assist in the review to validate their requirements.

Counts on use of rules or tools to identify unused rules/objects are useful.

Once you've completed the review and you have a list of issues, questions, these should be entered into a report or spreadsheet and changes required identified and prioritised. Redundant rules should be disabled temporarily prior to deletion and comments updated. Rules which can be more restrictive should be updated and commented.

Once you've done the above across the estate, it's probably time to start again!

Answer 2

I create manual scripts to test intended and unintended rules. It requires access to the firewall rules, as well as the intent (comments, tickets) of each. Each firewall rule gets a specific test in the same way a programmer creates unit tests (Test-Driven Development approach). In addition, corner cases are conceived and tested.

I generate test traffic both inside and outside of the boundaries I am testing. With a good script, you can even kick off a continual test and make changes to the firewall rules in order to see the effect of the changes in real time. The source code of the scripts can be saved in source control management repos (svn, git, hg, etc.) for auditability. A junior member can run the scripts on a regular basis (monthly?) to audit the firewalls. The script can change for every change to the firewalls.

In addition, I use nmap for a general sweep to see the baseline of a full port sweep, but port sweeps cannot test all the possible configurations of traffic types (malformed packets, custom app traffic, etc.).

In practical terms, I used to use hping3 quite extensively (tcl scripting support), but I have very recently converted my scripts to Python using scapy.