Richard G Baldwin (512) 223-4758, NRG Room 4238, Baldwin@DickBaldwin.com, http://www.austincc.edu/baldwin/

ITNW 1351 Fundamentals of Wireless LANs

Lab Project # 10

Disabling SSID Broadcast

Revised:  August 26, 2005
By Richard G. Baldwin

File:  FwlProj090.htm


Preface

This laboratory project was prepared specifically for the benefit of my students who are enrolled in ITNW 1351, Fundamentals of Wireless LANs.

The project was designed under the assumption that students enrolled in the course have successfully completed the prerequisite course, ITNW 1325, Fundamentals of Networking Technologies.

The project design also assumes that the students are actively studying the material in the prescribed textbook for this course, which explains such complex topics as the IEEE 802.11g wireless specification.

Another browser window

I recommend that you open another copy of this document in a separate browser window so that you can easily view the discussion and the figures at the same time.

Purpose of Project

The purpose of this project is to show you how to disable the broadcasting of the Linksys router SSID and to explore the implications of doing so.

Equipment Requirements

The following equipment is required to complete this laboratory project:

Background Information

A contentious topic

This project gets into a fairly contentious topic on which there is quite a lot of disagreement.  The disagreement revolves around whether or not you should disable the broadcasting of the SSID by your router.

The default behavior

By default, the Linksys router (and other brands of access points as well) broadcasts the SSID of the router several times per second in clear text.  The purpose is to make it possible for wireless client computers to identify all of the active wireless networks within range of the computer so that they can connect to one of those active networks.

A security hazard?

In some cases, particularly in Small Office/Home Office (SOHO) systems, there is no need to make it possible for client computers to identify available networks.  The authorized users of the networks already know all about the networks.  Thus, there are those who claim that the broadcasting of the SSID by the router serves to increase the vulnerability of the networks to outside attackers.  After all, an outsider can't successfully connect to a network if he doesn't know the SSID of the network.

SSID can be determined anyway

In rebuttal, there are others who claim that any attacker worth his salt can easily learn the SSID of the network and that failing to broadcast the SSID does little or nothing to improve security.  Security, they say, should be achieved through the use of proper encryption in the authentication and data transmission process.

(This, by the way, appears to be the official position of Microsoft. See The Microsoft View later.  To some extent, this debate seems to break down along the lines of Windows users versus Linux users.)

Should concentrate on encryption

Folks in this camp further claim that anyone who knows enough to be able to disable SSID broadcasting should also know enough to implement WEP, WPA, or WPA2 encryption on the network, in which case the exposure of the network of no security consequence.

Where does the truth lie?

The truth probably lies somewhere in the middle.  One viewpoint might be that if you can show that someone used extraordinary means to learn of the existence of your network, and then broke into your network, you may have better grounds for prosecution than would be the case if that person could break in without the use of extraordinary means.

(This is sort of like posting a NO TRESPASSING sign at your swimming pool.  It might not keep the midnight skinny dippers out, but it might make it easier to prosecute them when they do trespass.)

A non-security based position

Finally, there is a third school of thought, which claims that there is a positive benefit to exposing the SSID, particularly in areas that are densely populated with wireless networks, such as apartment buildings and college dorms.

The argument goes that if all of the wireless networks are exposed, those who construct networks in that environment can do a better job of channel selection in an attempt to avoid having the networks interfere with one another.  I saw a note on one discussion forum where the poster claimed to purposely use the following SSID as a means of staking his claim on the use of Channel 6 in his neighborhood:

Chan6at2437MHz

He didn't say how successful he had been at enforcing his claim.

The Microsoft view

Here is a quotation from a Microsoft web site that states the Microsoft position on this matter and some of the implications of disabling the broadcasting of the SSID:

"When your Windows XP Service Pack 1 or Service Pack 2 (SP1 or SP2)-based Wireless Zero Configuration (WZC) client computer is in the proximity of two wireless access points, and one of the access points is broadcasting its Service Set Identifier (SSID) but the other is not, your computer always connects to the access point that is broadcasting its SSID. This occurs regardless of the preference order of the networks that are configured on the Preferred Networks list.

Additionally, when your computer is connected to an access point that is not broadcasting its SSID, and another access point that is broadcasting its SSID is enabled nearby, your computer automatically connects to the access point that is broadcasting its SSID. ... Wireless Zero Config Service (WZC) always tries to connect to a broadcasting Access Point that is listed in the Preferred Networks list first. ... This behavior is by design.

Disabling SSID broadcasts on an access point is not considered a valid method for securing a wireless network. Microsoft does not recommend this practice for any wireless network."

I'm not certain that the experimental results for this project bear out the above statements to the letter.  However, they certainly bear out the spirit of those statements.

Discussion

In this project, you will configure two Linksys wireless routers (access points).  One access point will broadcast its SSID and the other will not.  You will then perform a series of experiments in the proximity of those two access points and observe the behavior of your client computer.

Project Instructions

Configure two access points

