[unisog] VPN Protection of Wireless Networks

Patrick Darden darden at armc.org
Fri Dec 14 15:12:17 GMT 2001


We're big on HIPAA over here as well (obviously).  However, MACs are too
easily spoofed to be relied upon for any aspect of security.  That is the
whole reason MITM attacks are so effective.

Here is what I propose as a standard basic secure wireless system:


===============                ===================
|             |                |   internal      |
|  wireless   |---VPN Engine---|   network       |
|  cloud      |   ipsec        |                 |
===============   3des, md5    |  radius server  |
      |                        |  or tacacs+     |
      |                        ===================
      |
    dhcp server
    local ips only
    (10.10.X.X)


The only weakness here is that the internal network is susceptible to
sniffing or MITM attacks for the radius or tacacs+ traffic.  You could put
the radius/tacacs+ server on it's own segment with the VPN Engine if you
wanted:

               radius/tacacs+
                      |
===============       |        ===================
|             |       |        |   internal      |
|  wireless   |---VPN Engine---|   network       |
|  cloud      |   ipsec        |                 |
===============   3des, md5    |  radius server  |
      |                        |  or tacacs+     |
      |                        ===================
      |
    dhcp server
    local ips only
    (10.10.X.X)


Much more secure this way, however, you lose a lot of power and
convenience.  With the radius/tacacs+ server internal, you can use
internal username/password pairs (NT Domain or Unix or both via LDAP) for
VPN as well as internal servers/services--making it more along the lines
of a single sign-on system.  In addition, with the radius/tacacs+
internal, you can SSH to it to manage it, whereas if it is physically
discrete you have to administer it locally (unless you have a vpn engine
that can allow traffic to and from the radius server, opening up almost
the same can of worms as having it internal to begin with.)

--
--Patrick Darden                Internetworking Manager             
--                              706.354.3312    darden at armc.org
--                              Athens Regional Medical Center


On Fri, 14 Dec 2001, Harris, Michael C. wrote:

> we are side stepping the issue by only allowing Citrix (terminal server)
> connectivity to and from the wireless LAN segment and on the wireless
> devices. using 128b encryption within both the wireless cards&hub and again
> with the Citrix ICA client.  Forcing registration of the mac address at the
> wireless hub lets us tightly control our user community.  we believe this is
> a must for patient identifiable data and the only we can maintain the spirit
> if not the letter of HIPAA.  Application access is also very limited on the
> Citrix host to protect against app abuses.
> 
> Mike
> 
> --------------------------------------------------
> Michael C Harris
> System Security Analyst - Expert
> ITS / Research Education and Support
> University of Missouri Health Center
> Phone: 573-882-3392 
> 
> harrismc at health.missouri.edu
> --------------------------------------------------
> This e-mail is sent with 99.73% recyclable electrons
> 
> 
> -----Original Message-----
> From: Patrick Darden [mailto:darden at armc.org]
> Sent: Friday, December 14, 2001 7:14 AM
> To: Gary Flynn
> Cc: unisog at sans.org
> Subject: Re: [unisog] VPN Protection of Wireless Networks
> 
> 
> 
> You can just use a preshared secret (a password) plus a username.  Make
> them both big and varied, e.g.
> 
> 	username:	robertjordansmith
> 	password:	bobisHISnameforSURE
> 
> The man in the middle attach isn't effective against IPSEC, unless you are
> using the lowest possible encryption.  The whole process is encrypted.
> Passwords, usernames, etc.
> 
> WEP is an attempt at a wireless network with built-in vpn for ease of use
> in addition to security. It is a first attempt, and has some severe
> problems due to the "ease of use" factor.
> 
> --
> --Patrick Darden                Internetworking Manager             
> --                              706.354.3312    darden at armc.org
> --                              Athens Regional Medical Center
> 
> 
> On Thu, 13 Dec 2001, Gary Flynn wrote:
> 
> > 
> > In October I asked about vendor lockins on various security options 
> > for wireless networks.  VPN protection was mentioned quite often. 
> > >From my reading, effective VPN protection would require each individual 
> > user to have a unique key or digital certificate. Are people actually 
> > doing that? If so, how are you handling the administration of handing 
> > out and revoking keys and certificates? What, if anything is done to 
> > educate the end user of the importance of keeping them secret?
> > 
> > >From a Cisco web page:
> > 
> > "The wildcard pre-shared key feature is vulnerable to IP spoofing, 
> >  specifically the man-in-the-middle attack. An attacker can 
> >  potentially redirect all traffic between the IPSec peers to go 
> >  through an IKE proxy. If an attacker knows the pre-shared key 
> >  and can redirect all traffic between the IPSec peers to go through 
> >  an IKE proxy, the attacker can read and modify the IPSec-protected 
> >  data without detection."
> > 
> >
> http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csvpnc/csvpnsg/icl3enc
> r.htm#29351
> > 
> > One philosophy I've heard about wireless is not to worry about
> > securing it more than your wireless network. However, it sounds to
> > me like this type of man-in-the-middle attack is different from
> > those against SSH and SSL. With the attacks I've seen against SSH or 
> > SSL a user gets a warning message about a changed host key or 
> > mismatched certificate. The Cisco doc says the MIM attack against
> > IKE can be done without detection.
> > 
> > Without individual keys or certificates, it would seem to me that
> > a wireless network depending upon VPN technology is less secure
> > than one depending upon WEP. True?
> > 
> > thanks,
> > -- 
> > Gary Flynn
> > Security Engineer - Technical Services
> > James Madison University
> > 
> > Please R.U.N.S.A.F.E.
> > http://www.jmu.edu/computing/runsafe
> > 
> 



More information about the unisog mailing list