Wi-Fi

10 Wi-Fi security tips


Wireless networking can be kind of scary from a security standpoint. It opens up whole new attack vectors that were not present with wired network infrastructures. That doesn't mean you can't do it securely, however, and I aim to give you some ideas that can help you in that regard.

Many of these tips are likely to be inapplicable to a lot of people. For instance, if you're running a wireless network that has to allow connections from a changing lineup of computers so that the specific computers on the network will not be constant, the point about restricting access by MAC address is unlikely to do much good. As always, you must exercise some common sense when reading through a list of security tips like this. You have to determine what options apply to you, and whether the fact that your plans make a given suggestion unusable means your plans are wrong or the suggestion simply is not relevant in your case.

  1. Use a strong password. As I pointed out in the article A little more about passwords, a sufficiently strong password (on a system with decent password protection) makes the likelihood of cracking the password through brute force attacks effectively impossible. Using a sufficiently weak password, on the other hand, almost guarantees that your system will be compromised at some point.
  2. Don't broadcast your SSID. Serious security crackers who know what they are doing will not be deterred by a hidden SSID -- the "name" you give your wireless network. Configuring your wireless router so it doesn't broadcast your SSID does not provide "real" security, but it does help play the "low hanging fruit" game pretty well. A lot of lower-tier security crackers and mobile malicious code like botnet worms will scan for easily discovered information about networks and computers, and attack those that have characteristics that make them appear easy to compromise. One of those is a broadcast SSID, and you can cut down on the amount of traffic your network gets from people trying to exploit vulnerabilities on random networks by hiding your SSID. Most commercial grade router/firewall devices provide a setting for this.
  3. Use good wireless encryption. WEP is not exactly "good" encryption. With a freely available tool like aircrack, you can sniff wireless traffic protected by WEP and crack security on that network in a matter of minutes. WPA is the current, common encryption standard you should probably be using -- though, of course, you should use something stronger as soon as it becomes available to you. Technology is advancing every day, on both sides of the encryption arms race, after all.
  4. Use another layer of encryption when possible. Don't just rely on wireless encryption to provide all your security on wireless networks. Other forms of encryption can improve the security of the systems on the network, even if someone happens to gain access to the network itself. For instance, OpenSSH is an excellent choice for providing secure communications between computers on the same network, as well as across the Internet. Using encryption to protect your wireless network does not protect any communications that leave the network, so encryption schemes like SSL for dealing with e-commerce Websites is still of critical importance. The fact you're using one type of encryption in no way suggests you should not be using other types of encryption as well.
  5. Restrict access by MAC address. Many will tell you that MAC address restriction doesn't provide real protection but, like hiding your wireless network's SSID, restricting the MAC addresses allowed to connect to the network helps ensure you are not one of the "low hanging fruits" that people prefer to attack. It is best to be effectively invulnerable to the expert security cracker, but there's nothing wrong with being less palatable to the amateur as well.
  6. Shut down the network when it's not being used. This bit of advice is even more dependent on specific circumstances than most of them. If you have the sort of network that does not need to be running twenty-four hours a day, seven days a week, you can reduce the availability of it to security crackers by turning it off when it isn't in use. While many of us run networks that never sleep, and cannot really put this suggestion into practice, it is worth mentioning if only because one of the greatest improvements to the security of a system you will ever encounter is to simply turn it off. Nobody can access what isn't there.
  7. Shut down your wireless network interface, too. If you have a mobile device such as a laptop that you carry around with you and use in public, you should have the wireless network interface turned off by default. Only turn it on when you actually need to connect to a wireless network. The rest of the time, an active wireless network interface is nothing more than another attack vector for malicious security crackers to use as a target.
  8. Monitor your network for intruders. You should always make sure you have an eye on what's going on, that you are tracking attack trends. The more you know about what malicious security crackers are trying to do to your network, the better the job of defending against them you can do. Collect logs on scans and access attempts, use any of the hundreds of statistics generating tools that exist to turn those logs into more useful information, and set up your logging server to email you when something really anomalous happens. As a certain cartoon military SpecOps team from the 1980s would tell you, knowing about the danger is half the battle.
  9. Cover the bases. Make sure you have some kind of good firewall running, whether on a wireless router or on a laptop you use to connect to wireless networks away from home. Make sure you turn off unneeded services, especially on MS Windows where the unneeded services that are active by default might surprise you. In fact, do everything you can to secure your system regardless of OS platform, mobility of the system, or type of network.
  10. Don't waste your time on ineffective security measures. Every now and then, I run across some technically deficient end user handing out free advice about security based on things overheard and half-understood. Generally, this advice is merely useless, though often enough it can be downright harmful. The single most common bit of bad advice I hear from such people with regard to wireless networking is the admonition that when connecting to a public wireless network, such as in a coffee shop, you should only connect if the network uses wireless encryption. Sometimes these people get the advice half right, and recommend only connecting to networks protected by WPA -- it's half right only because WPA is the wireless encryption you should use, if you are going to use wireless encryption at all. There is no point in trying to "protect" yourself by connecting to a public access point only if it uses encryption, however, because the fact that the encryption key will be handed out to anyone that asks for it completely obviates the supposed protection you expect. It's a bit like locking the front door of the house, but leaving a big sign on the door that says "The key is under the welcome mat," which only protects against illiterate burglars. If you want your network to be available to everyone that walks onto the premises, just leave it unencrypted, and if you need to connect to the Internet in some public location, don't worry about encryption. In fact, if anything, the wireless encryption might more properly serve as a deterrent rather than an enticement to using that particular wireless network, because it reduces convenience without effectively improving security at all.