Using what you learned in the project entitled Automatic Switching Among Access Points, set up a wireless network router with the following configuration:

Then, also using what you learned in the project entitled Automatic Switching Among Access Points, set up a second wireless network router with the following configuration:

Once you do that, your setup will match the setup that I discuss in this project except that my second router was a Belkin router with an SSID of belkin54g instead of a Linksys router with an SSID of R2.

Disable SSID Broadcasting on R1

Go to the Wireless/Basic Wireless Settings page of the administrator panel and select Disable for Wireless SSID Broadcast as shown in Figure 1.

Then click the Save Settings button and click Continue on the confirmation page when it appears to save the change in configuration.



Figure 1

Disconnect and reboot

Disconnect the patch cable between your computer and the R1 router if it is still connected.  Then reboot your computer.

Confirm that the list of Preferred networks is empty

When your computer finishes rebooting, go to the Wireless Network Connection Properties dialog shown in Figure 2 and make certain that the list of Preferred networks is still empty.



Figure 2

Confirm that network R1 is not available for connection

Go to the Wireless Connection Dialog shown in Figure 3 and confirm that the network named R1 is not showing there.

(It should not be showing there because it is no longer broadcasting its SSID.  Therefore, Windows will not find it when it scans for active networks within range.)



Figure 3

Two critical factors

The two critical factors at this point are:

  1. Even though the R1 router is running, it is not broadcasting its SSID and its SSID does not appear in the list of networks in the Wireless Connection Dialog.
  2. The list of Preferred networks showing in Figure 2 is empty.

There should be no wireless connections

Your computer should not connect to the R1 network because it will not find it when it scans for active networks within range.

In addition, your computer should not connect to the R2 network (in my case, the belkin54g network) because even though that network is active and within range, it is not on the list of Preferred networks.

An alert bubble

Because there was an active wireless network, belkin54g, within range of my computer, and it was broadcasting its SSID, I got an alert bubble notifying me that there were networks within range of my computer and inviting me to click on the box to view the list of networks.

However, and this is very important, the computer did not connect to any wireless network, even though both R1 and belkin54g were active and both were within range of my computer.

Figure 3 shows the list of active networks that were within range of my computer that were broadcasting their SSID.  The R1 network is not on the list even though it was within range of my computer, because it was not broadcasting its SSID.

To reiterate

There are two important things to note:

Can NetStumbler see the R1 network?

Using what you learned in the project entitled Introduction to NetStumbler, start the NetStumbler program running to determine if it can see the R1 network.

Figure 4 shows the result of running NetStumbler on my machine.



Figure 4

Only belkin54g was visible to NetStumbler

As you can see, NetStumbler clearly identified my router named belkin54g, which was broadcasting its SSID on a regular basis.  However, it did not identify the router named R1, because SSID Broadcast was disabled on that router.

Therefore, some technique more sophisticated than simply running the NetStumbler program is required to learn of the existence of the router named R1 when it isn't broadcasting its SSID.

What good is an invisible network?

By now you are probably wondering what good it does to have a wireless network running if you can't identify it or connect to it.  The truth is, you can connect to it if you already know its SSID.  That is what you will do next.

Add R1 to the list of Preferred networks

Once again, using what you learned in the project entitled Automatic Switching Among Access Points, open the Wireless Network Connection Properties dialog and add the R1 network to the list of Preferred networks as shown in Figure 5.



Figure 5

R1 must be Automatic

Make certain that the R1 network is shown as Automatic in the dialog of Figure 5.

(If it shows anything other than Automatic, remove it from the list and then restore it to the list.  That should cause it to show Automatic.)

Can't add it if you don't know its name

From a quasi-security viewpoint, keep in mind that in order to add the network to the list of Preferred networks in Figure 5, you must know the SSID.  If you don't know the SSID, you can't possibly add it to the list.

(From what I have read, however, any attacker with decent computer skills, the correct tools, and the available time can determine the SSID using techniques that are more sophisticated than simply running a program like NetStumbler.)

Reboot your computer again

Now comes the acid test.  Reboot your computer again and observe how it behaves with respect to connecting to a wireless network on startup.

By entering R1 in the list of Preferred networks, you have told the computer that the network named R1 may be active and within range even though it is not broadcasting its SSID.

Connection to network R1

On my machine, the reboot caused Windows to automatically find and connect to the network named R1.

Even though R1 isn't broadcasting its SSID, it is contained in the list of Preferred networks in Figure 5.  This caused Windows to seek it out and to connect to it.  To re-quote Microsoft,

"Wireless Zero Config Service (WZC) always tries to connect to a broadcasting Access Point that is listed in the Preferred Networks list first."

Active versus passive scanning

Scanning is the process by which client machines remain aware of the available networks that are within range.  Although I'm not certain, I believe that this illustrates the difference between passive scanning and active scanning on the part of the wireless client.

Access points that broadcast their SSIDs are detected through passive scanning.  However, active scanning is required to detect an access point that is not broadcasting its SSID.

An aside, hibernation versus restart

