NetReg: Rogue Wireless Access Points

[Robert Lowe]

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---
> <?php
> PRINT "Your IP Address is " . $_SERVER['REMOTE_ADDR'] . "<br>\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