CBAC

CBAC provides four main functions:

Filtering traffic
Inspecting traffic
Detecting intrusions
Generating alerts and audits
Filtering traffic
One of the main functions of CBAC is to filter traffic intelligently, specifically for TCP,
UDP, and, recently, ICMP connections. As with RACLs, one of its functions is to allow
returning traffic into your network; however, it can be used to filter traffic that originates on
either side of routerinternal or external.
Unlike extended ACLs, which can filter only on Layers 3 and 4, and RACLs, which can
filter on Layer 5 (session layer) information, CBAC supports application inspection, it can
examine the contents of certain kinds of packets when making its filtering decision.It also can
examine a connection's messages to determine the state of a connection. For example, FTP uses
two connections, a control and a data connection. CBAC can examine the control connection,
determine that a data connection is being created, and add this connection to its state table.
Inspecting Traffic
CBAC can inspect application layer information and use this to maintain its stateful
firewall function, even for applications that open multiple connections or embed NATed
addressing or port information in applications. This inspection process not only allows returning
traffic back into our network, but it also can be used to prevent TCP SYN flood attacks
CBAC can examine the rate at which connections are being made to a service and can
shut down these connections if a specified threshold is reached. It also can examine TCP
connections to make sure that sequence numbers fall within a certain range, dropping any
suspicious packets. Besides examining TCP connections, it can examine traffic for DoS fragment
attacks.
Detecting Intrusions
CBAC can inspect traffic to implement a stateful firewall, but it also can use this
feature to detect certain kinds of DoS attacks. All of these kinds of attacks can cause CBAC to
generate logging information about the attack, as well as optionally resetting TCP connections or
dropping malicious packets.
Generating Alerts and Audits
CBAC can generate real-time alerts of problems and detected attacks, as well as provide a
detailed audit trail of connection requests. For example, we can log all network connection requests,
including the IP addresses of the source and destination, the ports used in the connection, the
number of bytes sent, and at what time the connection started and ended.
Operation of CBAC
CBAC was introduced in Cisco IOS 12.0(5)T. To keep track of connections that it is
monitoring, it builds a state table that contains information about each connection. This table
is similar to the state table that the Cisco PIX uses. CBAC monitors TCP, UDP, and ICMP
connections and maintains information in the state table for them. CBAC then uses the state
table to build dynamic ACL entries to allow returning traffic back through the perimeter
router/firewall. This is somewhat similar to RACLs; however, CBAC can inspect application layer
information, whereas RACLs cannot. CBAC uses the state table and dynamic ACL entries to
detect and prevent certain kinds of DoS attacks, especially those that involve TCP connection
flooding.

Basic Operation

These steps occur in this example:

1. A user initiates an outbound connection, such as a Telnet. If an inbound ACL is applied, this
is processed first before any inspection by CBAC. Based on our inspection rules for CBAC,
the Cisco IOS might or might not be inspecting the connection. If it is not inspecting the
connection, the Cisco IOS allows the packet through; otherwise, the Cisco IOS proceeds to Step
2.
2. The Cisco IOS compares this connection to the entries in its state table: If this connection
does not exist, the entry is added; if it exists, the Cisco IOS resets the idle timer for the
connection.
3. If this is a new entry, the Cisco IOS adds a dynamic ACL entry on the external interface in
the inbound direction, to allow the returning traffic into the network. These dynamic ACL
entries are not saved to NVRAM. CBAC opens temporary openings in ACLs to allow
returning traffic.
These entries are created as inspected traffic leaves your network and are removed whenever
the connection terminates or the idle timeout period for the connection is reached. As with RACLs,
you can specify which protocol or protocols you want to inspect, as well as on which interface and
in which direction the inspection should occur.
A new feature was introduced in Cisco IOS 12.3(4)T, called Firewall ACL Bypass
(FAB). This feature was developed to speed up the Cisco IOS processing of traffic returning to
the network. With the FAB feature, the Cisco IOS does not create dynamic ACL entries to allow
returning traffic into the network. Instead, the Cisco IOS examines the state table to determine
which traffic should be allowed back into the network, which can be handled by fast switching
processes such as
Cisco Express Forwarding (CEF). If the Cisco IOS does not find a match in the state table, the
Cisco IOS uses the ACL applied inbound on the returning interface to enforce policies. By
using this process, the router does not have to create and manage dynamic ACL entries on the
returning interface: instead, the router only has to check the state table that it maintains.
Starting in Cisco IOS 12.3(4)T, the FAB feature automatically is used and cannot be
disabled.
One nice feature of CBAC is that it is flexible in its configuration, especially in what
direction we want to inspect traffic. In the most typical setup, we use CBAC on perimeter
router/firewall to allow returning traffic into the network. However, we can configure CBAC to
inspect traffic in two directionsin and out. We might need to do this if we want to protect two
parts of our network.

