EVOLUTION OF FIREWALL PART 2 REFLEXIVE ACL

Poster of ACL

 REFLEXIVE ACL

The idea of reflexive ACL is to take a packet flow, extract session information
(src/dst IP and ports) and create dynamic entry in access-list that is applied in
opposite direction, to permit the “mirrored” flow. You need a named access-list to
implement traffic reflection.

A typical approach to network perimeter security is to allow outbound traffic not explicitly denied, and to deny inbound traffic unless it is explicitly allowed. Although simple in concept, this approach requires significant considerations regarding the return path of internally initiated sessions. Consider the following scenario:

Clients resides on the secure 192.168.0.0/24 subnet, which is connected to the Internet by R1. We can place both inbound and outbound access lists on R1's F0/1 interface to restrict communication between our internal network and the Internet.

For the sake of an example, let's assume we want to allow web traffic from the client to web servers on the Internet. We can leave outbound traffic (from client to server) unrestricted by simply not including an ACL, but how would we restrict return traffic from the Internet? Obviously we can't simply deny all traffic, or nothing would work. Nor can we allow all traffic, as it would leave the secure subnet exposed.

We also can't simply allow all TCP traffic with a source port of 80, as an attacker could easily send malicious traffic using 80 as his source port. And we can't restrict inbound traffic to certain source IP addresses, as we'd have to create a new entry for every server we want to access on the Internet. We could allow inbound traffic to the client's source port, but this is typically a randomly-chosen high port number which can't be practically matched with static configuration. But what if we could record and match each source address/port pair automatically?

Enter reflexive access lists. To employ reflexive ACLs, three access lists are actually needed: one for inbound traffic, one for outbound traffic, and one (the reflexive ACL) to keep track of dynamic entries. Outbound traffic matched in the outbound ACL is reflected to the reflexive ACL; that is, the source and destination addresses and ports are swapped and the entry is recorded in the reflexive ACL with an expiration timer. Traffic in the other direction is matched against the inbound ACL, which in turn evaluates the entries in the reflexive ACL.

--Source : Packetlife:

Problems with Reflexive ACLs

This basic “session” idea works well with “simple” protocols, like HTTP and Telnet. However, complex protocols like FTP may open additional data channels, which could not be intercepted properly by simply reflecting a traffic flow.Additionally, reflexive ACLs have poor scalability, since router opens the pinholes temporarily and needs to age them out, constantly keeping the track of every new “session”. Keep in mind that router-originated traffic is not subject to “reflection”, unless you use local policy routing to divert it into loopback interface, therefore making it “ingress”.

Lab work:

R3:
!
! Outbound access-list, mirror all outbound sessions
ip access-list extended OUTBOUND
permit tcp any any reflect MIRROR
permit udp any any reflect MIRROR
permit icmp any any reflect MIRROR
!
! Ingress ACL, permit only the “returning” packets
ip access-list extended INBOUND
evaluate MIRROR
!
! Apply ACLs
!
interface FastEthernet 0/1
ip access-group OUTBOUND out

ip access-group INBOUND in

output at R3 i.e Firewall router:

REF#sh ip access
Extended IP access list INBOUND
    10 evaluate MIRROR
Reflexive IP access list MIRROR
     permit tcp host 10.1.23.1 eq telnet host 10.1.13.1 eq 34791 (14 matches) (time left 299)
     permit icmp host 10.1.23.1 host 10.1.13.1  (20 matches) (time left 256)
Extended IP access list OUTBOUND
    10 permit tcp any any reflect MIRROR (10 matches)
    20 permit udp any any reflect MIRROR

    30 permit icmp any any reflect MIRROR (11 matches)

==================Thanx===