jathanism / acl Goto Github PK

We need to make some modifications to the "make discard" behavior, especially given how the NOC staff uses this information.

This is the current syntax as displayed by check_access (match conditions trimmed down to try and keep this short)::

term permit_ftp { 
    /* trigger: make discard */
    /* Allow FTP */
    /* trigger: altered from accept for display purposes */ 
    from { 
        destination-address { 
            25.18.14.0/26; 
        } 
        protocol tcp; 
        destination-port [ 20-21 1024-65535 ]; 
    } 
    then { 
        discard; 
    } 
} 

And of course the action is actually "accept" on the routers, but modified for the purpose of access checkes within the ACL.

Consider one of the following changes, in order of descending preference.

1. Ideally, would like to leave the action unchanged (continue to display as accept) and strike the "altered from accept for display purposes" syntax. Understand this may well be impossible to do and retain the rest of the make discard behavior, and almost certainly would be most difficult. So...
2. Change the "altered from accept for display purposes" to "!!!! Action is NOT DISCARD. Probably is accept but check the router to confirm!!!!" and insert this immediately beneath the discard action. I assume here that make discard will work with actions other than permit, but if not then could change the wording to reflect that the action is certainly accept.
3. If you can't do this, then leave the additional syntax where it is but change the syntax as above.

When passing "any" to check_access it is converted to an empty list ([]) that is equivalent to Cisco's "any" or Juniper's null "source-address" block, which equates to "any source" when performing an access test.

Source addresses passed along such as "0.0.0.0" or "0.0.0./0" need to also be properly normalized to "any" (or []) in this context). This should be something that is standard throughout the Trigger ACL libraries.

These two tools have almost identical functionality. check_access could be considered to be a "loose" version to and find_access is "strict". One tool should do both.

The current grouping algorithm is hard-coded to a pattern match on the hostname of the device. That is why I did factor it out to the group() function as you determined, so that we can make this something that can be tweaked in the settings.

Let's move this criteria to a callable that can be found within settings.py.

The timeouts for brocade need to be looked at because they don't seem to be timing out and just hand on "connecting to....". Finally, need to determine why certain ACLs couldn't complete the load on Brocade devices and fix/throw error.

Take this very benign example of a policy-statement:

policy-statement Martians {
    term T1 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /25-/32;
            route-filter 10.0.0.0/8 orlonger;
            route-filter 127.0.0.0/8 orlonger;
            route-filter 128.0.0.0/16 orlonger;
            route-filter 169.254.0.0/16 orlonger;
            route-filter 172.16.0.0/12 orlonger;
            route-filter 191.255.0.0/16 orlonger;
            route-filter 192.0.0.0/24 orlonger;
            route-filter 192.0.2.0/24 orlonger;
            route-filter 192.168.0.0/16 orlonger;
            route-filter 224.0.0.0/4 orlonger;
        }
        then reject;
    }
}

which I would call then in some sort of routing policy, in this case it might be for a bgp peer:

bgp {
    log-updown;
    remove-private;
     group Your Mom {
        type external;
        import [ Martians YM_communities-next_hop ];
        export [ Public-Stuff Match_Any_Deny ];
        peer-as 1234;
        neighbor 1.2.3.4;
    }
}

Trigger should be able to handle me modifying either a section of the policy, either to add a new term, possibly insert a statement into an existing term, or change the behavior of the policy-statement in some way:

policy-statement Martians {
    term T1 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /25-/32;
            route-filter 10.0.0.0/8 orlonger;
            route-filter 127.0.0.0/8 orlonger;
            route-filter 128.0.0.0/16 orlonger;
            route-filter 169.254.0.0/16 orlonger;
            route-filter 172.16.0.0/12 orlonger;
            route-filter 191.255.0.0/16 orlonger;
            route-filter 192.0.0.0/24 orlonger;
            route-filter 192.0.2.0/24 orlonger;
            route-filter 192.168.0.0/16 orlonger;
            route-filter 224.0.0.0/4 orlonger;
        }
        then reject;
     }
    term T2 {
       then log;
   } 

}

Or possibly even add/change another variable of my peer. Lets say I wish to drain this router:

bgp {
    log-updown;
    remove-private;
     group Your Mom {
        type external;
        import [ YM_communities-next_hop ];
        export [ Your_Mom_Drain_Policy ];
        peer-as 1234;
        neighbor 1.2.3.4;
    }
}

Examples could vary. I may roll a new routing policy to a router and add it to an import or export statement. There are also a huge variety of types of policy match conditions and actions that might be useful.

