Cisco: How to use reflexive access-list and why they are useful

Reflexive access-list are one of the method that help us achive firewall functionality with a router hardware. The other methods that serve to the same purpose are Context-Based Access Control (CBAC) and TCP Intercept. For an introduction to CBAC with example please check my older post Cisco: Use CBAC to achieve firewall functionality on router device . For TCP Intercept check my blog in the next weeks.

Today, I will present Reflexive access-list and how can take advantage of their specific behavior. Reflexive access list commands are used to configure IP session filtering. IP session filtering provides the ability to filter IP packets based on upper-layer protocol “session” information. They are generally used to allow outbound traffic and to limit inbound traffic in response to sessions that originate inside the router. E.g. you want to allow a TCP connection from outside only is the initall packet was send from the inside. Take FTP active mode session on data port TCP 20. If you are doing FTP from inside the LAN port 20 will be allowed outbound and also inbound. But if somebody from outside try to reach one device on your LAN on port 20, the session will be dropped due to Access-list implemenation.

Reflexive ACLs can be defined only with extended named IP ACLs. They cannot be defined with numbered or standard named IP ACLs, or with other protocol ACLs. Reflexive ACLs can be used in conjunction with other standard and static extended ACLs. As a syntax Reflexive access-list are presented exactly like any normal ACL, with the implementation of two parameters “reflect” and “evaluate”.

Let have a look to this example topology. R2 will be the router where the Reflexive ACL has to be implemented.  The implementation is quite simple. You configure an outbound access-list which permit tcp sessions from any subnet to any subnet. The difference from this outbound ACL and a normal one, will be the “reflect” parameter at the end on the permit line. The “reflect” parameter will have the name OUT (it can be any name you want).

After the outbound list is completed configured, then we will configure an inbound access-list with a “permit tcp any any” statement followed by the parameter “evaluate OUT”. Below it’s a simple example how to configure this Reflexive ACL on the topology presented above, to permit UDP and TCP inside only if the session was initiated from inside:

ip access-list extended OUTBOUND
permit tcp any any reflect TO_REFLECT
permit udp any any reflect TO_REFLECT

ip access-list extended INBOUND
evaluate TO_REFLECT

interface Serial1/0
ip access-group OUTBOUND out
ip access-group INBOUND in

So, the INBOUND ACL will evaluate OUTBOUND ACL to permit or deny TCP packet from outside. Remember that by default, packets generated by the router itself will not be
reflected. This is why if you have a routing protocol running towards outside,  on your router you have to permit static those packets.  Let’t take the example of the BGP routing protocol. Assume that you have a BGP peering between R2 and R3. On R2 you will have to permit static the BGP packets from outside, like in the example below:

ip access-list extended OUTBOUND
permit tcp any any reflect TO_REFLECT
permit udp any any reflect TO_REFLECT

ip access-list extended INBOUND
permit tcp any any eq bgp
permit tcp any eq bgp any
evaluate TO_REFLECT

interface Serial1/0
ip access-group OUTBOUND out
ip access-group INBOUND in

In this way the BGP packets local generated on the router, will be allowed IN and OUT on the WAN interface. You will proceed in the same way for other packets that are generated on  the router and you want to allow them to pass through WAN interface.

For a live example please see the video presentation below. If you did not had a look to the example topology, now it would be a good time to do it. Already I have preconfigured BGP AS 300 on router R3 and BGP AS100 on R2 and R1, so the conectivity from R1 to R3 is not a problem. Also R1 and R3 have a  Loopback interface which is advertised into BGP. After implementing the Reflexive ACL on R2 I will be allow to telnet from R1 to R3, but not viceversa. Also the BGP packets between R2 and R3 will be static permited in ACL.

cisco-reflexive-acl

I hope that I could helped you to understand the importance on the Reflexive ACL. Sometime simple ACL would do the job and then I would suggest not to complicate things. But if you have something tricky to solve regarding access in your LAN, or you prepare for some exam like CCIE, then Reflexive ACL are quite useful and important.

The stateful LAN: Layer 7 visibility and control

osi-layer-modelEnterprises have seen an explosion of new applications, devices and classes of users on their LANs, which makes it harder than ever for IT to ensure network performance, secure corporate assets and comply with regulations. In response, next-generation intelligent LAN switches are emerging that are designed to provide stateful, deep-packet inspection up through Layer 7, providing granular user- and application-level controls.

Other network devices that have already “moved up” the protocol stack include WAN-acceleration platforms and load-balancing switches. Now, by maintaining state information, intelligent switches can forward based on flows instead of packets. Advanced deep-packet inspection provides user identity and L7 application detail in classifying flows, enabling IT to apply access and QoS policies far beyond the virtual LAN/ACL controls that traditional L3/L4 switches support.

Read the full article on NetworkWorld.com

Cisco: 6 best practice security tips for BGP

As we all know, in today’s digital communication world, there is a very big possibility that your network is or was target for a malicious activity. BGP is one of the most targeted routing protocols when we are talking about network attacks.Why? This is quite simple. BGP is your connection to the exterior world (peer networks, Internet and everything which is outside your LAN/MAN), so it is somehow normal to be the main target of the conducted attacks. If in case of the WWW, DNS, E-mail services we can say that maybe an attack was not intentionally made (e.g. a user got infected with some trojan/malware/botnet tool that is attacking random destinations), in the case of BGP, you can be 90% sure that this is an intentionally conducted attack. The main scope of a BGP attack is to flood the network with false information (e.g. false network prefixes) in this way trying to direct interesting traffic to special destinations where this can be sniffed and decoded.

I will present here 6 tips that I’m using the most to protect BGP against malicious information. This is really easy to implement, if you have any basic idea about how to configure BGP protocol, but it can save you from hours of troubleshooting and investigation.

1. Limit the maximum number of prefixes that you learn from BGP peer, to avoid overload of your machine.
2. Deny updates that include a private AS number in the AS Path (64512 – 65535).
3. Use ACLs on your external interface to permit input/output BGP packets only from your defined source and destination
4. Limit TTL in BGP packets to limit the communication only with next-hop peers.
5. Use a password  to authenticate peer neighbors.
6. Limit the maximum length of  the AS path

Also here I would like to mention, not necessary as a security tip, but more like a best practice,  enable when it is possible logging. This can help you to observe some strange behavior that occur on your machines where you are not arround them.

There is no topology present for this tutorial, but we will assume that we have a point-to-point serial connection between 2 routers, R2 (10.0.23.2) and R3 (10.0.23.3). Please click the image below to view the tutorial:

BGP Security tips

If for some reasons the tutorial above is not available for you, please check this text file which present in text mode everything  needed to implement BGP security tips presented above.