Hams Report 85-mile 802.11b File Transfers @ Oregon

[Mark C. Langston]

On Wed, Apr 14, 2004 at 05:45:15PM -0700, Roy S. Rapoport wrote:
> 
> Right.  What I'm saying, however, is that -- unless I misunderstand the
> basic concept behind WPA (disclosure: I haven't deployed it yet) -- nothing
> requires you to let the user select the password, right? So why not do "Hi,
> here's your new laptop with wireless card.  And here's your WPA password:
> B2A40F73F92810."  (BTW, this was auto-generated from an 11-line script I just
> wrote)
> 
> Doesn't this solve the problem?
> 


It minimizes the possibility that the WPA hash will be brute-forced.
It significantly raises the possibility that the user in question will
keep the password written down somewhere, or that management will decree
that Easier Passwords Shall Be Used(TM).


My Best Practice for deploying a wireless network is the following:

1)  Deploy all wireless access points outside your edge, with standard
    precautions taken (MAC ACLs, high-entropy password, non-default
    SSID, no 802.11b/g/whathaveyou broadcast frames enabled, etc.)

2)  Connections originating from/routed through the access point can
    go only one place:  One end of a VPN, after authenticating to
    an internal LDAP, RADIUS, or similar system.  All traffic will
    thus be wrapped in TCP 50/51 while in the air.

3)  All traffic shall use encrypted protocols whenever possible.  This
    implies that the AP's encryption, the AP's access restriction, the
    VPN's encryption, and the VPN's access restriction are still 
    insufficient.  Which is entirely true, because the whole bet's off
    if, after jumping through these hoops, the user then telnets, POP3s,
    or otherwise insecurely puts account name and password on the wire
    to a system that has access to your network, over whose transit
    you have no control.  Because I can assure you to a fairly high
    degree of certainty that a great many users make an effort to use
    the same username and password everywhere, unless forced to do 
    otherwise.

4)  If possible, port and protocols will be firewalled at the VPN
    endpoint, before encapsulation, providing further control over traffic
    influx from the wireless network.

5)  If possible, permitted traffic will be proxied outbound from the
    VPN, and restricted or prohibited otherwise.


...of course, this is my preferred remote access solution crossing an
edge in either direction.  Needless to say, I rarely if ever get to
implement the full-spectrum best practice as described above.  However,
I try to insist on 1-4 when deploying wireless networks, and am only
really comfortable negotiating away #4.

There are other approaches that provide a similar level of security,
if you're willing to grant access to all and sundry:  E.g., put the
AP outside your edge, and only allow traffic from the APs to travel
out from your edge, never cross it.  So wardrivers may end up with
free bandwidth, but they'll hit a null route when trying to hit your
infrastructure.


-- 
Mark C. Langston                                    Sr. Unix SysAdmin
mark at bitshift.org                                       mark at seti.org
Systems & Network Admin                                SETI Institute
http://bitshift.org                               http://www.seti.org