By the way, in order to save the status of the programs that I was running, I also caused the computer to hibernate and then wake up to see if that would have the same effect.  It didn't.  A full restart was required to cause the client computer to automatically connect to R1.

The current list of active networks in range

At this point, the Wireless Network Connection dialog shows both R1 and belkin54g as being active and within range as shown in Figure 6.



Figure 6

Once Windows was told of the R1 network, and found it, it put it on the list of active networks even though it wasn't broadcasting its SSID.

Manually disconnect from R1

Now manually disconnect from R1.  Windows provides a warning that states something like the following:

"Are you sure you want to disconnect from the network 'R1'?

Once you have disconnected, Windows will not re-connect to this network automatically.  To re-connect to this network in the future, select it from the list, and click Connect."

Reconnection is possible

Once you have manually disconnected from R1, you can follow the above instructions to select R1 from the list and successfully reconnect.

Houston, we have a problem!

Those instructions are well and good except for one minor problem.  Once you disconnect from an access point that isn't broadcasting its SSID, that network can disappear from the list making it impossible to select it for reconnection.

Refresh network list

For example, if you click the link in the upper-left of Figure 6 that reads "Refresh network list" after manually disconnecting from the network, the R1 network will no longer appear on the list.  Therefore, it cannot be selected for reconnection.

R1 is now in the Manual state

Furthermore, if you view the list of Preferred networks in Figure 7, you will see that the the R1 network is now showing Manual instead of Automatic.



Figure 7

The state of R1 must be changed back to Automatic in order for Windows to be able to reconnect automatically.

Converting R1 to Automatic state

One way to convert R1 back to the Automatic state is to remove it from the list in Figure 7 and then add it back to the list.  When you do that and then click the OK button in Figure 7, Windows should automatically reconnect to the R1 network.

Forcing Windows to connect to R1

I believe that it is safe to say that if there is a network that is active and within range, but which is not broadcasting its SSID, you can cause Windows to automatically connect to that network by making it the topmost (and possibly only) network in the list of Preferred networks and making certain that it is showing to be in an Automatic state.

R1 takes a back seat to another network

However, if the topmost network on the list is not broadcasting its SSID and there is another active network (within range of the computer) further down the list that is broadcasting its SSID, Windows won't connect to the network that is not broadcasting its SSID.  Rather, Windows will connect to the one further down the list that is broadcasting its SSID.

Must be careful about mixing networks 

The implication is that if you mix networks that don't broadcast their SSID with networks that do broadcast their SSID on the Preferred networks list, those that don't broadcast their SSID will be ignored by Windows if those that do broadcast their SSID are active and within range.

However, it should work fine to have two wireless networks, one which broadcasts its SSID and one that doesn't, on the list of Preferred networks provided they are not both active and within range at the same time.

For example, I could have a home network that doesn't broadcast its SSID on the list along with a college network that does broadcast its SSID.  Because my home is several miles away from the college where I teach, Windows will never see both of those networks active and within range at the same time.

Evidence to support the above conclusion

When I pulled the power plug on the belkin54g router, forcing it to become inactive and stop broadcasting its SSID, Windows immediately disconnected from belkin54g and reconnected to R1.

A funny thing happened on the way to the forum

However, when I reconnected power to belkin54g, Windows did not disconnect from R1 and  reconnect to belkin54g.  Rather, Windows remained connected to R1.

The implication seems to be that once Windows identifies the router that is not broadcasting its SSID and enters it into the list on the Wireless Network Connection dialog, it is happy to stay connected to that network as in Figure 6.  This doesn't seem to agree with that portion of the Microsoft quotation that reads

"Additionally, when your computer is connected to an access point that is not broadcasting its SSID, and another access point that is broadcasting its SSID is enabled nearby, your computer automatically connects to the access point that is broadcasting its SSID."


Copyright 2005, Richard G. Baldwin.  Reproduction in whole or in part in any form or medium without express written permission from Richard Baldwin is prohibited.

About the author

Richard Baldwin is a college professor (at Austin Community College in Austin, TX) and private consultant whose primary focus is a combination of Java, C#, and XML. In addition to the many platform and/or language independent benefits of Java and C# applications, he believes that a combination of Java, C#, and XML will become the primary driving force in the delivery of structured information on the Web.

Richard has participated in numerous consulting projects and he frequently provides onsite training at the high-tech companies located in and around Austin, Texas.  He is the author of Baldwin's Programming Tutorials, which have gained a worldwide following among experienced and aspiring programmers. He has also published articles in JavaPro magazine.

In addition to his programming expertise, Richard has many years of practical experience in Digital Signal Processing (DSP).  His first job after he earned his Bachelor's degree was doing DSP in the Seismic Research Department of Texas Instruments.  (TI is still a world leader in DSP.)  In the following years, he applied his programming and DSP expertise to other interesting areas including sonar and underwater acoustics.

Richard holds an MSEE degree from Southern Methodist University and has many years of experience in the application of computer technology to real-world problems.

Baldwin@DickBaldwin.com

-end-