Firewall Ruleset Review

I’ve done a lot of firewall ruleset reviews for companies large and small. There is a pattern forming in almost every firewall I’ve seen.

Bad management.

It’s not about blaming people though. The economy is in the sewer and layoffs plague every company across the planet. Most every security team is dealing with tons of ongoing work to stay secure and low budgets and resources to get the job done.

The firewall rule sets I’ve seen range from 50 lines to 10,000+ lines. Some are so complex that we schedule a week of work to audit and determine what can be taken out, what needs to stay and what shouldn’t have been there in the first place.

Let’s face it; many firewalls have dead rules, non-existent networks and “permit any” rules. Those are the low lying fruit that we look for first and when fixed, automatically increase security surrounding the attached networks.

Any access list that ends in “permit ip any any” is wasted CPU power and increased RAM usage. Why make your firewall go thru all of those rules if you permit everything at the end anyways? Not to mention, if you’re going to do that, you could have saved yourself hundreds or thousands of dollars and just gotten a router and used static routes to forward traffic. But in the security world that isn’t an option.

Too often we see timeout settings that are too large, insecure protocols being used and lack of ingress or egress rules. The worst cases are the firewalls that are built backwards (a whole slew of deny statements followed by a permit any statement).

Overall, the largest issue is lack of egress filtering. Time and time again, we run into this. And in many of our assessments we capitalize on this. In both Social Engineering attacks and Penetration tests we are able to accomplish many tasks by using these lax rules. Even if you aren’t worried about the next major virus or worm, you should care in not helping spread the infection. Close your doors and be a good neighbor!

All of these issues add up to the sum of bad network security which is caused by bad management. There needs to be process and documentation of all rules and configuration settings within a configuration. Asking “Hey Chuck, there’s a strange rule in here, did you do that?” doesn’t count as documentation either.

At the end of the day, if you skip on a little security here and a little security there, what’s the point of implementing high dollar equipment? If you’re going to implement your firewall properly you should have dedicated process behind the ruleset. Justify every rule, every business segment, set it, and forget it. There should be no need to constantly be modifying your firewall. I can see the need if you’re installing a new server or software package, but adding and dropping lines daily or even weekly is not efficient use of anyone’s time.

The moral of the story is, if you are making constant changes, have bad rules, or an insecure configuration, then you should start over and build your configuration properly. A regular audit of the firewall ruleset is always a good idea and should be budgeted for. Put in the proper change control, documentation and justification, and you will be amazed how much more secure your network will become.