[NTLUG:Discuss] Wireless Home Network -- WEP+MAC filter, VPN or Kerberos, 802.1X+EAP-TLS, etc...

[Bryan J. Smith]

TOP-POST SECTION:  

- Bare Minimum / Maximum Compatibility WLAN Security

At a _bare_minimum_, with any 802.11 AP, I recommend the following:

1.  Turn off SSID Broadcast
2.  Enable MAC filtering allowing only _specific_ MAC addresses
3.  Enable 128-bit WEP and _require_ it for access

In this configuration, at the most, a potential vunerability _only_
exists _if_ a wardriver is around when you are sending 802.11 frames.
He can then still discover your SSID and MAC, emulating the latter, but
it does become somewhat of a PITA to crack a 128-bit WEP key, although
it is only RC4 with some weaknesses so it _can_ be done.

This is compatible with any 802.11 compliant wireless AP, or should be.

The IEEE designed WEP as a basic, common denominator privacy mechanism. 
At the time, you couldn't find much power in a AP, and today's common,
embedded 200MHz MIPS or PowerPC core was more like sub-25MHz at the time
802.11 and WEP were released.  Although the IEEE still made a few errors
in design.

- VPN, Kerberos and host-to-host/network authentication/authorization

Beyond that, then we must start to talk about options.  A quick and easy
option is to put the AP on its own "zone" -- like with IPCop 1.4.0 and
its "BLUE" zone.  Now you simply provide a port pinhole so a
host-to-network VPN protocol will work.  The choice is up to you, but
something like IPSec (OpenSWAN and NT 5.x built-in), tunneling over SSH,
etc...  SSH is an effective mechanism for many times of access, and I
recommend it for portable users who don't need a full VPN connection --
especially using mutual DSA keys.

More traditional, but very effective is to Kerberosize your networks.
This is more involved, but solves the problem nicely.  You can even
drop the zoning requirement, although zoning and allowing only a fixed
set of Kerberozied ports through.  Ideally your wired network should
have a 5th zone, one dedicated to the KDC (Kerberos Distribution
Center), allowing only port 88 into it.  A lot of Fortune 100
enterprises I have been at, both ActiveDirectory and independent
LDAP/Kerberos infrastructures, have used this for their wireless
clients.  Their Kerberos tickets expire every 5 minutes (instead of
every so many hours or days).

[ The "lack of protection" of the KDC is why I _dislike_ Microsoft
ActiveDirectory's implementation of Kerberos.  I think the Freedomware
community should come up with a better implementation, although that
would mean we need a better, private LAN-designed, integrated, layer 2
and layer 3 name server than we have with disseparate BIND, DDNS and 
DHCP services. ]

- 802.1X, LEAP/PEAP v. EAP-TLS, etc...

Probably the "holy grail" of network-level authentication is with IEEE
802.1X.  For those unfamiliar, the IEEE 802 project consists of the
802.2 LLC -- Logical Link Control (LLC), the upper portion of the OSI
Layer 2 Data Link layer) -- and the 802.3-15+ MAC -- Media Access
Control (MAC), the lower portion of the  OSI Layer 2 which deals with
the actual, physical connections (.3 Ethernet, .5 Token Ring, .10
VGAnyLAN, .11 WLAN, etc...).  What 802.1 is an "open feature" committee.

802.1X is network authentication, a way to authenticate nodes when they
attempt to use the network, possibly encryption as well.  802.1X itself
is just a protocol standard, and not a specific implementation.  802.1X
like XML where it's a framework, not an actual implementation, so there
is _no_ guarantee that one 802.1X/XML implementation is any compatible
with another.

A lot of legacy 802.1X implementations use RADIUS, either an open or
vendor-specific one (e.g., Microsoft's Internet Authentication Service,
IAS, is RADIUS).  They are fairly flawed because even if they are
encrypted, many are not, the authentication is rather simplistic in most
cases.  Shared secrets or many other details that leave them no better
than WEP.  Authentication is key, more so than just encryption.  Mutual
authentication is best, meaning both sides can authenticate each other.

The IETF has pushed for EAP-TLS, which is also a mutually authenicated
implementation for 802.1X.  X.509 is required to work, so it also
prevents some major implementation overhead and considerations.  Several
vendors (e.g., Sun, Novell, others) have added EAP-TLS support into
their X.509 directory services to minimize the manual implementation
requirements.  There does not seem to be a full, Freedomware solution
yet that does not require a lot of "piecemeal" coordination.  But it can
be done -- especially if you already have an OpenLDAP+GSSAPI setup where
Kerberos is being used as the underlying authentication service.

