PaulDotCom mailing list archives

Re: Guest Wifi Policy?


From: Uriah Robins <urobins () ncmec org>
Date: Wed, 13 Apr 2011 17:11:32 +0000

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" <touellette83 () gmail com> 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: pauldotcom-bounces () mail pauldotcom com
[mailto:pauldotcom-bounces () mail pauldotcom com] 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
<Russell.Butturini () healthways com> 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: pauldotcom-bounces () mail pauldotcom com
[mailto:pauldotcom-bounces () mail pauldotcom com] 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
<touellette83 () gmail com>
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
Pauldotcom () mail pauldotcom com
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
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com

_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com

_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com
_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com


Current thread: