One Man's Method for Dealing with WarDrivers 

Here is what I have done to educate myself on the strengths and weaknesses 
of the wireless systems in my operational area, learn the traffic patterns 
of our customers, control their bandwidth and set up our systems to deal 
with the WarDrivers and others who would hop a free ride on our wireless 
systes. 

For reference, we are using Teletronics DS and Cirronet FH equipment.  The 
things I am discussing here apply to just about all DS equipment that will 
run in ethernet bridge mode.  Each of our wireless APs sits behind a Linux 
box (RedHat 6.2) that acts as a gateway, 

Step 1:  Learn your surroundings by becoming a WarDriver 

Initially, I used the Teletronics software to browse for access points and 
determine channel clearness and availability.  However, I am now using 
NetStumbler (www.netstumbler.org) to determine other DS access points in 
our 
area.  A quick drive around one of our service areas in my war driver 
(2001 
Bonneville SSEi with a 12db Omni sticking out the sunroof and plugged into 
a 
Lucent card in my Win2000 laptop) produced 26 DS access points (including 
5 
of our own) in our main service area.  With a GPS plugged in, NetStumbler 
can give pretty good approximations of AP locations also.  This produced a 
pretty good idea of how many channels were in use and by whom, what kind 
of 
equipment they are using, approximate antenna locations and signal 
strengths.  Before picking up a channel to operate an AP on, I then run 
NetStumbler at the base, plugged into the amplifier and antenna that the 
AP 
will run on.  Once you can see what your AP antenna is seeing, it makes it 
a 
lot easier to pick out the clearest channels. This utility won't pick up 
BreezeCom or Raylink APs, nor will it find any of the Cisco FH equipment.  
However, judicial application of social engineering (asking questions) and 
keeping an eagle eye out for 2.4Ghz antennas will serve as an excellent 
source of clues as to what the competition is doing. 

In my situation I found the following information about my competitors 
(this 
is across 9 POPs in 7 towns) 

2 Using Cisco
3 Using Breezecom
1 Using Lucent
1 Using Raylink 

In addition, there were another 20 or so corporate and residential 
wireless 
gateways, mostly Cisco.  The networks that have DHCP turned on are easy to 
get on, just set the ESSID on the card and grab an address. If there is no 
DHCP turned on, Ethereal and Windump will provide enough clues to make 
educated guesses as to the IP subnet and gateway in use.  If the AP 
doesn't 
block on unknown MACs, it is easy to hop on, just as I hopped right on 
several of the networks.  A traceroute from the pilfered IP address will 
show the backbone structure of the network, which is information that can 
be 
useful in the future. 

Unfortunately, the same methods that I used to hop on these networks 
worked 
equally well to hop onto my network.  Ugh.  Time to figure out how to deal 
with that. 

Step 2:  Determining Customer's Traffic Patterns and Detecting 
WarDriver/Other roamers 

Now that I know the strengths and weaknesses of my system, as well as all 
the related details about the other systems in my area, it is time to find 
out more about the hackers.  Even more useful, is that data collected in 
the 
watch for the hackers can be used to profile customer traffic use.  What 
is 
needed is some kind of network sniffer that can collect packet data and 
provide a useful format for reading the data, as well as some kind of 
graphing program to monitor historical trends.
All of our APs have a Linux box at the base, to provide the routing 
capability. 

The graphing program was easy.  We have used MRTG - 
http://people.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html - for some time 
to 
monitor the traffic on our routers.  By having SNMP capable switches at 
each 
AP location, we are able to monitor the bandwidth on the port that serves 
the AP gateways.  Our radios don't provide SNMP information directly, so 
this was the most cost effective way to get the information - used 10 meg 
Cisco switches are fairly inexpensive - and the switches perform much 
better 
than hubs.  This is a very useful tool when it comes to finding network 
congestion spots - just look for the MRTG graph that is pegged to the 
maximum speed of the connection or far above the historical pattern.  
Viruses, file-sharing programs and even Internet radio junkies can put 
extreme pressure on a network segment.  MRTG provides the alarm system for 
these "abuses". 

MRTG is great for looking at the over picture, but a network protocol 
analyzer is necessary to find the culprit and determine the causes of the 
increased traffic patterns.  A search on the Internet by one of my 
cohorts, 
Jerry Allen, turned up Ntop - http://www.ntop.org , a network protocol 
analyzer for Linux. 

