Category: security

Due to the way Cisco routers behave when dropping packets with an inbound access list, whenever you use access lists to protect the router from the outside attacks (or port scans), the protected ports (even though they're not active on the router) will appear filtered (some scanners might use the term stealth), which is almost an invitation to a determined hacker.

Sometimes (it depends on the application you're protecting) you can configure application-layer protection in Cisco IOS. For example, you can protect HTTP server with ip http access-class global configuration command or the Telnet server with the access-class in line configuration command (and BGP will not accept incoming TCP SYN packets unless you've configured a BGP neighbor). The access-class configuration causes the incoming request to be rejected within application (in control plane after the TCP stack), resulting in TCP RST packet being sent back. The port scanner thus reports the protected TCP port as closed.

When I was testing the inspection of router-generated traffic, I wanted to block and log all incoming traffic (apart from inspect-generated conduits, obviously) with a simple access-list:

access-list 102 deny ip any any log

Unfortunately, the port numbers in the logging printout were always zero:

%SEC-6-IPACCESSLOGP: list 102 denied udp 10.0.0.1(0) -> 192.168.1.3(0), 1 packet

The reason for this behavior is very simple: unless a line in the IP ACL matches on the layer-4 port numbers, the router does not inspect them; the log action thus has no port number to show in the syslog printout.

To fix the printout, you have to force the router to inspect the layer-4 port numbers. If you still want to block-and-log all traffic, the minimum access-list achieving this goal is the following:

access-list 102 deny   udp any gt 0 any gt 0 log
access-list 102 deny   tcp any gt 0 any gt 0 log
access-list 102 deny   ip any any

Recently I was trying to figure out what the various port states reported by Nmap really mean. This is what's actually going on:

• If a packet is intercepted by a router's access-list, the router sends back an ICMP administratively prohibited packet. This is reported as filtered port by Nmap (and probably as stealth port by some other scanners).
• If you do a TCP SYN scan of a router and the scanned port is not active, the router sends back TCP RST packet. This is reported as closed port.
• If you perform a UDP scan of a router, the router sends back ICMP port unreachable message if the UDP application is not active. This is reported by Nmap as filtered port (even though in most cases it should be equivalent to closed TCP port).
• In some cases, the router simply doesn't reply to UDP scans (for example, if you scan the discard service). This is reported as Open¦Filtered (as the scanner cannot reliably determine whether the probe was dropped due to a filter or simply not replied to).

Note: In any case, UDP scans are way more unreliable than TCP scans due to connectionless nature of UDP.

A while ago a reader has asked me whether you could modify an IP access-list when the interface IP address changes. While that's definitely doable with Tcl and Embedded Event Manager, it's not a trivial task, so I've tried to understand why he would need such a functionality.

The answer was quite interesting: he's running NTP on his firewall router and thus needs to accept incoming NTP responses from an external NTP server. While that could be easily achieved with the following configuration (only the relevant bits-and-pieces are shown), he didn't want to make the access-list too generic (allowing NTP from the external server to any IP address).

ip inspect name DEFAULT100 tcp
ip inspect name DEFAULT100 udp
!
interface Dialer0
 description $FW_OUTSIDE$
 ip access-group 102 in
 ip inspect DEFAULT100 out
!
access-list 102 remark #### Dialer0 incoming ####
access-list 102 remark #### non-relevant lines deleted
access-list 102 permit udp host 1.2.3.4 eq ntp any eq ntp

This problem nicely illustrates a broader issues: the router does not inspect it's own traffic and thus does not prepare conduits for the return packets; you have to specify all the return traffic you're expecting in the incoming access list. This drawback has been fixed in IOS release 12.3(14)T with the introduction of the Inspection of Router-Generated Traffic feature. In our scenario you only need to change the inspect rules:

ip inspect name DEFAULT100 tcp router-traffic
ip inspect name DEFAULT100 udp router-traffic

... and the router synchronizes to an external NTP server:

sp#show ip inspect sessions
Established Sessions
 Session 474032B4 (192.168.1.3:123)=>(10.0.0.1:123) udp SIS_OPEN
sp#
01:04:34: %NTP-5-PEERSYNC: NTP synced to peer 10.0.0.1
01:04:34: %NTP-6-PEERREACH: Peer 10.0.0.1 is reachable

Note: This article is part of You've asked for it series.

The IOS documentation claims that the quiet mode the router enters after a series of login failures blocks all telnet (or ssh) sessions as well as HTTP requests. Unfortunately the latter is wrong; you can execute any HTTP request on the router during the quiet mode.

If you want to block HTTP requests during the quiet mode, you can use EEM applets to change the HTTP server configuration when the quiet mode is started and completed.
First you need to configure a standard numbered IP access list that will be used to block HTTP requests during the quiet mode (the ip http access-class command accepts only numbered ACLs), for example:

access-list 95 deny any log

Then you define two EEM applets: one that triggers when the router enters the quiet mode (matching the SEC_LOGIN-1-QUIET_MODE_ON syslog message) and another that runs when the quiet mode is finished (triggered with the SEC_LOGIN-5-QUIET_MODE_OFF). Both applets modify the router configuration, changing the access-list used in ip http access-class configuration command.

event manager applet EnterQuietMode
 event syslog occurs 1 pattern "SEC_LOGIN-1-QUIET_MODE_ON" period 1
 action 1.0 cli command "configure terminal" 
 action 1.1 cli command "ip http access-class 95" 
 action 2.0 syslog msg "Entered Quiet mode on HTTP server"
!
event manager applet ExitQuietMode
 event syslog occurs 1 pattern "SEC_LOGIN-5-QUIET_MODE_OFF" period 1
 action 1.0 cli command "configure terminal"
 action 1.1 cli command "ip http access-class 70"
 action 2.0 syslog msg "Exiting Quiet mode on HTTP server"

In a comment to my post describing how to make a router into a primary DNS server, one of the readers noted that you could easily overload a router doing that ... and he's obviously right.

Apart from having too many valid DNS requests for the zone the router is responsible for, the observed behavior could be spam-related. Just a few days ago when I've discussed the router-based DNS server with my security engineers, they've pointed out that a lot of spammers perform regular DNS attacks trying to poison the DNS cache of unpatched open caching DNS servers.

Obviously, a router is no match in raw CPU power to a high-end server, so even when running the authoritative server on the router, it might not be a bad idea to use a DNS server of your ISP as the secondary DNS and list only the ISP's DNS server in the NS records for your zone. This would deflect most of the traffic (as nobody would know your router is acting as a DNS server), but I would still apply an inbound access-list allowing only DNS queries from the secondary name server on the Internet-facing interface.

Alternatively, you could protect the router with Control Plane Policing and drop excessive DNS request packets, but that would affect the queries you should respond to as well.

Cisco has released security response acknowledging that the IPS software does not properly handle a rarely used Unicode encoding. Reading the security notice you might be left wondering what's going on. Here's the whole story.

Within an URI (web address), the ASCII characters can be encoded in one of three ways:

• Unless they are reserved, they can be included in the URI directly (for example, you can always use the letter a in an URI).
• You can always escape a character using its hexadecimal value. Letter a can thus be written as %61.
• Unicode character set includes full-width form of ASCII characters, where letter a can be encoded as a two-byte value 0xFF61 (or %ff%61 in an URI)

The IPS software (standalone or integrated in Cisco IOS) does not recognize the sequence %ff%61 as letter a. It's thus possible to evade some IPS triggers by replacing ASCII characters with their full-width Unicode encoding.

The vulnerability by itself does not open new attack routes, unless you use the IPS as the only means of protection of a vulnerable system (which is a bad practice anyway).

One of my readers made an interesting observation when faced with configuring zone-based firewall on Cisco IOS: „My main issue is a confusion between when to use self and when to use in/outside.“

The rules are simple:

• Whenever you filter traffic transiting the router, you control it with a zone-pair specifying an inside and an ouside zone.
• The self zone controls traffic sent to the router itself or originated by the router.
• Unless you specify a zone-pair combining self zone with another zone, all traffic from that zone sent to the router itself is allowed (the router is not protected)
• To control traffic that the router can send into a zone use a zone-pair from self to another zone. Use inspect in the service-policy to allow the return traffic.
• To filter the traffic that the router can accept, use a zone-pair from another zone to self. Only the packets accepted by this zone-pair's service-policy will be accepted by the router.

More information about the self zone (as well as other aspects of zone-based firewall configuration) can be found in my digital book Deploying Zone-Based Firewalls published by Cisco Press.

In his latest Q&A post, Scott Morris mentioned an excellent Cisco article that describes routing tricks needed to implement sinkholes and remote blackholes in great details. Highly recommended reading.

Cisco routers preconfigured for SDM have default username/password cisco/cisco. As many users forget to disable or change the default username after configuring their router with SDM, they could end up with an exposed router.

Cisco has patched this vulnerability in IOS release 12.4(11)T that includes the one-time password/secret option of the username command, allowing you to define a username/password combination that can be used only once.

Cisco IOS long had the ability to define local users that could be used to authenticate incoming telnet sessions or dial-up connections (using PAP or CHAP). Until IOS release 12.3, the passwords assigned to local usernames were encrypted using the weak (type 7) reversible encryption. With crack tools widely available on the Internet, there's obviously almost no protection offered by this encryption type.

With IOS release 12.3, Cisco introduced enhanced password security and the new username user secret password command which uses strong (type 5) encryption, making local user passwords secure. Of course, such usernames cannot be used in scenarios where you need access to cleartext password (for example, CHAP authentication).

I've got an interesting question a while ago: Do new Cisco routers still use CBAC?

Of course they do, it's just been renamed. The marketing department has decided that Context Based Access Control (CBAC) does not sound nearly so nice as the Cisco IOS Firewall. Even the command structure hasn't changed, you still use the ip inspect commands to configure it, unless, of course, you have IOS release 12.4(6)T or newer, where you can use zone-based policy firewall configuration.

This article is part of You've asked for it series.

Recenty, a lot of people were looking for information on the sl_def_acl access list. Here's the whole story: if you've configured IOS login enhancements on your router, the router generates an access list named sl_def_acl (unless you specify your own with the login quiet-mode access-class command) the first time it has to enter the quiet mode. This access-list is then applied to the VTY lines whenever the router enters the quiet mode and removed from the after the quiet period is over. The access list itself is left in the running configuration.

In the security advisory detailing the Crafted IP Option Vulnerability (a nasty bug that allows an intruder to reset your router with a ping packet), the authors forgot to mention a great tool available in IOS release 12.3(4)T (and integrated in 12.4): the ability to filter packets with IP options in an access-list.

In my discussion of per-packet versus per-destination load sharing, I've relied on the "accepted wisdom" that out-of-order TCP packets reduce session performance (as a side note, out-of-order UDP packets are a true performance killer; just try running NFS with out-of-order packets).

Today I've discovered another huge show-stopper: stateful firewalls (read: almost everything in use today) might just drop out-of-order packets, resulting in TCP timeouts and retransmissions (and repeated timeouts will totally wreck the session throughput). Here's how Cisco devices handle this problem:

• PIX allows three out-of-order packets per TCP session (cannot be changed, but should be enough)


• You can configure out-of-order packet handling on ASA with the queue-lenght parameter of a tcp-map
.

• Cisco IOS firewall (formerly known as CBAC) drops out-of-order packets until release 12.4(11)T where you can use the ip inspect tcp reassembly configuration command (and it looks like the zone-based firewall configuration is not yet supported).