Consider this topology below and let's see how easily we can get it configured.
First of all let me give you a brief overview on Context Based Access Control (CBAC). CBAC basically takes our beloved access-lists one step further. It introduces the inspect element which can inspect the traffic leaving the "trusted inside" of the network and keeps track of the sessions so the return traffic can be allowed inside by poking holes in the access-lists. And when I say sessions I am including both TCP and UDP. I know some of you are wondering how can that be? UDP is connection-less and does not have the concept of "sessions", however the Cisco router uses UDP idle timeout value to "guesstimate" whether the return traffic is part of a UDP conversation.
So the first thing to do is pick an interface (internal or external) and figure out the direction of the traffic. In my blogtorial I have picked the external interface which by definition is facing the outside and I want to inspect the traffic leaving that interface so return traffic can then be allowed back in.
Remember to keep in mind that if you pick the internal interface then:
- The inbound access-list must permit the traffic you want to inspect. If the inbound access denied the traffic to be inspected then the packets will be dropped before CBAC can inspect it.
- The outbound access-list must deny the traffic you want to inspect. Because the outbound access-list will be "poked" by CBAC to allow the return traffic.
Remember to keep in mind that if you pick the external interface then:
- The inbound access-list must deny the traffic you want to inspect. Because the inbound access-list will be "poked" by CBAC to allow the return traffic.
- The outbound access-lilst must permit the traffic to be inspected. If the outbound access-list denied the traffic to be inspected then the packets will be dropped before CBAC can inspect it.
Alright so with this brief overview in mind let's get started. As usual let's get all of our interfaces configured.
Easiest router (R2) configuration.
- Configure the interface IP.
- Create a default route to R3.
- Configure Internal interface which is Fast1/0.
- Configure External interface which is Fast1/1.
- Configure the interface facing R3.
- Create a default route to R3 for the 192.168.1.0/24 subnet.
We have now created an access-list which denies everything and it is applied in the inbound direction of R3 Fast1/1. Naturally if you try ping the R4 Fast1/0 from R2 or R3 the return traffic which in this case would be echo reply should be denied at R3 Fast 1/1. Let's verify.
As per the access-list you can see that the return traffic from 1.1.1.2 (R4) is denied going to 1.1.1.1 (R3). How can we only allow return traffic (icmp echo reply) through the access-list? Well this is where CBAC and inspect can do the trick.
This will examine (inspect) traffic leaving (out of) this interface (R3 Fast 1/1) and only let return traffic.
Let's see what happens when we ping 1.1.1.2 which failed earlier.
Notice that the pings are now working. Also notice the 'debug ip inspect object-creation'. Shows who intiated the connection among various other things. This session will stay open the default 10 second timeout. 'ip inspect name <name> ?' will you give numerous options such as snmp, syslog, http, irc, ftp and so on which can be inspected by CBAC.
Conclusion:
The combination of lightweight and numerous options/flexibility makes Context Based Access Control (CBAC) an ideal candidate for smaller deployments.
Many more articles to come so stay tuned.
Please subscribe/comment/+1 if you like my posts as it keeps me motivated to write more and spread the knowledge.
Thank you.
As per the access-list you can see that the return traffic from 1.1.1.2 (R4) is denied going to 1.1.1.1 (R3). How can we only allow return traffic (icmp echo reply) through the access-list? Well this is where CBAC and inspect can do the trick.
- Create the inspect rule which states that ICMP should be inspected and the inbound access-list should be "poked" if it's return ICMP traffic. Also states that this rule should inspect locally (router) generated packets so from R3 to R4.
- Show command to verify that the rule exists and it's settings.
- Apply it to R3 Fast1/1 interface.
This will examine (inspect) traffic leaving (out of) this interface (R3 Fast 1/1) and only let return traffic.
Let's see what happens when we ping 1.1.1.2 which failed earlier.
Conclusion:
The combination of lightweight and numerous options/flexibility makes Context Based Access Control (CBAC) an ideal candidate for smaller deployments.
Many more articles to come so stay tuned.
Please subscribe/comment/+1 if you like my posts as it keeps me motivated to write more and spread the knowledge.
Thank you.
No comments:
Post a Comment