Reverse Engineering A Firewall Policy With Securify

Some years back, a company I was working for had a big problem – they had a number of PIX firewalls where the primary firewall rule – give or take a few specific permits and denies – was pretty much “permit ip any any”. We called them routers, because that was pretty much how they acted.

After we mocked these ridiculous devices long enough, management finally said “Fine – put your money where your mouth is and make them proper firewalls with a real ruleset.”

And that’s where the problem begins – how do you reverse engineer a firewall policy based on the traffic going through it?

Solving The Problem

Maybe we could use Netflow? Set up monitoring on both sides of the firewall perhaps, export the data to a netflow collector, analyze it to identify all the layer 4 flows over a period of time, and then try and process the data to figure out which flows the firewall was allowing through (seen on both sides perhaps), then try to convert that into a ruleset of some sort. All of this assuming that your switches or routers on each side of the firewall are capable of capturing every packet (rather than doing sampling). Hopefully you also get the netflow table size and dump frequency right, otherwise you’ll lose data.

Securify

Securify was founded in 1998. It was acquired in September 2008 by Secure Computing which in turn – also in September 2008 – was acquired by McAfee. Go figure. Anyway, one of Securify’s products (I forget if it was their only one at the time) was for firewall policy creation and enforcement. It was possible to configure the Securify appliance with the intended corporate security policies, stick taps (or use SPAN ports) on the inside and outside of a firewall, and it would evaluate the traffic going through the firewall to determine whether the traffic passing through the firewall was in compliance with the policy. It’s a great way to audit your policies in real time and detect unauthorized changes. When ‘out of policy’ traffic is detected, the management console would track the alerts, and if the traffic should be allowed, it was then possible to add it automatically to the Securify policy base so that you wouldn’t see future alerts.

The Solution

So here’s what we did. We spanned two interfaces on the PIX firewall (let’s say ‘inside’ and ‘outside’ for the sake of argument), and configured Securify to believe that the security policy was to allow nothing.

As traffic passed through the firewall, the management console went insane with alerts because all traffic was outside policy. Each flow that showed up in the console was checked for validity, then added to the policy if it was acceptable. This continued over the next couple of weeks. Obviously as time went on, the number of alerts decreased because most traffic had already been identified and allowed, and once we got to the point where we saw no new alerts for a couple of days, we made the assumption that we had seen 99% of the valid traffic and captured it in the Securify policy base.

Now what? Securify, rather handily, had the ability to export the security policy you created in a number of formats, including PIX ACL. Export the ACL, put it on the firewall, apply it, and we’re in business. One security policy reverse-engineered based on actual traffic; it wasn’t that hard, and didn’t require any scripting.

Caveats

I somewhat glossed over the biggest challenge of reverse-engineering a ruleset based on active traffic is that if there are already illicit flows taking place, you might accidentally permit that flow and thus permit a flow that should have been blocked. The part where you validate each flow is really important – validating that the source should be allowed to initiate a flow to a given destination is the very minimum that you should do. If you know that a particular destination only uses certain ports, you can configure that too.

The resulting policies are not as perfectly organized as they might be if you were to set things up manually, using object-groups and the like, but it’s an awful lot better than ‘permit ip any any’.

Ta-Dah!

So there it is. A quick tale from the past, and (I think) quite a neat solution. Enjoy!