pip install acl
Defaulting to user installation because normal site-packages is not writeable
Collecting acl
Downloading acl-0.2.tar.gz (53 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 53.8/53.8 kB 468.9 kB/s eta 0:00:00
Preparing metadata (setup.py) ... error
error: subprocess-exited-with-error

× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [9 lines of output]
Traceback (most recent call last):
File "", line 2, in
File "", line 34, in
File "C:\Users\rathod\AppData\Local\Temp\pip-install-7u4zumfs\acl_e76dc37a32814d5b9773f408007ddc5e\setup.py", line 11, in
from acl import full_version as version
File "C:\Users\rathod\AppData\Local\Temp\pip-install-7u4zumfs\acl_e76dc37a32814d5b9773f408007ddc5e\acl_init_.py", line 25
print "Skipping parser imports"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)?
[end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.

This work will be non-trivial. We just added ipv6 address parsing as a first pass (see: trigger/trigger#12) for Juniper access-lists. The address parsing grammar should work for any ACL format, but the IOS grammar has not been updated yet to support ipv6.

Each vendor grammar should be broken into a distinct module so that they can be independently maintained.

http://support.citrix.com/proddocs/topic/netscaler-advanced-networking-92-map/ns-nw-acl-intro-wrapper-con.html

Example to follow...

Currently the ACL parser only supports the numeric form (112) to specify vrrp as a protocol. Example:

term permit-vrrp {
            from {
                destination-address {
                    224.0.0.18/32;
                }
                protocol vrrp;
            }
            then accept;
        }
}

Enhance the parser to support either form. This was explicitly disabled in the past because it breaks parsing of certain Cisco access-lists. We can find a way!

See python-netfilter (which actually has a parser):
https://github.com/jlaine/python-netfilter

Or python-iptables (which is a low-level lib):
https://github.com/ldx/python-iptables

See IPTables::Parse (Perl) for regex patterns:
http://www.cipherdyne.org/modules/IPTables-Parse.html

Reference for Juniper ipv6 ACLs:
http://www.juniper.net/techpubs/en_US/junos12.2/topics/reference/general/firewall-filter-match-conditions-for-ipv6-traffic.html

Self-explanatory.

The magic comment acl: make discard can be put in to an ACL term to modify the behavior of the term for the purpose of access checks.

This feature needs to be documented properly, with examples, of course. The impetus behind the feature, too.

See: acl.tools.check_access
See: acl.parser.Term.makediscard
See: bin/check_access and how it displays terms modified by the acl: make discard comment.

trigger.acl.tools.check_access() looks for both permits and denies and can search for membership within networks or port-ranges, protocols, but does not check modifiers such as fragment-offsets, or other header options. Because term block_snmp_fragments has a fragment-offset 0 modifier in the term, the access was not an exact match and therefore was being skipped.

Note in this output below that it displays term block_snmp_fragments as being part of the access path, but it does not accurately determine it to be dropping the traffic because were weren't asking it to check fragment-offset 0. It reports the following term 10net-TCPUDP-ALLOW as permitting the access with the inline comment "/*check_access: PERMITTED HERE*/".

% ./check_access acl.123 10.180.124.82/32 1.2.3.4/32 udp 161 
term cflow { 
    then { 
    next term; 
    count arbor-cflow; 
    } 
} 
term block_snmp_fragments { 
    /* DIsallow snmp fragments */ 
    from { 
    fragment-offset 0; 
    protocol udp; 
    destination-port 161-162; 
    } 
    then { 
    discard; 
    count T42; 
    } 
} 
term 10net-TCPUDP-ALLOW { 
    /*check_access: PERMITTED HERE*/ 
    from { 
    source-address { 
        10.0.0.0/16; 
        10.2.0.0/16; 
...

We need to research the commands required to do this.

They are IOS-like, but differ in that you may specify CIDR prefixes for addresses, and that the "ip access-list/no ip access-list" syntax is like Cisco's "ip access-list extended", but without the extended keyword. There are likely other caveats that will require research.

Others include lines like:

! igmp
permit tcp any any eq mlag ttl eq 255
permit tcp any eq mlag any range 1024 65535
permit udp any any eq mlag ttl eq 255
permit udp any eq mlag any range 1024 65535

Simple example:

add policy expression abc_123_dtc "SOURCEIP = 25.18.64.0 -netmask 255.255.240.0" 
add policy expression abc_123_mtc "SOURCEIP = 6.2.0.0 -netmask 255.255.240.0" 
add policy expression abc_123_ntc "SOURCEIP = 20.20.12.0 -netmask 255.255.255.0" 
add policy expression abc_123_frr "SOURCEIP = 19.9.5.0 -netmask 255.255.254.0" 
add policy expression abc_123_networks "abc_123_dtc || abc_123_mtc || abc_123_ntc || abc_123_frr" 
add filter policy block_abc_123 -rule abc_123_networks -reqAction DROP 
add policy expression abc_123_and_webcache_networks "abc_123_networks || abc_webcache_networks" 
add filter policy block_abc_123_and_webcache -rule abc_123_and_webcache_networks -reqAction DROP 

http://support.citrix.com/servlet/KbServlet/download/23195-102-666134/NS-PolicyConfig-Guide.pdf

Here's the syntax for the match conditions I have in the filters now:

    term evil-8065_DSCP { 
        /* Project:"non-zero TOS value DCSP"  */ 
        from { 
            dscp-except [ be cs0 ]; 
        } 

    term evil-8065_PRECEDENCE { 
        /* Project:"non-zero TOS value PRECEDENCE"  */ 
        from { 
            precedence-except routine; 
        } 

Would like to go ahead and add the rest of the matches.

DSCP:
af11 Assured forwarding class 1, low drop precedence
af12 Assured forwarding class 1, medium drop precedence
af13 Assured forwarding class 1, high drop precedence
af21 Assured forwarding class 2, low drop precedence
af22 Assured forwarding class 2, medium drop precedence
af23 Assured forwarding class 2, high drop precedence
af31 Assured forwarding class 3, low drop precedence
af32 Assured forwarding class 3, medium drop precedence
af33 Assured forwarding class 3, high drop precedence
af41 Assured forwarding class 4, low drop precedence
af42 Assured forwarding class 4, medium drop precedence
af43 Assured forwarding class 4, high drop precedence
be Best effort (default)
cs0 Class selector 0
cs1 Class selector 1
cs2 Class selector 2
cs3 Class selector 3
cs4 Class selector 4
cs5 Class selector 5
cs6 Class selector 6
cs7 Class selector 7
ef Expedited forwarding

TOS:
Possible completions:
Range of values
[ Open a set of values
critical-ecp Critical/ECP
flash Flash
flash-override Flash override
immediate Immediate
internet-control Internet control
net-control Network control
priority Priority
routine Routine

And also (obviously) make sure we support the non-except syntax, so...

from { 
            dscp [ all the same match variables ]; 

and

from { 
            precedence [ all the same match variables ];