Category: Security

Reading an interestingly-titled article on InformIT, I’ve stumbled across the following text:

The survival time is an estimate of how long an un-patched computer will remain uncompromised once it’s connected to the Internet. While the actual time varies, historically it tends to run between 4 and 20 minutes.

This is such an obvious nonsense that I had to check the source, which is also full of alarming messages, but admits at the end that the problems described largely disappeared with XP SP2. Just to put things in perspective: XP SP2 was released in August 2004 and the graph in the alarming blog post displays data from 2008.

Based on the title, I would assume that the Cisco Press book Voice over IP Security: Security best practices derived from deep analysis of the latest VoIP network threats attracts primarily senior voice engineers who know that they have to secure their production networks. The author of the book strongly disagrees with my opinion, however, spending more than a third of the book on baseline explanations of VoIP, SIP, H.323, firewalls, NAT, DES, IPSec…. I enjoyed the overview chapters, as I last configured VoIP before SIP was invented, but an experienced VoIP engineer would be disappointed.

The Network World recently published a story describing the results of an independent security product testing lab, where they’ve discovered (surprise, surprise) that adding security features to Cisco routers “presents a tremendous bottleneck” and “can turn a 60G router into a 5G one or even a 100M bit/sec device”.

The test results haven’t been published yet; I’ve got all the quotes from the NW story, so they might be the result of an ambitious middleware.

We don’t need “independent experts” for that. Anyone who has ever configured VPNs in a high-speed environment can tell you how to kill the performance. The basics are always the same: make sure the dedicated silicon can’t handle the job, so the packets have to be passed to the CPU. Here are a few ideas:

When I chose the word “unfortunately” in my post describing how Cisco IOS performs DNS lookup when you enter a host name in an access list, I’ve triggered several responses that disagreed with my choice of words. Here’s why I still think IOS ACL could be improved with dynamic DNS lookup:

When I was configuring the access list that should prevent spammers from misusing my workstations, I obviously had to figure out the IP address of the ISP’s SMTP server (access lists and object groups accept IP addresses). I almost started nslookup on my Linux workstation, but then decided to try entering a hostname in an IOS ACL … and it works. Unfortunately, IOS performs a DNS lookup when you enter the hostname (assuming you have configured the ip name-server) and stores the resulting IP address in the ACL definition:

I always thought that there was no need to restrict outbound sessions across a firewall in low-security environments. My last encounter with malware has taught me otherwise; sometimes we need to protect the rest of the Internet from our clumsiness. OK, so I decided to install an inbound access-list on the inside interface of my SOHO router that will block all SMTP traffic not sent to a well-known SMTP server (and let the ISP’s SMTP server deal with relay issues).

Reading the stories of Windows workstations becoming members of a spam botnet becomes way less enjoyable when you’re faced with the same problem (one of my kids managed to install a Trojan). It took me a day to clean the infected computer (it would have been easier to just format it, but the repeated installation of the Windows XP + Office software is so boring), but I’ve learned a few interesting networking lessons in the process that I’ll document in the next days.

I was very anxious to get my copy of Cisco Secure Firewall Services Module (FWSM) from Cisco Press, as I’m a purely router-focused person, and I wanted to understand the capabilities of the Firewall Services Module (PIX/ASA-like blade for the Catalyst 6500 switching system with virtual firewall capability). I have a good background in IOS-based firewalls and network address translation (NAT), so the book was a perfect fit for me. However, if you’re looking for “best practices for securing networks with FWSM,” you’ve been misled by the subtitle.

One of my kids managed to get infected with a particularly sneaky Facebook Trojan: a link from a friend (probably also infected) pointed to a web page with a video that required installation of a newer version of the Flash player … which was actually the first part of the Trojan. It quickly downloaded a few more components and made itself cozy deep within Windows XP.

Before you start telling me that kids would click anything … we had “a few” not so very pleasant discussion after previous infections and they know not to open anything or click on something that looks strange. Unfortunately the update-happy industry has conditioned them to constant prompts to upgrade one or another component and the request to upgrade the Flash player was obviously too legitimate-looking.

Once upon a time, AAA command authorization in Cisco IOS queried the TACACS+ server for every single command a user entered. Rules have changed drastically in the meantime (at least for IOS release 12.4):

• Non-privileged show commands are executed without TACACS+ authorization. Privileged show commands (show running or show archive log config) are still authorized.
• Some commands that can be executed in non-privileged (aka disable) mode (enable, disable, help, logout) are authorized only if you configure aaa authorization commands 0 methods regardless of the current privilege level.
• Other commands (for example, ping) are authorized based on the current privilege level.

For example, if you’ve configured AAA command authorization only for privilege level 15, the ping command will be authorized if you’re working in enable mode, but not otherwise.

• Command authorization is not performed on console unless you’ve configured aaa authorization console.