Using Context-Based Access-Lists
Problem
You want to use your router as a Firewall to perform advanced filtering functionality.
Solution
The following example shows how to configure the router to perform stateful inspection of TCP or UDP packets:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#access-list 166 deny ip any any
Router1(config)#access-list 167 permit tcp any any eq telnet
Router1(config)#ip inspect name Telnet tcp
Router1(config)#interface Serial0/1
Router1(config-if)#ip access-group 166 in
Router1(config-if)#ip access-group 167 out
Router1(config-if)#ip inspect Telnet out
Router1(config-if)#exit
Router1(config)#end
Router1#
|
Discussion
Context-Based Access Control (CBAC) has been available as part of the IOS Firewall feature set since 11.2(P). CBAC does a stateful inspection of TCP and UDP packets to manage sessions as they pass through the router. It uses this state information to dynamically modify existing extended ACLs to control the active sessions. CBAC can also monitor and manage sessions based on application type and can identify, terminate, or log suspicious activity.
CBAC provides much greater security than a regular filtering ACL because it uses features similar to those found in dedicated Firewalls. In fact, the IOS Firewall feature set, including CBAC, makes an excellent firewall for small or cost-conscious organizations. Although it is not suitable for every application, CBAC's stateful inspection does provide better security than simple packet filtering firewalls.
CBAC works by inspecting active sessions and dynamically creating temporary ACL entries to allow the return traffic through. In our example, we configured the router with an inbound ACL that denies all IP packets, which would normally prevent the router from accepting any inbound IP traffic on this interface. However, when somebody on the inside of the network initiates an outbound connection through this port, CBAC creates a temporary ACL that allows the device on the outside to respond.
We can demonstrate this by initiating an outbound Telnet session through this interface and then viewing the inbound ACL:
Router1#show ip access-list 166
Extended IP access list 166
permit tcp host 10.2.2.2 eq telnet host 172.25.1.1 eq 1379 (22 matches)
deny ip any any (456 matches)
Router1#
Notice that the original ACL now contains a new entry to allow the return data of the Telnet session that we originated. Notice also that this temporary ACL entry includes the exact source and destination IP addresses and port numbers. This ensures that our Telnet session works normally, but it prevents all other possible IP addresses from connecting to the client device's source port. In fact, CBAC even prevents the external server from connecting to internal device's source port by using a new session because it maintains specific session information such as source and destination port numbers and TCP sequence numbers. This temporary ACL entry will terminate when the session ends, leaving only the static deny all entry that we originally configured in ACL number 166.
This configuration will block all inbound connection attempts. A common and very simple technique used by hackers as a prelude to attacking an Internet site is to perform a port scan. This essentially means systematically trying to start an inbound session on each port in a large range. If there is any response at all, the attacker knows that there is something listening, which presents a useful starting point for breaking in. However, because this CBAC configuration blocks all unsolicited connection attempts, regardless of the port, this scanning technique reveals nothing useful. This is usually enough to deter all but the most sophisticated hackers.
In fact, the only effective way to get a packet past the ACL configuration shown in this recipe is to send a packet with the right source and destination addresses and port numbers, as well as the right TCP sequence number. This technique is called a hijack attack, and it is almost impossible to prevent. Attackers using this technique generally are able to get a single packet past the firewall. In some cases, an attacker can use this single packet to cause mischief. Fortunately for us, hijack attacks are extremely difficult to execute. But it is important to be aware of the limitations of any security measure.
The show ip inspect sessions command lets you view information about all of the sessions that CBAC is currently watching:
Router1#show ip inspect sessions
Established Sessions
Session 821061C0 (172.25.1.1:1379)=>(10.2.2.2:23) tcp SIS_OPEN
Router1#
The example shows how to inspect generic TCP sessions. However, one of CBAC's greatest strengths is its ability to identify application specific behavior and adjust its ACL entries accordingly. Table 27-2 displays the various applications that CBAC is able to monitor.
| Keyword | Application protocol |
|---|---|
| cuseeme | CU-SeeMe Protocol |
| fragment | IP Fragmented packets |
| ftp | File Transfer Protocol |
| h323 | H.323 Protocol |
| http | HTTP (Java blocking) |
| netshow | Microsoft's NetShow |
| rcmd | Unix R-commands |
| realaudio | RealAudio |
| rpc | Sun RPC |
| rtsp | Microsoft's RPC |
| smtp | Simple Mail Transfer Protocol |
| sqlnet | SQL*Net |
| streamworks | StreamWorks |
| tcp | Generic TCP |
| tftp | Trivial File Transfer Protocol |
| udp | Generic UDP |
| vdolive | VDOLive |
Just because an application is not listed in this table doesn't mean that CBAC will not manage its sessions. In fact, the Telnet example in this recipe used generic TCP inspection. Unless your application does something unusual in its session setup and negotiation sequences, the generic inspection should work well. For example, standard HTTP also uses standard TCP session rules. The only reason why there is a special HTTP option for CBAC is to handle Java.
Let's take a look at an application that doesn't use standard TCP ports to build connections, passive FTP. As we indicated in Recipe 19.12, passive FTP is difficult to secure because the server can choose to use a large number of ports for its data session. The result is that both the source and destination ports are determined dynamically when the session is established. Recipe 19.12 showed a way to filter this traffic statically, but with the unfortunate side effect of leaving open some 64,000 other ports. With CBAC this is not necessary since the router can watch the FTP control session and determine the server's data port. This allows it to open only the required port:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#access-list 155 permit tcp any any eq ftp
Router1(config)#access-list 155 deny ip any any
Router1(config)#ip inspect name TEST ftp
Router1(config)#interface Serial0/0
Router1(config-subif)#ip access-group 155 in
Router1(config-subif)#ip inspect TEST in
Router1(config-subif)#exit
Router1(config)#end
Router1#
In this example, the ftp keyword invokes FTP inspection instead of the generic TCP inspection that we showed in the previous example. Also, notice that the first line of our ACL includes the ftp keyword, which permits only the FTP control session. This is necessary so that CBAC will permit the control part of the application to pass.
Now we can connect to the FTP server using a web browser. Looking at the ACL shows the new entries that CBAC has created for us:
Router1#show ip access-list 155
Extended IP access list 155
permit tcp host 172.20.1.2 eq 11252 host 172.25.1.3 eq 49155 (1415 matches)
permit tcp any any eq ftp (151 matches)
deny ip any any (3829 matches)
Router1#
As you can see, CBAC monitored the FTP control session and opened the specific FTP data ports for the passive FTP data connection. You can tell that this is a passive FTP session from the high port numbers.
CBAC inspection can also handle normal FTP. CBAC FTP inspection blocks third-party connections, allowing only "safe" FTP data ports (102465535). CBAC monitors the FTP control session, and will not open a data port if the client authentication fails.
Although we haven't shown an example for UDP, CBAC can also handle UDP-based applications in a similar fashion to TCP. When you send a UDP packet out through the interface, CBAC knows to expect an appropriate response. UDP is difficult to handle because it is not session oriented. But CBAC handles UDP traffic well, offering application support for TFTP in particular that is rarely seen in commercial Firewalls.
The TFTP server uses the well-known UDP port 69. The client sends an initial packet to the server on this well-known port. But then the server opens a new arbitrary port greater than 1023 for the duration of the TFTP session. A standard packet filter would have to permit all UDP ports above 1023 to let TFTP work. CBAC gets around this problem by monitoring the TFTP session to determine which UDP port to open.
CBAC has a several settings you can adjust to improve the overall performance and security of the router. We include some of the most important options in Table 27-3.
| Setting | Description | Default | Recommended |
|---|---|---|---|
| TCP idle-time | Length of time CBAC will continue to permit an idle TCP session. | 1 hour | 30 minutes |
| UDP idle-time | Length of time CBAC will continue to permit an idle UDP "session." | 30 seconds | 20 seconds |
| Finwait-time | Length of time CBAC will continue to permit a TCP session after the exchange of FIN packets. | 5 seconds | 1 second |
| Synwait-time | Length of time that CBAC will wait after receiving a SYN packet without completing the session establishment. | 30 seconds | 15 seconds |
The following set of commands configures the timer settings of CBAC shown in Table 27-3:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip inspect tcp idle-time 1800
Router1(config)#ip inspect udp idle-time 20
Router1(config)#ip inspect tcp finwait-time 1
Router1(config)#ip inspect tcp synwait-time 15
Router1(config)#end
Router1#
You can view the CBAC configuration settings with the show ip inspect config command:
Router1#show ip inspect config
Session audit trail is disabled
Session alert is enabled
one-minute (sampling period) thresholds are [400:500] connections
max-incomplete sessions thresholds are [400:500]
max-incomplete tcp connections per host is 50. Block-time 0 minute.
tcp synwait-time is 15 sec -- tcp finwait-time is 1 sec
tcp idle-time is 1800 sec -- udp idle-time is 20 sec
dns-timeout is 5 sec
Inspection Rule Configuration
Inspection name Telnet
tcp alert is on audit-trail is off timeout 1800
Router1#
CBAC also provides a method of logging managed sessions, by enabling audit trails. You can enable an audit trail on a particular CBAC inspection command with the audit-trail keyword:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip inspect name Telnet tcp audit-trail on
Router1(config)#end
Router1#
When you enable CBAC audit trails, the router will create a log entry after each session terminates. This log entry includes detailed information about the connection. Here a sample audit trail log that the router recorded after we terminated a Telnet session:
Feb 8 14:37:24: %FW-6-SESS_AUDIT_TRAIL: tcp session initiator (172.25.1.1:1402) sent 59 bytes -- responder (10.2.2.2:23) sent 1299
For more information on logging, please see Chapter 18.