|Intro|  |News|  |Threats|  |Alerts|  |Papers|  |Events|  |Reading|  |Links|  |About Me|  |Powered-by...|
I fi, you fi, we all fly to WiFi
[Back to Main]

Well it looks like 802.11 is finally catching on, to the relief of early vocal proponents, and the chagrin of naysayers everywhere (and perhaps many security directors, as well).  Not only is it being rolled out in offices, popular coffee shops, airport terminals, hotels, and convention centers, but also fast food joints, of all places and even private residences.  In fact, home consumers may be the most eager of all groups to implement wireless networks, although I'm not quite sure why...

No matter, it's here and we have to deal with it.  As I showed in the Sniffing threat, there's a very real security problem posed to e-mail by wireless networks and the fact that they flow freely through the air for anyone to pick up.  In the Sniffing section I also outlined several ways to encrypt e-mail traffic so that It cannot be sniffed, but there are more problems with WiFi than just sniffing.

The well publicized problem of War Driving doesn't only present a problem to the owners of databases, file servers, and other squishy internals of your corporate network, it provides an avenue for spam, too (doesn't everything?)!  Consider the following:  you're funneling all internal SMTP traffic through a handful of servers in order to consolidate control over the sources of relaying to the Internet (a good thing), but in order to make this consolidation smoother you just allowed all internal networks to use your SMTP relays to send mail.  Also, not only do those relays have the ability to send mail to the Internet, but they can send mail to your groupware server without going through your spam filter.  See where I'm going with this?

Drive by spammings are a very real threat, and the threat is only going to get more practical and more available as more organizations roll out wireless access.  Already in very built-up and WiFi-saturated areas such as New York City, San Francisco, and Silicon Valley it's very feasible for a spammer to drive around in a vehicle and hit several large sites in a few hours or less.  This type of spamming can have a very high penetration rate due to the probable lack of filtering on servers accessed via this method (while nearly all of those sites do have a commercial-grade solution protecting their Internet-facing SMTP MX hosts).  To make matters worse, this method of spamming may not be illegal.  War Driving is not illegal, and if you don't have any anti-spam protection on the servers that are abused, the spammer (if caught) may be able to argue that you were allowing all mail sent through that segment.

Finally, forgetting the inboxes of your own users, what if your network is used to relay spam out to other sites?  Your business partners or customers very well may have whitelisted your servers through their own anti-spam solutions.  You may be a very reputable company that is on many whitelists, or is the beneficiary of a favorable ranking in a collaborative filtering community.  What will it do to your reputation if millions of spam messages start spewing out of your network (even using your domain name)?  Even clever solutions like SPF (see the Social Engineering section) will not stop this type of spam, since it actually is coming from you, by all indications.

Clearly, this is a job for a technical solution.  First, from the e-mail administrator's perspective, you should absolutely not allow IPs on wireless segments to open SMTP connections, unless authenticated.  If you have employees that send mail over a local wireless connection, require them to use some form of authentication, either POP-before-send, or SMTP AUTH.  If you use SMTP AUTH, it should be something other than AUTH PLAIN or AUTH LOGIN, since those are sent in the clear or weakly encoded.  Also, as discussed in the Sniffing section, all such connections should be encrypted.  For Open Source solutions, investigate SASL/SASL2.  Microsoft has NTLM available for e-mail authentication.

After doing what you can from the messaging side, inquire from the security and networking teams what they're doing to lock down WiFi segments.  At the very least they should employ SSID "cloaking", MAC address restrictions, and some type of strong authentication.  It's also a very good practice to implement wireless networks in a DMZ environment, with a firewall blocking all unnecessary traffic coming out of that DMZ.  Only services that are expressly necessary for wireless workers should be available through that firewall, everything else should be kept out of your internal networks.




This site © copyright 2003-2011 Brian Keefer.  Unauthorized republication is forbidden.