TCP Traffic(With CBAC)

With TCP, CBAC inspects the connection and examines the control bits in the TCP
segment header. If it sees a teardown process (FIN), the Cisco IOS waits 5 seconds for the
connection to be torn down gracefully, and then the dynamic ACL entry (before FAB) is
removed from the external ACL and the corresponding entry in the state table is removed. If a
TCP session is idle longer than 1 hour, the Cisco IOS removes the entry.
CBAC also monitors the setup of a connection. With CBAC, the Cisco IOS expects the
connection to be set up within 30 seconds (this is user-configurable) of seeing the first SYN
segment. If the connection is not established during this time period, the Cisco IOS removes the
entry from its state table and ACL.
CBAC also examines the sequence numbers in TCP connections to make sure that they fall
within an expected range. If they do not fall within an expected range, CBAC drops these packets
and assumes that a spoofing or DoS attack is occurring.
UDP Traffic
UDP is connectionless, making the inspection process more difficult. As with RACLs,
CBAC approximates the life of a UDP connection. It assumes that if no traffic is seen on a UDP
connection for more than 30 seconds (By Default), the connection must have completed;
therefore, the Cisco IOS removes the entry in the state table (and the dynamic ACL entry). This is
similar to RACLs, with the exception of the default timeout.
CBAC also inspects DNS queries and replies. With this feature, CBAC expects that when
an internal device generates a DNS query, the remote DNS server will respond with a DNS reply
within 5 seconds . If a reply is not seen in 5 seconds, the DNS connection entry is removed, to
prevent spoofing. Likewise, when the DNS reply is seen from the DNS server, the Cisco IOS
immediately removes the entry from its state table (and the dynamic ACL entry). These two
enhancements are used to prevent DNS spoofing and DoS attacks.
ICMP Traffic
Inspection of ICMP traffic was introduced in Cisco IOS 12.2(11)YU and was integrated into
12.2(15)T. Before this, CBAC could inspect only TCP and UDP traffic. With ICMP inspection,
CBAC can inspect common ICMP message types, including echo request, echo reply, destination
unreachable, time exceeded, timestamp request, and timestamp reply messages.
CBAC does not inspect other ICMP message types. When inspecting ICMP traffic, the Cisco
IOS expects replies to the supported ICMP message types within 10 seconds. If none is seen, the
ICMP connection is removed from the state table and the dynamic ACL entry is removed. However,
if a response is seen, only the supported message types are allowed (based on the request); other
message types are dropped.
DoS Detection and Prevention
CBAC can detect certain kinds of DoS flood attacks. When an attack occurs, the Cisco IOS
can take any of the following three actions:
# Block the offending packets
# Protect the internal resource from becoming overloaded with fake connections
# Generate an alert message
To detect DoS attacks, CBAC uses timeout and threshold values to inspect the setup of
TCP connections. When TCP connections are being established, they usually do not take more
than a second or two. Therefore, if a lot of TCP SYNs are seen from a single source, a threshold
can be set to restrict the number of these sessions.
In addition, if the connections are not completed within a specific time frame (30 seconds,
by default), the Cisco IOS removes this information from its state table and notifies both the source
and destination with a TCP RST message on the connection. This is used, especially for our internal

