For a low budget firewall functionality, a Cisco router with the proper IOS version can work as a network firewall providing stateful protocol inspection using the Context-Based Access Control (CBAC) feature. Many people use normal Access Control Lists on Cisco routers for traffic filtering and protection. However, a normal ACL is just a static packet filtering mechanism and nothing else. With a CBAC configuration, the router acts like a firewall. That is, it inspects protocols and sessions and keeps a state of the connection in memory. This means that an outbound packet (from inside the network to the outside) is inspected and a connection state of the session is kept in memory. The reply packet which belongs to the original outbound connection is allowed to pass through the router/firewall and reach the internal system which originated the connection. This stateful functionality is achieved by the IOS Firewall CBAC mechanism by opening temporary holes on an Access List in order to allow the reply packets.

A normal ACL checks traffic up to the transport layer. CBAC on the other hand inspects traffic up to the application layer to learn about the state of the session and to apply firewall filtering on the specific application. The protocols supported by CBAC for inspection are the following:

CUSeeMe Protocol, ftp, h323, http, rcmd, realaudio, rpc, smtp, sqlnet, streamworks, tcp, tftp, udp, vdolive. CBAC helps to protect also against DoS attacks such as SYN-floods or fragmentation attacks.

CBAC is applied either inbound or outbound on a specific router interface. CBAC applied “Inbound” on an interface inspects traffic entering the interface and CBAC applied “Outbound” on an interface inspects traffic exiting the interface. CBAC cooperates with an ACL applied on the same interface in order to provide the firewall stateful functionality that we described above. Lets see a simple example below.

In the figure above, assume that there is an inbound ACL applied on S0 on the router. The ACL is configured to block Telnet traffic initiated from the outside. Assume also that there is a CBAC rule applied “outbound” on S0. An internal user (User1) initiates a Telnet session from inside to outside. When the connection request for User1′s Telnet session passes through the firewall, CBAC inspects the Telnet traffic when exits interface S0 and creates a temporary opening in the inbound access list at S0 to permit returning Telnet traffic for User1′s Telnet session. (If the same access list is applied to both S0 and S1, the same opening would appear at both interfaces.)

Important Note: CBAC which inspects outbound traffic from an interface, will create temporary openings on the Access List which is applied Inbound on the interface. This is required to allow the return packets to pass through the ACL.

Let us see a configuration example below to get a better picture.

Configuration Example:

Refer to the diagram below for our configuration example:

We have a border Cisco router connecting the internal LAN 192.168.1.0/24 to the Internet. We have a static public IP address 50.50.50.1 on interface Serial0/0. Also, we have a DMZ segment (interface FE0/0) hosting a DMZ Web Server 10.1.1.1. We want to allow access from Internet towards the Web Server only. We use static NAT to hide the Web server private address behind our public address. Also, we use PAT on interface S0/0 for all outbound communication from the internal LAN towards the internet.

Lets see a snapshot of the configuration below:

! Create the outbound CBAC inspection rules
ip inspect name CBAC-IN-OUT tcp
ip inspect name CBAC-IN-OUT ftp
ip inspect name CBAC-IN-OUT h323
ip inspect name CBAC-IN-OUT rcmd
ip inspect name CBAC-IN-OUT http
ip inspect name CBAC-IN-OUT netshow
ip inspect name CBAC-IN-OUT realaudio
ip inspect name CBAC-IN-OUT rtsp
ip inspect name CBAC-IN-OUT sqlnet
ip inspect name CBAC-IN-OUT streamworks
ip inspect name CBAC-IN-OUT tftp
ip inspect name CBAC-IN-OUT udp
ip inspect name CBAC-IN-OUT vdolive

! Create the inbound CBAC to inspect inbound HTTP
ip inspect name CBAC-OUT-IN http

! DMZ interface
interface FastEthernet0/0
ip address 10.1.1.254 255.255.255.0
ip nat inside
full-duplex
no cdp enable
!
! Internal LAN interface
interface FastEthernet0/1
ip address 192.168.1.254 255.255.255.0
ip nat inside
full-duplex
no cdp enable
!

! External Internet Interface
! Notice that we apply an inbound ACL and CBAC rules for both in and out inspection
interface Serial0/0
description CONNECTED TO INTERNET
bandwidth 1024
ip address 50.50.50.1 255.255.255.252
ip access-group FIREWALL in
ip nat outside
ip inspect CBAC-OUT-IN in
ip inspect CBAC-IN-OUT out

ip nat inside source list 122 interface Serial0/0 overload
ip nat inside source static tcp 10.1.1.1 80 50.50.50.1 80 extendable no-alias
ip classless
ip route 0.0.0.0 0.0.0.0 50.50.50.2

! This ACL will be used by the CBAC out rule to open temporary holes for return traffic
ip access-list extended FIREWALL
permit icmp any any echo-reply
permit tcp any host 50.50.50.1 eq 80
deny   ip any any log

access-list 122 permit ip 192.168.1.0 0.0.0.255 any

The use of password protection in any Cisco device is of paramount importance since passwords provide the first level of defence against unauthorised access to our Cisco networks. Especially on terminal lines (either console line or VTY lines), the use of passwords is a fundamental element of security.

The following techniques enable you to control who is allowed access to the router and what IOS privilege levels they are granted once they gain access:

• password (line configuration): To specify a password on a line, use the password command in line configuration mode. A line is a console port (CTY), auxiliary port (AUX), virtual terminal (VTY), or asynchronous (TTY) line.

