Slashdot Mirror
Securing 802.11b with PPPoE?
no free lunches asks: "After giving up in disgust on layer 2 auth like *EAP/802.1x (which is a nightmare to configure properly and requires expensive access points and bleeding edge - flaky - firmware) I am considering controlling access to my wireless LAN (a small 50-user setup, with only one Linux user - me) using PPPoE, and would like to ask the Slashdot crowd their opinion."
Disadvantages:
Mind you, the usual procedures apply (disabling SSID broadcast, changing MTUs for PPPoE, investigating other data encryption methods) so on and so forth, but this approach strikes me as being quite 'clean', cheap and, most important of all, easy to implement NOW instead of waiting for the 802.1x crowd to get their act together (sure, some people will say you can get usable 802.1x now, but my experience with six different vendors indicates that full interoperability is a joke, and that you need all sorts of proprietary items and tweaks - you either use a single vendor for everything, or you're bust).
I know some ISPs are already doing this and I'm sure there are some people with PPPoE knowledge out there, so I'd like to know about similar experiences."
So far, the issues can be summarized as follows:
Advantages:
- Totally platform, NIC and AP independent - you can use any NIC, any OS, any access points.
- No IP addresses required on the PPPoE server or the APs - no DHCP, no nothing, so there is no easy way to have access without establishing a PPPoE session.
- Built-in crypto per session - using CHAP for auth and MPPE for data encryption.
- No client/proprietary auth software required on Windows XP (around 40 of my users, and the ones that will actually use this)
- Full session control (IP address assignments, traffic accounting, sessions only allowed during office hours, etc.), same as any remote access server.
- Cheap (server packages available for Linux and FreeBSD, any box can take the load)
- No proprietary IPSec tricks required - yes, I've considered it as an option, but remember, my users are Windows users, and PPPoE has the advantage of removing all IP addresses from the WLAN segment.
Disadvantages:
- No PPPoE clients for PDAs (yet)
- No published HOWTOs on PPPoE server setup under Linux (plenty of DSL/PPPoE client info and at least one HOWTO for FreeBSD, but since PPPoE servers are mostly commercial products, no one wants to give away info for free)
- MPPE encryption has some religious detractors (but it works fine for 98% of my users - the 49- strong Windows laptop crowd - and totally removes the need for WEP key management)
- Rogue PPPoE Servers - not really an issue if you can filter PPPoE frames on the radio interface - and I can, so you need wired access to set up one - but I'd like to know people's opinions on whether this is more than an urban myth fanned by 802.1x proponents.
- Freeloaders can still use the WLAN (even though there are no IP addresses) as a bridged segment (but I can sniff on the PPPoE server interface and/or poll every AP and kick out/ban any MAC addresses without an established PPPoE session - so MAC spoofing is of very limited use).
Mind you, the usual procedures apply (disabling SSID broadcast, changing MTUs for PPPoE, investigating other data encryption methods) so on and so forth, but this approach strikes me as being quite 'clean', cheap and, most important of all, easy to implement NOW instead of waiting for the 802.1x crowd to get their act together (sure, some people will say you can get usable 802.1x now, but my experience with six different vendors indicates that full interoperability is a joke, and that you need all sorts of proprietary items and tweaks - you either use a single vendor for everything, or you're bust).
I know some ISPs are already doing this and I'm sure there are some people with PPPoE knowledge out there, so I'd like to know about similar experiences."
pppoe is crap for your security. Don't use it and thinks you are safe.
Use IPSec or some VPN solution. e.g. tinc - tinc.nl.linux.org, available for most unices with a TUN/TAP driver.
WinXP Supports IPsec out of the box. (Okay, you have to install the support tools from the WinXP CD, but thats it)p hp
.. works like a charm.
http://www.natecarlson.com/linux/ipsec-x509.
I've setup an Linux IPsec GW for WinXP with dhcp a few days ago
(Using the x509 patch of course)
Before you email me, remember: "There is no god!"
You seem to have researched your problem more than anyone else here would research it for you.
Document your results in the form of a HOWTO, or HOW-NOT-TO as the case may be. Just remember that active attacks are not necessarily your largest problem. Packets can still be sniffed off the air and analyzed, no matter what protocol you use.
...
Why not use a DHCP server that hands out IP addresses that aren't part of your internal network. e.g. if you're internal network is 192.168.0.x, then have it hand out 192.168.1.x addresses. Then use any sort of VPN to connect to the "real" network.
DHCP and VPN solutions exist for just about everything.
Really. I looked into PPPoE and it's pretty nasty. I recently set up a wireless network for a company in Birmingham and found that the easiest thing to do was just use IPSec - Linux supports it, FreeBSD supports it, Win2K and XP support it. Set up one Linux or BSD box as an access point (note that you don't want ad-hoc mode for this) and use either shared secrets for each node or keypairs - that's an easy sneakernet install. If you want you can do clever things with your firewalling so systems without keys or secrets can get onto your network and abuse your network connection.
There's plenty of IPSec and 802.11b HOWTOs out there, and they're pretty useful - just make sure you're using a recent version of racoon, the *nix IKE daemon, and you should be fine.
I would say your taking a big risk by doing this. MPPE is trivial to break, and is just downright bad by design....If you loose a single packet on the wireless connection, ppp is going to have to stop, and renegotiate encryption if you set it up to be stateless.... so then somebody is going to be able to sniff everything, and then use the nice packages out there to break it, then watch EVERYTHING that is going on with your clients... in about a 10th of the time that it takes with WEP.
Either that, or tunnel everything with SSH2
Works for me (although I've not gotten encryption running yet), works for linux, works for Win 95 and higher without installing extra tools. Full authentication and encryption support. This should get you going. It's similar to PPPoE, except I suspect it's a little less hated by sysadmins.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
just wondering.. why not? thus making it pppoe workable on pda.. just nitpicking but :).
and another thing, does there yet exist a way to windows to get the ppp to talk to a tcp-port instead of com-port?(serial-port-> tcp wrapper basically, i know it's not a good solution/smart but i got a friend who needs to do this and i'm finding it hard for him to install linux/freebsd on his main, and only, computer).
world was created 5 seconds before this post as it is.
Why TCP Over TCP Is A Bad Idea
If you want to try it, consult the VPN PPP-SSH Mini-HOWTO
hello? " i know it's not a good solution/smart ". i knew somebody would link to why that is a bad idea and yadda yadda yadda...
i wasn't asking for a linux/freebsd/anything else than windows solution, but a way to get _windows_ machines to do this(get ppp talking to tcp-pipe, the searches i went through a couple of weeks ago came up empty, but there was a bazillion other guys wanting to do the same on windows platform too, so what i was asking for was that if somebody knew that somebody had written a dummy modem driver that instead of talking to a real modem actually just piped it to a tcp connection..).
world was created 5 seconds before this post as it is.
easy. assuming that you're sharing root keys between two boxes (not smart, and there's more elegant ways to do it, but this should give you the general idea.)
on one box (the trusted box:)
pppd pty 'ssh -t trusting.host.net pppd noipdefault noauth' trusted.box.ip:trusting.box.ip
the -t is important, or pppd on the remote end will choke.
You're doing it wrong.
I work for an ISP that sells broadband wireles. In designing our network, I chose to use almost the exactly same setup as you described. PPPoE gives us a lot more flexibility than any other access control method. You can back it with RADIUS for simple user management, and there are a lot more client solutions out there, ranging from free to licensed. We've been running with few problems for over 6 months now with our current hardware setup. I'd suggest checking out MikroTik RouterOS. It's a linux-based OS that supports everything mentioned thus-far in this thread.. from PPPoE to PPTP and even IPsec. You can even toss a pci/pcmcia card in it and make it an access point which removes another device from the network.
PPPoE is a terrible, terrible protocol in my opinion. I'd go with IPSec myself...
Except that this won't work on windows, which was the point of the question (that I mis-read).
The situation would change if someone wrote a tun/tap driver for Windows
It appears there are all types of network tunnels available for other platforms.
whoops... i misread that as well.... erk.
prior to windows 2000 (or NT4 if you can handle PPPoE), there's no easy way to set up tunnels. Win2k and XP can do IPSec tunnel mode, and L2TP/IPSec; either of these are fairly rad and play nicely with free software at the other end.
There's a whole bunch of links floating around the shop with details, most of them are linked from freeswan.org.
You're doing it wrong.
Have you considered Nocat or Auth. Gateway?
No complicated setup or client component required, just a browser or SSH. They don't do encryption so you'll need to use encrypted channels(ssl, ssh, etc..).
I don't have time or energy to create a login here. Got more to do, like work on improving the 802.1x standard.
As to this idea, CHAP on wireless is passing out passwords for free.
I don't have time to rip this up any more than that.
Robert Moskowitz
rgm@icsalab.com