This may be getting a bit off topic for the wireless discussion, but we use the "Security Risk" category of web filtering on our Fortigate firewall (http://www.fortiguard.com/webfilter). It works very well; it even alerted a faculty member to a hijack of their personal web site when they couldn't access it from campus and got the "malicious site" warning from our firewall.
Thomas Carter Network & Operations Manager Austin College -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Dale W. Carder Sent: Tuesday, March 1, 2016 12:43 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Self-registered MAC device bypass- worth the headaches? Thus spake Lee H Badman (lhbad...@syr.edu) on Tue, Mar 01, 2016 at 06:19:55PM +0000: > Interesting discussion- so on the free and open WLAN, do you send them off to > only the Internet, and deny important apps on campus? Do you require VPN or > 2-factor for bursar account access etc from that network? We do block things that I would characterize as ddos amplification vectors, and we block inbound SYN so discourage (unintentional) servers. We have started to look into some filtering capabilities on a firewall where there is some sort of blacklist for known malware sites (I am highly skeptical of such things, but if we can do it for low cost and provide a high value to our users, so be it). VPN is pretty much not used in the general case. Security is handled at the application layer. Your IP address is not an authorization token, and none of the few hundred virtual firewalls we run blindly allow much of anything through be it from wireless or from dept 'a' to dept 'b'. Dale > -----Original Message----- > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Dale W. > Carder > Sent: Tuesday, March 01, 2016 1:06 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] Self-registered MAC device bypass- worth the > headaches? > > There are of course lots of vendors selling lots of products to solve > lots of "problems". > > I will also echo everything that Jeff has said below. We read what > our requirements were and the educause community at the time was quite > active on this front, leading to the excellent summary on their site. > > So, yes, we operate one of these big open wireless love fests. ;-) > > Dale > > Thus spake Lee H Badman (lhbad...@syr.edu) on Tue, Mar 01, 2016 at 05:45:18PM > +0000: > > So... you open up a big wireless free love ranch, and let everything and > > everything on. How to keep 10K users off of each others devices? I'm not > > poo-pooing, just asking! > > > > > > -Lee > > ________________________________ > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Jeffrey D. Sessler > > <j...@scrippscollege.edu> > > Sent: Tuesday, March 1, 2016 12:37 PM > > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > > Subject: Re: [WIRELESS-LAN] Self-registered MAC device bypass- worth the > > headaches? > > > > I think your legal needs to revisit their position. There are a number of > > great articles about the EDU requirements of DMCA. A university is every > > bit the ISP, and in fact, there is no legal obligation under the DMCA for > > student enforcement as you are but the transit for their data. Most all > > campuses use it as a teaching moment, but it’s not a requirement. You also > > have no obligation to identify someone – If you rotate logs every 15 days > > and the request comes in on the 16th day, you can respond that you have no > > data. This is also no obligation to match an IP with a person. > > > > Jeff > > > > From: > > "wireless-lan@listserv.educause.edu<mailto:wireless-...@listserv.edu > > cause.edu>" > > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:wireless-...@listserv.edu > > CAUSE.EDU>> on behalf of Mike Cunningham > > <mike.cunning...@pct.edu<mailto:mike.cunning...@pct.edu>> > > Reply-To: > > "wireless-lan@listserv.educause.edu<mailto:wireless-...@listserv.edu > > cause.edu>" > > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:wireless-...@listserv.edu > > CAUSE.EDU>> > > Date: Tuesday, March 1, 2016 at 9:31 AM > > To: > > "wireless-lan@listserv.educause.edu<mailto:wireless-...@listserv.edu > > cause.edu>" > > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:wireless-...@listserv.edu > > CAUSE.EDU>> > > Subject: Re: [WIRELESS-LAN] Self-registered MAC device bypass- worth the > > headaches? > > > > Talk to your campus legal office before opening your wifi to the world. We > > asked ours about this and were strongly advised against it. Contracting > > with a local telecom company to provide free wifi would be better. A > > college or university is not an ISP like a Verizon or AT&T or Comcast is. > > If someone is abusing the campus network you’re responsible for their > > action. If law enforcement comes knocking on your door asking about network > > traffic originating from you campus you need to be able to point to a > > person or at least a room and say “there”. If it was a guest on campus for > > a short period of time you still need to be able to identify who that guest > > was. At least that is the interpretation of current law according to our > > legal office. > > > > Mike Cunningham > > Pennsylvania College of Technology > > > > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of David R. > > Morton > > Sent: Tuesday, March 01, 2016 12:21 PM > > To: > > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:wireless-...@listserv.educ > > AUSE.EDU> > > Subject: Re: [WIRELESS-LAN] Self-registered MAC device bypass- worth the > > headaches? > > > > Joel, thanks for the detailed reply. I agree that Personal PSK is an > > interesting idea, but it may fall apart at scale (we see 200k+ devices per > > week), security, implementation or other burdens. My thoughts about on > > boarding, user name as part of the credential/password have been along the > > same lines as yours. While we wouldn’t put all of their devices on the same > > VLAN, I would see them being able to access their printers, chrome cast, > > AppleTV, etc. The later is already possible using something like ClearPass > > and AirGroup. > > > > We’ve been engaged in some conversations with our vendor about how to solve > > this problem, but so far there isn’t anything to report. > > > > As an aside, we are also keeping an eye on MAC randomization and how this > > might impact systems based on MAC for authentication and other headaches. > > > > David > > > > > > > > > > > > David Morton > > Director, Mobile Communications > > Service Owner: Wi-Fi, Mobile & HuskyTV University of Washington > > dmor...@u.washington.edu<mailto:dmor...@u.washington.edu> > > tel 206.221.7814 > > > > On Mar 1, 2016, at 9:02 AM, Coehoorn, Joel > > <jcoeho...@york.edu<mailto:jcoeho...@york.edu>> wrote: > > > > Ruckus supports a PPSK variant, as well. > > > > I'm just gonna put this out there. I have this idea in my head for an ideal > > wifi service. It starts with personal pre-shared key (PPSK), but it's > > something I don't believe is possible yet with any vendor. > > > > Step one is to create a unique key prefix for each user, effectively > > embedding a username value (the prefix) into the same field as the > > key/password. The prefix would be as short as possible, perhaps as small as > > three characters, in order to keep entry into devices simple. The purpose > > of this prefix is to allow users to choose their own wifi password, while > > still ensuring that each PSK value is unique and identifiable to a given > > user. If we don't value allowing users to choose their own wifi passwords, > > we could instead generate and assign them, and just map back the assigned > > key to the user.. but I believe there is value in this. > > > > Users would onboard by first connecting to a portal available via > > open/limited ssid to claim their key. They would have to log in with their > > traditional username/password. The portal would then prompt them for a key > > suffix (their wifi password), and then show them the complete key (prefix + > > suffix), which would be registered with our system. It would also have > > options to show them history for devices authenticated using their key, > > expire an old/create a new key using the same prefix, and other typical > > account management options. Once created, that key could be used with > > anything that supports traditional PSK connections. > > > > One important feature that I'd like to see as part of this, and what I > > think helps make this idea unique, is that devices authenticated with the > > same PPSK should always end up with the same vlan id. In this way, a > > student would be able to, for example, connect to a desktop in his room > > from the phone/tablet he brought to class and grab a file he forget to show > > an instructor. It also makes things like wireless printers, long the bane > > or our existence, almost reasonable in terms of setup and support. > > > > By keeping a prefix that's unique to each user, or mapping all key > > assignments back to the user, we can still always know who is responsible > > for a given device. We could do things like get a report of keys that > > authenticate more than, say, 6 devices to monitor for key abuse, expire > > keys when there is a problem, engage a known user when expiring old keys is > > not enough, and even map users to specific vlan pools for network policy > > enforcement. We could also create keys for events or specially classes of > > device (security cameras, door locks, wifi phones, etc). Additionally, > > per-user keys means each user's over-the-air signals have different > > encryption keys, preventing things like firesheep from working. This is > > just about all the things we do with 802.1x today, but in a form that's > > much friendlier to the consumer devices we have to support. > > > > This plan effectively embeds a username (the prefix) and a password > > (suffix) into the same value, with our without the prefix, so some of the > > same security concerns apply, but these are solvable problems. We just need > > to get vendors on board with the idea. > > > > > > [http://www.york.edu/Portals/0/Images/Logo/YorkCollegeLogoSmall.jpg] > > > > Joel Coehoorn > > Director of Information Technology > > 402.363.5603 > > jcoeho...@york.edu<mailto:jcoeho...@york.edu> > > > > > > > > The mission of York College is to transform lives through > > Christ-centered education and to equip students for lifelong service > > to God, family, and society > > > > On Tue, Mar 1, 2016 at 10:20 AM, David R. Morton > > <dmor...@uw.edu<mailto:dmor...@uw.edu>> wrote: > > Matt, Bill and others, > > > > You’d indicated that you have instructions for most common devices, is this > > something that you can share. Like others, we have a manual registration > > process (built on ClearPass), but it does require the MAC in order to > > complete the registration. The Amazon Echo is now relatively > > straightforward, as it shows up in the Alexa app after you’ve connected > > your phone to the Echo. To find it, users open the Alexa app, go to > > settings, choose the device and scroll all the way down to the bottom of > > the screen. There it will show you the software version, serial number and > > MAC address. All of that said, I haven’t been able to test the latest > > versions to see if you can do all of this without needing to connect to the > > Internet. If you aren’t we are back at square one and have to take it off > > site to get through the initial setup, which is a real pain. > > > > Another device we’ve had a lot of issues with is the newest AppleTV. Again > > I haven’t checked the latest update so this may have changed, but when it > > first came out, you had to do a little dance to get the MAC. The dance had > > you connect it to wired, navigate to the network settings when the MAC > > address and then remove the wired cable. This would put the device back > > into Wi-Fi mode and would display the Wi-Fi MAC. Then you are able to > > manually register it and go through the complete process. > > > > Chromecast has had a few other issues, mostly related to dropping sessions > > and making poor AP choices. > > > > This whole discussion has got me thinking and brings up a topic that > > I think that the industry needs to address. There is a growing > > number of devices that don’t support 802.1x and the number those > > devices will continue to as Internet of Things and more consumer > > devices make it onto our campuses. We need a better, easier way for > > our students, faculty and staff to connect appropriate devices to > > the network. Using a captive portal is one way to try to get around > > these restrictions and get the devices on the network, but as this > > thread demonstrates it brings other difficulties. Some schools use a > > PSK network to onboard non-802.1x devices, but this too has > > problems. While it makes it easy for the user to get devices on the > > network, there isn’t a good way to track the owner of that device. > > It also raises and issue of why anyone would go through the 802.1x > > process when they can just put their devices on the PSK network. > > Putting restrictions on the PSK network will help, but still not a > > great solution. \ > > > > David > > > > > > > > > > David Morton > > Director, Mobile Communications > > Service Owner: Wi-Fi, Mobile & HuskyTV University of Washington > > dmor...@u.washington.edu<mailto:dmor...@u.washington.edu> > > tel 206.221.7814<tel:206.221.7814> > > > > On Mar 1, 2016, at 7:21 AM, Williams, Matthew > > <mwill...@kent.edu<mailto:mwill...@kent.edu>> wrote: > > > > Our helpdesk folks sat down and wrote up documents on how to find the MAC > > addresses for as many devices as they could. We haven’t done any > > instructions for the Amazon Echoes yet. We hit the most common devices and > > are waiting to see what tickets we get for devices that we missed so we can > > build them into our registration page. Our registration page was written > > in-house and the developers set it up to display the instructions for > > finding the MAC address, including screen shots, based on the device that > > you selected in the drop down. > > > > Respectfully, > > > > Matt > > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Thomas > > Carter > > Sent: Tuesday, March 1, 2016 10:01 AM > > To: > > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:wireless-...@listserv.educ > > ause.edu> > > Subject: Re: [WIRELESS-LAN] Self-registered MAC device bypass- worth the > > headaches? > > > > This is something we struggle with, especially being a small school. > > Keeping up with the latest Chromecast/Roku/Amazon Echo, etc devices is near > > impossible. A big thank you to product designers who put the MAC on a label > > on the outside. > > > > Thomas Carter > > Network & Operations Manager > > Austin College > > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H > > Badman > > Sent: Tuesday, March 1, 2016 8:12 AM > > To: > > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:wireless-...@listserv.educ > > AUSE.EDU> > > Subject: [WIRELESS-LAN] Self-registered MAC device bypass- worth the > > headaches? > > > > Hi Everyone, > > > > Not looking for a lot of input on all of the things you CAN do- just asking > > a focused question for those that are doing it. > > > > We're piloting the ability for students to self-register games, TVs, Roku, > > etc. but am astounded at how hard some devices are to find MAC addresses > > for from the user side. Amazon Echo is notorious, also fighting with a Roku > > 2. No labels, not easy to find in menu. Sure, you can find all of this on > > APs, but that isn't "self-service" for self-registration. > > > > Anyone have thoughts, comments, scars, suggestions? I know Clearpass and > > ISE can fingerprint, but I'm finding that's far from accurate at times, and > > again- doesn't help with "register YOUR device by MAC" for users that can't > > see what network admins use. > > > > -Lee Badman > > > > Lee H. Badman > > Network Architect/Wireless TME > > ITS, Syracuse University > > 315.443.3003<tel:315.443.3003> > > ********** 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/. > > ********** 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/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
