Access Control to Infrastructure (iACL) and Transit (tACL)

As we said in our basic ACL How To, ACL’s’ are vital to networking today. Everyone uses them, and proper usage is imperative.

In this How To, we are going a little deeper into two ACL types: Intrastructure and Transit.  We will discuss the two with examples and you will clearly understand the difference between them.

Both iACL’s and tACL’s are ACL’s.  This makes them axtremely similar.  So what makes them different?  In a nut shell, the answer is, that iACL’s protect you network infrastructure: they explicitly permit only traffic you authorize into the infrastructure equipment while permitting (all legitimate transit traffic); tACL’s explicitly permit only required traffic into your network or networks.  

Here is how Cisco specifies iACL’s:

To protect infrastructure devices and minimize the risk, impact, and effectiveness of direct infrastructure attacks, administrators are advised to deploy infrastructure access control lists (iACLs) to perform policy enforcement of traffic sent to infrastructure equipment. Administrators can construct an iACL by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. For the maximum protection of infrastructure devices, deployed iACLs should be applied in the ingress direction on all interfaces to which an IP address has been configured.

Here is how Cisco specifies tACL’s:

To protect the network from traffic that enters the network at ingress access points, which may include Internet connection points, partner and supplier connection points, or VPN connection points, administrators are advised to deploy transit access control lists (tACLs) to perform policy enforcement. Administrators can construct a tACL by explicitly permitting only authorized traffic to enter the network at ingress access points or permitting authorized traffic to transit the network in accordance with existing security policies and configurations.

Confused?  Let’s see some examples to clear the confusion.

Infrastructure ACL Example

As explained above, iACL’s are going to be a barrier or gauntlet to stop certain types of traffic at the edge of your infrastructure.  Some examples of this would be:

  • Deny all Anti-Spoofing Addresses – meaning packets with source addresses that do not make sense.
    • RFC 1918 Addresses – meaning the we should never see packets from private IP addresses entering on the public side of our infrastructure.
    • RFC 3330 Address – meaning we should never see packets from special use source addresses
    • We would want to deny packets that are entering your network from outside with a source address from inside your network!  
  • We would want to permit any routing protocols that allow our edge to connect to the outside world, like BGP
  • We would want to deny traffic targeting any of our internal router or switch addresses.  Remember, traffic will transit those devices, but when we are administring them, we will do this from inside our network.
  • We should permit everything else as “transit traffic” allowed through our iACL gauntlet.
You may edit these examples, or leave off whatever does not apply to your needs.

csi-edge(config)# !— Anti-spoofing entries first

csi-edge(config)# !— Deny RFC 3330 special-use address sources

csi-edge(config)# access-list 110 deny ip host 0.0.0.0 any

csi-edge(config)# access-list 110 deny ip 127.0.0.0 0.255.255.255 any

csi-edge(config)# access-list 110 deny ip 192.0.2.0 0.0.0.255 any

csi-edge(config)# access-list 110 deny ip 224.0.0.0 31.255.255.255 any

csi-edge(config)# !— Deny RFC 1918 private address sources

csi-edge(config)# access-list 110 deny ip 10.0.0.0 0.255.255.255 any

csi-edge(config)# access-list 110 deny ip 172.16.0.0 0.15.255.255 any

csi-edge(config)# access-list 110 deny ip 192.168.0.0 0.0.255.255 any

csi-edge(config)#!— Deny your address space as source from entering your network

csi-edge(config)#!— Lets assume your network is 66.66.66.0/24

csi-edge(config)# access-list 110 deny ip 66.66.66.0 0.0.0.255 any

csi-edge(config)#!— Permit BGP.  

csi-edge(config)#!— Let’s assume our BGP router IP address is 66.66.66.100

csi-edge(config)#!— and the peer IP address is 11.11.11.11 

csi-edge(config)# access-list 110 permit tcp host 11.11.11.11 host 66.66.66.100 eq bgp

csi-edge(config)# access-list 110 permit tcp host 66.66.66.100 eq bgp host 11.11.11.11

csi-edge(config)#!— Deny access to internal infrastructure addresses.

