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

[matty91 at bellsouth.net]

On Thu, 27 Mar 2003 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

This is trivial for any platform (Linux, FreeBSD, Windows XXXX).

> "cantenna" in hand?  Furthermore, to what extent is the use of such tools taking
> place in the real world?
>
> - 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
>
_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale