You must apply your CBAC configurations to an interface for traffic to be inspected. Along with applying your named inspection rule to an interface, you must specify the traffic direction that will be inspected. Traffic can be inspected when entering an interface or when exiting an interface. Actually, you can apply CBAC in two directions on the same interface; however, it is rarely done. The syntax to apply CBAC inspection is Router(config-if)# ip inspect inspection-name [in out] An example that applies CBAC to inspect traffic leaving an interface is shown in Figure 4.10. Figure 4.10. Applying an outbound inspection rule.
You can also have other services applied to the same interface as CBAC. You could and should have ACLs on the same interface. You can also apply QoS or policy-based routing on the same interface as CBAC. Remember that when you use CBAC, your router interfaces are considered to have different trust levels. For instance, if your internal LAN resides off the Gigabit Ethernet 0/0 interface, it would be the most trusted interface. If the link to your ISP were using the Fast Ethernet 1/0 interface, that interface would be considered an untrusted interface. The general rules for applying CBAC are the following:
A few examples will reinforce these guidelines. Inbound TrafficSuppose you have a three-interface router. Ethernet 0 is the inside, Ethernet 1 is the outside, and Ethernet 2 is the DMZ. Your organization has a WWW server in the DMZ used for e-commerce with an IP address of 30.100.100.253. Therefore, you must allow connections from the outside to the DMZ WWW server for HTTP (port 80) and Secure HTTP (HTTPS) (port 443). Further, the DMZ WWW server might respond to requests from customers but is not allowed to initiate connections. The first step is to define ACLs to permit the desired traffic and to deny WWW-server “initiated connections. Here is an example that permits outside initiated connections to the WWW server: Router(config)# access-list 101 permit tcp any host 30.100.100.253 eq 80 Router(config)# access-list 101 permit tcp any host 30.100.100.253 eq 443 Router(config)# access-list 101 deny ip any any log Router(config)# interface ethernet 1 Router(config-if)# ip access-group 101 in The last ACE is used so that you can view the number of hits that were denied by ACL 101. You need to create another ACL that permits HTTP and HTTPS from allowed interfaces through the DMZ interface. The ACL would be similar to the following: Router(config)# access-list 102 permit tcp any host 30.100.100.253 eq 80 Router(config)# access-list 102 permit tcp any host 30.100.100.253 eq 443 Router(config)# access-list 102 deny ip any any log Router(config)# interface ethernet 2 Router(config-if)# ip access-group 102 out Now, the only traffic that is getting through the DMZ interface is HTTP and HTTPS. However, you still need to create an ACL that does not allow the WWW server to initiate connections on its own. Here is an example of the ACL that you could use to comply with your organization's security policy: Router(config)# access-list 103 deny ip host 30.100.100.253 any log Router(config)# interface ethernet 2 Router(config-if)# ip access-group 103 in Now this point is important: You need to understand the flow of traffic that results from applying these ACLs to the outside and DMZ interfaces. Let's start when a user named Audrey, who tries to connect to the WWW server. The port 80 traffic hits the outside interface of the router on Ethernet 1. Given ACL 101, the traffic is permitted. The traffic then flows through the router and needs to use Ethernet 2 as the exit interface. The router examines ACL 102, and because the traffic is port 80 traffic, the router allows the flow of data to the WWW server. Well, the Internet would not be of much use if users were only able to send data; they need to receive data also. When the WWW server goes to respond to Audrey's request, you start to get into problems. Remember, ACLs are static, not dynamic. Further, your organization's security policy stated that the WWW server cannot initiate connections on its own. However, the WWW server needs to respond to Audrey's request, and it does so by sending traffic that hits the router's Ethernet 2 interface. ACL 103 says to deny anything that is inbound to the Ethernet 2 interface; therefore, Audrey's request is never fulfilled because the router drops all traffic inbound to Ethernet 2. The solution to this bad situation is easy. Use CBAC to inspect traffic, which results in the dynamic creation of ACEs that allow legitimate traffic to flow back to the user-initiated connected. Okay, so we use CBAC, but what interface do you apply an inspection rule to? The answer is up to you. You can inspect traffic that is inbound to Ethernet 1's outside interface, or you can inspect traffic that leaves (outbound) the Ethernet 2 interface. Either will work. Here is an example that allows permitted traffic which is initiated on the outside to flow to the DMZ and return. The ACLs are not modified or changed in any way. The only configuration that you need to do is implement CBAC: Router(config)# ip inspect name WWW_Server tcp Router(config)# interface ethernet 2 Router(config-if)# ip inspect WWW_Server out The ACLs allow port 80 and port 443 traffic, and when the allowed traffic leaves Ethernet 2, CBAC creates dynamic ACEs that allow the WWW server to respond to Audrey even though ACL 103 denies all traffic. That is the beauty of CBAC. The return traffic from the WWW server is allowed through the IOS Firewall because CBAC created the dynamic ACL.
Outbound TrafficGreat, you've solved outside-to-DMZ-initiated and outside-to-inside-initiated security issue. Now you need to solve the inside-initiated security issues. Your organization states that employees (internal users) are only allowed to surf the World Wide Web, buy products from the DMZ WWW server, and use SMTP. Once again, you need to create an ACL that permits this activity and denies all other activity. The internal network uses the 10.1.0.0/16 IP address space. Here is an example of an ACL that implements the required security policy that is applicable to internal users: Router(config)# access-list 199 permit tcp 10.1.0.0. 0.0.255.255 host 30.100.100.253 eq 443 Router(config)# access-list 199 permit tcp 10.1.0.0. 0.0.255.255 any eq 80 Router(config)# access-list 199 permit tcp 10.1.0.0. 0.0.255.255 any eq 25 Router(config)# access-list 199 deny ip any any log Router(config)# interface ethernet 0 Router(config-if)# ip access-group 199 in This ACL permits only WWW traffic on port 80 and 443 and SMTP traffic; everything else is denied and logged. This list is really all you need if users only want to surf the DMZ WWW server. However, your organization allows SMTP in addition to HTTP to the Internet. But ACL 101 is blocking any traffic that is destined for the internal network because the ACL only allows traffic to the DMZ WWW server. Once again, CBAC saves the day through the dynamic creation of ACEs. You need to create an inspection rule that allows WWW traffic and SMTP traffic. Because the IOS Firewall is not as robust as a PIX Firewall, you can only perform generic TCP inspection if you allow HTTP. However, you can perform application-specific SMTP inspection. Here is an example of the inspection rules you need: Router(config)# ip inspect name INTERNAL_USERS tcp Router(config)# ip inspect name INTERNAL_USERS smtp Router(config)# interface ethernet 0 Router(config-if)# ip inspect INTERNAL_USERS in When you apply this rule to the internal interface, and internal users create port 80, port 443, or port 25 connections, CBAC creates dynamic ACEs to allow the return traffic back into the router.
|