csi-edge(config)#!— Let’s say we use the 172.16.1.0/24 space for infrastructure

csi-edge(config)# access-list 110 deny ip any 172.16.1.0 0.0.0.255

csi-edge(config)#!— Permit anything that has made it through our gauntlet

csi-edge(config)#!— as this must be transit traffic.

csi-edge(config)# access-list 110 permit ip any any

The last step would be to apply this access list to the interface facing the outside of the network.  Let’s say that the interface is a gig 1/0 interface:

csi-edge(config)# interface gig 1/0

csi-edge(config-if)# ip access-group 110 in

The key here is that we will be watching the inbound traffic against our iACL.

Transit ACL Example

As explained above, tACL’s are going to be a barrier or gauntlet to stop certain types of traffic from transiting through your infrastructure.  Some examples of this would be:

  • Deny all Anti-Spoofing Addresses – meaning packets with source addresses that do not make sense.
    • RFC 1918 Addresses – meaning the we should never see packets from private IP addresses entering on the public side of our infrastructure.
    • RFC 3330 Address – meaning we should never see packets from special use source addresses  
  • We would want to permit any routing protocols that allow our edge to connect to the outside world, like BGP
  • We would want to deny traffic targeting any of our internal router or switch addresses.  Remember, traffic will transit those devices, but when we are administring them, we will do this from inside our network.
  • Permit specific traffic that is allowed to return to our network:
    • ICMP traffic so we can track errors on the network
    • Outgoing DNS queries and older DNS queries and replies to primary DNS server
    • Legitimate Business traffic
    • FTP, TFTP, and other multimedia traffic
  • Permit specific traffic that is externally sourced into our network:
    • Incomming DNS queries, zone transfer DNS queries, and older queries, but then deny all other DNS traffic
    • IPsec VPN Traffic to specific hosts
    • Internet-sourced connections to our publicly accessible servers
    • Data connections to the FTP server are allowed by the permit established ACE
  • FInally, deny anything else

You may edit these examples, add or leave off whatever does/does not apply to your needs.

 

csi-edge(config)# !— Anti-spoofing entries first

csi-edge(config)# !— Deny RFC 3330 special-use address sources

csi-edge(config)# access-list 110 deny ip 127.0.0.0 0.255.255.255 any

csi-edge(config)# access-list 110 deny ip 192.0.2.0 0.0.0.255 any

csi-edge(config)# access-list 110 deny ip 224.0.0.0 31.255.255.255 any

csi-edge(config)#!— Note: the deny statement should not be configured

csi-edge(config)#!— on Dynamic Host Configuration Protocol (DHCP) relays.

csi-edge(config)# access-list 110 deny ip host 0.0.0.0 any

csi-edge(config)# !— Deny RFC 1918 private address sources

csi-edge(config)# access-list 110 deny ip 10.0.0.0 0.255.255.255 any

csi-edge(config)# access-list 110 deny ip 172.16.0.0 0.15.255.255 any

csi-edge(config)# access-list 110 deny ip 192.168.0.0 0.0.255.255 any

csi-edge(config)#!— Deny your address space as source from entering your network

csi-edge(config)#!— Lets assume your network is 66.66.66.0/24

csi-edge(config)# access-list 110 deny ip 66.66.66.0 0.0.0.255 any

csi-edge(config)#!— Permit BGP.  

csi-edge(config)#!— Let’s assume our BGP router IP address is 66.66.66.100

csi-edge(config)#!— and the peer IP address is 11.11.11.11 

csi-edge(config)# access-list 110 permit tcp host 11.11.11.11 host 66.66.66.100 eq bgp

csi-edge(config)# access-list 110 permit tcp host 66.66.66.100 eq bgp host 11.11.11.11

csi-edge(config)#!— Deny you internal infrastructure addresses as source (see RFC 2827)

csi-edge(config)#!— Let’s say we use the 172.16.1.0/24 space for infrastructure

csi-edge(config)# access-list 110 deny ip any 172.16.1.0 0.0.0.255

csi-edge(config)#!— Explicitly permit return traffic.

csi-edge(config)#!— Allow specific ICMP types.

