RE: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms)
We'll be replacing our switches over the next 6-18 months, and I'm hoping the new ones may include this capability. David Gillett _ From: Jason Todd [mailto:jt...@westernu.edu] Sent: Tuesday, September 20, 2011 08:06 To: WIRELESS-LAN@listserv.educause.edu Subject: Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) Our rogue DHCP server problems went away once we started blocking DHCP offers at the edge. Before that we were hooking protocol analyzers up to the segment having problems to detect rogues. Jason Todd Network Security Officer Western University of Health Sciences From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Helman Sent: Tuesday, September 20, 2011 5:22 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN] Wireless in dorms) Oh, tell me more about this perl script you are using. Anyone else have good methods for identifying and terminating rogue DHCP (and rogue AP's for that matter) servers? -Brian _ From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Ray DeJean [r...@selu.edu] Sent: Monday, September 19, 2011 12:11 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie grac...@canisius.edu wrote: On 09/19/2011 11:04 AM, Ray DeJean wrote: All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of course we realize the interference issues that may arise in a crowded 2.4ghz space... The University of Wisconsin-Madison (http://www.housing.wisc.edu/resnet/gameConsoles.php) already has a policy like this in place. Just looking to hear from other universities who have or are considering a policy such as this. You don't mention what kind of network architecture you have - if you're using a relatively flat topology, with comingling of residence hall, administrative, and academic traffic, be sure that you've got technology and procedures in place to shut down misconfigured endpoints. Nobody will be happy when they start getting RFC1918 addresses from the DHCP server on little Timmy's free-with-rebate Linksys AP. -- Matt Gracie (716) tel:%28716%29%20888-8378 888-8378 Information Security Administrator grac...@canisius.edu Canisius College ITSBuffalo, NY http://www2.canisius.edu/~graciem/graciem_public_key.gpg ** 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
Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms)
On 9/20/2011 11:52 AM, David Gillett wrote: We'll be replacing our switches over the next 6-18 months, and I'm hoping the new ones may include this capability. Just be a bit cautious... our city buses offer free WiFi on board. We were deauth-ing / dropping users on the buses when they drove through campus :) Jeff ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN] Wireless in dorms)
We are using the last version of this script: https://roguedetect.bountysource.com/ It's pretty old but works for us. We may have made some minor changes for our environment. I think mainly the script would only email the mac, and i modified it to also report the interface/vlan. Each of our 22 dorms is a different vlan, so we brought 22 vlan interfaces up on a central linux box, and just kick off the script on each interface every 30 minutes. It emails us the vlan and mac address of rogues, and we put that mac in a quarantine vlan. All traffic in the quarantine gets redirected to a page that says let us know when you unplug the router and your internet access will be restored. It works, but it's a manual process for us and sometimes frustrating for the student (especially at the beginning of the semester). Dropping DHCPOFFER's at the edge seems like a much better solution, which is what we're moving to this week. (Our 3com 5500 switches can do it with ACLs. The older 4400 switches can do it with a QoS profile) ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu http://r-a-y.org On Tue, Sep 20, 2011 at 7:21 AM, Brian Helman bhel...@salemstate.eduwrote: Oh, tell me more about this perl script you are using. Anyone else have good methods for identifying and terminating rogue DHCP (and rogue AP's for that matter) servers? -Brian -- *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [ WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Ray DeJean [r...@selu.edu] *Sent:* Monday, September 19, 2011 12:11 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie grac...@canisius.eduwrote: On 09/19/2011 11:04 AM, Ray DeJean wrote: All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of course we realize the interference issues that may arise in a crowded 2.4ghz space... The University of Wisconsin-Madison (http://www.housing.wisc.edu/resnet/gameConsoles.php) already has a policy like this in place. Just looking to hear from other universities who have or are considering a policy such as this. You don't mention what kind of network architecture you have - if you're using a relatively flat topology, with comingling of residence hall, administrative, and academic traffic, be sure that you've got technology and procedures in place to shut down misconfigured endpoints. Nobody will be happy when they start getting RFC1918 addresses from the DHCP server on little Timmy's free-with-rebate Linksys AP. -- Matt Gracie (716) 888-8378 Information Security Administrator grac...@canisius.edu Canisius College ITSBuffalo, NY http://www2.canisius.edu/~graciem/graciem_public_key.gpg ** 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
RE: [WIRELESS-LAN] Rogue Device detection. (was[WIRELESS-LAN]Wireless in dorms)
The state mandates a competitive bidding process, so it will be some time before I know the vendor, let alone the model. We're far enough into the process that I probably can't get this added to our list of required functionality. I just have to hope it has become a common enough feature (since the last time we did this) that whoever we wind up with supports it, one way or another. David Gillett _ From: Leo Song [mailto:s...@uoguelph.ca] Sent: Tuesday, September 20, 2011 09:03 To: WIRELESS-LAN@listserv.educause.edu Subject: Re: [WIRELESS-LAN] Rogue Device detection. (was[WIRELESS-LAN]Wireless in dorms) Hi, David. What specific switch model you are going to use? Leo Song, Senior Analyst Cluster Lead Computing and Communication Services - Networking and Security University of Guelph (519) 824-4120 x 53181 _ From: David Gillett gillettda...@fhda.edu To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Sent: Tuesday, September 20, 2011 11:52:34 AM Subject: Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) We'll be replacing our switches over the next 6-18 months, and I'm hoping the new ones may include this capability. David Gillett _ From: Jason Todd [mailto:jt...@westernu.edu] Sent: Tuesday, September 20, 2011 08:06 To: WIRELESS-LAN@listserv.educause.edu Subject: Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) Our rogue DHCP server problems went away once we started blocking DHCP offers at the edge. Before that we were hooking protocol analyzers up to the segment having problems to detect rogues. Jason Todd Network Security Officer Western University of Health Sciences From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Helman Sent: Tuesday, September 20, 2011 5:22 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN] Wireless in dorms) Oh, tell me more about this perl script you are using. Anyone else have good methods for identifying and terminating rogue DHCP (and rogue AP's for that matter) servers? -Brian _ From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Ray DeJean [r...@selu.edu] Sent: Monday, September 19, 2011 12:11 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie grac...@canisius.edu wrote: On 09/19/2011 11:04 AM, Ray DeJean wrote: All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of course we realize the interference issues that may arise in a crowded 2.4ghz space... The University of Wisconsin-Madison (http://www.housing.wisc.edu/resnet/gameConsoles.php) already has a policy like this in place. Just looking to hear from other universities who have or are considering a policy such as this. You don't mention what kind of network architecture you have - if you're using a relatively flat topology, with comingling of residence hall, administrative, and academic traffic, be sure that you've got technology and procedures in place to shut down misconfigured endpoints. Nobody will be happy when they start getting RFC1918 addresses from
Re: [WIRELESS-LAN] Rogue Device detection. (was[WIRELESS-LAN]Wireless in dorms)
Most enterprise class equipment (Cisco, Brocade, etc) come with dhcp-snooping standard now. Not sure about Juniper, and I think I heard the HP does it. I have DHCP-Snooping up in all student areas. Heath On 9/20/2011 11:16 AM, David Gillett wrote: The state mandates a competitive bidding process, so it will be some time before I know the vendor, let alone the model. We're far enough into the process that I probably can't get this added to our list of required functionality. I just have to hope it has become a common enough feature (since the last time we did this) that whoever we wind up with supports it, one way or another. David Gillett *From:* Leo Song [mailto:s...@uoguelph.ca] *Sent:* Tuesday, September 20, 2011 09:03 *To:* WIRELESS-LAN@listserv.educause.edu *Subject:* Re: [WIRELESS-LAN] Rogue Device detection. (was[WIRELESS-LAN]Wireless in dorms) Hi, David. What specific switch model you are going to use? Leo Song, Senior Analyst Cluster Lead Computing and Communication Services - Networking and Security University of Guelph (519) 824-4120 x 53181 *From: *David Gillett gillettda...@fhda.edu *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Sent: *Tuesday, September 20, 2011 11:52:34 AM *Subject: *Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) We'll be replacing our switches over the next 6-18 months, and I'm hoping the new ones may include this capability. David Gillett *From:* Jason Todd [mailto:jt...@westernu.edu] *Sent:* Tuesday, September 20, 2011 08:06 *To:* WIRELESS-LAN@listserv.educause.edu *Subject:* Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) Our rogue DHCP server problems went away once we started blocking DHCP offers at the edge. Before that we were hooking protocol analyzers up to the segment having problems to detect rogues. Jason Todd Network Security Officer Western University of Health Sciences *From:*The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Brian Helman *Sent:* Tuesday, September 20, 2011 5:22 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN] Wireless in dorms) Oh, tell me more about this perl script you are using. Anyone else have good methods for identifying and terminating rogue DHCP (and rogue AP's for that matter) servers? -Brian *From:*The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Ray DeJean [r...@selu.edu] *Sent:* Monday, September 19, 2011 12:11 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu mailto:r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie grac...@canisius.edu mailto:grac...@canisius.edu wrote: On 09/19/2011 11:04 AM, Ray DeJean wrote: All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of course we realize the interference issues that may arise in a crowded
Re: [WIRELESS-LAN] Rogue Device detection. (was[WIRELESS-LAN]Wireless in dorms)
I can confirm Juniper does it. On Tue, Sep 20, 2011 at 5:47 PM, Heath Barnhart heath.barnh...@washburn.edu wrote: Most enterprise class equipment (Cisco, Brocade, etc) come with dhcp-snooping standard now. Not sure about Juniper, and I think I heard the HP does it. I have DHCP-Snooping up in all student areas. Heath On 9/20/2011 11:16 AM, David Gillett wrote: The state mandates a competitive bidding process, so it will be some time before I know the vendor, let alone the model. We're far enough into the process that I probably can't get this added to our list of required functionality. I just have to hope it has become a common enough feature (since the last time we did this) that whoever we wind up with supports it, one way or another. David Gillett -- *From:* Leo Song [mailto:s...@uoguelph.ca s...@uoguelph.ca] *Sent:* Tuesday, September 20, 2011 09:03 *To:* WIRELESS-LAN@listserv.educause.edu *Subject:* Re: [WIRELESS-LAN] Rogue Device detection. (was[WIRELESS-LAN]Wireless in dorms) Hi, David. What specific switch model you are going to use? Leo Song, Senior Analyst Cluster Lead Computing and Communication Services - Networking and Security University of Guelph (519) 824-4120 x 53181 -- *From: *David Gillett gillettda...@fhda.edu gillettda...@fhda.edu *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Sent: *Tuesday, September 20, 2011 11:52:34 AM *Subject: *Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) We'll be replacing our switches over the next 6-18 months, and I'm hoping the new ones may include this capability. David Gillett -- *From:* Jason Todd [mailto:jt...@westernu.edu jt...@westernu.edu] *Sent:* Tuesday, September 20, 2011 08:06 *To:* WIRELESS-LAN@listserv.educause.edu *Subject:* Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) Our rogue DHCP server problems went away once we started blocking DHCP offers at the edge. Before that we were hooking protocol analyzers up to the segment having problems to detect rogues. Jason Todd Network Security Officer Western University of Health Sciences *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [ mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDUWIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Brian Helman *Sent:* Tuesday, September 20, 2011 5:22 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN] Wireless in dorms) Oh, tell me more about this perl script you are using. Anyone else have good methods for identifying and terminating rogue DHCP (and rogue AP's for that matter) servers? -Brian -- *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [ WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Ray DeJean [r...@selu.edu] *Sent:* Monday, September 19, 2011 12:11 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie grac...@canisius.edu wrote: On 09/19/2011 11:04 AM, Ray DeJean wrote: All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device
