From Jeff.Nagel at wlc.edu Tue Feb 7 11:47:48 2006 From: Jeff.Nagel at wlc.edu (Jeff Nagel) Date: Tue Feb 7 11:47:58 2006 Subject: NetReg: dhcpd.conf Message-ID: <2DCED758614A2B419109135BFD3E934A60E0E4@WLCMAIL.wlc.edu> We are having a problem with netreg where unregistered users are able to get on the internet and do everything that unregistered users can. It was working correctly but all of a sudden it stopped working correctly. I have attached our dhcpd.conf file. Any help would be appreciated. Thanks in advance. Jeff ## ISC DHCPD v3 Configuration file ## for NetReg 1.5 ## Belongs at /etc/dhcpd/dhcpd.conf max-lease-time 120; default-lease-time 120; option domain-name "wlc.edu"; server-identifier netreg2.wlc.edu; ignore bootp; ddns-update-style ad-hoc; ddns-updates off; omapi-port 7911; # Two pools on the same subnet subnet 172.16.32.0 netmask 255.255.224.0 { authoritative; option routers 172.16.32.1; # Begin unauthorized pool pool { option domain-name-servers 172.16.32.32; one-lease-per-client true; max-lease-time 120; default-lease-time 120; range 172.16.32.100 172.16.32.254; allow unknown clients; } # End unauthorized pool # Begin authorized pool pool { option domain-name-servers 172.16.10.20; option netbios-name-servers 172.16.10.20; one-lease-per-client true; max-lease-time 28800; default-lease-time 28800; range 172.16.34.1 172.16.38.254; deny unknown clients; } # End authorized pool } # End subnet ## Two pools on different networks on the same wire #shared-network "Student VLAN200" { # subnet 10.110.0.0 netmask 255.255.0.0 { # authoritative; # one-lease-per-client true; # # Begin unauthorized pool # pool { # option routers 10.110.8.1; # option domain-name-servers 10.210.8.38; # option subnet-mask 255.255.0.0; # option broadcast-address 10.110.255.255; # max-lease-time 120; # default-lease-time 120; # range 10.110.10.1 10.110.15.254; # allow unknown clients; # } # End unauthorized pool # } # End subnet 10.110.0.0/16 # # Begin authorized pool # subnet 10.200.0.0 netmask 255.255.0.0 { # authoritative; # pool { # option routers 10.200.8.1; # option domain-name-servers 10.140.8.17,10.140.8.18; # option netbios-name-servers 10.140.8.17,10.140.8.18; # option subnet-mask 255.255.0.0; # option broadcast-address 10.200.255.255; # max-lease-time 28800; # default-lease-time 28800; # range 10.200.10.1 10.200.15.254; # deny unknown clients; # } # End authorized pool # } # End subnet 10.200.0.0/16 #} # End shared-network Test Vlan include "/usr/local/etc/netreg/dhcpd/netreg.registered"; -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.southwestern.edu/pipermail/netreg/attachments/20060207/5bcb56a8/attachment.html From Robert.H.Lowe at lawrence.edu Tue Feb 7 12:23:36 2006 From: Robert.H.Lowe at lawrence.edu (Robert Lowe) Date: Tue Feb 7 12:23:44 2006 Subject: NetReg: dhcpd.conf In-Reply-To: <2DCED758614A2B419109135BFD3E934A60E0E4@WLCMAIL.wlc.edu> References: <2DCED758614A2B419109135BFD3E934A60E0E4@WLCMAIL.wlc.edu> Message-ID: <43E8E5A8.90907@lawrence.edu> Jeff Nagel wrote: Jeff, > We are having a problem with netreg where unregistered users are able to > get on the internet and do everything that unregistered users can. It > was working correctly but all of a sudden it stopped working correctly. > I have attached our dhcpd.conf file. > > > > Any help would be appreciated. Well, let's see if we can deduce what isolation technique you might be using. Options, from worst to better, include... 1. Security by obscrutity (DNS [and bogus gateway]) 2. Router or firewall rules (stops A/V and OS updates though) 3. Separate proxy server (e.g. squid with rules for A/V and OS updates) Of course, combinations can be effectively layered. > ## ISC DHCPD v3 Configuration file > > ## for NetReg 1.5 > > ## Belongs at /etc/dhcpd/dhcpd.conf > > > > max-lease-time 120; > > default-lease-time 120; > > option domain-name "wlc.edu"; > > server-identifier netreg2.wlc.edu; > > ignore bootp; > > ddns-update-style ad-hoc; > > ddns-updates off; > > omapi-port 7911; > > > > # Two pools on the same subnet > > subnet 172.16.32.0 netmask 255.255.224.0 { > > authoritative; > > option routers 172.16.32.1; Single gateway for both pools, so not a bogus gateway. Still don't know about router/fw rules, or proxy server. > > # Begin unauthorized pool > > pool { > > option domain-name-servers 172.16.32.32; > > one-lease-per-client true; > > max-lease-time 120; > > default-lease-time 120; > > range 172.16.32.100 172.16.32.254; Highly unlikely that any router/fw rules are in place. Also seems unlikely that a proxy server is involved. Why? You need *four* rules to cover these addresses: 1. 172.16.32.100/30 2. 172.16.32.104/29 3. 172.16.32.112/28 4. 172.16.32.128/25 > allow unknown clients; > > } # End unauthorized pool > > # Begin authorized pool > > pool { > > option domain-name-servers 172.16.10.20; > > option netbios-name-servers 172.16.10.20; > > one-lease-per-client true; > > max-lease-time 28800; > > default-lease-time 28800; > > range 172.16.34.1 172.16.38.254; > > deny unknown clients; > > } # End authorized pool > > } # End subnet > include "/usr/local/etc/netreg/dhcpd/netreg.registered"; So, it's fairly certain that you're using the security by obscurity approach (easily circumvented by users, if they are willing to expend any brain cycles). So, what you need to look at are the syslog messages capturing the IP address assignment for an unregistered client, just to make sure it is getting an address from the correct pool. If so, what is your DNS server doing about it? That should put you on the right track... -Robert From Jeff.Nagel at wlc.edu Tue Feb 7 20:05:07 2006 From: Jeff.Nagel at wlc.edu (Jeff Nagel) Date: Tue Feb 7 20:05:12 2006 Subject: NetReg: dhcpd.conf Message-ID: <2DCED758614A2B419109135BFD3E934A60E275@WLCMAIL.wlc.edu> Thanks for the information. It turned out to be a dns problem. Replacing the named.conf and named.ca with the files from the NetReg distribution fixed the issue. Thanks again. Jeff Nagel, MCSE Network Support Specialist Wisconsin Lutheran College (414)443-8798 -----Original Message----- From: netreg-bounces@southwestern.edu [mailto:netreg-bounces@southwestern.edu] On Behalf Of Robert Lowe Sent: Tuesday, February 07, 2006 12:24 PM To: NetReg - an automated DHCP registration system Subject: Re: NetReg: dhcpd.conf Jeff Nagel wrote: Jeff, > We are having a problem with netreg where unregistered users are able to > get on the internet and do everything that unregistered users can. It > was working correctly but all of a sudden it stopped working correctly. > I have attached our dhcpd.conf file. > > > > Any help would be appreciated. Well, let's see if we can deduce what isolation technique you might be using. Options, from worst to better, include... 1. Security by obscrutity (DNS [and bogus gateway]) 2. Router or firewall rules (stops A/V and OS updates though) 3. Separate proxy server (e.g. squid with rules for A/V and OS updates) Of course, combinations can be effectively layered. > ## ISC DHCPD v3 Configuration file > > ## for NetReg 1.5 > > ## Belongs at /etc/dhcpd/dhcpd.conf > > > > max-lease-time 120; > > default-lease-time 120; > > option domain-name "wlc.edu"; > > server-identifier netreg2.wlc.edu; > > ignore bootp; > > ddns-update-style ad-hoc; > > ddns-updates off; > > omapi-port 7911; > > > > # Two pools on the same subnet > > subnet 172.16.32.0 netmask 255.255.224.0 { > > authoritative; > > option routers 172.16.32.1; Single gateway for both pools, so not a bogus gateway. Still don't know about router/fw rules, or proxy server. > > # Begin unauthorized pool > > pool { > > option domain-name-servers 172.16.32.32; > > one-lease-per-client true; > > max-lease-time 120; > > default-lease-time 120; > > range 172.16.32.100 172.16.32.254; Highly unlikely that any router/fw rules are in place. Also seems unlikely that a proxy server is involved. Why? You need *four* rules to cover these addresses: 1. 172.16.32.100/30 2. 172.16.32.104/29 3. 172.16.32.112/28 4. 172.16.32.128/25 > allow unknown clients; > > } # End unauthorized pool > > # Begin authorized pool > > pool { > > option domain-name-servers 172.16.10.20; > > option netbios-name-servers 172.16.10.20; > > one-lease-per-client true; > > max-lease-time 28800; > > default-lease-time 28800; > > range 172.16.34.1 172.16.38.254; > > deny unknown clients; > > } # End authorized pool > > } # End subnet > include "/usr/local/etc/netreg/dhcpd/netreg.registered"; So, it's fairly certain that you're using the security by obscurity approach (easily circumvented by users, if they are willing to expend any brain cycles). So, what you need to look at are the syslog messages capturing the IP address assignment for an unregistered client, just to make sure it is getting an address from the correct pool. If so, what is your DNS server doing about it? That should put you on the right track... -Robert ********************************************************************** To unsubscribe from this list, visit http://www.southwestern.edu/mailman/listinfo/netreg Send requests for assistance to: netreg-owner@southwestern.edu ********************************************************************** From rbailey at annamaria.edu Mon Feb 13 15:14:38 2006 From: rbailey at annamaria.edu (Roger Bailey) Date: Mon Feb 13 15:18:38 2006 Subject: NetReg: Rogue Wireless Access Points Message-ID: <43F0F6BE.5080403@annamaria.edu> Good day, How are you dealing with rogue wireless access points? They have a nasty way of bypassing all of my NetReg stuff and iptables. I really would only like those who went through NetReg successfully to be able to access the Internet. I tried tweaking my iptables, which is based on rc.firewall-2.4-stronger. I do block all IP addresses except for the valid ones (192.168.19.0, 192.168.20.0, 192.168.21.0) but the routers blow by that. Any help would be greatly appreciated! -- --------------- Roger Bailey Computer Systems Administrator Anna Maria College http://www.annamaria.edu --------------- Man who run in front of car get tired. From MKing at bridgew.edu Mon Feb 13 16:25:29 2006 From: MKing at bridgew.edu (King, Michael) Date: Mon Feb 13 16:25:33 2006 Subject: NetReg: Rogue Wireless Access Points Message-ID: What do you have for switches? Some new switches have a feature called BPDU guard. It looks for BPDU's, and if it get's them, it shutsdown the linked ports. Granted, this depends on the router sending out a BPDU. > -----Original Message----- > From: netreg-bounces@southwestern.edu > [mailto:netreg-bounces@southwestern.edu] On Behalf Of Roger Bailey > Sent: Monday, February 13, 2006 4:15 PM > To: netreg@southwestern.edu > Subject: NetReg: Rogue Wireless Access Points > > Good day, > > How are you dealing with rogue wireless access points? They > have a nasty way of bypassing all of my NetReg stuff and > iptables. I really would only like those who went through > NetReg successfully to be able to access the Internet. > > I tried tweaking my iptables, which is based on > rc.firewall-2.4-stronger. I do block all IP addresses except > for the valid ones (192.168.19.0, 192.168.20.0, 192.168.21.0) > but the routers blow by that. > > Any help would be greatly appreciated! > > -- > --------------- > Roger Bailey > Computer Systems Administrator > Anna Maria College > http://www.annamaria.edu > --------------- > Man who run in front of car get tired. > > > ********************************************************************** > To unsubscribe from this list, visit > http://www.southwestern.edu/mailman/listinfo/netreg > Send requests for assistance to: netreg-owner@southwestern.edu > ************************************************************** > ******** > From dmeuleman at defiance.edu Wed Feb 15 08:20:12 2006 From: dmeuleman at defiance.edu (David Meuleman) Date: Wed Feb 15 08:20:17 2006 Subject: NetReg: Rogue Wireless Access Points In-Reply-To: <43F0F6BE.5080403@annamaria.edu> References: <43F0F6BE.5080403@annamaria.edu> Message-ID: <43F3389C.5000302@defiance.edu> Roger Bailey wrote: > Good day, > > How are you dealing with rogue wireless access points? They have a > nasty way of bypassing all of my NetReg stuff and iptables. I really > would only like those who went through NetReg successfully to be able > to access the Internet. > > I tried tweaking my iptables, which is based on > rc.firewall-2.4-stronger. I do block all IP addresses except for the > valid ones (192.168.19.0, 192.168.20.0, 192.168.21.0) but the routers > blow by that. > > Any help would be greatly appreciated! > It should be pointed out that your problem is with rogue NAT routers, not the access points. If they were just access points, you'd be better off. Since they are routers with unsecured access points built into them, you are experiencing this issue. Another point is that they are not really "bypassing" Netreg. Netreg assigns the IP to the router, which has registered. If you see traffic from a device connected to one of these routers, it will point you back to the router and at least you have the username of the person who registered the router. Here are some options you may have: 1. Deploy wireless access points of your own that are secure. Perhaps merely having the option available will keep people from setting up their own. 2. Deploy a wireless IDS system (this usually works well with option #1). These devices alert you when they detect a wireless network that is not authorized on your campus. Some will even flood the rogue network to make it inoperable. 3. Develop a policy that forbids the use of wireless networks or at least ones that aren't secure. Also, putting something in there that sharing a NAT router is akin to sharing your username and password and may result in revocation of network privileges may help too. Occasionally walk through your residence halls (or wherever these APs are showing up) with your laptop looking for them. If you come across one that lets you onto the network without registering (or without a WEP key or WPA-PSK), get the IP of the router (there's a php script below that is great for this). When you get back to your desk, find the username associated to that IP. Optionally, disable the ethernet port the router is connected to. Give the user a call and/or send them an e-mail to tell them how naughty they've been. Here's that PHP script. Obviously, getting the NATed IP of the router doesn't do you any good, you need to get the external IP to do your lookup on NetReg. But, if you have an firewall like we do, going to a site like http://www.whatsmyip.org will only return the corporate firewall address. Solution: Throw this script on a webserver behind your corporate firewall...someplace like http://www.yourwebsite.edu/whatsmyip.php . When you come across a rogue AP/router, bring up this page and write down the address. ---code--- \n"; ---end code--- Dave From Robert.H.Lowe at lawrence.edu Wed Feb 15 10:29:39 2006 From: Robert.H.Lowe at lawrence.edu (Robert Lowe) Date: Wed Feb 15 10:29:48 2006 Subject: NetReg: Rogue Wireless Access Points In-Reply-To: <43F3389C.5000302@defiance.edu> References: <43F0F6BE.5080403@annamaria.edu> <43F3389C.5000302@defiance.edu> Message-ID: <43F356F3.5090804@lawrence.edu> David Meuleman wrote: > Roger Bailey wrote: > >> Good day, >> >> How are you dealing with rogue wireless access points? They have a >> nasty way of bypassing all of my NetReg stuff and iptables. I really >> would only like those who went through NetReg successfully to be able >> to access the Internet. >> >> I tried tweaking my iptables, which is based on >> rc.firewall-2.4-stronger. I do block all IP addresses except for the >> valid ones (192.168.19.0, 192.168.20.0, 192.168.21.0) but the routers >> blow by that. >> >> Any help would be greatly appreciated! >> > It should be pointed out that your problem is with rogue NAT routers, > not the access points. If they were just access points, you'd be better > off. Since they are routers with unsecured access points built into > them, you are experiencing this issue. Most of them can be configured to disable NAT (and DHCP), and some schools require this by policy. > Another point is that they are > not really "bypassing" Netreg. Netreg assigns the IP to the router, > which has registered. If you see traffic from a device connected to one > of these routers, it will point you back to the router and at least you > have the username of the person who registered the router. Yes, but the problem is that once a *single* user registered behind the NAT device, any subsequent access by *anyone* (even from the parking lot), is unchallenged. > Here are some options you may have: > 1. Deploy wireless access points of your own that are secure. Perhaps > merely having the option available will keep people from setting up > their own. > 2. Deploy a wireless IDS system (this usually works well with option > #1). These devices alert you when they detect a wireless network that > is not authorized on your campus. Some will even flood the rogue > network to make it inoperable. > 3. Develop a policy that forbids the use of wireless networks or at > least ones that aren't secure. Also, putting something in there that > sharing a NAT router is akin to sharing your username and password and > may result in revocation of network privileges may help too. > Occasionally walk through your residence halls (or wherever these APs > are showing up) with your laptop looking for them. If you come across > one that lets you onto the network without registering (or without a WEP > key or WPA-PSK), get the IP of the router (there's a php script below > that is great for this). When you get back to your desk, find the > username associated to that IP. Optionally, disable the ethernet port > the router is connected to. Give the user a call and/or send them an > e-mail to tell them how naughty they've been. > > > Here's that PHP script. Obviously, getting the NATed IP of the router > doesn't do you any good, you need to get the external IP to do your > lookup on NetReg. But, if you have an firewall like we do, going to a > site like http://www.whatsmyip.org will only return the corporate > firewall address. Solution: Throw this script on a webserver behind > your corporate firewall...someplace like > http://www.yourwebsite.edu/whatsmyip.php . When you come across a rogue > AP/router, bring up this page and write down the address. > > ---code--- > PRINT "Your IP Address is " . $_SERVER['REMOTE_ADDR'] . "
\n"; > ---end code--- Connected from the wireless side, this won't get you the right IP address from a NAT device. For example, you connect to a WAP, it will hand out a private IP address to you with a default gateway address of the internal interface of the router, not what that address is translated to for outbound traffic (the address that router is acquiring from your campus DHCP server). I've worked on this problem, and now insert a re-director into the registration path that encodes a timestamp and IP TTL into a registration key that is decoded on the NetReg side, i.e. matched with OS fingerprint and your network topology to determine whether the user is behind a NAT device or not. Thus far I've only used it for monitoring, and not policy enforcement. The software is not ready for primetime yet (it's been used for the last three or four registration periods here, but still needs some tweaking), requires a fairly complex Apache setup, and can still be defeated by a determined user. Details are available at: http://www.lawrence.edu/fast/NATfinder.html -Robert From rdrummond at vfmac.edu Wed Feb 15 10:36:19 2006 From: rdrummond at vfmac.edu (Drummond, Rob) Date: Wed Feb 15 10:36:26 2006 Subject: NetReg: Rogue Wireless Access Points Message-ID: <3F087977B2AD524A9DB524737B79C5BBBBADA8@nt7.vfmac.edu> we have the problem where students like to patch into the lan ports on their broadband routers and leave DHCP running. So when a user on that local segment turns on their PC, they get an IP on the wrong subnet. -----Original Message----- From: Robert Lowe [mailto:Robert.H.Lowe@lawrence.edu] Sent: Wednesday, February 15, 2006 11:30 AM To: NetReg - an automated DHCP registration system Subject: Re: NetReg: Rogue Wireless Access Points David Meuleman wrote: > Roger Bailey wrote: > >> Good day, >> >> How are you dealing with rogue wireless access points? They have a >> nasty way of bypassing all of my NetReg stuff and iptables. I really >> would only like those who went through NetReg successfully to be able >> to access the Internet. >> >> I tried tweaking my iptables, which is based on >> rc.firewall-2.4-stronger. I do block all IP addresses except for the >> valid ones (192.168.19.0, 192.168.20.0, 192.168.21.0) but the routers >> blow by that. >> >> Any help would be greatly appreciated! >> > It should be pointed out that your problem is with rogue NAT routers, > not the access points. If they were just access points, you'd be better > off. Since they are routers with unsecured access points built into > them, you are experiencing this issue. Most of them can be configured to disable NAT (and DHCP), and some schools require this by policy. > Another point is that they are > not really "bypassing" Netreg. Netreg assigns the IP to the router, > which has registered. If you see traffic from a device connected to one > of these routers, it will point you back to the router and at least you > have the username of the person who registered the router. Yes, but the problem is that once a *single* user registered behind the NAT device, any subsequent access by *anyone* (even from the parking lot), is unchallenged. > Here are some options you may have: > 1. Deploy wireless access points of your own that are secure. Perhaps > merely having the option available will keep people from setting up > their own. > 2. Deploy a wireless IDS system (this usually works well with option > #1). These devices alert you when they detect a wireless network that > is not authorized on your campus. Some will even flood the rogue > network to make it inoperable. > 3. Develop a policy that forbids the use of wireless networks or at > least ones that aren't secure. Also, putting something in there that > sharing a NAT router is akin to sharing your username and password and > may result in revocation of network privileges may help too. > Occasionally walk through your residence halls (or wherever these APs > are showing up) with your laptop looking for them. If you come across > one that lets you onto the network without registering (or without a WEP > key or WPA-PSK), get the IP of the router (there's a php script below > that is great for this). When you get back to your desk, find the > username associated to that IP. Optionally, disable the ethernet port > the router is connected to. Give the user a call and/or send them an > e-mail to tell them how naughty they've been. > > > Here's that PHP script. Obviously, getting the NATed IP of the router > doesn't do you any good, you need to get the external IP to do your > lookup on NetReg. But, if you have an firewall like we do, going to a > site like http://www.whatsmyip.org will only return the corporate > firewall address. Solution: Throw this script on a webserver behind > your corporate firewall...someplace like > http://www.yourwebsite.edu/whatsmyip.php . When you come across a rogue > AP/router, bring up this page and write down the address. > > ---code--- > PRINT "Your IP Address is " . $_SERVER['REMOTE_ADDR'] . "
\n"; > ---end code--- Connected from the wireless side, this won't get you the right IP address from a NAT device. For example, you connect to a WAP, it will hand out a private IP address to you with a default gateway address of the internal interface of the router, not what that address is translated to for outbound traffic (the address that router is acquiring from your campus DHCP server). I've worked on this problem, and now insert a re-director into the registration path that encodes a timestamp and IP TTL into a registration key that is decoded on the NetReg side, i.e. matched with OS fingerprint and your network topology to determine whether the user is behind a NAT device or not. Thus far I've only used it for monitoring, and not policy enforcement. The software is not ready for primetime yet (it's been used for the last three or four registration periods here, but still needs some tweaking), requires a fairly complex Apache setup, and can still be defeated by a determined user. Details are available at: http://www.lawrence.edu/fast/NATfinder.html -Robert ********************************************************************** To unsubscribe from this list, visit http://www.southwestern.edu/mailman/listinfo/netreg Send requests for assistance to: netreg-owner@southwestern.edu ********************************************************************** The preceding e-mail message (including any attachments) contains information that may be confidential, be protected by Valley Forge Military Academy & College or other applicable privileges, or constitute non-public information. It is intended to be conveyed only to the designated recipient(s). If you are not an intended recipient of this message, please notify the sender by replying to this message and then delete it from your system. Use, dissemination, distribution, or reproduction of this message by unintended recipients is not authorized and may be unlawful. From Robert.H.Lowe at lawrence.edu Wed Feb 15 10:48:29 2006 From: Robert.H.Lowe at lawrence.edu (Robert Lowe) Date: Wed Feb 15 10:48:37 2006 Subject: NetReg: Rogue Wireless Access Points In-Reply-To: <3F087977B2AD524A9DB524737B79C5BBBBADA8@nt7.vfmac.edu> References: <3F087977B2AD524A9DB524737B79C5BBBBADA8@nt7.vfmac.edu> Message-ID: <43F35B5D.6020304@lawrence.edu> Drummond, Rob wrote: > we have the problem where students like to patch into the lan ports on their > broadband routers and leave DHCP running. So when a user on that local > segment turns on their PC, they get an IP on the wrong subnet. This is another strong argument for policy regarding NAT and DHCP, which are usually coupled... There are several tools for detecting rogue DHCP servers, but one of the best defenses is to filter DHCP/BOOTP responses from rogue servers. You do this through ACLs at some boundary -- this might limited the effects to a floor or building, for example. Some edge switches may have features in this space too. This not an intractable problem... it can be eliminated for greatly restricted. -Robert From dmeuleman at defiance.edu Wed Feb 15 11:20:43 2006 From: dmeuleman at defiance.edu (David Meuleman) Date: Wed Feb 15 11:20:48 2006 Subject: NetReg: Rogue Wireless Access Points In-Reply-To: <3F087977B2AD524A9DB524737B79C5BBBBADA8@nt7.vfmac.edu> References: <3F087977B2AD524A9DB524737B79C5BBBBADA8@nt7.vfmac.edu> Message-ID: <43F362EB.7020509@defiance.edu> Drummond, Rob wrote: > we have the problem where students like to patch into the lan ports on their > broadband routers and leave DHCP running. So when a user on that local > segment turns on their PC, they get an IP on the wrong subnet. > We fixed this problem with the "port protected" command on our Cisco Catalyst switches. Our network configuration is now such that each switch in the residence hall has it's own vlan/subnet. We have ACL's at the router that do not allow traffic to pass between these subnets. The "port protected" command does not allow ports on the same switch to communicate with each other if they both have this feature enabled. This originally was put in after the Blaster/Welchia worm. It had the added benefit of stopping DHCP servers. It has the downside of not allowing students to play their network based games on our network. A side effect of which is that they apparently run Cat-5 cables down the hall at night. Dave From dmeuleman at defiance.edu Wed Feb 15 11:32:28 2006 From: dmeuleman at defiance.edu (David Meuleman) Date: Wed Feb 15 11:32:33 2006 Subject: NetReg: Rogue Wireless Access Points In-Reply-To: <43F356F3.5090804@lawrence.edu> References: <43F0F6BE.5080403@annamaria.edu> <43F3389C.5000302@defiance.edu> <43F356F3.5090804@lawrence.edu> Message-ID: <43F365AC.8040601@defiance.edu> > Yes, but the problem is that once a *single* user registered behind > the NAT device, any subsequent access by *anyone* (even from the > parking lot), is unchallenged. > I guess this is semantics. From NetReg's point of view, it wasn't bypassed. It worked as designed. From the Admin's POV, we have a problem. >> ---code--- >> > PRINT "Your IP Address is " . $_SERVER['REMOTE_ADDR'] . "
\n"; >> ---end code--- > > Connected from the wireless side, this won't get you the right IP > address from a NAT device. For example, you connect to a WAP, it > will hand out a private IP address to you with a default gateway > address of the internal interface of the router, not what that > address is translated to for outbound traffic (the address that > router is acquiring from your campus DHCP server). > That's why you put this script on a webserver that is outside of the NAT device you are connecting to and inside the corporate firewall. It will return the outside IP of the NAT device you are connected to. I've done it countless times. > I've worked on this problem, and now insert a re-director into the > registration path that encodes a timestamp and IP TTL into a > registration key that is decoded on the NetReg side, i.e. matched > with OS fingerprint and your network topology to determine whether > the user is behind a NAT device or not. Thus far I've only used it > for monitoring, and not policy enforcement. The software is not > ready for primetime yet (it's been used for the last three or four > registration periods here, but still needs some tweaking), requires a > fairly complex Apache setup, and can still be defeated by a determined > user. Details are available at: > > http://www.lawrence.edu/fast/NATfinder.html I'd love to take a look at this, but got a 404 error. Dave From Robert.H.Lowe at lawrence.edu Wed Feb 15 11:34:36 2006 From: Robert.H.Lowe at lawrence.edu (Robert Lowe) Date: Wed Feb 15 11:34:43 2006 Subject: NetReg: Rogue Wireless Access Points In-Reply-To: <43F365AC.8040601@defiance.edu> References: <43F0F6BE.5080403@annamaria.edu> <43F3389C.5000302@defiance.edu> <43F356F3.5090804@lawrence.edu> <43F365AC.8040601@defiance.edu> Message-ID: <43F3662C.2090406@lawrence.edu> David Meuleman wrote: > >> Yes, but the problem is that once a *single* user registered behind >> the NAT device, any subsequent access by *anyone* (even from the >> parking lot), is unchallenged. >> > I guess this is semantics. From NetReg's point of view, it wasn't > bypassed. It worked as designed. From the Admin's POV, we have a problem. > >>> ---code--- >>> >> PRINT "Your IP Address is " . $_SERVER['REMOTE_ADDR'] . "
\n"; >>> ---end code--- >> >> >> Connected from the wireless side, this won't get you the right IP >> address from a NAT device. For example, you connect to a WAP, it >> will hand out a private IP address to you with a default gateway >> address of the internal interface of the router, not what that >> address is translated to for outbound traffic (the address that >> router is acquiring from your campus DHCP server). >> > That's why you put this script on a webserver that is outside of the NAT > device you are connecting to and inside the corporate firewall. It will > return the outside IP of the NAT device you are connected to. I've done > it countless times. > >> I've worked on this problem, and now insert a re-director into the >> registration path that encodes a timestamp and IP TTL into a >> registration key that is decoded on the NetReg side, i.e. matched >> with OS fingerprint and your network topology to determine whether >> the user is behind a NAT device or not. Thus far I've only used it >> for monitoring, and not policy enforcement. The software is not >> ready for primetime yet (it's been used for the last three or four >> registration periods here, but still needs some tweaking), requires a >> fairly complex Apache setup, and can still be defeated by a determined >> user. Details are available at: >> >> http://www.lawrence.edu/fast/NATfinder.html > > I'd love to take a look at this, but got a 404 error. Sorry, http://www.lawrence.edu/fast/lower/NATfinder.html ... no code available for distribution yet, but the concept is thoroughly explained. -Robert From jfiske at clarkson.edu Wed Feb 15 11:56:45 2006 From: jfiske at clarkson.edu (Josh Fiske) Date: Wed Feb 15 11:56:49 2006 Subject: NetReg: Rogue Wireless Access Points In-Reply-To: <3F087977B2AD524A9DB524737B79C5BBBBADA8@nt7.vfmac.edu> Message-ID: netreg-bounces@southwestern.edu wrote on 02/15/2006 11:36:19 AM: > we have the problem where students like to patch into the lan ports on their > broadband routers and leave DHCP running. So when a user on that local > segment turns on their PC, they get an IP on the wrong subnet. > If you have a Cisco based switching environment, you might also consider enabling DHCP snooping. This is a switch-level feature which only allows DHCP response packets to come from trusted ports. See this article for further details: http://www.thtech.net/article/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.southwestern.edu/pipermail/netreg/attachments/20060215/40e3b257/attachment.html From SJaworsk at bw.edu Wed Feb 15 13:32:36 2006 From: SJaworsk at bw.edu (Steve Jaworski) Date: Wed Feb 15 13:32:41 2006 Subject: NetReg: Rogue Wireless Access Points Message-ID: <96EB90D5C6986A41B7F2E6B38DF7FB2C071C3514@stargazer.bw.edu> I have not tried this but it sounds interesting. http://www.lawrence.edu/fast/lower/NATfinder.html Steve Jaworski Network Administrator Baldwin-Wallace College http://homepages.bw.edu/~sjaworsk 440 826 6969 -----Original Message----- From: netreg-bounces@southwestern.edu [mailto:netreg-bounces@southwestern.edu] On Behalf Of Roger Bailey Sent: Monday, February 13, 2006 4:15 PM To: netreg@southwestern.edu Subject: NetReg: Rogue Wireless Access Points Good day, How are you dealing with rogue wireless access points? They have a nasty way of bypassing all of my NetReg stuff and iptables. I really would only like those who went through NetReg successfully to be able to access the Internet. I tried tweaking my iptables, which is based on rc.firewall-2.4-stronger. I do block all IP addresses except for the valid ones (192.168.19.0, 192.168.20.0, 192.168.21.0) but the routers blow by that. Any help would be greatly appreciated! -- --------------- Roger Bailey Computer Systems Administrator Anna Maria College http://www.annamaria.edu --------------- Man who run in front of car get tired. ********************************************************************** To unsubscribe from this list, visit http://www.southwestern.edu/mailman/listinfo/netreg Send requests for assistance to: netreg-owner@southwestern.edu ********************************************************************** From jeff at cowart.net Wed Feb 15 15:07:39 2006 From: jeff at cowart.net (Jefferson Cowart) Date: Wed Feb 15 15:07:26 2006 Subject: NetReg: Rogue Wireless Access Points In-Reply-To: Message-ID: <01b001c63273$db20b720$0805a8c0@mal> Just to build on this comment, we are using DHCP Snooping on all our switches here. It does a couple things: 1. It only allows DHCP responses to come from trusted ports. Basically you mark all your uplink ports on switches to be trusted and then you also mark the port(s) that you have DHCP servers connected to as trusted. This will prevent users from accidentally putting a DHCP server on your network. (Note: You can also achieve the same thing with VLAN Maps, but it isn't quite as clean.) 2. It inserts an option into the DHCP requests that indicate what switch and port the request came from. You can then have your DHCP server use this. (The link below has more information on that) 3. Causes the switch to maintain a table internal to it with a complete mapping of IP->MAC->Ports. With this information it can also do other useful thing like IP Source Guard (prevents IP spoofing by ensuring IP matches a valid IP for the port) and Dynamic ARP Inspection (eliminates ARP based man-in-the-middle attacks by verifying ARP packets have a valid IP/MAC match). We use all these features (where our switches support them) and think it has done a lot to improve security. As far as switch support here is what I know: DHCP Snooping Works: 2970, 3550, 3750, 4500 Doesn't Work: 2940 IP Source Guard/Dynamic ARP Inspection Works: 3550, 3750, 4500 Doesn't Work: 2940, 2970 ---------------- Thanks Jefferson Cowart Jeff@cowart.net > -----Original Message----- > From: netreg-bounces@southwestern.edu > [mailto:netreg-bounces@southwestern.edu] On Behalf Of Josh Fiske > Sent: Wednesday, February 15, 2006 09:57 > To: NetReg - an automated DHCP registration system > Subject: RE: NetReg: Rogue Wireless Access Points > > > netreg-bounces@southwestern.edu wrote on 02/15/2006 11:36:19 AM: > > > we have the problem where students like to patch into the > lan ports on their > > broadband routers and leave DHCP running. So when a user > on that local > > segment turns on their PC, they get an IP on the wrong subnet. > > > > If you have a Cisco based switching environment, you might > also consider enabling DHCP snooping. This is a switch-level > feature which only allows DHCP response packets to come from > trusted ports. See this article for further details: > > http://www.thtech.net/article/10 > From aworl at blackburn.edu Fri Feb 17 10:10:15 2006 From: aworl at blackburn.edu (Aaron Worley) Date: Fri Feb 17 10:11:35 2006 Subject: NetReg: How the audit page is created Message-ID: <00f7d1b85f3c610094d29da09016472d@blackburn.edu> I've written some perl scripts to find rogue users and to audit who has the most registrations. I would like the location of the script/scripts that construct that page. I would also like to formally request that that be put into the later version. In addition I would like to request a link to that page on the admin interface. Aaron B. Worley Data Center/Network Systems Junior Administrator Blackburn College From rdrummond at vfmac.edu Fri Feb 17 12:08:21 2006 From: rdrummond at vfmac.edu (Drummond, Rob) Date: Fri Feb 17 12:08:26 2006 Subject: NetReg: How the audit page is created Message-ID: <3F087977B2AD524A9DB524737B79C5BBBBADB2@nt7.vfmac.edu> Bryan, you can create a new short cut on your desktop. The location is \\nt6\home\operations Let me know If you need any assistance. -----Original Message----- From: Aaron Worley [mailto:aworl@blackburn.edu] Sent: Friday, February 17, 2006 11:10 AM To: netreg@southwestern.edu Subject: NetReg: How the audit page is created I've written some perl scripts to find rogue users and to audit who has the most registrations. I would like the location of the script/scripts that construct that page. I would also like to formally request that that be put into the later version. In addition I would like to request a link to that page on the admin interface. Aaron B. Worley Data Center/Network Systems Junior Administrator Blackburn College ********************************************************************** To unsubscribe from this list, visit http://www.southwestern.edu/mailman/listinfo/netreg Send requests for assistance to: netreg-owner@southwestern.edu ********************************************************************** The preceding e-mail message (including any attachments) contains information that may be confidential, be protected by Valley Forge Military Academy & College or other applicable privileges, or constitute non-public information. It is intended to be conveyed only to the designated recipient(s). If you are not an intended recipient of this message, please notify the sender by replying to this message and then delete it from your system. Use, dissemination, distribution, or reproduction of this message by unintended recipients is not authorized and may be unlawful. From rdrummond at vfmac.edu Fri Feb 17 12:24:40 2006 From: rdrummond at vfmac.edu (Drummond, Rob) Date: Fri Feb 17 12:24:45 2006 Subject: NetReg: How the audit page is created Message-ID: <3F087977B2AD524A9DB524737B79C5BBBBADB4@nt7.vfmac.edu> Oops, sorry about that one guys. I didn't look to see what email I clicked on when I hit reply. How do I get that email out of the archives. -----Original Message----- From: Drummond, Rob [mailto:rdrummond@vfmac.edu] Sent: Friday, February 17, 2006 1:08 PM To: 'NetReg - an automated DHCP registration system' Subject: RE: NetReg: How the audit page is created Bryan, you can create a new short cut on your desktop. The location is \\nt6\home\operations Let me know If you need any assistance. -----Original Message----- From: Aaron Worley [mailto:aworl@blackburn.edu] Sent: Friday, February 17, 2006 11:10 AM To: netreg@southwestern.edu Subject: NetReg: How the audit page is created I've written some perl scripts to find rogue users and to audit who has the most registrations. I would like the location of the script/scripts that construct that page. I would also like to formally request that that be put into the later version. In addition I would like to request a link to that page on the admin interface. Aaron B. Worley Data Center/Network Systems Junior Administrator Blackburn College ********************************************************************** To unsubscribe from this list, visit http://www.southwestern.edu/mailman/listinfo/netreg Send requests for assistance to: netreg-owner@southwestern.edu ********************************************************************** The preceding e-mail message (including any attachments) contains information that may be confidential, be protected by Valley Forge Military Academy & College or other applicable privileges, or constitute non-public information. It is intended to be conveyed only to the designated recipient(s). If you are not an intended recipient of this message, please notify the sender by replying to this message and then delete it from your system. Use, dissemination, distribution, or reproduction of this message by unintended recipients is not authorized and may be unlawful. ********************************************************************** To unsubscribe from this list, visit http://www.southwestern.edu/mailman/listinfo/netreg Send requests for assistance to: netreg-owner@southwestern.edu ********************************************************************** From tcantrel at westmont.edu Fri Feb 17 13:13:10 2006 From: tcantrel at westmont.edu (Thomas Cantrell) Date: Fri Feb 17 13:13:18 2006 Subject: NetReg: How the audit page is created In-Reply-To: <00f7d1b85f3c610094d29da09016472d@blackburn.edu> References: <00f7d1b85f3c610094d29da09016472d@blackburn.edu> Message-ID: <708BCB9C-B36A-4186-9877-D7FF1FFB4956@westmont.edu> Aaron, I don't think my version of Netreg 1.5.1 has an audit page, but I'm happy to talk code with you. I would be really interested in seeing your scripts and where they integrate in. Here at Westmont, I think about 30% of Netreg is our own code, including a registration wizard and scripts that talk to the Cisco Switches. Sometimes I wonder if we got all of our Netreg users together if we wouldn't have a nice library of contributions. Just a thought. Thomas --------------- Thomas Cantrell Assistant Server Administrator Westmont College (805) 565-7249 tcantrel@westmont.edu On Feb 17, 2006, at 8:10 AM, Aaron Worley wrote: > I've written some perl scripts to find rogue users and to audit > who has the most registrations. I would like the location of the > script/scripts that construct that page. I would also like to > formally request that that be put into the later version. In addition > I would like to request a link to that page on the admin interface. > > Aaron B. Worley > Data Center/Network Systems Junior Administrator > Blackburn College > ********************************************************************** > To unsubscribe from this list, visit http://www.southwestern.edu/ > mailman/listinfo/netreg > Send requests for assistance to: netreg-owner@southwestern.edu > ********************************************************************** From stella at rider.edu Wed Feb 22 12:09:50 2006 From: stella at rider.edu (Ricardo Stella) Date: Wed Feb 22 12:09:57 2006 Subject: NetReg: Archive maintainer: Can you remove email addresess ? In-Reply-To: References: Message-ID: <43FCA8EE.40102@rider.edu> Looking at spam sources (to fight back) a popular source is mailing lists archives. Can the maintainer, remove or mangle them please ? TIA... -- ?(((=((===???(((=========================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: stella.vcf Type: text/x-vcard Size: 146 bytes Desc: not available Url : http://www.southwestern.edu/pipermail/netreg/attachments/20060222/6e1561fd/stella.bin From DWilliams3 at spc.edu Mon Feb 27 09:18:34 2006 From: DWilliams3 at spc.edu (Williams, Daniel A.) Date: Mon Feb 27 09:18:52 2006 Subject: NetReg: Re: LDAP With ADC Message-ID: I'm having some issue connecting to LDAP SERVER error failed to bind with LDAP Server any solutions. Thanks Daniel A. Williams Network Manager Office Of Information Technology Services Saint Peter's College Jersey City, NJ 07306 Tel# 201-915-9384 Cel# 732-668-9124 CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. -----Original Message----- From: netreg-bounces@southwestern.edu [mailto:netreg-bounces@southwestern.edu] On Behalf Of Drummond, Rob Sent: Friday, February 17, 2006 1:08 PM To: 'NetReg - an automated DHCP registration system' Subject: RE: NetReg: How the audit page is created Bryan, you can create a new short cut on your desktop. The location is \\nt6\home\operations Let me know If you need any assistance. -----Original Message----- From: Aaron Worley [mailto:aworl@blackburn.edu] Sent: Friday, February 17, 2006 11:10 AM To: netreg@southwestern.edu Subject: NetReg: How the audit page is created I've written some perl scripts to find rogue users and to audit who has the most registrations. I would like the location of the script/scripts that construct that page. I would also like to formally request that that be put into the later version. In addition I would like to request a link to that page on the admin interface. Aaron B. Worley Data Center/Network Systems Junior Administrator Blackburn College ********************************************************************** To unsubscribe from this list, visit http://www.southwestern.edu/mailman/listinfo/netreg Send requests for assistance to: netreg-owner@southwestern.edu ********************************************************************** The preceding e-mail message (including any attachments) contains information that may be confidential, be protected by Valley Forge Military Academy & College or other applicable privileges, or constitute non-public information. It is intended to be conveyed only to the designated recipient(s). If you are not an intended recipient of this message, please notify the sender by replying to this message and then delete it from your system. Use, dissemination, distribution, or reproduction of this message by unintended recipients is not authorized and may be unlawful. ********************************************************************** To unsubscribe from this list, visit http://www.southwestern.edu/mailman/listinfo/netreg Send requests for assistance to: netreg-owner@southwestern.edu **********************************************************************