Introduction

Disclaimer: I don't claim to be a full-time security expert. (Does that make me a part-time know-it-all?) I spend too much time doing other things to stay 100% current on things. Nonetheless, I try to keep tabs on what's happening in the field, since it impacts so heavily on everything we do.

New Factors on the Security Scene

I also see that SMB and college/university shops tend to use automated OS tools, especially patch and anti-viral tools. That's more of a challenge for larger enterprises which have diversity of user base application needs. Patching mobile users is still a concern. The Cisco Perfigo acquisition may be due to that customer need. Cisco NAC or the alternatives are a longer-term answer to the mobile user patching issue?

Also mildly new: Sarbanes-Oxley (Sox) and HIPAA, and the "how much is enough" debate. That's a topic I'll leave for another article. Ditto, tools for protecting against inappropriate employee behavior, compliance tools, etc. They are out there, but are there leading contenders?

As a guest and/or contractor when consulting, I've noticed an increase in the number of shops telling me to not connect, or blocking my outbound SSH tunnels (for POP3 and SMTP email). On the other hand, I'm still not seeing a lot of port security (wired 802.1x). We definitely have done some 802.1x work for our customers, there seems to be gradually increasing interest in 802.1x, and Cisco NAC developments are being watched closely and tested in some instances. In a perfect world, I'd like to see automated control over switch ports, with amenities for guests and contractors. It appears we're getting there, slowly.

Subtle phishing using "homograph spoofing". The irony of this is it affected Mozilla and Firefox but not Internet Explorer.  The point to this is that the links href='http://www.theshmoоgroup.com/' and href='http://www.theshmoogroup.com/' are subtly different. They look alike in the browser, but are different as far as DNS is concerned. It helps that more careful scrutiny is being given to these by the various Internet Root Certificate Authorities.

There was recently an outbreak of .RAR virii. They exploited the fact that the default settings on some if not all major anti-virus scanning software doesn't scan that particular obscure type of archive file.

Cell phone virii and IM worms and virii -- need I say more?

DNS cache poisoning is also occuring. Overall, it seems like more secure DNS is to be desired. The good news: the effects seem to be mostly confined to older and unpatched DNS versions.

External Security Threats

Bo ets are the growing external threat. They seem to be evolving from hacker credentials validation to a monetary, even extortion, focus. There are an estimated 1 million or more hijacked computers on the Internet waiting to be used. They can be organized into groups of slave machines. Researchers found one Botnet of 50,000 machines. If these all hit your web server (etc.) at one time, the results can get ugly.

For that matter, you might also want to have an Acceptable Use Policy for guests and contractors. The last thing you need is a contractor or guest doing reprehensible things to the outside using a connection to your network.  What if they're from Company A, they connect to you as a guest at Company B, and try to hack into Company C? Do you have legal liability? Only your own lawyers can tell you what the proper policy is in regards to this. Part of this probably depends on how big a potential lawsuit target your company is.

Wireless Security

