[ale] Practical Office Wireless (was Feedback on WirelessStandards)

Thu Mar 27 13:51:16 EST 2003

On Thu, 2003-03-27 at 13:34, hbbs at attbi.com wrote:
> Joe -
> 
> Yours is a great response (as have been the rest of y'all's) and I really
> appreciate your taking the time to go in to such detail.  I have a few questions:
> 
> > Finally, I have a Cisco VPN client that I need to use to access my
> > employer's corporate net. Since that client relies on a custom
> > IPsec service on Windows, it can't co-exist with the Windows
> > IPsec stuff; which means that when I want to get to the
> > corporate net, I have to plug my XP laptop into my wired LAN,
> > disable Windows IPsec services, and enable the Cisco ones.
> > Bleh.
> 
> Whence the "custom IPsec service" and why?
> 
> I also have a more general question.  When it comes to people being able to muck
> about with other people's wireless LANs, does it take a Bob Toxen / Kevin
> Mitnick or can fairly average shmoes find, download, and run "133t H4x0r" apps
> that do all the heavy lifting once they've got a laptop, wireless card, and
> "cantenna" in hand?  Furthermore, to what extent is the use of such tools taking
> place in the real world?

It is enough of an issue that open AP's has hit the attention of the
Homeland Defense Department. It does not take a Bob Toxen to access a
wireless network. I'm sure Bob could do it in no time flat. The big
headache is that the script kiddie crowd has the tools and toys to
access this stuff pretty much at will without the PIA cryptography if
IPSEC.

As for the question "to what extent is it being done (net sniffing)?",
consider this: how many bored, unemployed geeks are there right now? How
many are intrigued enough by the technology to not pay heed to the
ethics (how many between the ages of 12 and 22)?

NOTE: I'm not intending on slamming the age group listed above. I merely
point out that age group as a reference to the maturity factor in a
predominately male social structure (calm down riannen :). That age
group has a noted history of being fascinated with the toys and
oblivious to the legal ramifications of their actions.

It would be a good idea to test wireless security on a disconnected
machine first, then add limited access to other services as needed
later.