Most of the security tips one can offer about wireless networking are the sort of thing someone might call "common sense". Unfortunately, there's an awful lot of "common sense" floating around out there, and it's not easy to keep it all in mind all the time. You should always check up on your wireless networks and mobile computers regularly to make sure you aren't missing something important, and you should always double-check your assumptions to make sure you aren't wasting your energy on something not only unnecessary, but entirely useless, when more effective security measures could use your attention.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

24 comments
guest2
guest2

Over 2 years ago, George Ou wrote an article "The six dumbest ways to secure a wireless LAN" about urban legends and myths on wireless LAN security. You've picked 2 of his 6 dumbist ways. http://blogs.techrepublic.com.com/Ou/?p=43

thetryckster
thetryckster

http://technet.microsoft.com/en-us/library/bb726942.aspx I'd like feedback regarding the following excerpt from Microsoft TechNet. (The full article can be viewed at the link above.) In this article, Microsoft recommends AGAINST use of the Non-Broadcast feature of the SSID. Comments anyone? "A non-broadcast network is not undetectable. Non-broadcast networks are advertised in the probe requests sent out by wireless clients and in the responses to the probe requests sent by wireless APs. Unlike broadcast networks, wireless clients running Windows XP with Service Pack 2 or Windows Server?? 2003 with Service Pack 1 that are configured to connect to non-broadcast networks are constantly disclosing the SSID of those networks, even when those networks are not in range. Therefore, using non-broadcast networks compromises the privacy of the wireless network configuration of a Windows XP or Windows Server 2003-based wireless client because it is periodically disclosing its set of preferred non-broadcast wireless networks. When non-broadcast networks are used to hide a vulnerable wireless network???such as one that uses open authentication and Wired Equivalent Privacy???a Windows XP or Windows Server 2003-based wireless client can inadvertently aid malicious users, who can detect the wireless network SSID from the wireless client that is attempting to connect. Software that can be downloaded for free from the Internet leverages these information disclosures and targets non-broadcast networks."

Schuylkill
Schuylkill

This list is why my company does not allow our telecommuters to use wireless at home. As I say to every new telecommuter, it is easy to setup a home wireless network; it is very difficult to do so securely. This article proves my point - it is great information for an IT tech, but most people are not IT techs. Until wireless can be done easily AND securely, I just don't feel comfortable with our home users using wireless in their homes. The wireless manufacturers need to address this.

mjd420nova
mjd420nova

I take these tips and go one step further by mounting grounded foil near the antennas to prevent a usable signal from leaving the immediate area. It also helps to eliminate interference from other routers. I've tested it and can't get any signal at all outside the home and nothing usable just outside the wall where it's located. These tips are great but still won't stop a determined hacker who really wants into your system.

Sterling chip Camden
Sterling chip Camden

