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."

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."

Re:NoNO

[Anonymous Coward]

I really don't think PPPoE is that insecure, not the way this guy has it planned out. Passwords are encrypted, and he even knows about MPPE encryption (which is just as good as WEP encryption. BTW. Even better, because every single - M$ - L2TP client supports it)

IPsec is not the Holy Grail - In fact, it's more like the Holy Mess. Just try doing it in a heterogeneous environment (i.e., not all-Linux) and see how far it gets you.

In fact, his idea seems so well thought out (and simple) I'll investigate it myself. I'm totally fed up with wierd vendor-specific solutions.

Re:NoNO

[Anonymous Coward]

IPSec is (quickly becomming) the right way, especially when you are in a heterogeneous environment. Just don't fall into the trap of vendor specific extensions, like user/password based authentication. IPSec is not yet the univeral and easy solution it needs to be for widespread adoption, but the pieces are falling into place. SDNS is one large missing part of the puzzle which could make IPSec plug&play, but even without that, it is not very hard to use.

Ipsec Tricks?

[Ashran]

WinXP Supports IPsec out of the box. (Okay, you have to install the support tools from the WinXP CD, but thats it)
http://www.natecarlson.com/linux/ipsec-x509.p hp

I've setup an Linux IPsec GW for WinXP with dhcp a few days ago .. works like a charm.
(Using the x509 patch of course)

Go for it.

[cybermace5]

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.

Seperate Network and VPN?

[Zack]

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.

Re:Seperate Network and VPN?

[sporty]

Because your DHCP server becomes vulnerable, since it does everything in a non-encrypted protcol, where as with PPP, everything is encrypted.

'sides, you can DOS a dhcp server by taking all IP's possible.

Re:Seperate Network and VPN?

[Zack]

The only thing the DHCP server does is hand out IPs. That's it. After that the connection is done over a VPN which is all encrypted.

And you can DOS anything. Just flood the 802.11 spectrum with crap and nothing will work.

Re:Seperate Network and VPN?

[sporty]

Yeah, but DOS'ing a DHCP server over wireless means your internal network can't even get an IP... which can screw up some bootups.

Re:Seperate Network and VPN?

[Zack]

Only if you use the same machine to do both internal and wireless DHCP. That's why the two networks are kept completely seperate, connected only by what we'll call the "wireless gateway"

So the "wireless gateway" hands out IPs to the wireless folks (in a different range from the internal network) and acts as the VPN router for the wireless. That's all that box should do. Then it has no effect on the internal network except for routing authorized network traffic.

Re:Seperate Network and VPN?

[Ashran]

Theres no 100% need to seperate them phyically, just use two daemons for the two different interfaces.

Re:Seperate Network and VPN?

[Ashran]

> Because your DHCP server becomes vulnerable, since it does everything in a non-encrypted protcol, where as with PPP, everything is encrypted
http://www.strongsec.com/freeswan/dhcpr elay/ipsec- dhcp-howto.html

If I read the thing correct everything happens encrypted in this example... not 100% sure tho
(DHCPRelay is listening on ipsec0)

More Hassle Than It's Worth

[alexpage]

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.

MPPE

[LWolenczak]

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.

Re:MPPE

[LWolenczak]

I would suggest a google [google.com]. Personally. I have not messed with MPPE in over a year and a half, but the design issues remain the same. The ppp session stoping and renegotiating encryption is part of the MPPE design.

IPSEC is your friend

[vasqzr]

Either that, or tunnel everything with SSH2

Try PPTP

[shepd]

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 [poptop.org] should get you going. It's similar to PPPoE, except I suspect it's a little less hated by sysadmins.

Re:Try PPTP

[teqo]

Before deploying PPTP, you might want to have a look at these security issues [counterpane.com]. Others consider it secure as long as the keys are sophisticated enough, IIRC...

Re:Try PPTP

[LWolenczak]

But the keys can be broken... the entire session can give a wealth of information.... Everything from the NTLM Password hashes.... to the data of the session. Since the keys are generated from the NTLM hash, the keys can never be sophisticated, or even secure at all. PPTP over wireless is even more of a risk then using it over the normal internet... because all somebody needs is a yagi from down the street to record everything.

Re:Try PPTP

[teqo]

Don't get me wrong, I rather do not advocate PPTP as the best solution for secure wireless networking. I would opt for something which has proven (or belived) to be more secure, like IPSec.

However, I know people deploy PPTP-based VPN networks, for several reasons, among them PPTP being a free (as in beer) VPN version for Windows versions since Windows 95. I know of a university WLAN network which has to deal with numerous clients the network admins don't control and thus have to support as many client versions as possible. They chose to use longer passwords, which function as 'keys' in MS PPTP.

It's true that the challange/response authentication scheme has been proven [counterpane.com] to be pretty insecure, mainly because LAN Manager passwords are suffering from significantly weaker encryption than NT passwords, but for backward compatibility reasons both are sent together, always, which makes password guessing way more easy. I figure that is what you refer to as 'breaking keys'. I agree. OTOH, Microsoft released a so-called pptp3-fix, which fixes the LAN Manager password problem. I know there remain a number of other issues, but the main problem has been fixed in there, according to MS and some other [ciac.org] sources.

Still, I am no fan of PPTP. But sometimes, admins face needs which force them to make compromises...

Re:Try PPTP

[DA-MAN]

To get encryption going, you will need to install a couple of patches.

1) The kernel patch for ppp w/ mppe support 2) pppd patch for encryption support

check out this link [sourceforge.net]

Re:Try PPTP

[shepd]

Thanks a million!

I'll try that... I think it'll solve my encryption problems. :)

zaurus pppoe? (and ppp-over-ssh-in-win-q)

[gl4ss]

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).

Re:zaurus pppoe? (and ppp-over-ssh-in-win-q)

[Nynaeve]

does there yet exist a way to windows to get the ppp to talk to a tcp-port instead of com-port?

Why TCP Over TCP Is A Bad Idea [sites.inka.de]
If you want to try it, consult the VPN PPP-SSH Mini-HOWTO [linux.org]

Re:zaurus pppoe? (and ppp-over-ssh-in-win-q)

[gl4ss]

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..).

Re:zaurus pppoe? (and ppp-over-ssh-in-win-q)

[Michael Hunt]

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.

Re:zaurus pppoe? (and ppp-over-ssh-in-win-q)

[Nynaeve]

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 [google.com]
It appears there are all types of network tunnels [netheaven.com] available for other platforms.

Re:zaurus pppoe? (and ppp-over-ssh-in-win-q)

[Michael Hunt]

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.

Works for me

[Dan Sisson]

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 [mikrotik.com]. 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.

Another way?

[amblin]

Have you considered Nocat [nocat.net] or Auth. Gateway [tldp.org]?
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..).

Re:PPPoE for 802.11

[Apathy costs bills]

Robert, great point.

Despite the fact that this rather funny article on CHAP [experts-exchange.com] claims that reverse-MD5'ing a password is hard, any one way hash is going to be hit hard by a decent dictionary attack, especially since you get to go offline and attack it with as much computing power as you want.

In short, bad idea.