> 
> - Jeff
> > hbbs at attbi.com writes:
> > 
> > > Given an office setting in a typical office building, what is a typical 
> > *proper*
> > > setup for the use of wireless to handle Windows laptops?  I'm particularly
> > > concerned about security and Linux-friendliness on both the WAP and laptop 
> > ends.
> > > 
> > > We currently have a D-Link DWL-1000 11Mbps WAP and as far as I can tell, the
> > > only real control that is placed on it is that the community string is set,
> > > although I don't know if it has been changed from the default (I assume that
> > > this "community string" also gets set somehow on the client side and acts as a
> > > kind of password).   
> > > 
> > > We also have a couple of D-Link DWl520+ PCI wireless adapters on hand but I'm
> > > unsure as to their usability under Linux.
> > > 
> > > Two things concern me:  RF "sniffability" (i.e., being able to capture and
> > > understand wireless network traffic) and "freeloading" (i.e., providing 
> > Internet
> > > and file server access to people upstairs, downstairs, in the parking lot, 
> > etc.  
> > > 
> > > Can anyone here clue me in or do I just need to go buy Bob's book? :)
> > 
> > I'm working on this very issue now. My wireless clients are a mix of
> > Linux and WinXP/Me/98. I have everything working for both Windows and
> > Linux clients, but all is not completely smooth.
> > 
> > Here's what I'm doing and why:
> > 
> > (1) WEP is *disabled*. It's useless and a pain to configure when adding
> > new machines to the network. That means that anyone can associate with
> > my AP (all they need to do is stiff the SSID). However, that does them
> > no good; the measures below prevent intruders from taking any advantage
> > of my open AP.
> > 
> > (2) I've got a firewall box sitting between the AP and my LAN. That
> > box's only job is to protect me from wireless interlopers. It also
> > ensures that untrusted machines on the wireless net can't see machines
> > on the wired LAN.
> > 
> > (3) All traffic between the wireless clients and the firewall box is
> > encrypted using IPsec. The firewall is a Slack 8.1 box running
> > SuperFreeS/WAN and RoaringPenquin L2TPD. On the WinXP side, I'm using
> > the native Windows IPsec+L2TP+PPP client, which is a pain in the ass
> > to configure, but which works. It's also possible to convince WinXP
> > and Win2K to do plain IPsec without L2TP, but I haven't tried it.
> > On the WinME/98 boxes I'll use the Microsoft VPN adapter, available
> > "for free" from M$ (I actually haven't set this up yet). Linux clients
> > use FreeS/WAN to talk to the firewall.
> > 
> > The reason for this is so that snoopers can see only IPsec
> > Encapsulated Security Payload packets on my wireless segment; that's
> > much harder to break (when properly configured) than WEP.
> > 
> > (4) The firewall is configured to accept IP packets on the wireless
> > interface (eth1) only on port 500 (ISAKMP). That means that all you
> > can do on the wireless side is establish an IPsec tunnel; no
> > in-the-clear traffic can get into or through the firewall. (Once a
> > client establishes an IPsec tunnel, they can pass any traffic they
> > like across it.)
> > 
> > (5) Except for a couple of trusted wireless clients, the firewall
> > prohibits packets from the wireless side from going anywhere
> > except to the Internet gateway on my wired LAN; wireless clients
> > can't talk to any machine on the wired network unless I
> > explicitly allow them to do so. That means that even in the
> > unlikely event that an interloper manages to establish an
> > IPsec tunnel with my firewall, they still can't touch any
> > of the critical stuff on my wired LAN; all they can do is
> > steal Internet access.
> > 
> > Note that without the IPsec tunnels, an intruder would still
> > be able to talk to the other wireless clients. The presence
> > of the IPsec tunnels prevents that, as well as providing
> > strong encryption for all the wireless traffic.
> > 
> > To figure all this out, I started with the FreeS/WAN page
> > (http://www.freeswan.ca), and this nice page (pointed out to me by
> > another ALEr) about Windows and FreeS/WAN:
> > http://www.jacco2.dds.nl/networking/msl2tp.html.  The Linux FreeS/WAN
> > stuff was easy to set up on both the client and the server. Getting
> > the Windog clients working was more of a challenge, and involved lots
> > of network sniffing and debug-log analysis to figure out what the heck
> > was going on; but invariably the problem turned out to be that I
> > hadn't read the instructions and manpages carefully enough.
> > 
> > I do have some lingering problems with the wireless clients.  First,
> > sometimes I have to shutdown ipsec on the firewall and then bring it
> > back up in order to get the XP client to make a VPN connection. That's
> > a real pain, and would likely be a showstopper in a corporate
> > environment.
> > 
> > Second, the protocol overhead is a bugger. Anything that's going to
> > talk to the Windows wireless clients has to have its MTU set to 1000
> > or less, because of the many layers of protocol encapsulation that
> > happen between the firewall and the Windows clients
> > (PPP-in-L2TP-in-IPsec). I'd like to handle the MTU issue in one single
> > place (like on the firewall), but I haven't figured out how yet.  So
> > some stuff (mainly VNC) won't work on the Windows wireless clients at
> > the moment, unless I take special pains to set the MTU on the box on
> > the wired LAN (or on the Internet) that I want to talk to.
> > 
> > Finally, I have a Cisco VPN client that I need to use to access my
> > employer's corporate net. Since that client relies on a custom
> > IPsec service on Windows, it can't co-exist with the Windows
> > IPsec stuff; which means that when I want to get to the
> > corporate net, I have to plug my XP laptop into my wired LAN,
> > disable Windows IPsec services, and enable the Cisco ones.
> > Bleh.
> > 
> > Cheers,
> > 
> > -- Joe Knapka
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://www.ale.org/mailman/listinfo/ale
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
-- 
James P. Kinney III          \Changing the mobile computing world/
CEO & Director of Engineering \          one Linux user         /
Local Net Solutions,LLC        \           at a time.          /
770-493-8244                    \.___________________________./
http://www.localnetsolutions.com

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics) <jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7 

 This is a digitally signed message part