I think that the mistaken recommendation to only use public networks if encrypted stems from a general misunderstanding of how wireless encryption works.

apotheon
apotheon

Basically, George seems to think that since SSID hiding and MAC filtering are not effective as primary means of securing a network, using them [b]at all[/b] is "dumb". They're not. If nothing else -- when doing these things does not interfere with legitimate needs for the network -- SSID hiding and MAC filtering can help cut down on the unwanted traffic of "low-hanging fruit" type attacks. Sometimes, that can be worth quite a lot. If George specified that these techniques for adding security to a network were not effective against someone specifically targeting your network that has some measure of competence, I'd agree with him. Just making broad, sweeping statements to the effect that one should never do either, though, misses the whole point. It's like shifting your SSH access port from 22 to something with four digits: it doesn't stop targeted attacks from people who know what they're doing, but it cuts down on the vast quantities of crap filling up your logs from people scanning for systems with open port 22 and trying to brute-force the root account. That doesn't mean you should never shift your SSH daemon's listening port to anything other than 22. Having George Ou think you're dumb is, in many cases, a good sign.

w2ktechman
w2ktechman

to raise unneeded fear. Now, if you broadcast the SSID, everyone can see it. If you do not broadcast, it can be seen from free SW. But lets say that you connect to several hidden SSID networks. Ok, the would be intruder would need to follow you around to find the other networks. If they were broadcasting the SSID's as well, someone would need to follow you around to find them! How is it less secure? Either they follow someone around to find all of their networks, or, they need to do the same... Really, this is a very weak article and was not thought out very well. They were likely trying to address hiding the SSID was not security. And it really is not. But, I still fail to see how it is less secure??? The article is misleading at best.

apotheon
apotheon

If you turn off your wireless adapter any time it is not in use, and disable automatic network discovery and connection, that shouldn't be a problem. Granted, I haven't looked into it too much lately with WinXP and WS2k3, because most of my wireless network administration experience has primarily dealt with either non-Microsoft OSes or open access points that you really don't want hidden from casual users, but last I checked I seem to recall that the above measures would fix the problem. The idea, of course, is not to render your network undetectable, but to render it less easily discoverable. The security issue in particular that the TechNet article indicates relates to giving out information about where your mobile computer normally connects, and not to the SSID of a local wireless network per se. In other words, because of some poor design decisions on the part of Microsoft, that article is suggesting that you should never configure your wireless access point so that it doesn't broadcast the SSID so default configuration MS Windows laptops won't operate in a less-than-secure manner.

Michael Kassner
Michael Kassner

Not broadcasting the SSID adds a great deal of over head to the network and I have seen where not broadcasting the SSID on MS AD networks has created all sorts of problems.

apotheon
apotheon

The TechNet article brings up at least two real, genuine security concerns, though it does not explicitly identify either of them: 1. If your wireless client is constantly handing out information about the networks to which it's trying to attach as part of its roaming behavior, malicious security crackers can in theory use that information to spoof those wireless access points you normally use and get your computer to connect to the security cracker's access point. This could lead to attacks to gain more direct access, or to harvesting data from communications routed through the security cracker's wireless access point. 2. As should be obvious to the discerning security-conscious IT professional from point 1, Microsoft's roaming wireless client software is probably not what you want to use if you care about security. The implication of the facts behind the TechNet article is that the article is suggesting you should never use a wireless access point that doesn't broadcast the SSID because it causes the Microsoft roaming wireless client software to behave in a manner that compromises security for that client. Microsoft's wireless client software is not the only example of such software out there, but the commonality of a vulnerability in no way makes it less of a vulnerability. (edit: I managed to miss a punctuation mark on the first pass.)

Michael Kassner
Michael Kassner

