Myth #6:A wireless IDS is unnecessary if other rogue AP

While exposing the myth about the prevention of rogue APs could be a blow to wireless IDS vendors, there is another common Wi-Fi myth that has been having the opposite effect. Many networking professionals are under the mistaken impression that a wireless IDS is unnecessary if other rogue AP prevention measures are in place.

It’s easy to understand why the average network administrator might be hesitant to get behind a wireless IDS. They are very expensive and there’s not a whole heck of a lot of folks out there who actually understand everything that a wireless IDS is doing. Even most of the folks who have invested in a wireless IDS only did so because they need to prevent rogue access points.

The reality is that there’s a whole other area of troubleshooting and Wi-Fi optimization features that make wireless IDS products a valuable addition to most networks. Some of today’s wireless IDS offerings do location tracking, remote packet captures, and analysis of RF interference levels.

When you think about it, these other wireless IDS features are much more likely to make a networking person’s job easier than the ability to neutralize rogue APs. Instead of having to send field technicians out to every location that has a problem, a wireless IDS allows the experts that own your network to troubleshoot the wireless medium from a centralized location.


One more thing to think about is the fact that so many Wi-Fi users are new to the technology. New users are often reluctant to report problems or call the support team. A wireless IDS may be the best way to find out if some area of a facility is likely to be unsuitable for time-sensitive applications like VOIP or video conferencing.

This myth about the ways the use a wireless IDS really has more to do with the performance of the network than the security of the network. Let’s look at three more myths that really touch on the performance of Wi-Fi networks.

Myth #5:You need a wireless IDS to prevent rogue access

The previous Wi-Fi myth was a chance to examine a well-known relationship of safety and security: The more secure something gets, the less accessible it becomes to the folks who need to use it. There is another, more fascinating dichotomy as it pertains to technological advances in safety and security: As any entity becomes safer or more secure, the advance of technology will continue to create new ways to push the limits of this new security.

Take the security of automobiles. With airbags, crumple zones, and enhanced braking technology, cars and trucks are safer than ever. But as these safety enhancements have been introduced, more and more cars are capable of faster and more dangerous speeds due to ever-improving engine, cooling, and suspension technology.

In the world of Wi-Fi, things are no different. As Wi-Fi security has evolved from WEP to WPA and WPA2, people have become more and more comfortable buying Wi-Fi access points and station devices. With this boom in the number of wireless devices, network administrators have been forced to deal with the ever-increasing threat of rogue devices being attached to the network.

While the number of potential rogue access points has surely risen, the potential for intrusion has long been present. Many companies have introduced wireless intrusion detection systems (wireless IDS) as a way to counteract such intrusions. A wireless IDS can identify, locate, and even contain rogue access points. Over the last several years, many wireless IDS vendors have touted their products as essential tools for counteracting the threat of rogues.

There’s little question that a wireless IDS will help prevent rogue access points, but the question has to be asked: Is a wireless IDS the best tool for preventing rogue access points? The answer is a clear, “No.”

A wise man once said, “To thwart thy enemy, one must first know thy enemy.” (Actually, we’re not sure if anyone said that, but it sounds great, though.) Knowing rogue access points means knowing exactly what type of threat they pose to a network. A rogue access point is a threat because it could allow unauthorized users to gain access to network resources through a wireless link. Since a rogue AP is not managed by the network administrator, the authentication and encryption quality being used on a rogue AP cannot be verified. Without the guarantee of strong authentication and encryption, an intruder could use any number of means to gain network access from outside the walls of the organization.

In understanding these the nature of rogue access points, two important principles come to light: They must be identified separately than any authorized APs in the area and they must be blocked from network access.

A wireless IDS does a superb job of identifying 802.11a/b/g rogue APs. If an ACL is configured on the wireless IDS, the network administrator will receive an alarm every time an unauthorized device is nearby.

Unfortunately, a wireless IDS does a much less impressive job of identifying non-802.11a/b/g rogue APs. If someone plugs in a legacy AP that was based on 900 MHz and/or FHSS technology, that device will remain undetected. The same applies for certain newer non-802.11a/b/g APs like those based on Bluetooth and MIMO technology. Some newer wireless IDS vendors now offer products that can identify some of these non-standard APs, but comprehensive AP identification is virtually impossible.

