• WirelessSecurity

Wireless Security Howto

Abstract: This aims to provide a detailed security howto for wireless networks..

1. Why wireless is an insecure medium inherently (broadcast nature)
   1. "15-mile sniff" example of San Francisco to Berkeley (Peter Shipley example)
      • Peter Shipley conducted a proof of concept of associating with a standard desktop access point over 15 miles away across the SF bay, with a 24 dBi parabolic grid, and a powerful amplifier.
2. Why people should be using these security measures on their wired networks and on the wired internet, and not just the wireless networks.
3. Simple explanation of WEP problems (not the purpose of this text)
   1. Brute Force
      • ~200 days on a laptop for 40bit WEP, and 10^19 years for 104-bit WEP
   2. Using vulnerabilities in the implementation of RC4 in WEP

      • you need to collect a lot of packets to complete this crack. ~6 million to 10 million. For a normal home user this is over 1 month of activity. For a corporate wireless lan this is over a week (unless someone is doing some high traffic activity such as backups across the wireless lan). Using ping flooding to artificially generate more traffic (1 data byte ping packets) you can generate enough traffic in over an hour. This attack can be a completely passive attack. For tools search for AirSnort or WEPCrack on google or freshmeat.

   3. 40-bit WEP becomes 21-bit wep when using generated pass phrases.

      • Tim Newsham's crack on passphrase generate WEP keys. Capture 20 packets, analyze for a couple of minutes, and you have the WEP key. The passphrase generated WEP keys are uses by vendors such as Linksys and DLink. Works on 128/104 and 64/40 bit WEP. (2^{21 vs 2}40 = 2097152 possible combinations vs 1099511627776 possible combinations) http://www.lava.net/~newsham/wlan/

   4. 40-bit WEP becomes less when using ASCII password (~62^{5 vs 2}40 = 916132832 vs 1099511627776)

      • http://www.cranite.com/wireless_card_install.htm for a list of the ASCII to hexadecimal conversion.

   5. Why you wouldn't use WEP in a public network. --AdamShand

      • the security implications of 802.11b are basically not an issue for what we're doing. i'm not sure how much detail you want on it but here's the real basics and feel free to ask for more detail.
      • 802.11b has a protocol called WEP (which stands for wired equivalent privacy). wep was intended to give a wireless connection as much security as a normal wired (like traditional ethernet) connection. so basically you can control who connects, at a physical level, to your network.
      • wep has been widely used by corporations to deploy access points in their corporate networks. this way you could deploy an access point inside your firewall without fear of someone sitting in the parking lot using it.
      • the problem is that wep is an awfully written protocol. technically it has more holes in it then a seive and an hostile attacker can circumvent it on less then an hour with publicly available tools. this really sucks for corporations who have deployed access points in this way because now they have a glaring security problem in the soft insecure part of their network.
      • ... now, why don't i care? because we were never using wep. from a community networking point of view wep is useless, it uses a shared password so anyone who you want to give access to has to know the password, if you now want to revoke access from someone (lets say cause they did something bad on the network) you can do that without changing the password, which means that you break everyone else ... and all your other customers can't connect until they update their software with the new key. as you can imagine this could quickly become a major pain in the ass.
      • so we circumvented wep and wrote software called a captive portal (sometimes also referred to as an active portal). this means that instead of using the security "features" built into the 802.11b protocol we use our own software to control access which gives us much more flexibility and security.

      • if you're curious you can read more about this stuff at: WhyCaptivePortal

4. Other security mechanisms -- AdamShand

   1. SSL & TLS (web, pop, imap, smtp)

      • Use SSL to encrypt your data end to end. This SSL can be used for many applications, including web surfing (HTTPS), receiving email (POP over SSL, and IMAP over SSL), sending email (SMTP over SSL), and tunneling (stunnel).
   2. SSH (replacement for telnet, tunneling, scp)
      • SSH is the secure replacement for telnet, rlogin, etc. It has largely held up to public crytological attacks.
   3. VPNs (PPTP [which has it's own holes], IPSec)

      • Replacing WEP with IPsec: http://rt.fm/~jcs/ipsec_wep.html --EliabHelon

   4. PGP/GPG encryption

   5. NoCatAuth

      • NoCatAuth does not encrypt your data, but provides you with a security mechanism to prevent who passes traffic on your wireless network to your wired network. For more info see http://nocat.net

   6. Which of these are vulnerable to Man in the Middle Attacks
   7. Extrusion Detection Idea

5. Building a wireless network so that everything has to go through a VPN server, only VPN traffic is allowed through. Most secure wireless network design. -- MichaelCodanti Set your AP to bridged mode, and hook it to a computer that is double homed, and has a VPN server running on it. Have a DHCP sever running that passes out non-routable IPs over the wireless network (you could even let an airport or rg-1000 do this) Then setup that computer to only accept your flavor of VPN/IPSec... This can be either a Linux or Win2k box and is fairly easy to setup.. (Win2KServer automatically filters everything when you use the wizard to setup VPN on a computer..) Once you have done that you just have to setup a VPN icon on the client machines and either make them log on each time, or you can set it up to automatically connect... Once you've done that you should be as secure as you can get right now... (As far as I know)

6. Considerations of a home network versus a corporate network
7. Where to wire your access points into your existing network
   1. Not behind your firewall
   2. Not on your DMZ ??--??
   3. Possible before your firewall
   4. Correctly as a separate network segment that is firewalled from the internet and firewalled from your internal network.

-- TerrySchmidt

External Links

Free whitepapers, case studies, and current reports on Wireless Security

[CategoryDocumentation]