resource, to free up these half-open (commonly called embryonic) connections. We can define
three different thresholds to limit the number of half-open connections:
# Total number of half-open TCP or incomplete UDP sessions
# Total number of half-open TCP or incomplete sessions over a period of time
# Total number of half-open TCP sessions per host
When these thresholds are reached, the Cisco IOS can start dropping incomplete connections
that have not been deleted, notify the source and destination that the connections have been torn
down (TCP RST), generate an alert, and/or block TCP traffic from the offending device(s).
CBAC Performance
Given all of the inspection features that CBAC supports, this can put a large burden on
router, especially in a large network that has many simultaneous sessions that CBAC must
maintain. For each session that the router must keep track of, an additional 600 bytes of
memory are required to the entry in the state table. If router must support thousands of
connections, router's memory requirements will be high, as will the CPU cycles needed to
handles all of these entries. CBAC provides for three performance-improvement features,
however, to help with reducing the overhead and load on firewall router:
# Throughput improvement
# Connections per second improvement
# CPU utilization improvement
Throughput Improvement Feature
Throughput, from the CBAC perspective, is defined by the number of packets
transferred from one interface to another interface over a 1-second interval. CBAC uses a
hash table to perform the lookup process to determine what session a packet is associated with.
The issue of using a hashed table is that multiple session entries might match to the same hash
value, thereby slowing down the search function of CBAC. When more then one connection
entry matches the same hash value, this is called a collision. The more collisions that occur, the
longer it takes to find a match, and, thus, the lower throughput becomes. This is especially true
when connection table becomes larger.
The throughput performance feature of CBAC enables us to dynamically change the size
of the hash table that references the connections without having to reboot the router. This
feature is new in Cisco IOS 12.2(8)T and is configured using the following command:
Router(config)# ip inspect hashtable hash_number
The hash number that we configure specifies the number of buckets that the hash table
uses. A bucket is basically a reference to one or more sessions. The more buckets you have, the
less likely it is that you will experience collisions. The default number of buckets is 1024; this can
be changed to 2048, 4096, or 8192.
Connections Per Second Improvement Feature
CBAC measures the number of short-lived connections that are created or deleted over
a 1-second interval. CBAC can measure only connection-oriented connections. Therefore, only
TCP connections are counted; UDP and ICMP are not.
Normally, CBAC would process-switch packets for the first few initial TCP packets in
adding or removing a connection from the state table. Then packets would be switched
normally using whatever switching method was enabled on the router or its interfaces,
including CEF.
The problem with this approach is that it affects the performance of the router, especially if
it was hit with hundreds of simultaneous TCP setup or teardown requests.The connections per
second improvement feature reduces the number of packets that have to be processed
switched .only the first packet in the session is processed-switched (all packets after that are
processed normally). This feature provides a significant boost in performance when your router

