Category: security

The inability of Control Plane host interface to detect inbound OSPF packets has prompted Sebastian and myself to search for more documentation and conduct further tests. Sebastian already had a working configuration from which he could infer most of the configuration rules and he also found the well-written Understanding CPPr document on CCO. Together with the tests I ran in my router lab, we're pretty confident the CPPr inbound packet classification rules are (approximately) as follows:

Use the latest 12.4T software (at least 12.4(15)T5) if you want reliable CPPr operation.

• control-plane aggregate service-policy disables any control-plane subinterface service policies.
• If you want to use the per-subinterface (host, transit and cef-exception) policies, you have to remove the inbound service policy from the control-plane aggregate path.
• Routed packets that cannot be CEF-switched (have to be punted to another switching mechanism) are classified as transit packets.
• Local multicast packets with destination IP addresses within IP prefix 224.0.0.0/24 and packets with TTL <= 1 are classified as transit packets in 12.4(15)T5. These packets will be classified as cef-exception packets in the future (see the Understanding CPPr document).
• Unicast packets without IP options addressed to the router and having TTL > 1 are classified as host packets.
• Non-IP traffic (ARP, Frame Relay keepalives, CDP ...) is classified as cef-exception.

The TTL-related rules explain why the router classifies IBGP packets as host packets and EBGP packets as transit packets. As soon as you configure neighbor ebgp-multihop on the router router, inbound EBGP packets become host packets.

Euphrates Greene sent me a report of a very annoying “functionality” of Cisco 851/871: they're bridging between the inside (LAN) ethernet and outside (WAN) ethernet interfaces while they're running the ROMMON code (from the reload/power-up throughout the software decompression process until the control is transferred to the Cisco IOS). It's worth mentioning that these routers are commonly used as SOHO firewalls and that the internal LAN is exposed while the router is in the bridging mode.

Our security experts have replicated the behavior and reported it to Cisco PSIRT. Fortunately it's a known vulnerability, documented as CSCsd60259 (release note is available on CCO to registered users) and fixed with a ROMMON upgrade.

New routers are shipped with new ROMMON version, so you shouldn't be seeing this behavior on brand new boxes … but one cannot help but wonder why such a nasty behavior was not documented as a field notice/security advisory.

One of the comments to my Sunday post mentioned RTBH. Obviously I'm not geeky enough, as I had to ask uncle Google for help (but don't worry, I'll work on my geekiness factor :).

The search results produced a few very interesting links, among them a well-structured presentation on RTBH that refers to a paper describing how you can detect remote DoS attacks with the backscatter analysis (assuming the attackers are randomly spoofing source IP addresses).

The information on the IOS XE software used by the recently launched ASR 1000 router is pretty scarce (there is still no link to the documentation available on CCO), but obviously some backdoor links already exist, as I was able to find some IOS XE-related documents with Google. One of the most amazing features I've found is the support for the security-oriented RFC 3514 which allows you to mark the security level of an IP packet.

The RFC 3514 requires the end host to participate in the process, but as most operating system vendors still don't have a trusted computing platform, a transparent proxy has to be implemented on the network edges to properly tag the ingress packets. ASR 1000 has the first high-speed implementation of the RFC 3514 proxy thanks to its non-deterministic parallel QuantumFlow processors.

The configuration of the RFC 3514 proxy is extremely simple: all you need to do is to configure auto-secure mark on the ingress interfaces of the ASR 1000. Once the security bit has been set, you can use the match ip security-bit 0|1 command in a class-map or a route-map on any router running IOS release 12.4(11)T or later (the command is still hidden).

Andy Davis from the Information Risk Management has written an interesting "application note": how to create a backdoor to Cisco IOS using Tclsh (I've tested it and it works quite nicely). His backdoor implementation relies on a bug in Cisco IOS that allows a "hung" (or never-ending) Tclsh script to continue executing even after the user session has been disconnected (the only means of stopping such a script is with the clear line command). That bug has been fixed in recent IOS versions (I've tested that as well, the Tclsh script is killed as soon as the Telnet session is disconnected in IOS 12.4(15)T), but you can still use the same technique (although it might be a bit less convenient) if you convert the Tclsh script into an EEM policy and trigger it periodically with a timer event.

One of my readers asked a very interesting question:

“Is there a way to have a port on a router open for legitimate use while closed to port scanning software and the such. For example. I have SSL VPN configured on my IOS router. Is it possible to have the port seem stealthed to port scanners while still allowing legitimate access to the service? An example being, allowing a web browser to connect using the port but making sure that a port scanner doesn't detect it as open.”

