 Little
Known Cisco IOS Security Features
Tim Sammut
There are many security features of Cisco's IOS that may be uncommon,
yet are useful in the quest for heightened network security. These
features provide the ability to scrutinize network traffic more
critically in the case of Reflexive Access Control Lists, or even
alter the path the network sensitive data takes using Policy Based
Routing. TCP Intercept and Unicast Reverse Path Forwarding help
eliminate damaging and security threatening traffic at the edge
of the network by validating inbound connection attempts and their
sources. The following sections describe some of these useful and
under utilized Cisco security features.
Reflexive ACLs
Typically, Access Control Lists (ACLs) are statically configured
to drop or permit network packets. This can make securing the network
difficult as return traffic for connections initiated from inside
the network must explicitly be allowed. With reflexive ACLs, the
router will automatically create entries in a dynamic ACL, which
can then be evaluated to authorize return traffic. As these dynamic
ACL entries are automatically created for a specific connection
and specify the IP protocol, source and destination addresses, and
ports of the connection, they improve network security by only allowing
inbound traffic that is directly associated with a connection initiated
from the inside of the network. Without this functionality, security
is difficult to achieve using the only alternative of allowing the
return traffic for all possible outbound connections.
Reflexive ACLs increase the power of IP extended named access
control lists by including two additional keywords: "reflect" and
"evaluate". The reflect keyword is used to updated a dynamic ACL
with the mirror image of the packet matching the ACL entry. Return
traffic is later checked against this dynamic ACL using the evaluate
keyword. Below is an example of the outbound and inbound IP named
extended ACLs required to allow a DNS client to talk to a DNS server
without using Reflexive ACLs:
ip access-list extended OUTBOUND
permit udp any any eq domain
ip access-list extended INBOUND
permit udp any eq domain any
While this may look benign enough, it will allow any outside computer
sending UDP traffic sourced on port 53 to communicate with any computer
inside your network via UDP. If we extend our example to include the
"reflect" and "evaluate" commands, we end up with a more secure configuration:
ip access-list extended OUTBOUND
permit udp any any eq domain reflect REFLEXIVE
ip access-list extended INBOUND
evaluate REFLEXIVE
In this example, the reflexive ACL is dynamically changed to allow
the return DNS traffic. For example, if we are speaking with a DNS
server at IP address 172.16.1.1 from a client at 192.168.1.1, the
reflexive ACL is modified, essentially adding the line "permit
udp host 172.16.1.1 eq domain host 192.168.1.1 eq 1024" to the
inbound ACL.
There are two circumstances that result in the removal of an entry
from a reflexive ACL. These are the end of a TCP session via the
FIN or RST bits, or the lack of traffic in a TCP or UDP session.
The inactivity timeout can be set globally through the ip reflexive-list
timeout global configuration command, or for an individual reflexive
ACL via the "timeout" option during creation. Here is a portion
of the previous example extended to include the timeout option:
ip access-list extended OUTBOUND
permit udp any any eq domain reflect REFLEXIVE timeout 120
After a reflexive ACL has been configured, you can view the dynamic
contents of the ACL with the show access-list privileged EXEC
command. This command will show the number of packets that have matched
each entry, as well as the time in seconds until the entry will be
removed if it remains inactive.
Policy Based Routing
Although it has many uses, Policy Based Routing (PBR) can be used
to direct sensitive network data over paths with higher security.
Possibilities include sending telnet traffic over an IPSec encrypted
tunnel or transmitting critical application data over dedicated
interfaces. Within a security context and when altering the next
hop of an IP packet, PBR configurations are router-centric. This
requires that each router along the traffic path from source to
destination be manually configured if a policy-based action is required.
There are several components to a PBR implementation. First, access
lists are defined to determine to which traffic a policy is applied.
IP standard and IP extended access lists can be created with the
access-list global configuration command. IP standard access
lists only test the IP source address field and should not be used
in favor of the more flexible IP extended and named IP extended
access list types. Named IP extended access lists provide improved
editing capabilities and the ability to add inline comments. The
global configuration command ip access-list extended
is used to create named IP extended access lists.
Route maps are then created to pair packet conditions with setting
changes. The route map essentially takes a packet matching an access
list and applies one or more alterations to the packet. For example,
packets between two hosts can have their next hop altered so that
they are sent over a slower but more secure link regardless of what
has been learned via a routing protocol or configured via static
routes. As it is only possible to apply a single route map to an
interface, it is possible to create multiple instances of a route
map. Each instance of a route map can apply different settings to
different traffic. Instances are applied to traffic in order using
sequence numbers, from low to high. A route map instance is created
with the route-map global configuration command, which has
the following syntax:
route-map NAME ACTION SEQNUM
For use in PBR, the action field, shown above as ACTION, should
always be permit. This tells PBR to apply the settings of the
route map to the packets matching the conditions of the route map.
The access list is linked to the route map instance with the match
address route map configuration command as shown below:
route-map NAME ACTION SEQNUM
match address ACL
It is possible to effect several changes on a packet or traffic flow
using policy-based routing. Most often used within a security context,
the ip next-hop alters the path of a traffic flow. Below is
the complete syntax to create a route map instance that changes the
next hop of a packet:
route-map NAME ACTION SEQNUM
match address ACL
set ip next-hop NEXTHOP
Once the access list and route maps have been created, they are then
applied to an interface with the ip policy route-map interface
configuration command. Policy routing will look at all traffic arriving
as input on an interface and does not look at traffic to be transmitted
out of an interface. The following sample configuration will send
all telnet traffic to host 192.168.4.100 over a slower point-to-point
serial line instead of the faster frame relay link:
interface Ethernet1
ip address 192.168.1.1 255.255.255.0
ip policy route-map ROUTE-MAP
interface Serial2
description T1 to Frame Relay
ip address 192.168.2.1 255.255.255.252
encapsulation frame-relay
interface Serial3
description 56k to Site B, remote router 192.168.3.2
ip address 192.168.3.1 255.255.255.252
!
ip access-list extended ROUTE-MAP-ACL
permit tcp any host 192.168.4.100 eq 23
!
route-map ROUTE-MAP permit 10
match address ROUTE-MAP-ACL
set ip next-hop 192.168.3.2
Although we did not need it for this example, it is possible to expand
the ACL to include many types of traffic and settings using multiple
instances of the same route map. In addition to the security-related
next hop change in our last example, this example also directs Web
traffic to a Web cache device:
ip access-list extended ROUTE-MAP-ACL
permit tcp any host 192.168.4.100 eq 23
!
ip access-list extended WEB-CACHE-ACL
deny tcp 192.168.1.100 any eq 80
permit tcp any host any eq 80
!
route-map ROUTE-MAP permit 10
match address ROUTE-MAP-ACL
set ip next-hop 192.168.3.2
!
route-map ROUTE-MAP permit 20
match address WEB-CACHE-ACL
set ip next-hop 192.168.1.100
While it is possible to have multiple entries in access lists and
multiple route map instances, only a single route map may be applied
to an interface.
To improve the performance of policy routed packets, the ip
route-cache policy interface configuration command should be
used to enable fast switching on interfaces with policy routing
enabled. Fast switching utilizes a route cache to greatly improve
router performance and permits packets by the router without the
interruption of the main CPU. To verify that policy-routed packets
are fast switched, use the show ip interface EXEC command
and look for the line that lists the IP route-cache flags. If this
line contains the keyword "Policy", fast switching of policy-routed
packets is enabled on that interface.
TCP Intercept
With TCP Intercept, a router can reduce the effect of SYN flood
attacks on an organization's servers. Specifically, TCP Intercept
monitors TCP connections matching an access list and will timeout
half-open sessions in a much more aggressive fashion than most server
operating systems.
It is possible to configure TCP Intercept in one of two modes.
When configured for the first and default mode, the router will
establish connections on the server's behalf with outside clients.
Once the connection has been successfully established between the
router and client, the router will open a session to the server
and connect the two sessions. This operation is transparent to both
the client and server, but does require more router resources. This
mode is known as "intercept mode".
In the other mode, called "watch mode", the router passively monitors
TCP connections to the servers. Under normal circumstances, the
router has no part in successful connections. If, however, a connection
fails to reach ESTABLISHED state before a timer expires, the router
sends a TCP reset to the server to close the connection. This timer
can be changed with the ip tcp intercept watch-timeout global
configuration command and defaults to 30 seconds. The TCP Intercept
mode is set with the global configuration command ip tcp intercept
mode.
If the server has 1100 incomplete connections at any point, or
if there have been 1100 connection attempts in the last minute,
TCP Intercept with default settings will behave much more aggressively.
While in this state, each new connection attempt causes an existing
half-open connection to be dropped. By default, the router will
drop the oldest incomplete connection, or alternatively can be configured
to drop a random connection using the ip tcp intercept drop-mode
global configuration command. If TCP Intercept is configured for
watch mode operation, the timeout for half-open connections is cut
in half (to 15 seconds by default) when entering aggressive mode.
The point at which TCP Intercept begins acting more aggressively,
and the duration of aggressive mode, can be tuned with the following
four global configuration commands:
ip tcp intercept max-incomplete high VALUE
When the number of incomplete connections reaches this value, TCP
Intercept enters aggressive mode. The default setting for VALUE is
1100.
ip tcp intercept max-incomplete low VALUE
This global configuration command tells the router at what point it
should return to normal operation from aggressive mode. The default
setting for VALUE is 900.
ip tcp intercept one-minute high VALUE
When VALUE number of connection attempts have been received in the
last minute, TCP Intercept will begin aggressive mode processing.
The default setting for VALUE is 1100.
ip tcp intercept one-minute low VALUE
The router will continue to operate in aggressive mode until the number
of active connections drops below this value. The default setting
for VALUE is 900.
If both of the low values are exceeded, the router will enter
aggressive mode and start dropping half-open connections. It remains
in aggressive mode until both numbers drop below the low value thresholds.
Here is a complete sample configuration utilizing default values
and showing the minimum configuration required:
!
ip tcp intercept list 100
!
access-list 100 permit any 192.168.1.0 0.0.0.255
!
Below is a more extensive example that changes the intercept mode,
drop mode, and some timeout values:
!
ip tcp intercept list 100
ip tcp intercept mode watch
ip tcp intercept drop-mode random
ip tcp intercept one-minute high 2000
ip tcp intercept one-minute low 1600
!
access-list 100 permit any 192.168.1.0 0.0.0.255 eq www
access-list 100 permit any 192.168.1.0 0.0.0.255 eq smtp
!
There are only two show commands that can provide insight into
the operation of a TCP Intercept configuration. The first, show
tcp intercept connections, will show the active complete and incomplete
TCP sessions. It lists the state of these connections as well as counters
since the connection was created, and until it will time out. The
second command, show tcp intercept statistics, lists the number
of complete and incomplete sessions, as well as the one-minute connection
rate. This information will give you an important head start when
beginning to tune your TCP Intercept configuration.
Unicast Reverse Path Forwarding
With Unicast Reverse Path Forwarding (Unicast RPF), you can eliminate
spoofed IP packets at the network edge. Unicast RPF inspects each
input packet on enabled interfaces and verifies that the router
received the packet over the correct interface using the local routing
table. While in some situations this could be accomplished more
simply with access lists, Unicast RPF will guarantee that packets
arriving on the border router's outside interface do not claim to
be sourced by internal clients. Furthermore, ACLs require manual
editing and could become tedious and error prone in dynamic environments
or where dynamic routing protocols are used between business partners
or large remote sites.
A typical and appropriate scenario for Unicast RPF would be for
organizations with connections to external business partners or
possibly remote locations with untrusted users. Applying Unicast
RPF to router interfaces connecting these types of locations can
make sure that they are not the source of spoofed network packets
and certain types of denial of service attacks. Internet service
providers can also improve the security of their own network and
the Internet in general by implementing Unicast RPF on the connections
to their customers.
Since there is a certain level of traffic asymmetry with multi-homed
Internet connections, it is not possible to ensure that all traffic
will take the same path into and out of the network. For this reason,
Unicast RPF is not suitable for the border router or routers of
organizations with multiple Internet connections. Implementing Unicast
RPF in this setting could result in the blocking of valid traffic.
Available in Cisco 12.0 and later, Unicast RPF is only available
on platforms that support Cisco Express Forwarding. Configuring
Unicast RPF is straightforward and is enabled by simply entering
the command ip verify unicast reverse-path in interface configuration
mode. When configured on interfaces with ACLs defined, input ACLs
are checked before Unicast RPF processes the packet.
Restricting Telnet Access to Routers
Only a relatively small number of workstations require the ability
to telnet to routers within the network in most environments. The
access-class line configuration command gives us the ability
to control exactly which workstations can access the routers, or
alternatively, which workstations cannot. Even if this does not
seem appropriate for an organization's internal routers, it should
be configured on routers available from the Internet. The access-class
command takes an argument specifying the ACL to use when permitting
or denying inbound telnet connections:
access-list 90 permit 1.1.1.0 0.0.0.255
!
line vty 0 4
access-class 90 in
The above example will only allow devices with source IP addresses
of 1.1.1.0 to 1.1.1.255 to telnet to this router.
Disallowing Directed Broadcasts
Used in many of the prevalent denial of service attacks, directed
broadcasts allow a remote computer to send a broadcast to all of
the computers on a subnet. Until version 12.0, Cisco routers would
by default forward and convert these broadcasts to MAC-level broadcasts
once they reached the destination subnet. In all versions of IOS,
the interface configuration command ip directed-broadcast
enables this functionality.
Providing further functionality and control, the ip forward-protocol
global configuration command customizes which broadcasts are allowed
and converted. This command has a wide list of supported protocols,
which includes tftp, bootp, and netbios-ns.
The ip directed-broadcast command takes an optional argument
specifying an access list used to filter the broadcasts. This provides
additional granularity when specifying which broadcasts are forwarded.
In the following example, we permit only broadcasts sourced within
our network, which uses the 192.168.0.0 private address space:
interface Ethernet0
ip directed-broadcast 100
!
access-list 100 permit ip 192.168.0.0 0.0.255.255 any
Conclusion
Network security is an elusive target and is considered by many
to be unattainable. Although these are not all of the options, they
are tools that when used correctly can improve network security.
Tim Sammut, CCIE #6642, is a Sr. Network Engineer for Logicon
FDC and provides network design and implementation services to the
federal government in the Maryland and Washington DC areas. He can
be contacted at: tim.sammut@feddata.com.
| 