A wireless IDS also does a less-than-superb job of blocking rogue APs from gaining network access. Almost every wireless IDS vendor offers some method of rogue AP suppression. Some vendors send a wireless DoS to the rogue AP and its associated stations. This technique is weak because a Wi-Fi adapter can have its drivers manipulated to ignore de-authentication or disassociation frames that are used to cause a DoS attack. Other vendors shut down the wired port that the rogue AP is plugged in to. Another weakness of this technique is that a rogue AP configured with encryption and authentication (yes, even WEP) will not allow the wireless IDS
to send the message onto the wired side of the network so that the correct port can be identified.

Really, the problem with using a wireless IDS to prevent rogue APs begins and ends with the nature of the system itself. A wireless IDS is designed to be an overlay to a network. Heck, that’s part of its allure. You know: Installing the wireless IDS where Wi-Fi is not allowed. The best way to stop rogue APs is going to be something that is integrated with the network. It has to be something that allows a network manager to block access on every network port.
Wired 802.1X authentication is the perfect solution for blocking access on every network port.

When wired 802.1X is enabled, network access is denied until a device authenticates as an 802.1X supplicant. This is even more effective than using MAC address authentication for a couple of reasons. First of all, if you’re using 802.1X for your wireless users then you can use the same infrastructure that may already be in place. Secondly, 802.1X authentications generally include the negotiation of an encryption key. When encryption is used, MAC address spoofing becomes impossible because the intruder will not have the correct encryption key.

The myth that a wireless IDS is the best way to prevent rogue access points has benefited wireless IDS vendors for quite some time. Numerous students who attend our classes enter class with the idea that they need a wireless IDS to stop rogue APs, but by the end of the week, they usually see that wired 802.1X and wired MAC authentication are both more comprehensive methods.

Myth #4: Disabling the SSID broadcast will hide your

We’ve made it through a darn good portion of this paper without relying on analogies. As anyone who’s taken our classes knows, though, we love them. They tend to lighten up class a bit, and they let us talk about topics that we really know something about: movies and sports cars.We know you’re not exactly in a class right now, but let’s tackle our fourth myth by starting with an analogy of a really good Western movie.

Imagine your local bank. Imagine that Butch Cassidy and The Sundance Kid live nearby. Your bank clearly needs security, but it also needs to stay open to customers. Let’s now imagine that instead of installing a safe, some locks, and thick steel bars between the tellers and customers, you decide to simply take down the sign advertising the name of your bank. Your bank has now performed the financial equivalent of disabling the SSID broadcast.

Disabling the SSID broadcast has been touted by a number of network security professionals because the SSID will stay hidden from Wi-Fi client software. When users want to connect, they must manually configure the SSID (and accompanying security settings). Since hackers and wardrivers won’t know the SSID, they won’t be able to connect, right? Not exactly.

Forcing users to configure the SSID offers minimal security to a wireless network. As in our Wild West banking analogy, network intruders can see that a Wi-Fi network is there. Just as Butch and Sundance would have been able to identify the bank by watching the clientele that entered, wardrivers can identify the SSID by capturing frames with applications like Wildpackets Omnipeek when authorized users connect.

When stations are connected to the network, they are constantly looking for other APs with the same SSID. They must do that to enable roaming. When APs respond to these probing stations, the SSID is sent in the clear, viewable text whether encryption is being used or not.

Now, it should be pointed out that your SSID will stay hidden as long as the network remains unused. For an AP to respond with the SSID in clear text, a station must probe the AP using the correct SSID. But think about it; how often is your network in use? If your network is like most enterprise Wi-Fi networks, it’s in use darn near all day. That means attackers have the ability to uncover your hidden SSID in a matter of seconds whenever they darn well please.

In the end, what you’ve got is a security method that gives you no real protection against malicious intruders, but causes your novice Wi-Fi users to have a tougher time getting connected. Why put your users (and the support team) through all of that? Once you consider the good and bad of leaving the SSID broadcast enabled, you’ll probably find that it’s summarized best by paraphrasing Butch Cassidy’s thoughts from the first scene in the movie: “It’s a small price to pay for manageability.”

