[unisog] Access control in wireless and other plublic access networks

Arnold, Jamie harnold at binghamton.edu
Wed Oct 23 13:37:01 GMT 2002


The wireless segment is just that...it's own physical segment and there's
nothing on it other than wireless devices.  I'm not really concerned with
non-VPN traffic as there's nothing of interest on this segment to play with.
We will, eventually use a MAC based security model for certain areas, but
trying to do that in general would not fly.  The idea of a campus wireless
solution is to allow visitors to have some access to our network.  Asking
them to install a VPN client is obtrusive enough ( in the eyes of those that
pay for such projects)

We're authenticating all of our public machines now...dorms will be next.
The number of "events" that we have to deal with have dropped significantly
since we launched the auth project.  I'm sure they'll begin to rise again,
but that's the nature of the beast.

-----Original Message-----
From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] 
Sent: Tuesday, October 22, 2002 2:48 PM
To: Arnold, Jamie
Cc: 'unisog at sans.org'
Subject: Re: [unisog] Access control in wireless and other plublic access
networks 


On Tue, 22 Oct 2002 08:27:08 EDT, "Arnold, Jamie" <harnold at binghamton.edu>
said:
> VPN and NAT.....works just fine.....

1) We better not catch you leaking RFC1918 addresses into the Net.  An
amazing number of sites do that (10% of the traffic at one of the root
nameservers is from 1918 space, according to recent numbers that Paul Vixie
posted to NANOG).

2) VPN and NAT are only *PART* of a solution. For instance, it doesn't
secure a wireless net unless you do *both* of the following: (a) prohibit
all non-VPN traffic and (b) make sure that all VPN connections are made by
authenticated entities (machines or users).  Remember in your analysis to
consider the case of an attacker sending one of your users a Trojaned email
or webpage (IE and Outlook both leak like sieves) to send back the user's
credentials and using them to steal access.  Not a standard script-kiddie
attack, but similar stunts are apparently now a stock part of the spammer's
repertory.

You might want to consider an end-run for parts of the solution.  For
instance, if you have a public lab, and it's common knowledge that you have
to show a University ID to get in, and that a note is made that you sat down
at computer 14, it will likely cut back a lot on mischief.  This of course
involves paying a lab proctor - see if you can get that done via work-study
funding. ;)

Using WEP and a non-default ESSID for wireless may be lame and hard to
scale, but they'll at least slow down the casual warchalker.  In this
environment, standoff distance is your friend.  Unfortunately, there will be
at least one department chair that will ask for your head on a platter if
you suggest making the parking lots be further away for security reasons. ;)
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech



More information about the unisog mailing list