Created on Thursday, 05 May 2005 16:26
Recent Trends in Security
This month I gave the keynote talk on security at a Cisco / TechData SMB Conference in New York City on 4/27/2005, on somewhat short notice. So my thoughts have been on security lately. This article is based on the information gathered for that presentation. The presentation in PDF form can be found at Security Trends from a SMB Perspective
. See the seminar for the ideas, material, and links that didn't fit smoothly into this article.
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
Thinking about the SMB (Small-to-Medium Business) aspect of my presentation lead me to something I haven't seen a lot in print. The word is out that IDSs can be labor-intense. I conclude that only medium to large organizations really can afford the staff to support that. Does that imply that SMB should be considering a managed IDS or IPS service? Where the provider can supply the economies of scale, as far as maintaining IDS rulesets, filtering false alarms, and other automation?
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.
One mini-theme is that worm attacks are down, virus up. This appears to be due to more use of firewalls, XP SP2, etc. The rate of new virus appearance is also increasing. My personal take is that spyware is up, but there's a dearth of hard data at present due to the lack of market maturity and established large market-share vendors. (Who do you think are the leading anti-spyware vendors?) One possible propagation vector: I've been seeing all too much spam lately that looks like bait to get me to click on something on a web site. Does greed cause people to install software without thinking?
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.
Information confidentiality is the other gap. Bank of America and several others reported backup tapes containing credit card or other private information that were missing, apparently lost in shipping. A recent development was tapes missing from an offsite storage provider, apparently now under investigation. Leaving such confidential information sitting around unencrypted seems like a rather good way to get sued. So this is definitely an area to keep an eye on.
External Security Threats
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.
Earlier I mentioned guests and contractors in conjunction with 802.1x, NAC, and controlling ports and network access. However, note that in general you cannot go around requiring your guests and contractors to patch. You especially cannot do remediation for them at connection time, since their laptop may be set up without admin privileges, you don't want to have to support it afterwards, and so on. The answer to me seems to be dynamic per-user-group VLANs, tied to good authentication. The general thought here is "if you can't completely trust their laptops, isolate them with a firewall or access lists in between". With 802.1x tied to dynamic VLANs, guests and contractors get in, but you can tightly control what passes between them and the internal network.
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.
I've covered this topic rather thoroughly in print recently, so let's start with the URL's.
In terms of action items for your network:
- 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
Concerning WEP being highly vulnerable, see the first of the above articles. It has many links to references on the topic.
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.
If you've just bet your company or organization on IP phones, you're very aware that network problems can now cut off the phones.
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
The first two topics seem to be often overlooked. For example, I'm working with some folks now who have a good design (it better be, we did it for them), and a good set of practices and network management tools. The tools have really helped with some performance problems during deployment of new Call Center caller ID-based customer record retrieval tools. But that's another whole article in itself.
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!
In general, I see Preventing Surprises as another part of security. To me, this topic blurs into stable, high-availability networking. I also like:
- 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.
The latter is an example of one way to experience a self-inflicted Denial of Service. That's something you may see if somebody in the desktop staff does a transfer of the current 20 GB PC build image to a server via the Gig port on their PC. Gigabit trunks between switches or sites look pretty good, until you encounter one person using 80% of that! That's really QoS rather than Security -- but your network is just as unusable as if a worm storm were consuming your bandwidth.
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...
Here are some other links you may find useful:
The Cisco ISP document is a bit dated, but has good ideas we all can use.
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!
I appreciate all the input from my friends and peers, without whom I'd have been scratching my head a lot longer. As always, any errors are mine! Thanks to Netcraftsmen's Joe Roundy, and to Grant Moerschel and Rick Dreger at WaveGard, http://www.wavegard.com/
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).
Copyright (C) 2005 Peter J. Welcher