experiences many short-lived connections, such as HTTP. This feature is new in Cisco IOS
12.2(8)T.
CPU Utilization Improvement Feature
Maintaining a low CPU utilization is important for a router using CBAC, especially
when it has to handle hundreds or thousands of sessions. Cisco rewrote the code for identifying
new sessions and how they are added and removed from the state table, reducing the number
of CPU cycles required to process the connection.
Cisco allows to dynamically change the size of the hash table to reduce the likelihood of
collisions that occur when the Cisco IOS is performing a CBAC state table lookup. Cisco IOS
reduces the number of times that it must perform process switching by doing this only on the
first packet of a session. All other packets are switched normally, which means that fewer CPU
cycles are required per packet and session. The CPU utilization feature also was introduced in Cisco
IOS 12.2(8)T.
Global Timeouts
The ip inspect tcp synwait-time command specifies how long the Cisco IOS waits for a
specific TCP session to be established (to complete the three-way handshake). The default is 30
seconds. If the three-way handshake does not complete by the end of this timeout, the Cisco
IOS removes the entry from its state table and the dynamic entry in the ACL (before FAB),
and it notifies both parties that the connection has been terminated.
The ip inspect tcp finwait-time command specifies how long the Cisco IOS waits to
remove an entry from its tables when the source or destination begins the teardown process of
a TCP session. The default is 5 seconds. When the Cisco IOS sees that a connection is being torn
down, it gives the two devices this time period to tear down the connection before removing the
entry from the state table and the corresponding dynamic entry from the ACL (before FAB).
The ip inspect tcp idle-time command specifies how long the Cisco IOS maintains an
idle TCP connection in its state table. An idle connection is one that is established but has no
traffic traversing it. The default is 3600 seconds (1 hour). When the idle period expires, the Cisco
IOS removes the entry from the state table and the corresponding dynamic entry from the
ACL (before FAB).
The ip inspect udp idle-time command specifies how long the Cisco IOS maintains an
idle UDP connection in its state table. The default is 30 seconds. After the idle period expires, the
Cisco IOS removes the UDP entry from the state table and the corresponding dynamic entry
from the ACL (before FAB).
The ip inspect dns-timeout command specifies how long the Cisco IOS maintains a DNS
query connection in its state table. The default is 5 seconds. When this time period expires, the
Cisco IOS removes the DNS query entry from the state table and the corresponding dynamic
entry from the ACL (before FAB). This timer supercedes the UDP idle timer. This timer is used
to prevent IP spoofing of DNS responses, providing a smaller window for a hacker to spoof
DNS responses and, thereby, redirecting an internal device to the wrong service.
Port Application Mapping
CBAC uses PAM to determine what type of inspection should be performed on a
connection. For example, the default application associated with port 25 is SMTP; therefore,
CBAC understands, by default, that e-mail is used on this connection and, consequently, can inspect
the connection for the appropriate SMTP commands.

We might have a web server running on port 8080. By default, CBAC treats this as a
normal TCP connection. To have CBAC inspect the connection and treat it as an HTTP
connection,We need to associate port 8080 with HTTP.
PAM is the process used to map nonstandard ports to applications so that CBAC can
perform the appropriate type of inspection. PAM can be used to associate either TCP or UDP
ports to applications. PAM even enables us to assign ports on a host-by-host basis to a specific
application.
PAM Table
Port mappings are placed in the PAM table, and CBAC uses this table to perform the
appropriate inspection on a connection. Three types of entries are used in this table:
System-defined entries These are the well-known port numbers of applications, such as TCP
port 80 for HTTP. These entries cannot be deleted or changed. For example, wecannot assign SMTP
port 25 to be inspected on port 80, or HTTP port 80 to 25; however, we can override the systemdefined entries on a host-by-host basis.
User-defined entries These are applications running on nonstandard port numbers, such as
a web server running on ports 8000 or 8080. we easily can create these entries in the PAM table
to accommodate all connections with the specified port number. We can map ranges of ports to a
specific application.
Host-specific entries These are a subset of user-defined entries, where the PAM mapping
maps only a connection or connections for a specific host or hosts, but not all connections
using the same port number. This enables us to limit the inspection that CBAC does for a
specific application. For example, we might have two applications running on port 8080: a web
server and a home-grown application. With PAM, you can put an entry in the table for port 8080 for
just the web server. This causes CBAC to use HTTP inspection on port 8080 for the web server
andnormal TCP inspection for 8080 on all other devices.
Router(config)# ip port-map application_name port port_# [list acl_#]
Alerts and Audits
CBAC inspection supports two types of logging functions: alerts and audits.
Alerts
Alerts display messages concerning the operation of CBAC, such as insufficient router
resources, DoS attacks, and other threats. Alerts are enabled by default and automatically display
on the router's console line. To globally disable alerts, use this command:
Router(config)# ip inspect alert-off
Remember that we also can disable and enable alerts per inspection rule.It is highly
recommend that we leave alerts enabled. Alerts are useful because they can notify you of network
attacks, such as an attack against your e-mail server.
Audits
Auditing keeps track of the connections that CBAC inspects, including valid and
invalid access attempts. For example, we can see messages when CBAC adds or removes an entry
from the state table. The audit record gives some basic statistical information about the connection.
Auditing is disabled by default but can be enabled with the following command:
Router(config)# ip inspect audit trail
CBAC Configuration