You are correct about the security issues relating to the client workstation as there are some very interesting pen attacks available right now. I wrote about one in this post. http://blogs.techrepublic.com.com/wireless/?p=144 The problem I was referring to is a network management one. Not broadcasting the SSID increases network management traffic significantly between client radios and any available AP's. Each access point announces itself on the network (approx. every 100ms), using a specific beacon frame. This frame informs all users about the access point capacities, one of these is the network name: SSID. Each client radio wanting to connect to a Wi-Fi network will listen for beacon frames in order to learn about the available networks in its coverage area. This list of available networks is automatically acted upon by the client radio firmware if it has a configured profile for that specific network. If the ability to ?automatically associate? is disabled, the proposed list of networks is advertised to the user who can then choose which one to connect to. After association, the client radio still continues to scan for other beacons in case the signal from the currently-associated AP become too weak to maintain communications. As the client radio receives beacons from all advertising AP's, it updates the database of active APs within range. The client radio also constantly updates its local clock to maintain timing by listening to the associated AP's beacon frame. In addition, the client radio will abide by any other changes that the associated AP's beacon frame indicates. Whenever the SSID is not announced in beacon frames, the client radio is not able to determine what networks are available by "just listening". The client radio then has to transmit a probe request frame asking for the required association information. The associated AP and any other AP within range then answers with a probe response frame contains network capability information. The authentication process then continues after that. Remember that the client radio is programmed to constantly check to see if it is associated with the best quality signal in the preferred network. This is imperative, otherwise the ability to roam while maintaining adequate link quality would not be possible. Also remember that all AP's within range are required to respond to probe requests. Multiply this by the number of client radios and active AP's in the RF coverage area and you can see that management overhead increases dramatically.

w2ktechman
w2ktechman

but in my limited exposure to corp. wifi, I was addressing the issue from smaller 1-3 AP setups. In these setups, it is likely to have bottlenecks from too many client stations, if security is setup well.

apotheon
apotheon

"[i]This would be true only if the SSID was being used as the only security (ok, exception would be MAC filtering as well).[/i]" WEP encryption is notoriously easy to crack. In theory, one could crack WEP encryption and spoof other security measures besides SSID hiding, too. Of course, it's highly unlikely, and if you follow the sort of advice I offer in the "10 WiFi security tips" article you shouldn't have to worry about this particular security issue with regard to hidden SSIDs. I was just addressing the security implications of the TechNet article itself, in a vacuum.

apotheon
apotheon

Since this subthread was in response to the supposed security issues for a wireless network, as related in the TechNet article, and did not address your comments in another subthread about bandwidth consumption and similar issues, I only addressed security matters in this subthread.

Michael Kassner
Michael Kassner

My concern is not even remotely related to security issues. It is predicated on whether the client radio JUST listens for the beacon frame or it has to send out a probe request frame to obtain critical management and timing information. If you have a large wireless network with each client sending probe request frames to a single AP at the normal "micro second" interval there is a good chance that the AP will be bottle necked. That is my only point, when I referenced the increase in management overhead by not having the AP broadcast the SSID in the beacon frame.

w2ktechman
w2ktechman

security does not match up, no connection is made. This would be true only if the SSID was being used as the only security (ok, exception would be MAC filtering as well). But I hadnt really thought of it from that position either. As for point 2, hmmm, many do use MS's wireless controls for a connection.

apotheon
apotheon