csi-edge(config)# access-list 110 permit icmp any any echo-reply

csi-edge(config)# access-list 110 permit icmp any any unreachable

csi-edge(config)# access-list 110 permit icmp any any time-exceeded

csi-edge(config)# access-list 110 deny icmp any any

csi-edge(config)#!— Allow outgoing DNS queries.

csi-edge(config)# access-list 110 permit udp any eq 53 host primary DNS server gt 1023

csi-edge(config)#!— Permit older DNS queries and replies to primary DNS server.

csi-edge(config)# access-list 110 permit udp any eq 53 host primary DNS server eq 53

csi-edge(config)#!— Permit legitimate business traffic (may be more than one subnet)

csi-edge(config)# access-list 110 permit tcp any [Internet-routable subnet] established

csi-edge(config)# access-list 110 permit udp any range 1 1023 [Internet-routable subnet] gt 1023

csi-edge(config)#!— Allow ftp data connections (may be more than one subnet)

csi-edge(config)# access-list 110 permit tcp any eq 20 [Internet-routable subnet] gt 1023

csi-edge(config)#!— Allow tftp data and multimedia connections (may be more than one subnet)

csi-edge(config)# access-list 110 permit udp any gt 1023 [Internet-routable subnet] gt 1023

csi-edge(config)#!— Explicitly permit externally sourced traffic.

csi-edge(config)#!— These are incoming DNS queries.

csi-edge(config)# access-list 110 permit udp any gt 1023 host [primary DNS server] eq 53

csi-edge(config)#!– These are zone transfer DNS queries to primary DNS server.

csi-edge(config)# access-list 110 permit tcp host [secondary DNS server] gt 1023 host [primary DNS server] eq 53

csi-edge(config)#!— Permit older DNS zone transfers.

csi-edge(config)# access-list 110 permit tcp host [secondary DNS server] eq 53 host [primary DNS server] eq 53

csi-edge(config)#!— Deny all other DNS traffic.

csi-edge(config)# access-list 110 deny udp any any eq 53

csi-edge(config)# access-list 110 deny tcp any any eq 53

csi-edge(config)#!— Allow IPSec VPN traffic.  You may have mutiple devices.

csi-edge(config)# access-list 110 permit udp any host [IPSec headend device] eq 500

csi-edge(config)# access-list 110 permit udp any host [IPSec headend device] eq 4500

csi-edge(config)# access-list 110 permit 50 any host [IPSec headend device]

csi-edge(config)# access-list 110 permit 51 any host [IPSec headend device]

csi-edge(config)# access-list 110 deny ip any host [IPSec headend device]

csi-edge(config)#!— These are Internet-sourced connections to publicly accessible servers.

csi-edge(config)# access-list 110 permit tcp any host [public web server] eq 80

csi-edge(config)# access-list 110 permit tcp any host [public web server] eq 443

csi-edge(config)# access-list 110 permit tcp any host [public FTP server] eq 21

csi-edge(config)#!— Data connections to the FTP server are allowed by the permit established ACE.

csi-edge(config)#!— Allow PASV data connections to the FTP server.

csi-edge(config)# access-list 110 permit tcp any gt 1023 host public FTP server gt 1023

csi-edge(config)# access-list 110 permit tcp any host public SMTP server eq 25

csi-edge(config)#!— Explicitly deny all other traffic.

csi-edge(config)# access-list 110 deny ip any any

Wow – what an access list!  

The last step would be to apply this access list to the transit interface of the network.  Let’s say that the interface is a gig 1/0 interface:

csi-edge(config)# interface gig 1/0

csi-edge(config-if)# ip access-group 110 in

 

If you want to know when any of these events happen, you can simply add the “log” keyword to the deny statements, and any events that trigger that part of the access list will be written to the system log.

We hope this more detailed How To helps with explaining iACL’s and tACLS’s, and that you can use our examples in your network.  To see some more examples, you can read the Cisco White Paper here. and here.

Leave a Comment

Contact Us Here


Please verify.
Validation complete :)
Validation failed :(
 
Your contact request has been received. We usually respond within an hour, but please be patient. We will get back to you very soon.
Scroll to Top