After specifying a password on a line using the password command, you must activate password checking at login using the login command in line configuration mode. The example below illustrates how to enable password security on each of the available lines. The password and login commands are widely available within IOS.

Router(config)# line con 0
Router(config-line)# password s3cr3t
Router(config-line)# login
Router(config-line)# line 1 8
Router(config-line)# password s3cr3t
Router(config-line)# login
Router(config-line)# line aux 0
Router(config-line)# password s3cr3t
Router(config-line)# login
Router(config-line)# line vty 0 4
Router(config-line)# password s3cr3t
Router(config-line)# login

• username password: The password command described above specifies a password for a specific line. Using the configuration in the example above, any user that attempts to connect to a line must enter the configured line password to be granted user EXEC mode access. To establish local  username-based password authentication, use the username command in global configuration mode. After specifying a username password, you must activate username-based password checking for the lines using the login local command in line configuration mode. The username command is widely available within IOS.

• enable secret: To specify an additional layer of security use the enable secret command in global configuration mode. The enable secret command provides better security by storing the configured enable secret password using a nonreversible cryptographic hash function, compared to the enable password command, which stores the configured password in clear text or in an easily reversible encrypted format. Storing the password as a cryptographic hash helps to minimize the risk of password sniffing if the router configuration file is transferred across the network, such as to and from a TFTP server. It is also useful if an unauthorized user obtains a copy of your configuration file. Note, if neither the enable password command nor the enable secret command is configured, and if there is a line password configured for the console port, the console line password will serve as the enable password for all VTY lines, which includes Telnet, rlogin, and SSH connections. The enable secret command is widely available within IOS. Username passwords may also be stored in the router configuration file in cryptographic hash format, similar to the enable secret. The associated command is username secret.

•  service password-encryption: To encrypt local router passwords, use the service password-encryption command in global configuration mode. This command applies to line passwords, username passwords, enable passwords, and authentication key passwords, including routing authentication passwords and key strings. By default, IOS does not encrypt passwords. Encrypting passwords in this way helps to minimize the risk of password sniffing if the router configuration file is transferred across the network such as to and/or from a TFTP server. It is also useful if an unauthorized user obtains a copy of your configuration file. This command is widely available within IOS.

There are usually 5 VTY lines on Cisco routers (VTY 0 to 4). An attacker can perform a Denial of Service attack by opening several simultaneous Telnet or SSH connections to the router, thus occupying all available lines and prohibiting the legitimate administrators for managing the device.

To protect from this kind of attack, we can configure and apply an ACL on lines 0 to 3 allowing the general Network Management address range, and then configure a more restrictive ACL for the last VTY line 4, which allows only a specific management station to connect.

 Configuration Example:

! Allow access from the general Network Management range (assume management network is 10.10.10.0/24)
Router(config)# access-list 100 permit tcp 10.10.10.0 0.0.0.255 any eq ssh

! Allow access from a single management station
Router(config)# access-list 101 permit tcp host 10.10.10.10 any eq ssh

Router(config)# line vty 0 3
Router(config-line)# access-class 100 in
Router(config)# line vty 4
Router(config-line)# access-class 101 in

There are several mechanisms that can be used to protect a Cisco IP network from Denial of Service attacks. Especially for Service Provider networks, DoS Attacks are the biggest threat the network administrators face today. Worms, flooding attacks, Distributed Denial of Service by BotNets etc are some forms of DoS attacks that can hit a Service Provider IP Network. The two most effective security features on Cisco routers to mitigate DoS attacks are the following:

Receive Access Control Lists (rACL)

The Receive ACL feature is applicable on the GSR model routers. It is used to increase security on Cisco 12000 by protecting the router’s gigabit route processor (GRP) from unnecessary and potentially malicious traffic. The rACL feature can be used in combination with Control Plane Policing and Routing Protection to implement a successful defence-in-depth strategy for Control Plane Protection in the Core. This feature is supported in IOS version 12.0(24)S (and newer) of the GSR platform.

The traffic inspected by the rACL is the one passing through the GSR Line Cards (LC) towards the LC CPU (ICMP and Logging) and also traffic passing through the LC towards the route processor (GRP) (Routing Protocols, SSH, Telnet, SNMP, NTP). Because the GRP has limited capacity to handle excessive traffic coming from the Line Cards, there is a danger of a Denial-of-Service attack on the GRP. Receive ACLs explicitly permit or deny traffic destined to the GRP, while transit traffic in the Forwarding (Data) Plane is not affected. Traffic is filtered on the ingress LC prior to RP processing. Deploying rACLs has helped defend against several security advisories in all US Service Providers Network Infrastructure.

Control Plane Policing (CoPP)

The Control Plane Policing mechanism is complementary to the rACL feature. The later controls what protocols and traffic are allowed to flow towards the router processor, while the CoPP feature controls how much traffic is allowed to flow. This feature is applicable on both the GSR 12000 and 7600 routers.
The Control Plane Policing feature treats the CP as a separate entity with its own ingress (input) and egress (output) ports, which are like ports on a router and switch. Because the Control Plane Policing feature treats the CP as a separate entity, a set of rules can be established and associated with the ingress and egress port of the CP. These rules are applied only after the packet has been determined to have the CP as its destination or when a packet exits from the CP. Thereafter, you can configure a service policy to prevent unwanted packets from progressing after a specified rate limit has been reached; for example, a system administrator can limit all TCP/SYN packets that are destined for the CP to a maximum rate of 1 megabit per second.