The short answer is no, unless you can differentiate legitimate users by their IP addresses. The port scanners (when using SYN scan) simply open and close a TCP session, and there is no way for a router to differentiate between the legitimate users (who would send valid HTTP GET requests) and port scanners (that would close the session as soon as it's established).

If you can distinguish between legitimate users and everyone else based on their IP address, the task becomes simpler: either you apply inbound access list on Internet-facing interface of the router or configure per-service access-list (for example, ip http access-class acl). When using the inbound access-list, the port appears filtered or stealth, when configuring per-service access-class, it's reported as closed.

I've stumbled across a blog post that indicates there's still confusion on some fundamental configuration issues. I will not even try to guess whether there is a wide consensus on how to configure a router, but these are the facts (and here is a ten year old position from Cisco):

• Type-7 encryption used in enable password has been broken. Source code for the decrypt program and cracker programs are available online, or you could use a router to do it for you.
• The type-7 encryption is reversible (and easily breakable due to a weak algorithm), whereas type-5 encryption is a one-way encryption that probably requires a dictionary attack to break.
• Based on the previous two facts, you should never use enable password. Use enable secret.
• The service password-encryption encodes passwords attached to local usernames with type-7 encryption. The usage of type-7 encryption is necessary as you might need the cleartext passwords in some authentication mechanisms (for example, CHAP). However, it's still better to have scrambled passwords than cleartext ones; at least a casual observer will not be able to read them. Conclusion: use service password-encryption.
• If your authentication methods don't need cleartext passwords (examples: local username/password authentication, local AAA authentication or PAP authentication), use username secret configuration command (available from IOS releases 12.2T, 12.3 and 12.0S).

Tim Riegert sent me an interesting hint: you don't need password crackers to decode type-7 passwords, you just need access to a router. Here's how you do it:

Joe Harris published an excellent post detailing how you can use Flexible Packet Matching to recognize (and potentially block) Skype traffic. The solution depends on recognizing the first four bytes sent by the Skype application in a TCP session. While this is a great idea, you have to be aware that there's always a non-zero chance of false positives, more so as the described filter is testing the beginning of the payload in every TCP packet (not just the first data packet in the session).

The IP-over-IP (usually GRE) tunnels (commonly in combination with IPSec to provide security) are frequently used when you want to transport private IP traffic over public IP network that does not support layer 3 VPNs. If you use the GRE tunnels in combination with default routing (or route summarization), you can get serious routing issues when the tunnel destination disappears, but a default (or summary) route in the IP routing table still covers it. You could work around this issue by deploying a routing protocol over the GRE tunnel (which could lead to hard to diagnose routing loops if you're not careful) or by using GRE keepalives introduced in IOS release 12.2(8)T.

The implementation of the GRE keepalives is amazing: the router sending the keepalive packet constructs a GRE packet that would be sent from the remote end back to itself (effectively building a GRE reply), sets the GRE protocol type to zero (to indicate the keepalive packet) and sends the whole packet through the tunnel (effectively encapsulating GRE reply into another GRE envelope). The receiving router strips the GRE envelope and routes the inside packet … which is the properly formatted GRE keepalive reply.

This trick allows you to implement different GRE keepalive timers on each end of the link. For example, the remote site might use fast keepalive timers to detect loss of primary link and switch over to a backup link, while the central site would use less frequent keepalive tests to detect failed remote site (if there is a single path to the remote site, you don't care too much when you detect it's down).

Every ingenious solution has its drawbacks and this one is no exception: if the receiving router protects its IP addresses (to stop spoofing attacks), it will drop the incoming GRE keepalive packet. Furthermore, a document available on Cisco's web describes the issues of using GRE keepalives in IPSec environment.

A few days ago, Jeremy Stretch asked me whether there's a command to display packet lists attached to router's interfaces. While he got pretty far with the output filters, he would like to have a nice tabular format as well as the contents of the access lists displayed next to the interfaces. The show ip access-list interface name command comes pretty close, but it displays the information only for a single interface, so it was time to write another Tcl script. To install it on your router:

1. Download it from my web site and copy it to your router's flash or NVRAM.
2. Define an alias, for example alias exec filters tclsh flash:packetFilters.tcl.

The script recognizes two parameters: the all parameter displays all interfaces, including ones with no access lists and the verbose parameter displays the contents of the access list after the interface name.

When developing yet another Tcl script, I've stumbed across an interesting show command: the show ip access-list interface name introduced in IOS release 12.4(6)T displays the contents of the inbound and outbound IP access-list applied to the specified interface. The really nice part is that the ACL statistics (number of matches displayed next to the ACL lines) are kept and displayed per-interface.

After I've published a post on how you can use the new router-traffic keyword to minimize the Internet-facing access list you use with CBAC, Euphrates Greene pointed out to me that this feature does not work for client DHCP traffic (if the router is acting as a DHCP client, for example, when connected to a MAN Ethernet environment).

Once you start thinking about what's really going on, it all becomes obvious: as the router has no IP address when it sends the DHCP request, and it sends the DHCP request to a broadcast address (as it doesn't know the IP address of the upstream DHCP server), there is no session that could be entered into the CBAC session table. So you still have to allow all DHCP traffic to your router with an access-list similar to this one:

ip access-list extended Internet
 permit udp any eq bootps any eq bootpc
 deny ip any any

Note: Replace the highlighted any keyword with the actual DHCP server's IP adress if you have it available and you want to have an even more secure IP access-list.

In response to the post detailing router response to port scans, one of my readers asked an interesting question:

“I was wondering if there was a way to prevent the router from sending those TCP RST packets administratively prohibited ICMP messages back to scanners for TCP and UDP respectively. I basically want my router to drop all packets period without replying back in any way, shape, form, or fashion.”

Here's how you do it:

In my previous post, I've described how you can get a very clean configuration with no holes in your Internet-facing access-list if you have IOS release that supports inspection of router-generated traffic. As it turns out, my solution was not complete - you could not ping from the router. On top of inspecting UDP and TCP traffic (as is usually done), you also have to inspect ICMP traffic that the router uses for pings.

Furthermore, if you use any protocols that have separate control and data sessions (for example, FTP, H.323 or SIP), you have to list them before tcp or udp keywords, otherwise their control streams will not be inspected and there will be no provision for data sessions.

ip inspect name Internet ftp
ip inspect name Internet h.323 router-traffic
ip inspect name Internet sip router-traffic
ip inspect name Internet tcp router-traffic
ip inspect name Internet udp router-traffic
ip inspect name Internet icmp router-traffic
!
interface FastEthernet0/0
 ip access-group Internet in
 ip inspect Internet out
!
ip access-list extended Internet
 deny ip any any