[b]Schuylkill:[/b] I don't have quite as dismal an opinion of the matter. To a certain extent, I do not think that building security into a given standard communication protocol is the best option. Doing so will tend to doom that protocol to a very short lifespan, because security concerns evolve quickly, but basic communication protocols should have a bit more longevity. The fact that the 802.11 wireless protocols have been able to migrate from WEP to WPA is, in part, a matter of flexibility that can only be granted by virtue of the fact that WEP wasn't built into it in the first place. If WEP had been "baked in" from the beginning, we would have faced a much bigger problem when it was discovered that WEP wasn't the protection people originally thought it was: we would have been stuck with WEP unless and until we could propagate a replacement for the entire 802.11 protocol set. There are, however, instances where a little more security conscious design would have been a good idea. Such instances include things like thinking about whether or not broadcasting information about your network is really a good idea. In this case, the problem is mostly on the side of the client developers and vendors, however, because they want to provide something that insulates the user against having to think. When the user stops thinking is when security [b]really[/b] falls apart. The MS Windows wireless client example of insulating the user against having to think involves providing automated network discovery and association that so removes the user from the loop that it will actually broadcast information about the client's network configuration and about each of the networks it's preconfigured to use constantly in some cases. It's a display of stultifying stubbornness -- kind of a "brute force attack" approach to wireless network roaming. [b]Michael Kassner:[/b] My understanding is that client broadcast of the SSID is never necessary unless you're roaming. That doesn't mean it doesn't happen -- only that it isn't necessary. Whether or not it happens is dependent upon the driver and network association software you're using. "[i]I think the part where we differ is that you suggest that this only happens during the discovery phase. As I understand it, beacon frames are constantly sent out and whether they have the SSID being advertised or not will determine if the client radio will be forced to use probe request frames.[/i]" . . . for certain configurations of certain software on the client. I am not as experienced with the wireless client applications integrated with MS Windows as I am with other client applications (such as wpa_supplicant for Unix-like systems), but as I understand things MS Windows XP's wireless client application cannot be configured to stop sending the SSID to the world when the beacon frames do not contain it -- but other client software [b]can[/b] be configured that way. Thus, it is your choice of client software that determines whether or not this is a direct security concern of yours as an operator of a wireless client system. This can be a security problem of yours as the admin of a wireless network only if you are not careful about what clients you allow to connect, and even then it is debatable whether the security issue raised by such clients is as significant as the security issue created by SSID broadcast by the wireless access point. Gaining the SSID from client communication requires just slightly more sophisticated tools than basic wireless client software, after all. The security point of turning off SSID broadcast is not to make the SSID undiscoverable, but to add a few inches' height to the fruit the malicious security crackers want to acquire. In other words, in addition to real security like WPA encryption, a certain amount of protection from the most casual or incompetent of security crackers can be gained by ensuring that your network is not the low-hanging fruit. At minimum, it should cut down on the amount of wireless traffic you get from people trying to crack your network's security, even if it doesn't reduce the chances of success. Do you have any arguments against the usefulness of turning off SSID broadcast for purposes of ensuring your network is not as low-hanging a fruit as those that do broadcast the SSID? I'd definitely be interested in [b]that[/b] argument.

Michael Kassner
Michael Kassner

You assumptions are as I see it as well. I think the part where we differ is that you suggest that this only happens during the discovery phase. As I understand it, beacon frames are constantly sent out and whether they have the SSID being advertised or not will determine if the client radio will be forced to use probe request frames. The probe request/response cycle will be continuous throughout the entire time a client radio is associated with an AP, unless the SSID is broadcast in the beacon frame, then the client radio will just listen and receive the management information it requires.

Schuylkill
Schuylkill

It seems to me (and I am no wireless expert) that once again, we have a series of protocols where security is an afterthought. This just seems very similar to e-mail, ftp, telnet, and a bunch of other TCP/IP protocols. The difference being that those protocols were written in a more naive time; there is really no excuse for such lousy security in Wi-Fi. As I said in a previous post, wireless security has to be made so simple that a grandmother can do it. I don't know if the current set of protocols can be made that simple - we might need to start from scratch.

apotheon
apotheon

"[i]Actually the more important concept is that all client radios by design constantly check if there is a stronger RF source in the vicinity, specifically for link quality and irregardless of roaming.[/i]" This is not universal behavior, and is not necessary behavior under most circumstances. It's behavior that is mostly based on an assumption of network roaming and/or movement between bridges, repeaters, or network segments while connected. For the vast majority of users, roaming is the only such circumstance that is likely to apply. Ultimately, what this adds up to is an assumption of use case -- and the solution provided for the most likely such use case (network roaming) is a piss-poor solution at best, from a security standpoint. SSID broadcast from the router only modifies behavior during network discovery. SSID broadcast from the client is part of a querying process that is used for automated access point discovery for systems that are set up to run through all the preset network configurations. When you're using that to connect to open access points like at coffee shops without encryption, it's not such a big deal -- but when this functionality is being used with secured networks, it's just an invitation for malicious security crackers to acquire information from your system about commonly used networks.

Michael Kassner
Michael Kassner

Roaming is only one aspect. Actually the more important concept is that all client radios by design constantly check if there is a stronger RF source in the vicinity, specifically for link quality and irregardless of roaming. If the beacon frame is not sent by the controlling AP, each client radio will use probe request frames to ask for that information. That also creates the additional management overhead.

apotheon
apotheon

"[i]This is imperative, otherwise the ability to roam while maintaining adequate link quality would not be possible.[/i]" You assume that automated "roaming" behavior is really necessary.

Editor's Picks