Ntop will provide all the information you would ever want to know about 
the 
traffic on the network segment that it is monitoring.  The best report in 
Ntop (for my purposes) is "L>R" under the "IP Traffic" tab, which shows 
the 
amount of traffic traveling from the clients on the AP out to the rest of 
the world.  This information can be sorted by IP address and amount of 
data 
sent or received.  A click on an individual IP address shows a slew of 
information about the equipment at the other end of the IP address 
(including MAC address, manufacturer, OS, first and last time seen, and 
more 
information), an hourly breakdown of the amount of traffic through the 
connection, and active TCP sessions. 

One thing to keep in mind about Ntop is that it's a memory hog.  To keep 
it 
from overwhelming our machines, we set up a cron job that kills Ntop every 
night at midnight.  Ntop will provide SNMP type information, so it is 
possible to set up MRTG to graph Ntop information for each customer. 

Ntop makes it pretty easy to spot the hackers on the network.  It will 
provide the MAC address, manufacturer, IP addresses used, when they 
appeared 
and where they went while they were on the network.  Wanderers onto our 
network are silently recorded.  The first time we turned Ntop on, an 
ex-employee (I'll call him Mr. Sneaky) was sitting right there on our 
network just like any other paying customer, except he was no longer 
paying 
for it. 

Ntop has proven to be very valuable in determining customer traffic 
patterns 
and works very well for DSL network segments as well as wireless segments.  
One very overloaded wireless network segment was traced back with Ntop to 
a 
single wireless customer (I'll call this customer Mr. Hogg) with file 
sharing running full blast.  A cursory look at his Ntop stats showed 
several 
hundred connections on ports 1214 (Morpheus) and 6346, 6347 (Gnutella).  
Nearly a T1 worth of bandwidth was getting consumed by this one $50 a 
month 
customer...that is not good. 

While Ntop could find this information, it doesn't have any way to control 
the flow of information.  Hence it is now time for some kind of bandwidth 
management. 

Step 3:  Bandwidth management 

The graphing and network analysis from Step 2 has introduced us to two new 
friends, Mr. Hogg and Mr. Sneaky. 

Mr. Hogg is a paying customer, but he is overloading the AP to the point 
that other customers are being affected and his own link is performing at 
a 
subpar level because of his file-sharing programs.  His bandwidth needs to 
be limited to the amount that his residential wireless service specifies 
(256K). 

Mr. Sneaky is a non-paying customer.  And if Mr. Sneaky is smart enough to 
figure out how to get on my network without having to pay for it, he can 
probably set up a bunch of his friends too.  He is just like the old-time 
dialup customer that would share his password with a bunch of his friends 
until the ISP either limited multiple logins or went out of business. 

CBQ routing can solve both problems.  One way to do that would be to put a 
Teletronics, WirelessCPE, etc etc type of CPR in AP mode at the center 
point 
of the network and use the built in CBQ routing.  In some situations, this 
will probably work just fine.  However I want to keep my network segments 
sourced right out of Linux box so that I can keep my MRTG, Ntop and 
IP-Chains rules.  Call me old-fashioned, but I don't really trust the 
engineering of the CPE boxes, at least as APs. 

Fortunately, CBQ capability is in the stock RedHat 6.2 kernel.  All that's 
needed is a way to specify the bandwidth rules and a set of commands to 
set 
up the rules.   My first two attempts at setting the rules up fail pretty 
badly.  However, the third attempt using a script called CBQ-Init - 
ftp://ftp.equinox.gu.net/pub/linux/cbq/cbq.init - works like a champ. 

Mr. Hogg's connection is setup for 256Kb down and 256Kb up.  Network 
congestion on the segment vanishes and Mr. Hogg gets a little bit more 
selective about how he uses his file-sharing programs. 

Mr. Sneaky's IP address, and all other open IP addresses that are not in 
use, are set to zeroKb up and zeroKb down.  Everything looks normal, but 
no 
traffic passes.  Too bad Mr. Sneaky.   Ntop even watches his futile 
attempts 
at finding another IP address that works.  And finally, his MAC address is 
blocked from associating at the AP.  Presto, no more unauthorized users on 
the network. 

This system seems to be working very well for us.   We still get the 
occasional nibble from a WarDriver, but are comfortable in the fact that 
he 
or she is not going to be able to do anything with the network. 

That's about it.  I get the mailing list in digest form, so if you have 
any 
questions or comments, just direct them to my email address below. 

Thanks again to the other members of this list who helped me figure this 
stuff out. 

Matt Larsen, Director of Internet Services
Airwave Wireless Networx
mlarsen@scottsbluff.net