How do I... Secure Windows XP NTFS files and shares?

How to .....File Share Permissions
Most users begin sharing files with workgroups, or peer-to-peer networks, by following these steps:

1. Right-clicking the folder containing the documents, spreadsheets and files they wish to share.
2. Selecting Sharing And Security from the pop-up menu.
3. Selecting the Share This Folder button from the Sharing tab of the folder's Properties dialog box. (Figure A)

A folder's Properties dialog box is used to configure share-level permissions for users and groups.

1. Entering a Share Name for the folder.
2. Optionally supplying some wording describing the folder's contents within the Comment field.
3. Clicking OK.

However, that method won't always work as you intend, especially on Windows XP systems formatted with NTFS (in which conflicting NTFS permissions can prevent an intended user from accessing those resources -- more on that in a moment). Worse, Windows XP's default share permissions behavior is set to provide Everyone with access to the share's contents.

It's also important to note that Windows XP's Simple File Sharing, enabled by default, must be turned off to specify different permissions for different users. To turn off Simple File Sharing:

1. Open Windows Explorer.
2. Click Tools.
3. Select Folder Options.
4. Click the View tab.
5. Within the Advanced Settings window, scroll to the bottom and uncheck the box for the Use Simple File Sharing (Recommended) option.
6. Click OK.

To remove the Everyone permissions, and specify varying access permissions different users should receive to a file share:

1. Right-click the folder you wish to share.
2. Select Sharing And Security from the pop-up menu.
3. Click the Permissions button. The Permissions ForFolderName dialog box will appear. (Figure B)

