The way we avoid this is with airtight. You can specify what networks your users are allowed to connect to and which they can't. Also prevents them from dual homing.
On Apr 13, 2011, at 12:56, "Timothy Ouellette" <[email protected]> wrote: > I do have to say that is another major concern. All legal set aside for the > moment (I am going to have them consult their lawyer for a verbiage > agreement on the AUP) the last thing I need is corporate laptop/mobile users > switching over to guest Wi-Fi bypassing the existing content filtering in > place for the clients private network. I'm wondering if there is a way to do > an almost 'reverse-MAC auth'. Meaning adding a list of MAC addresses not > allowed to authenticate (the exact opposite of your standard MAC Auth > mentality) so I can prevent the clients' users from doing this. I do > understand this would be easily thwarted using a spoofed MAC address but I > don't see your average user figuring that one out and remember this is too > keep users off an already open network not hackers off the private one. > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Robin Wood > Sent: Wednesday, April 13, 2011 10:06 AM > To: PaulDotCom Security Weekly Mailing List > Cc: Butturini, Russell > Subject: Re: [Pauldotcom] Guest Wifi Policy? > > On 13 April 2011 13:24, Butturini, Russell > <[email protected]> wrote: >> We do the same thing. One thing I do here also is run my guest Wi-Fi >> through the same content filter my corporate users use with a slightly > more >> relaxed rules set. This becomes a great deterrent for my internal users >> bringing in their personal devices and downloading movies etc. while on my >> network (Plus if they try, it becomes easy to catch them, which has > happened >> before). > > I've done testing for a client who has an open guest network and a lot > of people from the large international brand company next door use > their network for internet access, I guess it is to avoid their own > filters. > > Robin > >> >> >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Matthew Perry >> Sent: Wednesday, April 13, 2011 6:41 AM >> To: PaulDotCom Security Weekly Mailing List >> Subject: Re: [Pauldotcom] Guest Wifi Policy? >> >> >> >> We have a captive portal with a user agreement that they have to agree to >> before getting access to the internets. Last year we had a law office >> contact us about someone downloading a bittorrent for a popular movie at > the >> time and our verbiage on the captive portal seemed good enough for them. >> >> On Tue, Apr 12, 2011 at 12:14 PM, Timothy Ouellette > <[email protected]> >> wrote: >> >> Gentlemen, >> >> >> >> I am tasked with providing a Guest Wi-Fi solution for one of my clients. > The >> client already has an enterprise WLAN which is secured with radius and all >> that good stuff. Plan for the Guest Wi-Fi is to simply broadcast a second >> SSID on a separate VLAN taking them straight out to an onsite DSL circuit. >> Nothing fancy, no content filtering intended or desired by the client. > Just >> open internet obviously secured and separated from their private network. > I >> do intend to put up a captive portal or some sort of page which forces all >> users accessing the guest network to 'agree' with the internet usage > policy. >> >> >> >> So my question here is does anyone know what I have to do to ensure that > my >> client is not liable for anything that happens on this guest network, i.e. >> someone gets hacked, or some pervert is browsing from their IP and the FBI >> get's involved etc... My assumption is that you need to have a proper >> captive portal with proper verbiage on your 'user agreement' and I'm also >> assuming you need to log 'clicks' on the page when users 'agree' to your >> usage policy. >> >> >> >> Any experience or thoughts on this one? >> >> >> >> Thanks, >> >> Tim >> >> _______________________________________________ >> Pauldotcom mailing list >> [email protected] >> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >> Main Web Site: http://pauldotcom.com >> >> >> -- >> Matthew Perry >> >> > **************************************************************************** > ** >> This email contains confidential and proprietary information and is not to >> be used or disclosed to anyone other than the named recipient of this > email, >> and is to be used only for the intended purpose of this communication. >> > **************************************************************************** > ** >> >> _______________________________________________ >> Pauldotcom mailing list >> [email protected] >> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >> Main Web Site: http://pauldotcom.com >> > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com > > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com _______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
