(cisco, or any) acl *reducers* out there?

I have been looking at acl management s/w in the freecode space and I can find lots of tools which manage/distribute and test ACLs in routers.

I'm wondering if anyone has written a parser which can construct rule-trees and get rid of the cruft, unusable, order-misorder and other issues in a large ACL pool?

Its possible this is NP in the wider sense, but even a partial improvement would be useful

something which can take a couple of hundred basic and extended ACLs and tell you

  these <ten> don't work
  these <twenty> conflict
  the remaining <x> have a sequence and can reduce to this basic <x-y> set

(we've got the usual "acquisition of rule by accretion" problem across 4 edge/core routers with a mix of public facing, internal, WiFi, guest rules, and I hate to think this is either start from scratch, or intractable. The evidence is that its FRAGILE)

-G

Attempts by various commercial solutions aside, there isn't really a workable, usable, scalable and reliable automated way to do this, AFAIK; apart from the complexity of the task itself, platform-specific ACL handling complicates matters further.

To begin getting a handle on your ACLs, implement some form of revision control (RCS, CVS, subversion, whatever), and then work to modularize the ACLs by function:

<https://files.me.com/roland.dobbins/prguob>

Then take a look at whether the ACLs in question all actually belong on the edge, or whether it makes sense to break them out and instantiate the relevant policies at various points within the topology.

(we've got the usual "acquisition of rule by accretion" problem across 4 edge/core routers with a mix of public facing, internal, WiFi, guest rules, and I hate to think this is either start from scratch, or intractable. The evidence is that its FRAGILE)

Attempts by various commercial solutions aside, there isn't really a workable, usable, scalable and reliable automated way to do this, AFAIK; apart from the complexity of the task itself, platform-specific ACL handling complicates matters further.

To begin getting a handle on your ACLs, implement some form of revision control (RCS, CVS, subversion, whatever), and then work to modularize the ACLs by function:

<https://files.me.com/roland.dobbins/prguob&gt;

Then take a look at whether the ACLs in question all actually belong on the edge, or whether it makes sense to break them out and instantiate the relevant policies at various points within the topology.

a plug for some google-peeps:

<GitHub - google/capirca: Multi-platform ACL generation system;

potentially once you make the definitions/policy-files you can use the
proto-language to sort through your mess in a saner fashion. a nice
aside is you can also create (from the same policy file)
cisco/juniper/iptables configurations.
(tony/pete really did a nice job on this)

-chris

something which can take a couple of hundred basic and extended ACLs and tell you
these <ten> don't work
these <twenty> conflict
the remaining <x> have a sequence and can reduce to this basic <x-y> set

maybe you could go the other direction. as opposed to trying to digest
and correct cruft, generate the acls from something reasonable so that
they are canonic by construction.

randy

A reasonable call. Its probably where we'll be by default, because there isn't anything there and I think first principles upward is better than paring back.

Thanks for the responses (and Roland!)

I think its clear a tool like I asked doesn't exist, and very probably won't, anytime soon.

cheers

-G

one more comment. be careful aggregating filters. the peer may
actually announce all those damed frags, especially in massively
de-aggregated places such as india, indonesia, ...

randy

I should have been clearer that I really only want to aggregate ACLs like a port-22 ssh filter which has an endless list of specific /32, or the 'we don't like inbound UDP' -where it logically made sense. So if you happen to have an overarching UDP 'established' class rule, then its order compared to other rules might or might not make them useless.

Route filtering is best done by professionals. Always read the instructions on the packet.
(Your oven may be in centigrade, not fahrenheit, and the cup size varies by economy.)

-George

Something similar to this?

http://www.hpl.hp.com/techreports/2008/HPL-2008-111.pdf

cheers!

this paper, while full of math and graphs and sh*t, doesn't make my
acl management simpler, clearer or more complete... I keep trying to
push my acls through the paper, no joy yet.

there's code or something somewhere that implements the algorithms and
graphs and sh*t that the paper shows in a pretty fashion?

-Chris
(btw, you owe me some neosporin to take care of all the paper cuts)

this paper, while full of math and graphs and sh*t, doesn't make my
acl management simpler, clearer or more complete... I keep trying to
push my acls through the paper, no joy yet.

there's code or something somewhere that implements the algorithms and
graphs and sh*t that the paper shows in a pretty fashion?

Heh. Of course there's code associated with it -- how else would we have
managed to come up with numbers from practical application :stuck_out_tongue:

OTOH, without some idea of whether it's what he had in mind, it's
pointless to push the battle to go anywhere with it.

There are certainly some commercial products that do what he seemed to be
asking about, as well -- but I'm failing to find references to them just
now (nothing like illness and deadlines).

(btw, you owe me some neosporin to take care of all the paper cuts)

I've got some lovely iodine... :stuck_out_tongue:

cheers!

this paper, while full of math and graphs and sh*t, doesn't make my
acl management simpler, clearer or more complete... I keep trying to
push my acls through the paper, no joy yet.

there's code or something somewhere that implements the algorithms and
graphs and sh*t that the paper shows in a pretty fashion?

Heh. Of course there's code associated with it -- how else would we have
managed to come up with numbers from practical application :stuck_out_tongue:

oh! I thought perhaps on them fancy HP 37 calculators?

Seriously though, in a brief read I saw it talking about checkpoint
firewall policy stuff... does the code include compiling to meta-state
the policy? does it handle policy from things other than checkpoint?
(like juniper router firewall syntax and pix and cisco acls?)

OTOH, without some idea of whether it's what he had in mind, it's
pointless to push the battle to go anywhere with it.

There are certainly some commercial products that do what he seemed to be
asking about, as well -- but I'm failing to find references to them just
now (nothing like illness and deadlines).

(btw, you owe me some neosporin to take care of all the paper cuts)

I've got some lovely iodine... :stuck_out_tongue:

excellent! I love purple skin!

-chris

I'm wondering if anyone has written a parser which can construct rule-trees and get rid of the cruft, unusable, order-misorder and other issues in a large ACL pool?
  
fwbuilder (www.fwbuilder.org) can import Cisco ACLs and impart a
checkpoint-esque rule tree for you to look at, change, and test .. then
recompile back into ACL syntax. Also works on IPtables, PF, and a few
other things.

Cheers,

Michael Holstein
Cleveland State University

Maybe FLINT?

http://www.matasano.com/playbook/flint

Never tried it so feedback is welcome... :slight_smile:

/bs

Hello

[ I'm sorry this reply is so late, holiday season ]

I understand the problem and think that it is partly caused by the complexity of keeping the acl configuration on all edge ports in sync, and keeping the acl definitions/purpose documented.

The way around this, is to have a configuration management system that records the detail of the ACL (description / ticket number - along with the filter specification in generic terms), which generates the configuration - or even better uses flow-specification to distribute the rules. Further procedures to review the data in this management system periodically help this scale.

For the config management, this would tend to have to be locally bespoke (but simple to produce) in order to fit with existing policy and procedure, but the glue to push these rules out to routers is easy as open source tools exist :-
  http://labs.ripe.net/Members/thomas_mangin/content-exabgp-new-tool-interact-bgp
  http://bgp.exa.org.uk/

Andy