• Replace WEP with solid authentication (802.1x / *EAP) and encryption (WPA or WPA2 / AES)
• Detect (and disable?) rogue WAPs
• Protect yourself against dictionary attack (e.g. with Cisco LEAP) with well-chosen passwords
• Understand how WLAN security, authentication, and design all interact -- see above design articles
• Use different VLANs (and/or SSID's) to contain different user communities
• Use personal firewall software on each wireless PC
• Disable PC ad hoc mode unless there's a real need for it
• Distance is no guarantee: consider Cantenna and other ways crackers can remotely access your WLAN

802.11 wireless is vulnerable to Denial of Service and Man In the Middle attacks. There's code out there to make a PC act like a WAP. If you can do that, you can easily pretend to be a legit WAP and send disassociation frames. The IEEE is now working on a standard for encrypting wireless management frames. See the article at  http://www.wirelessweek.com/index.asp?layout=document&doc_id=1340004284. You might also find the proof-of-concept "WiFi Attack Droid" at http://www.engadget.com/entry/7166397862995041/ somewhat less than re-assuring!

Security for other forms of wireless also need to be considered. There's increasing use of 3rd Generation (3G, etc.) cell phone technology for data, including telemetry use, e.g. for SCADA. How good is cell phone authentication and encryption. One suspects the answer is: not very. One might think about using IPsec, although the overhead would be a bit unpleasant.

Do you use BlueTooth? It doesn't have  much security, wasn't intended for that. But it can expose PC file shares. See also Red Fang, http://www.silicon.com/networks/mobile/0,39024665,10005623,00.htm.

VoIP Security

This leads me to three conclusions:

• It's worth effort to protect the voice traffic (robust network, design Best Practices, tested QoS policy, etc.)
• It's worth investment in net management tools to reduce Mean Time To Repair (MTTR)
• The phone handsets and in particular the IP PBX should be protected and secured

Concerning VoIP Security, I'm a big fan of using Cisco AUX VLAN's, whether doing Cisco, Nortel, or Avaya phones. The Nortel phones listen to DHCP attributes and shift to the designated VLAN. You can then give them addresses out of a distinct address space. This makes access lists (ACLs) for QoS and Security much, much simpler. (See Clever Addressing Schemes, http://www.netcraftsmen.net/welcher/papers/addressing.html).

Concerning VoIP Security, what you can start with is protecting the IP PBX's. Only allow the appropriate ports through a firewall to the PBX server(s). Use OS hardening techniques on the server. Consider using something like Cisco CSA to harden the server as well. Unfortunately, vendor certification of OS patches hinders the commonly advice to "stay current on OS patches".

Once you've done that, you can consider protecting the phones. After all, high volumes of broadcast, multicast, or traffic to IPT UDP ports might constitute Denial of Service. Any UDP RTP traffic that gets classfied as VoIP for QoS purposes will cut into your configured priority bandwidth pool, possibly degrading service. That's why I prefer to classify UDP RTP traffic based on source and destination addresses in AUX VLAN subnets, to distinguish that RTP traffic from streaming web audio or video.

Softphones seem to me to mess this approach up. The source and destination address might be that of any PC, so they doesn't do you much good. Cisco IP phones and Softphones use a wide range of UDP ports, which also makes tightly controlled QoS and Security harder. Nortel IP phones use a very small set of ports, which I like a lot better. 

The issue here is telling "VoIP RTP" from "other RTP" without having source / destination addresses to help out. If you think you have a good way to deal with QoS and Security Softphones, please email me and tell me about it!

Preventing Surprises

• source address validation and anti-spoofing
• destination-based sinkhole router with logging
• screening router acting in tandem with firewall with DoS filtering
  
• routing controls and perhaps routing authentication
• distribute lists tightly controlling any external dynamic routing exchanges
  
• tight controls over IP multicast
• tight controls on Video on Demand.

Ok, so I'm a real fan of QoS. What else? Well, I've been touting L2 Security measures for a couple of years, but still don't see them getting used a lot. The Cisco DHCP inspection and ARP snooping (or is it the other way around?) features can help. See my article, Troubleshooting Poor Performance, and Dsniff Woes, at http://www.netcraftsmen.net/welcher/papers/perf-dsniff.html for why I keep pushing L2 security measures. The following figure shows the basics of how Dsniff and Ettercap work.

Other related links:

I'm also a big believer in designed-in security, with network design contributing to defense in depth.  After-the-fact retrofits don't work as well, and are often very painful to maintain. There are some common symptoms of security afterthoughts that I prefer to avoid, although sometimes folks don't get much choice about them:

Proliferation of firewalls at one campus Random termination locations for WAN and partner links (usual cause for firewall proliferation) Random server addressing (next available number in one server subnet?) Mass opening of new ports through the firewall on application team demand (admittedly, time is always too short to investigate fully, and the developers never document all the ports)

Consider instead having well-defined Internet, partner firewall modules. Consider per-partner NAT rather than importing many routes. Consider putting different kinds of servers into different subnets, or summarizable blocks of addresses within one subnet. About the ports, I have no easy answer. Logging of denied traffic to catch ports the developer forgot to mention?

Wrapping It Up...

I included the Unisog and Resnet lists because I've been skimming them for a while. They tend to be a bit chatty, but colleges and universities have problems and situations enterprises wouldn't begin to imagine, and tend to gain a lot of hard-won security experience. Good lists to learn from!

Summary

Your comments, questions, and suggestions for future articles are of course welcome! See below to decipher my email address.

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014, CCIP) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has ten CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, IPSec VPN, wireless LAN and bridging,  network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw <at> netcraftsmen <dot> net (formatted this way to fool email harvesting software).

5/5/2005
Copyright (C)  2005  Peter J. Welcher