While many paranoid system administrators and users still consider any WLAN to be a gaping hole, these networks can be successfully secured against snooping and unauthorized access with a little thought and effort. Fortunately for us, Linux provides some flexibility when it comes to choosing a wireless safeguard. While it's the ultimate wireless attacker's platform, it's also the optimal system to rely on when deploying a hardened WLAN. This is not surprising if you consider that network attack and defense are two sides of the same coin.
This article describes the security issues facing the modern 802.11 networks and the solutions available to mitigate these problems using the Linux platform.
Second, the equipment supporting the recently adopted 802.11i wireless security standard practically implemented by the Wireless Protected Access (WPA) Industry Certification still suffers from vendor interoperability problems, despite WPA version 1 being a part of the Wi-Fi Certification now. This presents a serious challenge for multivendor wireless networks, such as public hot spots relying on users bringing their own cards. Finally, the 802.11i wireless security standard is actually more like a set of standards, and some of these standards have well-known weaknesses, e.g., lack of mutual authentication in EAP-MD5. Besides, even when the standard design is solid, there are always bad implementations that nullify the advantages it presents.
Hotspotter allows successful man-in-the-middle attacks against unpatched Windows boxes, exploiting a flaw in Windows Profiles. Even the WPA-protected networks are vulnerable.
Aircrack optimizes cracking WEP, achieving a much higher efficiency than AirSnort, used casually for this task, and implements WEP'ed packets reinjection to accelerate WEP cracking in a way that's similar to OpenBSD Wnet's reinj tool. WEPPlus, a proprietary Proxim's solution to the FMS attack against WEP now replaced by TKIP in WPA-certified Proxim/Orinoco products, is also vulnerable to aircrack's novel statistical attack. Wep_labs is another optimized WEP cracking tool and its latest version, posted to Packetstorm two days before this article was written, has been successfully ported to MS Windows. This puts the last nail into the coffin of WEP. Those still relying on it as the main WLAN defense measure should immediately switch to TKIP or higher-layer defenses. WEP cracking is now as easy as it gets, and even a Netstumbler kiddie with XP Home Edition has a reasonable chance of getting your key.
However, WPA version 1 is also not without security problems. We have mentioned the lack of mutual authentication with EAP-MD5, the first EAP type to be employed by 802.1x that is still widely in use, since any 802.1x implementation would most likely support it. Setting up HostAP plus accepting any authentication credentials on a Linux host and forcing the clients to associate with such a rogue AP is dead easy. Cisco EAP-LEAP is also flawed or, better to say, the MS-CHAP it uses is. The attack against EAP-LEAP (implemented by Asleap-imp) was first unleashed by Joshua Wright at Defcon 11. Since then more tools that use it, such as THC-Leapcrack, were released. TKIP is vulnerable to offline dictionary attacks, at least in the SOHO preshared key (PSK) mode. A research paper describing these attacks in detail is available at http://wifinetnews.com/archives/002452.html. There is also a lot of hype regarding the use of the WPA version 1 hash message authentication code (HMAC) implementation as a vector for DoS attacks. However, launching such attacks in practical terms has been far from easy and we have never encountered them in the real world. Please refer to Table 1 for a comparison of various wireless encryption schemes.
ssid=Arhont-x
macaddr_acl=1
accept_mac_file=/etc/hostapd.accept
deny_mac_file=/etc/hostapd.deny
ieee8021x=1
wep_key_len_broadcast=13
wep_key_len_unicast=13
wep_rekey_period=900
own_ip_addr=192.168.111.22
nas_identifier=hostap.arhont.com
auth_server_addr=192.168.111.101
auth_server_port=1812
auth_server_shared_secret=Very-Secret_KEY
acct_server_addr=192.168.111.101
acct_server_port=1813
acct_server_shared_secret=Very-Secret_KEY
Adjust the following settings of your specific network setup: ssid, own_ip_addr, nas_identifier, auth_server_addr, auth_server_shared_ secret, acct_server_addr, and acct_server_shared_secret. The next step is to create /etc/hostapd.accept and /etc/hostapd.deny files, which will have a list of MAC addresses of wireless cards that are allowed to connect to your AP. Once the configuration files are ready, launch hostapd in the following manner:
hostapd /etc/hostapd.conf
where /etc/hostapd.conf is the location of the hostapd configuration file. Don't forget that you'll also need a working RADIUS server. The FreeRADIUS server is an excellent open source solution. You can download it from www.freeradius.org. Check out the freeradius mailing list and FAQ if you have any difficulties with the RADIUS implementation.
ssid=Arhont-X
macaddr_acl=1
accept_mac_file=/etc/hostapd.accept
deny_mac_file=/etc/hostapd.deny
auth_algs=1
own_ip_addr=192.168.111.22
wpa=1
wpa_passphrase=secret-password-blah
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP CCMP
As with the previous example, adjust the settings to represent your network requirements. Unlike 802.1x and WPA Enterprise authentication means, with WPA-PSK there is no need to specify RADIUS server details. Once the configuration files are ready to be deployed, run hostapd the same way you would with the 802.1x setup.
Congratulations, you now have a working hostapd with WPA-PSK support. However, don't forget to select a very strong PSK, taking into account its vulnerability to bruteforcing.
ssid=Arhont-x
macaddr_acl=1
accept_mac_file=/etc/hostapd.accept
deny_mac_file=/etc/hostapd.deny
ieee8021x=1
own_ip_addr=192.168.111.22
nas_identifier=hostap.arhont.com
auth_server_addr=192.168.111.101
auth_server_port=1812
auth_server_shared_secret=Very-Secret_KEY
acct_server_addr=192.168.111.101
acct_server_port=1813
acct_server_shared_secret=Very-Secret_KEY
wpa=1
wpa_key_mgmt=WPA-EAP
wpa_pairwise=TKIP CCMP
wpa_group_rekey=300
wpa_gmk_rekey=6400
As with dynamic WEP using 802.1x, WPA-EAP requires the use of a RADIUS server to authenticate mobile users. Once the hostapd is restarted, to take effect of the modified hostapd.conf file you should have a perfectly working Linux AP with WPA-EAP authentication means.
network={
ssid="Arhont-w"
proto=WPA
key_mgmt=WPA-EAP
pairwise=CCMP TKIP
group=CCMP TKIP
eap=TLS
identity="client_name@domain"
ca_cert="/etc/ssl/certs/cacert.pem"
client_cert="/etc/ssl/certs/client-cert.pem"
private_key="/etc/ssl/certs/client-priv.pem"
private_key_passwd="client-secret-password"
priority=1
}
In case you don't need the WPA enterprise-level authentication and you simply want to enable the WPA-PSK support, the following setup should be reflected in the wpa_supplicant.conf file:
network={
ssid="Arhont-w"
psk="very secret PSK passphrase"
priority=5
}
Once the configuration file is ready, you can launch the wpa-supplicant utility to associate and authenticate to the desired wireless network. It can be done the following way:
wpa_supplicant -i wlan0 -c/etc/wpa_supplicant.conf -D hostap -B
This should run wpa_supplicant in daemon mode using the hostap driver on a wlan0 interface with a configuration file located in /etc/wpa_supplicant.conf. You should get the following output from the iwconfig and iwlist commands once authentication is successful.
wlan0 IEEE 802.11b ESSID:"Arhont-w"
Mode:Managed Frequency:2.462GHz Access Point: 00:XX:XX:XX:XX:XX
Bit Rate:11Mb/s Tx-Power:50 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:61CC-3D80-78CF-33D4-294F-B24F-C7C6-C6B8
Security mode:restricted
Power Management:off
Link Quality=26/94 Signal level=-69 dBm Noise level=-95 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
ath0 3 key sizes : 40, 104, 128bits
4 keys available :
[1]: E619-D524-557B-21A3-7B48-6E26-DB68-2272 (128 bits)
[2]: 006E-D5E5-6EBC-F41B-A9EC-8906-74E6-DA7D (128 bits)
[3]: off
[4]: off
Current Transmit Key: [1]
Security mode:restricted
Once the configuration of xsupplicant is ready and configured for your WLAN, issue the following command to authenticate and get the per-session-based dynamic WEP key.
xsupplicant -i ath0 -c /etc/xsupplicant.conf
If all goes well, you should have a similar output to iwconfig command:
ath0 IEEE 802.11g ESSID:"Arhont-x"
Mode:Managed Frequency:2.462GHz Access Point: 00:XX:XX:XX:XX:XX
Bit Rate:36Mb/s Tx-Power:50 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:A3D0-FF7F-AD85-E6AB-1808-38A8-90 Security mode:restricted
Power Management:off
Link Quality=28/94 Signal level=-67 dBm Noise level=-95 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
As you can see, the xsupplicant successfully authenticated to AP with 802.1x support and received a pair of keys that is used to encrypt the unicast and broadcast traffic. By issuing the iwlist wlan0 key command you can get the list of keys that has been assigned to you by the AP.
ath0 3 key sizes : 40, 104, 128bits
4 keys available :
[1]: A3D0-FF7F-AD85-E6AB-1808-38A8-90 (104 bits)
[2]: CCD1-7D97-A2D3-9B4A-CAA1-DE7E-A6 (104 bits)
[3]: off
[4]: off
Current Transmit Key: [1]
Security mode:restricted
You can control reauthentication and rekeying time intervals from an access point side. If WEP and not TKIP or CCMP is used, we suggest rotating the key every five minutes.
When a suspicious event is detected, a siren sounds and information about the event flashes at the bottom of the screen. To see the info about recent suspicious events on your WLAN in a separate ncurses panel, press "w". If you're deploying a large WLAN, you can gain a great advantage from Kismet's client/server structure, with multiple clients installed along the network reporting the events to a centralized server.
On the server side, you can easily integrate Kismet with Snort, providing intrusion detection on all network layers. Open kismet.conf file, scroll toward the #fifo=/tmp/kismet_dump, uncomment this line, save the configuration file, and start kismet_server. Once started, Kismet will lock the /tmp/kismet_dump file until it's picked up by Snort. Now, let's start Snort. Configure it to your liking, but add an additional -r /tmp/kismet_dump switch when you run it, so it will read data from the FIFO feed of Kismet. You can further install and run ACID for pleasant and colorful IDS log viewing.
Another thing to consider is deploying higher-layer defenses instead of or with 802.11i (if the security requirements of the network are high or you're truly paranoid). Imagine a long-range point-to-point wireless link. Using IPSec as implemented by Linux OpenSwan or KAME suites to secure such a link provides more flexibility than using WPA, since you have a great choice of (symmetric, assymmetric, and hash) ciphers and IPSec modes. You won't need the RADIUS server for the link a la WPA Enterprise and will achieve a higher level of security than provided by WPA SOHO.
Make sure that the IPSec key distribution over such a link is mutually authenticated (Diffie-Hellman) to avoid crackerjack-style wireless man-in-the-middle attacks. If you consider IPSec too difficult to use or unnecessary, modern Linux PPTP with MPPE implementations are reasonably secure. Of course, in such cases you are limited to 128-bit RC4 and static PSK to encrypt wireless data.
If you want to connect a limited resources device such as a Linux PDA or mobile phone without 802.11i/WPA support, SSH port forwarding can be an appropriate and easy choice that is highly interoperable and does not put a large burden on the available device resources. Make sure that SSHv2 is running and there are no vulnerabilities in the sshd daemons used, since anyone can try to launch an attack against your link and daemons. There are many extensive sources that describe the practical use of IPSec, PPTP, and other VPN protocols such as cIPE and SSH port forwarding on Linux so we're not going to compete with them here.
Finally, it makes sense to separate your wireless and wired networks with a secure gateway. 802.11 Security by Bruce Potter and Bob Fleck (O'Reilly) goes to great lengths explaining how to build such gateways using stateful filtering and port/protocol forwarding with Linux Netfilter. The gateway must be as hardened as it can get: we strongly suggest using security-oriented distros such as Astaro or Immunix and implementing kernel-level security (OpenWall, Grsecurity, St Jude, etc.) alongside the standard Linux-hardening practices. Due to the flexibility of the OS, such a gateway can also serve as an 802.11i-secured access point, wireless traffic load-balancer, wIDS/IDS sensor, VPN concentrator, and RADIUS server. Combine all these properties in a commercial, proprietary, closed-source solution and you'll get a $100,000 product. With Linux, the opportunities are there and are only limited by your imagination, desire, and time.