Updated rapolicy Argus Client

[Dave Edelman]

There has been some discussion on the list about rapolicy() which is a
client that takes a Cisco IOS access control list and applies it to an Argus
stream. The version that has been available was designed to accommodate some
of the older ACL formats, specifically the original numbered IP access-list
(1-99 for standard and 100-199 for extended.)
 
With Carter's help I have revised the code and it now parses both named and
numbered IP access lists in both standard and extended format. It can apply
the rules to Argus flow streams just like any ra() based client. The output
can be displayed, written to a file, or written to stdout and piped to
another client. When rapolicy terminates, it prints out a table of each
entry in the list, its line number, and the number of flows, packets, and
bytes that matched each one. If it is a named ACL the top line (IP
access-list extended test_list_name) has the grand totals. Sorry there is no
place to put that on a numbered list.
 
[      1922         2612486            334033962]       ACL 100 Line 1:
access-list 100 permit tcp any any log
[      1937            3076               774718]       ACL 100 Line 2:
access-list 100 permit ucp any any log
[         0               0                    0]       ACL 100 Line 3:
access-list 100 permit icmp any any log
[         0               0                    0]       ACL 100 Line 4:
access-list 100 deny ip  any any log
 
Just to be clear, this is not an ACL syntax checker, it does a reasonable
job but it will happily accept TCP flags on an ACL entry for UDP packets.
You probably want to use IOS as the syntax checker and use the output of a
"show running" command as the input to rapolicy()
 
The parser provides copious debug information at -D 3. It will also remind
you to set -D 3 if it runs into a parsing problem. Debug information is only
available if the client is built with debug configured.
 
A set of four resource file parameters control some of rapolicy's more
important actions. 
 
RA_POLICY_LABEL_LOG               if this is set to "yes", any flow that
matches an ACL entry with a log qualifier is labeled (details below)
 
RA_POLICY_LABEL_ALL if this is set to "yes", all flows are labeled
regardless of the presence of a log qualifier. The labeling of a flow has no
impact on the output of the flow. If the flow matches a deny entry, you will
not see it. To make that happen there is the next option 
 
RA_POLICY_SHOW_WHICH if this is set to "deny", the output will be the flows
that match on a deny statement, if it is set to "permit" output is the set
of flows that match permit statements. Just like IOS, there is an implicit
deny at the end of every access list. 
 
RA_POLICY_PERMIT_OTHERS controls the scope of the ACL on raplolicy's output.
The normal action of an ACL is to only control traffic in its scope. An IP
access list will have no effect on an ARP packet. When you are debugging an
ACL, this extra traffic can be a distraction. If this parameter is set to
"no" then all out of scope traffic is suppressed. The default is to mimic
IOS and output all traffic that is not subject to the ACL.
 
The labels are pretty simple, they tag the flow with the details of which
line of which ACL matched the flow and what action was taken as a
consequence.
ACL=Permit_protocol-test3_Line_0006
ACL=Deny_protocol-test3_Line_0011
 
Numbered ACLs have the ACL number following the Permit/Deny/ImplicitDeny
action
ACL=Permit_100_Line_0002
 
ImplicitDeny actions, by definition have no line number
ACL=ImplicitDeny_protocol-test3
 
I am doing pretty methodical testing using an Argus instance to feed a
radium client configured to label the arriving flows. I have two rapolicy
clients taking traffic from radium. One rapolicy instance is configured to
show permits, the other to show denies. I also have an ra client taking the
same feed serving as a control and to allow for replay. I am using real
traffic, nping, and ostinato to generate test traffic and my intent is to
include a test suite as part of the distribution.
 
This is a work in progress and Carter has agreed to include it as such in
the next update. Please try it out and provide feedback. I already have a
few things that I'd like to add based on what I've seen so far. 
Because the purpose of an access list it to limit traffic there is currently
no way to indicate that you want to label but not limit the traffic. I will
probably add that as an option as well as an option to only show the flows
that are designated ImplicitDeny. I see value in both of those since using
the IOS ACL debugger on a heavily loaded device is evil.
 
Comments, questions, discussion are always welcome.
 
--Dave
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130319/5e03ea37/attachment.html>