| Home > A wireless network vulnerability assessment checklist | |
| Security School: |
|
||
Vulnerability assessments can help you find and fix WLAN weaknesses before attackers take advantage of them. But where do you start? What should you look for? Have you covered all the bases? This checklist will help to answer these questions.
1. Discover nearby wireless devices
For each discovered 802.11 access point, document: Media Access Control (MAC) address Extended service set identifier (ESSID) Channels Average/Peak signal-to-noise ratio (SNR) Type (i.e., 802.11a, b, g, or n) Beaconed security parameters (i.e., WEP, TKIP or AES-CCMP) Beaconed quality of service parameters (i.e., WMM access classes) Approximate location and probable owner MAC address Associated ESSIDs Type (i.e., 802.11a, b, g, or n) Associated AP(s) or peer station(s) Average/Peak SNR If visible, 802.1X identity Approximate location and probable owner
For non-802.11 sources of interference (e.g., microwave ovens, Bluetooth, cordless phones), a spectrum analyzer can help you fingerprint the source. For 802.11 devices, compare survey results to your existing inventory to isolate unknown devices that require further investigation. Note that looking for activity in bands and channels that you don't normally use can help you spot devices trying to evade detection. To learn more about how to investigate these "rogue" devices and the risks they may pose to your WLAN, please read our related tip, Recipe for rogue hunting.
3. Test your own access points Is the AP running the latest firmware and security patches? Has the factory default ESSID been changed? Has the default administrative login/password been changed? Is the administrative password easily cracked? Are stronger authentication options available (e.g., embedded 802.1X)? Are there any unnecessary ports open (e.g., Telnet, HTTP, SNMP, TFTP)? Are those open ports vulnerable to known exploits? Are encrypted administrative interfaces available (e.g., SSH, HTTPS)? Have security alerts or logs been enabled (e.g., syslog, traps)? Have filters been used to prevent unauthorized protocols (e.g., ARP, RIP, SNMP, NetBIOS) from propagating through the AP into the wired network? Are filters available/used to block user-to-user wireless? Is the AP using the right ESSID, channel and 11b/g protection? Are its security parameters consistent with defined policy? If the AP is using WEP, is it emitting any known weak initialization vectors (IVs)? Is the AP emitting any known weak initialization vectors (IVs)? If the AP is using a PreShared Key (PSK), is it easily cracked? If the AP is not using WPA2 (AES only), can it be upgraded to do so? Can the AP withstand simulated 802.11 DoS attacks (e.g., Authenticate floods)?
Some stations may not have been active during your survey, so make sure to hit every 802.11-capable device on your asset inventory, including laptops, desktops, PDAs, VoIP handsets, printers, scanners and headsets. You may want to "ping scan" wireless subnets to locate stealth devices that eluded earlier detection. Then, try to answer the following questions about each wireless station that you own: Is the station running the latest OS and application security patches? Is boot or OS authentication used to prevent lost/stolen/unintended use? Are current antivirus and antispyware programs running? Is the wireless interface protected by a personal firewall? Are there unnecessary ports open (e.g., netbios-ns/ssn, microsoft-ds, ssdp)? Are there unnecessary protocols bound to wireless (e.g., file/printer sharing)? Are potential wireless intrusions (e.g., blocked sessions) being logged? Is the wireless client willing to associate to ANY network? ANY Ad Hoc? Is the client automatically re-associating with home or hotspot SSIDs? Are there wireless user credentials (e.g., passwords) saved on disk? Is the station scanning the right bands/channel widths for the right ESSID(s)? Are its security parameters consistent with defined policy? Is the class of traffic that it sends consistent with QoS expectations? Is the station simultaneously connected to wired and wireless networks? Is the station emitting any known weak IVs? If the station is using 802.1X, is its identity visible? If using 802.1X, is it using a vulnerable EAP type (e.g., LEAP)? If using 802.1X, is it checking the server's certificate? If not using WPA2 (AES), are upgrades available to do so? If a VPN client is used over wireless, is it configured properly?
Finally, assess the security of any network infrastructure devices that participate in your wireless subnet, including wireless switches, firewalls, VPN gateways, DNS servers, DHCP servers, RADIUS servers, Web servers running captive portal login pages and managed Ethernet switches. Like your APs, all of these devices should be subject to the same penetration tests normally run against Internet-facing servers. For example, captive portals should be subject to tests normally run against a DMZ Web server, including tests designed to assess that program/version for known vulnerabilities that may need to be patched. Most infrastructure tests are not specific to wireless, but additional tests may be appropriate for 802.1X infrastructure. For example, you may wish to test your RADIUS server's ability to gracefully reject badly-formed EAP messages, including bad EAP lengths and EAP-of-death.
6. Apply your test results Once you've applied fixes, repeat tests to verify the result is now what you expected. Ideally, vulnerability assessments should be repeated at regular intervals to detect and assess new wireless devices and configuration changes. Also look for opportunities to automate your tests, making them faster, more consistent and more rigorous. >> Read the next tip: Hunting for rogue wireless devices
'); // -->
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
|
||||||||||