Frank, Thanks for the tips. I have a few concerns though.
> product can disrupt ad-hoc connections. So it's possible. Most ad-hoc > connections are accidental I'm not so sure that so many of these ad-hoc networks are accidental (some disappear when our presence is detected) Students use Ad-Hoc networks to share printing in the dorms, or sometimes exchange files in study rooms were WLAN is not available. Or share answers during online tests without using the infrastructure! Some applications (like the ones to aid hearing impaired people) request Ad-Hoc networking by design. (we have a few of these recognized Ad-Hoc on campus) , so if there were some way to somehow email the > student back about this (if you had registered the MAC address of the > student's wireless NIC, Most Ad-Hocs don't use the MAC of the NIC but a randomly generated one. That's our problem, detection is almost impossible in a loaded classroom. We can neither find the location, nor the registered MAC. Prevention or disruption are the only 2 actions that we have thought about. In prevention we only do one thing: make sure that XP is on infrastructure ONLY...we don't dare to delete Ad-Hoc networks from students laptops during registration. Too controversial. On the disruption side, we haven't done anything yet. I have heard about Air-Dedense and often wonder how legal it is to attack other people's network... Jamming is illegal in the USA for licensed spectrum...I wonder about unlicended spectrum. Under Part15 jamming seems ok but a disruption is also sort of a Denial Of Service... There is the UT Dallas story on Rogue APs, I wonder when someone will come up with a DoS suit for an appliance ;-) I wouldn't be to worry in a campus that's isolated but what if you are in a city and your Air-Defense disrupts legitimate networks. You build a list of exceptions...how often do you review the exceptions? Philippe Hanset Univ. of TN or, if you learned the MAC address of student's > wireless NIC because your network requires authenticated login) you would > quickly reduce the number of false alarms for those un-configured PCs. > > Regards, > > Frank > > > -----Original Message----- > From: Philippe Hanset [mailto:[EMAIL PROTECTED] > Sent: Monday, February 07, 2005 9:45 AM > To: Frank Bulk > Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: RE: [WIRELESS-LAN] Wireless Identification Tools > > Frank, > > We have no problem detecting them (we use the RAD function in our APs which > detects Ad-Hoc as well)! > We have problems stopping them. > Most of the time they are hidden in an > auditorium with 160 other laptops all > about 3 feet apart from each other. > I don't see our technicians entering classrooms and aiming Directional > antennas at individuals ;-) (could be a good "WLAN geek thriller" though). > > That's why we try to prevent the situation by changing the registry entry > (not through active directory, but through an executable that we developped > to check for patch level etc...). > > I understand that Airdefense has an Active mechanism to deny 802.11 > associations. Do they let you deny Ad-Hoc only? > > Philippe Hanset > Univ. of TN > > > > > On Sun, 6 Feb 2005, Frank Bulk wrote: > > > Philippe: > > > > AFAIK, the only way to catch ad-hoc networks is to use some kind of > > wireless security system (such as those provided by AirDefense, > > AirMagnet, etc) or use the IDS' in wireless switch vendors (such as > > Airespace, Aruba, Trapeze, etc). All of these products detect ad-hoc > > networks, though I'm not sure which ones exactly catch them based on > > the probes or if it requires an actual connection and communication. > > > > The use of a registry key to pre-dispose a certain behavior is smart > > thinking. Do Active Directory-based group policies accomplish the > > same thing? > > > > Regards, > > > > Frank > > > > -----Original Message----- > > From: Philippe Hanset [mailto:[EMAIL PROTECTED] > > Sent: Saturday, February 05, 2005 12:39 PM > > To: Frank Bulk > > Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > > Subject: Re: [WIRELESS-LAN] Wireless Identification Tools > > > > Allow me to throw some oil on this hot topic: > > > > I was saying: "we rarely have rogue APs in places were we provide > > decent free wireless coverage"...well... > > > > I forgot one issue though: Ad-Hoc/Peer-to-Peer wireless networks. > > (not Rogue APs, but definitely Rogue something!) Those are blooming > > all over campus, and people have the good taste to name their Ad-Hoc > > with the same SSID as our infrastructure. > > Creating race conditions all over the places. > > To help, Microsoft enables join "Any Available Network" by default. > > (SP2 seems to help with "access point preferred") We have had > > classrooms paralyzed by 2 "misconfigured" machines. > > The Macintosh is even a worse case. > > > > In the future our registration system will change a registry key to > > force machines to be in join "Access point networks only". > > That doesn't cover Macs though. > > > > How do you deal with Ad-Hoc? > > > > Philippe Hanset > > Univ of TN > > > > On Sat, 5 Feb 2005, Frank Bulk wrote: > > > > > Lee: > > > > > > I agree that providing wireless is not the final answer, but it does: > > > a) open the pressure valve so that those who really want to use > > > wireless can do it while abiding within the organization's policies > > > b) provide a condoned alternative to those already breaking policy > > > so that they have no real excuse. > > > > > > In a larger organization it can be more difficult to personally > > > visit each office and building and make sure that policy is being > > > adhered to, but if the WLAN administrator has support from > > > management, educates users, can apply some reasonable sanctions, and > > > quickly detect policy violations (if your wireless system has rogue > > > detection than this is reasonable -- walking around once a week > > > should not be considered effective), I think the employees will > > > learn that deploying > > rogue access points is a no-no. > > > > > > Of course, this is all easier said than done, especially in > > > educational environments where the emphasis on learning and academic > > > freedom seem more often than not to trump institutional policies. > > > This is tied along with the idea that many portions of an academic > > > network don't contain valuable intellectual property or data. But > > > if the institution values security (just think of the last few news > > > reports about schools discovering that thousands of records had been > > > retrieved) and considers the value of research work, hopefully they > > > will > > change their mind. > > > > > > Kind regards, > > > > > > Frank Bulk > > > > > > > > > -----Original Message----- > > > From: 802.11 wireless issues listserv > > > [mailto:[EMAIL PROTECTED] On Behalf Of Lee Badman > > > Sent: Saturday, February 05, 2005 9:50 AM > > > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > > > Subject: Re: [WIRELESS-LAN] Wireless Identification Tools > > > > > > Frank- > > > > > > I have found that in reality, providing wieless doesn't do all that > > > much to dissuade users from bringing their own gear- there is still > > > the problem on campuses of users who: > > > > > > - don't know they can't use their own, regardless of how many ways > > > you try to get the word out > > > - don't care > > > - insist that if they own it, they should be able to use it > > > - feel that the policy and architecture of a centrally managed WLAN > > > is an impediment > > > > > > It's dangerous to assume that by providing wireless, the problems of > > > self-installed goes away. I've found that it helps, but is far from > > > being the end of the story. > > > > > > Lee > > > > > > >>> Frank Bulk <[EMAIL PROTECTED]> 02/04/05 09:33PM >>> > > > If you are looking to find Ethernet devices on your network the open > > > source Netdisco is good place to start: > > > http://netdisco.org > > > > > > If you are running a homogenous network with Cisco, Foundry, or some > > > other vendor that has CDP, etc support, it should be easy enough to > > > whip up a Perl script that traces the port from the core down to the > > > edge. I wrote one two years ago for our Cisco network and it does > > > in seconds what took me minutes by hand with consecutive telnet > sessions. > > > Rogue PC's that showed up on our ResNET were automatically traced > > > and > > recorded for later visitations. > > > > > > At the end of the day you don't want to have to walk around your > > > dorms with a PocketPC to find rogue devices. I think you're much > > > better off doing some wireside detection (that looks for nodes that > > > have not registered with your ResNET system), use some more > > > affordable wireless security such as provided by Network Chemistry, > > > or, better yet, obviate the need by providing wireless service in those > areas. > > > > > > Frank > > > > > > -----Original Message----- > > > From: 802.11 wireless issues listserv > > > [mailto:[EMAIL PROTECTED] On Behalf Of Metzler, > > > David > > > Sent: Friday, February 04, 2005 7:18 PM > > > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > > > Subject: Re: [WIRELESS-LAN] Wireless Identification Tools > > > > > > We take a similar tact, but use the idea of tracking the IP address > > > reported by an internal campus web server to a specific location. > > > (Which we need to do for virus outbreaks anyway) Because we use > > > VLAN's it's a little tedious to search all networks for a similar mac > address. > > > > > > So we use a little server side script to report the IP address as > > > its seen by our web server (this gives you the external address even > > > on NAT enabled AP's. > > > > > > The process is as follows: > > > > > > 1. When we find the wireless signal that we can get internet > > > connection on visit the following web page: > > > http://www.evergreen.edu/netservices/clientinfo.asp (this page was > > > designed small enough to display easily on pocket pc or other handheld). > > > > > > > > > 2. Go to the internal router for the subnet or get on the same > > > subnet and arp the ip to obtain the mac address. (there's problably > > > more graceful ways to do this, particularly if you're on the same > subnet). > > > > > > 3. Follow the switch tables to track the port to its physical > > > location on our LAN. > > > > > > I find having the IP as reported by the web server, also lets me > > > know how worried to be about the rougue AP, since it tells me > > > instantly if its on a public network jack or a higher security > > > network. (again VLANs make it harder to know). > > > > > > David Metzler > > > The Evergreen State College > > > > > > -----Original Message----- > > > From: 802.11 wireless issues listserv > > > [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Wolfe > > > Sent: Friday, February 04, 2005 12:53 PM > > > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > > > Subject: Re: [WIRELESS-LAN] Wireless Identification Tools > > > > > > Philippe Hanset wrote: > > > > Don, > > > > > > > > A trick that I have been willing to test for a long time would be > > > > to join the Rogue AP, send traffic to a know sniffing host in that > > > > same > > > > layer2 network. > > > > This will reveal the Wired MAC address of the AP. > > > > Then search for that MAC on your wired side and disable the port. > > > > (if you have a good circuit-to-switchport DB, you know the > > > > location > > > as > > > > well) > > > > If the AP doesn't allow guests, we use Directional Antennas and > > > > Wireless Sniffers as you mentioned. > > > > > > > > And as I have mentioned before: we rarely have Rogue APs in places > > > > were we provide decent Free Wireless coverage! > > > > > > We've been able to have good luck by searching our switch FDBs for > > > MAC addresses matching all but the last octet of the MAC address in > > > the rogue AP's beacon. More often than not, manufacturers use > > > sequential MAC addresses for the wired and wireless ports of their > > > devices. Of the 5 or > > > 6 rogues we've seen over the last year, all were locatable that way. > > > > > > YMMV.. :) > > > > > > > > > -JEff > > > > > > ********** > > > Participation and subscription information for this EDUCAUSE > > > Constituent Group discussion list can be found at > > http://www.educause.edu/groups/. > > > > > > ********** > > > Participation and subscription information for this EDUCAUSE > > > Constituent Group discussion list can be found at > > http://www.educause.edu/groups/. > > > > > > ********** > > > Participation and subscription information for this EDUCAUSE > > > Constituent Group discussion list can be found at > > http://www.educause.edu/groups/. > > > > > > ********** > > > Participation and subscription information for this EDUCAUSE > > > Constituent Group discussion list can be found at > > http://www.educause.edu/groups/. > > > > > > ********** > > > Participation and subscription information for this EDUCAUSE > > > Constituent > > Group discussion list can be found at http://www.educause.edu/groups/. > > > > > > > > > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
