Figure 5-2. An Example of CBAC Implementation for Telnet
How can CBAC solve this problem? To turn on CBAC, create and apply a simple CBAC rule: inspect only TCP traffic for this example. This rule is turned on for the Ethernet 0 interface towards the direction of SYN packet (inspection must always be applied in the direction of the traffic initiation) as shown in Figure 5-2.
As before, if the Telnet connection is initiated from inside the host to outside, once the SYN packet goes through the router after ACL checking (in this example there is no ACL configured in the traffic initiation direction), the CBAC inspects it. The CBAC inspects it because the initiation packet is moving in the same direction in which the inspection rule is applied (on the Ethernet 0 interface as inbound). CBAC performs the following functions:
-
It extracts transport layer information such as source and destination address and port from the packet.
-
It determines the input and output interfaces.
-
It adds a dynamic entry in the ACLs (after swapping the addresses) for return traffic to allow traffic back for this connection.
This, in effect, creates a tiny hole in the ACL, which is specific to this connection only. As a result, the reply SYN-ACK packet makes it through this hole and reaches the inside end host. The inside end host then replies with the final ACK, and the connection is established. As a result, the first requirement is also met (remember, the first requirement is to allow connections to initiate from the protected network). Once the connection is established, CBAC examines traffic in both directions for this particular connection. CBAC recognizes when the end hosts close connection using FIN (Finish) Exchange or RST (Reset), and the CBAC removes the dynamic ACL entries accordingly. So CBAC not only resolves the issue of creating ACL statically, it also opens up a very specific hole in the ACL that is required, and closes it when finished.
So far we have seen how CBAC helps with single-channel protocol by creating a dynamic ACL. With static ACL, to accomplish this result, leave the outside interface ACL wide open and thereby permit everything. Permitting everything, of course, defeats the purpose of configuring the ACL on the router in the first place. To address this security issue, you may be able to configure the established keyword on the ACL applied on the serial 0 interface. The established keyword filters TCP packets based on whether the ACK or RST bits are set. The setting of ACK or RST bits indicates that the packet is not the first in the session, and therefore, that the packet belongs to an established session. Although this effectively blocks the SYN packet (that is, packet initiation from outside to inside is blocked) for TCP traffic, it works only with TCP and filters based on only the TCP flag, and is therefore vulnerable to a spoof attack.
Reflexive ACL is a better solution than using an established keyword in static ACL, as it works with UDP as well, and creates the dynamic ACL based on source and destination IP addresses and ports. Therefore the traffic is filtered not only by the flag, as in static ACL with the established option, but by source and destination addresses and ports in addition to flags. The biggest drawback, however, with Reflexive ACL is that it does not work with a multi-channel protocol, because the additional channels (other than the first control channel) are built up using the port negotiation that occurs when using the control channel, and Reflexive ACL is unable to learn about this negotiation. Therefore, Reflexive ACL is unable to create dynamic ACE in the ACL for the data channel in the case of a multi-channel protocol. This failure is one of the serious shortcomings of Reflexive ACL. The following section examines how CBAC is better able to handle this multi-channel issue.
To understand how CBAC addresses the shortcoming of Reflexive ACL with multi-channel protocol, examine how CBAC works with multi-channel protocols such as File Transfer Protocol (FTP), H323, Session Initiation Protocol (SIP), and so on. As the name implies, multi-channel typically creates more than one connection for transferring data. Typically, the first connection acts as a control connection. The address and port information for the secondary connections (also known as data connection) are dynamically negotiated by end hosts over this control connection. To illustrate this, study an example of a two-channel protocol, Active FTP with CBAC as shown in Figure 5-3.