Google

802.11b is not bulletproof

802.11b is not bulletproof

Contact:[email protected]

802.11b wireless security is not bulletproof.

Things to think about:

WEP

The only WEP key standard is for 40-bit, anything higher then that (at this
point) is vendor specific ... if you implement it, there goes your
cross-vendor compatibility.

Most vendors use a shared key configuration; all devices have the key that
lets them onto the network. This is okay if you control all the nodes, but
if you're running a shared network, this is a serious problem. So you give a
newcomer the key, a month later you want to kick them off the network (for
whatever reason), since there is no cable to unplug, your only option is
change the shared key and then contact everyone else and get them to change
their key as well.  This would be a management nightmare.

Rotating the WEP keys (using all 4 of them) can help avoid a flag day where
all users have to change their key at once. Most base stations can be told
to transmit on any one of the four keys, so you can switch to a new transmit
key every week or month, and replace the old key material with new. That
way, any user can set up their device with the current set of keys, leaving
them with at least 3 key changes worth of future access time. This can make
changing WEP keys almost practical, and sets a three key change limit on the
access remaining after a user is booted for some reason. It has the added
benefit of requiring rogue users to go back to their social engineering to
get the current keys at least once every 4 key changes.  Of course, your
access point has to support the four keys.  You still have the management
problem of getting the keys to the users.

WEP is a performance hit. When you enable WEP, the card has to do the
encryption and they aren't the fastest things in the world. I haven't seen
any measurements of the performance hit.  I have read you take a huge hit if
the encryption takes place with software (Lucent?), and maybe no noticeable
hit if the encryption takes place with hardware (Cisco?).  I am not 100%
sure what the different vendors are using for the encryption. The
performance hit isn't a big deal when you're using it in your house to surf
from your couch but when you're trying to connect two houses that are 3
miles apart it quickly becomes more of an issue.

So we use WEP and now we are relying on it to keep intruders (only in close
proximity) at bay, if they can get the shared key they have direct access to
the inside of your firewall.  The firewall protects you from "the internet";
WEP protects you from your neighbors.


MAC based security

Many commercial access points offer MAC based access control. 802.11b cards
are Ethernet cards over a different medium, so they do have MAC addresses.
You can restrict access by manually controlling ARP entries (or figuring out
a way to do MAC based firewalling).  Some people are using Linux as an
access point for more flexibility. That solves the problem of access
control; by controlling access on the MAC level, each wireless community can
restrict (or not) anyone that they choose.

MAC address matching for access control isn't a complete solution either.
MAC addresses on most wireless cards are changeable, and discovering which
MAC addresses a base station allows to connect is not impossible. MAC
address access control is a hurdle for a rogue user to bypass, but not a
severely high one.

Managing such access control lists across a whole network of access points
with a large and/or dynamic user population is difficult.  Some kind of
management tool might help this, but there aren't any tools out there yet.


Alternatives

For example, because of the issues with WEP, I decide not to use it. I would
rather get the most out of my wireless card and offload encryption to the
end user and the access points. The obvious solution is some sort of VPN,
probably IPSEC. Again, there is a problem, I use IPSEC and all my traffic is
now encrypted on my local network.  As soon as my traffic leaves the local
network for an Internet gateway, it's unencrypted again. That may be an
acceptable risk. The local LAN is secure and just like the real Internet
your traffic isn't safe past that.  A router or firewall could handle
encryption to data in places like Exodus.

End-to-end encryption or Vpn across a wireless LAN may be higher performing
and more easily administered systems.  For example, some organizations block
all traffic from their wireless users except that to TCP port 22 (for ssh
port forwarding), UDP port 500 (for IKE/IPSEC), or using AH and/or ESP
protocols (for IPSEC). This doesn't prevent users from doing other things
over ports 22 and 500, but it encourages them to set up end-to-end Vpn or
port forwarding, so their traffic is secured across both the wireless and
wired portions of their connection.

Other organizations don't mind the wireless traffic being subject to
sniffing, and use out-of-band authentication on a gateway, before the
gateway will pass any of their traffic from the wireless LAN to the rest of
the net. This can be as simple as a persistent SSL or proxy connection to an
authentication server. As long as the connection is up and hasn't lost synch
on the encrypted streams, the gateway routes their traffic. Once the
connection has gone away, routing for their connections can be torn down.
This can at least limit attacks to hosts on the wireless broadcast domain.

Both the VPN and proxy/gateway can allow turning off individual users
without having to have everyone else change their WEP keys.

Review
�	You can use WEP key rotation, which might be the solution within a large
network.
�	You can use MAC address access control, but it's no panacea, especially in
larger organizations.
�	You can encourage end-to-end Vpn or ssh port forwarding by simply
restricting what traffic is allowed on the wireless LAN.
�	You can arrange out-of-band authentication.

Some wireless links:

<http://www.networkcomputing.com/1113/1113f2full.html>  - Comparison of some
of the big players. July 10, 2000

<http://www.wireless-nets.com/column_wireless_security.htm>  - Securing
Wireless LANs.  August 3, 2000

<http://www.teleport.com/~samc/psuwireless/> - bunch of wireless stuff

<http://www.personaltelco.net/download/802.11b-primer.pdf> - 802.11b primer

<http://www.seattlewireless.net/> - people trying to setup a public wireless
network in Seattle.

http://developer.intel.com/technology/itj/q22000/articles/art_5.htm  -Overvi
ew of 802.11b security.


Back to the Index