Step 1. Determine which interfaces will be internal and external on your router.
Step 2. Create your normal IP ACLs to filter traffic entering and leaving your network. Make sure
that we permit the traffic that is to be inspected as it is leaving our network.
Step 3. Change the global timeout values for connections. This is optional.
Step 4. Configure Port Application Mapping (PAM), which specifies the port numbers that CBAC
should inspect if the application is using a nonstandard port number, such as HTTP with 8080. This
is optional and is required only if your application is using a nonstandard port number.
Step 5. Define our inspection rules. These rules define what entries are added to the state table and
what returning traffic is allowed back in. If outbound traffic does not match an inspection rule, the
router does not inspect it and treats it as normal traffic.
Step 6. Activate the inspection rule or rules on your router's interface(s). The router then will use
CBAC to inspect traffic.
Step 7. Test configuration by sending traffic through CBAC router.
TCP Intercept
The TCP intercept feature implements software to protect TCP servers from TCP SYNflooding attacks, which are a type of denial-of-service attack. A SYN-flooding attack occurs
when a hacker floods a server with a barrage of requests for connection. Because these messages
have unreachable return addresses, the connections cannot be established. The resulting volume of
unresolved open connections eventually overwhelms the server and can cause it to deny service to
valid requests, thereby preventing legitimate users from connecting to a web site, accessing e-mail,
using FTP service, and so on.
The TCP intercept feature helps prevent SYN-flooding attacks by intercepting and
validating TCP connection requests. In intercept mode, the TCP intercept software intercepts
TCP synchronization (SYN) packets from clients to servers that match an extended access list.
The software establishes a connection with the client on behalf of the destination server, and if
successful, establishes the connection with the server on behalf of the client and knits the two
half-connections together transparently. Thus, connection attempts from unreachable hosts will
never reach the server. The software continues to intercept and forward packets throughout
the duration of the connection. The number of SYNs per second and the number of concurrent
connections proxied depends on the platform, memory, processor, and other factors
In the case of illegitimate requests, the software's aggressive timeouts on half-open
connections and its thresholds on TCP connection requests protect destination servers while
still allowing valid requests.
When establishing our security policy using TCP intercept, we can choose to intercept all
requests or only those coming from specific networks or destined for specific servers. We can
also configure the connection rate and threshold of outstanding connections.
We can choose to operate TCP intercept in watch mode, as opposed to intercept mode. In
watch mode, the software passively watches the connection requests flowing through the
router. If a connection fails to get established in a configurable interval, the software intervenes
and terminates the connection attempt.
TCP Intercept Configuration
To configure TCP intercept, perform the tasks in the following sections. The first task is required;
the rest are optional.

Enabling TCP Intercept (Required)