Share permissions are configured using the Share Permissions tab (reached by clicking the Permissions button from a shared folder's Properties dialog box.

4. Highlight Everyone from within the Group Or User Names window.
5. Click the Remove button.
6. Click the Add button. The Select Users Or Groups dialog box will appear. (Figure C)

Specify users and groups by entering them in the Enter The Object Names To Select window and clicking OK

7. Within the Enter The Object Names To Select window, specify the users' names for whom you wish to provide access, then click OK.
8. Highlight (within the Group Or User Names window) the names of the users and groups you selected and specify the appropriate permissions (Allow or Deny for Full Control, Change and Read are the options that appear) within the Permission For Username or Group dialog box.
9. Click OK to apply the changes and close the dialog box; click OK to close the FolderName Properties dialog box.

The Full Control permission enables a user or group to read, write, delete and execute files within the folder. Users possessing Full Control permission can also create and delete new folders within the share.

The Change permission enables a user or group to read and change files within the folder and create new files and folders within the shared folder. Users with Change permission can also execute programs within the folder.

The Read permission, meanwhile, enables a user or group to read files within the share and execute programs located within the folder.

Windows XP systems formatted with the NTFS file system provide additional permission settings. The next section reviews configuring NTFS permissions.

NTFS Permissions

Windows NTFS permissions provide a host of additional permissions options. In addition, NTFS permissions can be applied to a single file or folder.

Before configuring NTFS permissions, first ensure the Windows XP system is configured to use the NTFS file system:

1. Click Start.
2. Click Run.
3. Type compmgmt.msc and click OK. The Computer Management console will appear.
4. Highlight Disk Management within the Storage section to learn the file system in use for each of the system's drives.

If a hard disk or partition isn't formatted using NTFS, you can upgrade the disk by typing convert X: /fs:ntfs where X denotes the drive requiring the upgrade. Using the convert command, you can upgrade a drive to NTFS without losing its data. However, it's always best to confirm you have a working backup on hand before executing the command.

To configure NTFS permissions:

1. Right-click the file or folder you wish to share.
2. Select Properties from the pop-up menu.
3. Click the Security tab.
4. Use the Add/Remove buttons to add and remove permissions for users and groups.
5. Highlight the respective user or group within the Group Or User Names window and specify the appropriate permissions from within the Permissions For User/Group window using the provided Allow and Deny checkboxes. (Figure D)
6. Click OK to apply the changes.

NTFS permissions permit applying more granular rights, as compared to folder shares.

Note that, by default, subfolders will inherit permissions from parent folders. To customize permissions inheritance, click the Advanced button found on the share or filename's Properties dialog box.

Several NTFS permissions are available:


Full Control -- enables a user or group to perform essentially all actions, including view files and subfolders, execute application files, list folder contents, read and execute files, change file and folder attributes, create new files, append data to files, delete files and folders, change file and folder permissions and take ownership of files and folders.
Modify -- enables a user or group to view files and subfolders, execute application files, list folder contents, view file and folder attributes, change file and folder attributes, create new files and folders, append file data and delete files.
Read & Execute -- enables a user or group to view files and folders, execute application files, list folder contents, read file data and view file and folder attributes.
List Folder Contents -- enables a user or group to navigate folders, list folder contents and view file and folder attributes.
Read -- enables a user or group to view a folder's contents, read data and view file and folder attributes.
Write -- enables a user or group to change file and folder attributes, create new files, make changes to files and create new folders and append file data.

To determine a user's ultimate resulting permissions, add all the NTFS permissions granted to a user directly and as a result of group membership, then subtract those permissions denied directly and as a result of group membership.

For example, if a user is explicitly granted Full Control but is also a member of a Group in which Full Control is denied, the user will not receive Full Control rights. If a user received Read & Execute and List Folder Contents in one group but was also a member of a group that had List Folder Contents denied, the user's resultant NTFS permissions would be only Read & Execute. For this reason, administrators should carefully apply Deny permissions, as the Deny attribute overrules any equivalent instances of Allow when the two rights are applied to the same user or group.

Windows XP includes an effective permissions tool you can use to help verify the permissions a user or group receives. To access the tool:

1. Open the folder or filename's Properties dialog box.
2. Click the Security tab.
3. Click the Advanced button. The Advanced Security Settings For File/Foldername will open.
4. Click the Effective Permissions tab. (Figure E)
5. Click the Select button.
6. The Select User Or Group dialog box will appear.
7. Type the group or username whose permissions you wish to confirm in the Enter The Object Name To Select window and click OK.
8. The Advanced Security Settings For File/Foldername dialog box will display the resulting NTFS permissions for that user or group.

The Effective Permissions tab helps simplify determining a user or group's actual permissions.

Combining Share and NTFS Permissions

It sounds straightforward. Configure the permissions you want and a user is good to go. But there's one additional catch to keep in mind. Folder share and NTFS permissions must combine to determine the actual rights a user or group receives. Unfortunately, they often conflict.

To determine the ultimate permissions a user receives, take the user or group's resulting shared permissions and compare it with the user or group's resulting NTFS permissions. Note that the most restrictive of those rights will prevail.

For example, if a user's resulting NTFS rights are Read and Execute and the same user's resulting share permission is Full Control, the user will not receive Full Control. Instead, Windows calculates the most restrictive of the two resulting rights, which in this case is the NTFS permission of Read and Execute.

Remember that, to determine a user or group's ultimate resulting permissions, the most restrictive of the resulting NTFS and share rights applies. This is an important lesson that's easily forgotten but that quickly leads to frustration for users, so be sure to spend time up front properly calculating share and NTFS permissions

Myth #3: Captive Portals are an effective way to prevent

When WPA or WPA2 can’t be used, many organizations turn to a captive portal to control network access. A captive portal is defined as a network security system that restricts access until a user verifies a credential through a web interface. The theory behind such systems is that web browsers are available on all manner of Wi-Fi devices, so creating a captive portal to authenticate the public would allow the largest number of authorized users to gain access to the Internet.

Hotels, universities, and airports are just some of the places that use captive portals. Those environments must handle such a wide variety of station devices that choosing one type of security is generally thought to be restrictive to the point that some of the target audience may be unable to enjoy wireless Internet access.

Using a captive portal does allow access to a wide variety of stations, but the security design is quite flawed. To understand the flaw in authenticating users via a captive portal, one must first understand what a captive portal is. Captive portals are a layer 2 security method. When users authenticate to a captive portal, their MAC address is placed in a list of authorized users. When the person logs off, their MAC address is removed from the list.

Once it is understood that a captive portal is nothing more than a dynamic MAC address filter, it becomes easy to understand why they are ineffective at restricting unauthorized users from a public Wi-Fi network. A number of free, simple software tools are available that allow people to modify the MAC address of their network interfaces. If an intruder has one of these tools and an 802.11 protocol analyzer, he could easily identify an authorized user’s MAC address and masquerade as that user to gain network access.

A secondary reason why captive portals are no longer considered a good way to restrict unauthorized users from a public network is that Wi-Fi client utilities have become largely standardized. Users of all operating systems now have client utilities available that support WPA and even WPA2 on a number of adapters. With these stronger security protocols now being nearly ubiquitous, it has become reasonable to require public access users to login with a WPA/WPA2 Personal passphrase rather than through a captive portal. A publicly distributed
passphrase may lack the security required for an enterprise network, but it is a far more secure solution for public networks than a captive portal.

Myth #2: Even with 802.11i, you still need a VPN to

Once a network security professional learns that the physical layer of the network can be extended outside a room, building, or even across town, by an intruder with a high-gain antenna, it’s only natural to get skittish about allowing access points on the LAN. When you consider security options for this type of network that has an openly accessible physical layer, comparisons to the Internet are inevitably made.

IPSec and SSL VPNs have long been a logical way to secure users accessing the network via WAN connections, so it makes sense that people would choose those same options to secure a wireless LAN. To make matters worse, many network security veterans have been bombarded with news items telling them how vulnerable Wi-Fi networks are to intrusion—WEP or no WEP.

When WEP was fixed with the introduction of WPA in 2003, many people noticed. When 802.11i and WPA2 were introduced in 2004, even more people noticed. But few people who knew about WPA and WPA2 really knew the ins and outs of how they make wireless networks secure.

WPA fixed WEP by introducing TKIP (Temporal Key Integrity Protocol) encryption and using 802.1X/EAP or WPA-PSK as secure authentication methods. TKIP is an encryption type based on the same ciph er as WEP. While TKIP fixes the flaws in WEP, perhaps even more important is the fact that it kept the same cipher as WEP so that legacy equipment could be upgraded with improved software, not hardware.

Even when WPA became widely available, security professionals still had good reason to recommend VPNs for some secure Wi-Fi environments. TKIP’s use of the RC4 encryption cipher meant that certain organizations (Department of Defense, financial services, etc.) would be unable to comply with tough regulatory standards for IT security unless IPSec or SSL were employed.

When WPA2 was released, all of that changed. WPA2 uses CCMP (Counter Mode CBC-MAC Protocol) encryption. This is significant because the cipher used in CCMP is AES. The AES cipher is the strongest cipher used with IPSec VPNs, and it has no known flaws. The end result is that using CCMP on an 802.11i network provides encryption that is as strong as the strongest IPSec VPN.


Some network security professionals who acknowledge the encryption strength of 802.11i still prefer VPNs because authentication on IPSec and SSL connections is known to be secure. In fact, there are very real concerns when certain types of authentication are used in concert with CCMP encryption. WPA-PSK and 802.1X/EAP-LEAP authentication are both vulnerable to dictionary attacks.

Even though vulnerable WPA2 authentication methods do exist, several secure authentication methods are available as well. When a Wi-Fi network is designed using the 802.1X framework with EAP-TLS, EAP-TTLS, or PEAP authentication, wireless credentials are kept private using tunneling technology similar to SSL. Devices that use CCMP encryption with any of the aforementioned types of authentication are easily identified with the WPA2 Enterprise certification.

The development of WPA2 Enterprise has been an important step in the security evolution of Wi-Fi networks. For some IT security folks, however, being just as secure as an IPSec or SSL VPN isn’t quite enough. Seasoned security people know VPNs. They may not really know WPA2 Enterprise and, therefore, may be unwilling to adopt it when VPNs are readily available. For that reason, it’s important to understand that WPA2 Enterprise is not just as good as an IPSec VPN –it’s better.

WPA2 Enterprise offers benefits over wireless VPN connections in terms of cost, performance, availability, and support. There are numerous ways to express the advantages of WPA2 Enterprise, but a look at the intrinsic nature of each technology is the most revealing way to understand it. Wi-Fi is a layer 2 technology and WPA2 Enterprise secures the network at layer 2. IPSec is a layer 3 technology, which makes it fundamentally less scalable, secure, and manageable for securing a layer 2 link.