Cisco and Microsoft have their PEAP "Protected" implementation of
Extensible Authentication Protocol (EAP), built upon Cisco's previous
LEAP "Lightweight" implementation of EAP in their hardware, using a
"vendor extended" EAP-TLS implementation.  LEAP has many hacks against
it, and it hard to change because it's in so much firmware.  PEAP
improves upon many things with it, and the integration into the various
mechanisms of ActiveDirectory (shared secret, Keberos or X.509) means it
offers a lot of flexibility and reduced integration headaches (although
X.509 in ActiveDirectory is still a challenge requiring deep, manual
implementation).  Both provide mutual authentication.

EAP-TTLS is a more legacy compatible implementation of EAP-TLS, which
has been seeing some deployments.  On the host side, it imploys PAP,
CHAP, MS-CHAP and other legacy compatible interface.  On the service
side, you can use an existing RADIUS server, instead of going with a
full blown X.509 infrastructure.  This has been popular with even
ActiveDirectory setups.

BOTTOM POST SECTION (Quotes and Reponses)

Tom Hoover wrote:  
> _If_ you have only a wireless network, connecting all of the computers
> in your house, then I'll have to agree with you...you're a little
> better off with it inside (you'll then have two layers of protection
> between your wireless network and the "internet").  

As I raised the question in my previous post, how is the packet filter
of one "router" better than another?  If one is compromised, another
could be as well.  Also, if the compromise is on the host side, what
protections do you have to prevent it from going out?

So I don't know if I'd call it "better."  Multiple layers are only good
when there are truly different levels of protection.  In this case,
we're talking the same level of access, but different "zones," so there
should really only be one firewall with multiple zones of control.

> But, as I mentioned in my previous message, I use only _wired_ on my
> internal network.  If I put the wireless inside the firewall, there
> would now be two potential ways to get to my internal network.  Since I
> keep it outside the firewall, there's only one potential way into my
> internal network (the Linux firewall/router)...it doesn't matter if I
> put 2 or 3 wireless routers outside the firewall, there's still only one
> potential way into the internal network.  I'd just rather have "one"
> potential weak spot than two separate ones.

Again, multiple zones of control, but all equal in access.

> I guess it's a difference in the way that I use the wireless router.
> I really don't care if an undiscovered firmware bug causes it to be
> compromised, I use it only as an access point for our laptops.  To
> access the internal network, I have to ssh thru the firewall into the
> internal network, which encrypts all wireless traffic anyway.

SSH does more than that.  At just a base level, SSH offers far better
authentication with a better level of non-repudiation than WEP.  Using
DSA public keys, SSH offers full non-repudiation with mutual
authentication.

> Since I don't have any unencrypted (or weakly encrypted, such as WEP)
> traffic on the wireless network, I don't care if someone wants to
> connect to wireless router...they're no more of a security risk that
> anyone else on the internet.

That's fine and dandy for accessing your LAN, but how do you prevent them
from accessing the Internet?  I.e., you don't want just anyone leeching off
your broadband (or other) connection, do you?

Or are you preventing _all_ access to the Internet by _requiring_ they go
through your LAN _first_, and you can only access that through port 22?
That would work, since you could tunnel ports 80 and 443 to your LAN,
possibly a Squid server on that LAN, first.

That's what I do with IPCop 1.3.0.

Paul Ingendorf wrote:  
> The point is to bridge the gap between the security and utility of a
> wireless connection while maintaining your feelings of security.  These are
> all personal matters and different people have opinions to differing degrees
> of each factor.  In the end WEP is better than nothing, trying to make
> wireless as secure as a wired connection will ultimately remove the utility
> of it and in the end all it takes is someone determined enough to get in to
> do it.

Again:
- No SSID Broadcast
- MAC Filtering to allow only _select_ addresses onto the AP
- Then 128-bit WEP

It's easy and compatible.

> I recommend you determine what you will not be able to live without as far
> as the utility goes spend your time figuring out what degree of prevention
> allows for your ideal usage and then implement a best practices approach to
> the situation.  With the amount of wide open wireless access points out
> there I would venture the guess that simply running wep lessens your chances
> of being hacked to about the same as your chances of being hit by lighting,
> twice.

And that was the intent the IEEE set out for.  They wanted a "basic" mechanism
of authorization to access the AP, and not a full authentication mechanism that
would be far better served for _all_ MAC types with a 802.1 standard like 802.1X.

The IEEE doesn't exist to set standards, but to provide or, better yet, document
an existing practice for others to follow.  They do not wish to tell vendors how
to provide solutions to problems that are complex.  Network-wide authentication
is one such complex issue.


-- 
     Linux Enthusiasts call me anti-Linux.
   Windows Enthusisats call me anti-Microsoft.
 They both must be correct because I have over a
decade of experience with both in mission critical
environments, resulting in a bigotry dedicated to
 mitigating risk and focusing on technologies ...
           not products or vendors
--------------------------------------------------
Bryan J. Smith, E.I.            b.j.smith at ieee.org