Setting the TCP Intercept Mode (Optional)
Setting the TCP Intercept Drop Mode (Optional)
Changing the TCP Intercept Timers (Optional)
Changing the TCP Intercept Aggressive Thresholds (Optional)
Monitoring and Maintaining TCP Intercept (Optional)
Enabling TCP Intercept
To enable TCP intercept, use the following commands in global configuration mode:
Step 1
Router(config)# access-list access-list-number {deny | permit} tcp any destination destinationwildcard
Step 2
Router(config)# ip tcp intercept list <access-list-number>
Enables TCP intercept.
We can define an access list to intercept all requests or only those coming from specific
networks or destined for specific servers. Typically the access list will define the source as any
and define specific destination networks or servers. That is, we do not attempt to filter on the
source addresses because we do not necessarily know who to intercept packets from. We
identify the destination in order to protect destination servers. If no access list match is found,
the router allows the request to pass with no further action.
Router(config)# access-list access-list-number {deny | permit} tcp any destination destinationwildcard
Router(config)# ip tcp intercept list access-list-number
Setting the TCP Intercept Mode
The TCP intercept can operate in either active intercept mode or passive watch mode.
The default is intercept mode. In intercept mode, the software actively intercepts each
incoming connection request (SYN) and responds on behalf of the server with an SYN-ACK, then
waits for an ACK from the client. When that ACK is received, the original SYN is sent to the server
and the software performs a three-way handshake with the server. When this is complete, the two
half-connections are joined.
In watch mode, connection requests are allowed to pass through the router to the server
but are watched until they become established. If they fail to become established within 30
seconds (configurable with the ip tcp intercept watch-timeout command), the software sends a
Reset to the server to clear up its state. To set the TCP intercept mode, use the following command
in global configuration mode:
Router(config)# ip tcp intercept mode {intercept | watch}
TCP Intercept Drop Mode
When under attack, the TCP intercept feature becomes more aggressive in its protective

behavior. If the number of incomplete connections exceeds 1100 or the number of connections
arriving in the last one minute exceeds 1100, each new arriving connection causes the oldest
partial connection to be deleted.
Also, the initial retransmission timeout is reduced by half to 0.5 seconds (so the total
time trying to establish a connection is cut in half).
By default, the software drops the oldest partial connection. Alternatively, we can
configure the software to drop a random connection. To set the drop mode, use the following
command in global configuration mode:
Router(config)# ip tcp intercept drop-mode {oldest | random}
TCP Intercept Timers
By default, the software waits for 30 seconds for a watched connection to reach
established state before sending a Reset to the server. To change this value, use the following
command in global configuration mode:
Router(config)# ip tcp intercept watch-timeout seconds
By default, the software waits for 5 seconds from receipt of a reset or FIN-exchange
before it ceases to manage the connection. To change this value, use the following command in
global configuration mode:
Router(config)# ip tcp intercept finrst-timeout seconds
By default, the software still manages a connection for 24 hours after no activity. To
change this value, use the following command in global configuration mode:
Router(config)# ip tcp intercept connection-timeout seconds
Changing the TCP Intercept Aggressive Thresholds
Two factors determine when aggressive behavior begins and ends: total incomplete
connections and connection requests during the last one-minute sample period. Both thresholds
have default values that can be redefined.
When a threshold is exceeded, the TCP intercept assumes the server is under attack and
goes into aggressive mode. When in aggressive mode, the following occurs:
Each new arriving connection causes the oldest partial connection to be deleted. (You can change
to a random drop mode.)
The initial retransmission timeout is reduced by half to 0.5 seconds, and so the total time trying to
establish the connection is cut in half.
If in watch mode, the watch timeout is reduced by half. (If the default is in place, the watch
timeout becomes 15 seconds.)
The drop strategy can be changed from the oldest connection to a random connection with
the ip tcp intercept drop-mode command.We can change the threshold for triggering
aggressive mode based on the total number of incomplete connections. The default values for
low and high are 900 and 1100 incomplete connections, respectively. To change these values, use
the following commands in global configuration mode:
Step 1
Router(config)# ip tcp intercept max-incomplete low number
Step 2
Router(config)# ip tcp intercept max-incomplete high number

We can also change the threshold for triggering aggressive mode based on the number
of connection requests received in the last 1-minute sample period. The default values for low
and high are 900 and 1100 connection requests, respectively. To change these values, use the
following commands in global configuration mode:
Step 1
Router(config)# ip tcp intercept one-minute low number
Step 2
Router(config)# ip tcp intercept one-minute high number
Monitoring and Maintaining TCP Intercept
To display TCP intercept information, use either of the following commands in EXEC mode:
Router# show tcp intercept connections
Router# show tcp intercept statistics