State of Secure Wireless Networking?

Mr. Sketch asks: "At my office, they want me to add a wireless network and it seems like it could be possible to do it in a secure way, but I'm not 100% confident. The setup I was thinking of was 802.11g only (no backward 802.11b compatibility), WPA-PSK with AES encryption with a 15 character password consisting of upper and lower case letters and numbers and special characters, MAC filtering, no ssid broadcast, and no default anything (ssid, passwords, etc). How secure would this network be? What type of attacks would it be vulnerable to? I haven't found any tools to crack AES, only WEP, does that mean it's secure or I just that I haven't looked hard enough? I want the wireless computers to still be able to access the computers on our network, in fact ideally, I just want it to be a wireless extension of our wired network, but only if it's secure enough. I'm sure there are plenty of other companies who want to add wireless to their network, but want to be reasonably confident that it will be secure and are unsure of the current state of wireless security."

tell me your SSID, password, subnet info,

[kayen_telva]

and address. I will tell you if its secure ;)

or just use IPSec on your whole network ?

[johnjones]

why not just use IPSec on your whole network ?

or just on the wireless network and use a gateway

Why is this so hard ?

regards

John Jones

Lock the door

[SillySnake]

Just be sure to lock the door to the servers and access points :)

The same as it was last week...

[AKnightCowboy]

and the week before that, and the month before that. Do not rely on your wireless access point's built-in encryption and authentication under any circumstances. Use it as a barebones minimum and then drop a VPN on top of that. Make sure the access points terminate on an insecure network isolated from the rest of your trusted LAN and require VPN access to reach the trusted side. Anybody that was trusting LEAP just got burned last week so don't make the same mistakes about trusting a hardware implementation when there's proven software VPN solutions that have stood the test of time.

Re:The same as it was last week...

[Deffexor]

Don't forget Ars Technica's finding that if you turn off SSID [arstechnica.com], Windows Wireless Zero Configuration may connect your to other networks that you don't want to connect to.

Re:The same as it was last week...

[T-Ranger]

I would tend to agree 100%. The whole slew of wireless technologies are changing too fast to choose WiFi specific solutions.

Even if you go with a commercial VPN solution, with dedicated/specialized hardware, you would still have vendor independence with the APs... Since you could run multiple VPNs you have a nice upgrade path too. If you rely on the APs, then to upgrade you at best would have to flash every AP you have, or if thats not possible, replace all of them.

My theory is to use the stupidest possib

Re:The same as it was last week...

[innosent]

Yeah, something like a Linux or FreeBSD machine with two NICs, one to your AP(s) and the other to your network. Set up PoPToP or IPSec on the machine, and have all clients use a username and password to connect to the VPN server. If you use PPTP (PoPToP) or IPSEC, virtually every client will be able to connect without additional software. If you do use PPTP though, and intend to use it for Windows clients, be sure to disable MSCHAPv1, and use only MSCHAPv2, since v1 is actually less secure than WEP. With the gateway server installed, you could even allow NATed connections to the internet (for clients in the board room, visiting, etc...), but deny access to the internal network to anyone not on the VPN. FreeBSD and Linux are both ideally suited to this sort of thing (I have a similar solution to this on a FreeBSD box at work).

Whatever you do, don't use hardware solutions. Ever had a flash update fail on a router? Try explaining why nobody can connect because the APs ROM is toasted, and that it will be three days before a new ROM comes in. Hardware security solutions have just as many errors (if not more) as software ones, but they are a hell of a lot worse to update. Don't trust them, and you likely won't have to deal with them. Also, sometimes it's best to go with a product that less well-known (i.e. NOT Cisco, Linksys, RealSecure (laughs), Internet Security Solutions (laughs again), Microsoft, Microsoft, Microsoft....), since you won't see an exploit that has 500,000 machines attacking your network within two hours of the release of the patch (or before). I have had to fix two security issues with my FreeBSD box since it went in, and only one required a 2 minute service outage (reboot).

Re:The same as it was last week...

[Bishop]

VPN technology is more mature and better tested. When it comes to security that is a very nice feature. VPNs are easier to manage due to a better suite of management tools. Typically VPNs can be managed in one place versus manageing multiple access points. Secure easy to use administration is often overlooked, but it is a very important piece of the security puzzle. If a procedure is difficult or time consumeing, it is not going to be completed in a timely fashion.

Public shared keys as used with WPA-PSK are difficult to manage and generally a bad idea. Consider the following: A laptop is lost or stolen. If WPA-PSK is used, the password on every wireless client must now be changed. This is not a quick and easy task. If a VPN with certificated based authentication is used instead, only one certificate needs to be revoked. Revokeing a certificate is a trivial task.

There is one advantage to WEP or WPA. Useing either will keep the wardriving kiddies away.

Regarding AES:

While AES is better then the RC4 algorithm used in WEP, it dosen't mean that a product using AES will be more secure. RC4 is not the problem with WEP. The poor implementation of RC4 is the problem. Specially WEP allows known weak keys. A poor implementation of AES could also be vulvnerable to attack. This is a big problem with encryption. Too many people see a product's buzzword compliant encryption algorithms and assume this makes the product secure. Any idiot can use encryption, but it takes a smart developer to use encryption properly.

Re:The same as it was last week...

[AKnightCowboy]

While AES is better then the RC4 algorithm used in WEP, it dosen't mean that a product using AES will be more secure. RC4 is not the problem with WEP. The poor implementation of RC4 is the problem. Specially WEP allows known weak keys.

My main problem with WEP is it's silly to use outside of a group of about 10 people. After that you really need to use rotating keys that are different for each person, otherwise when some employee leaves your company then everyone's changing their WEP key. It just doesn't

Security

[rusty0101]

How secure would this network be? What type of attacks would it be vulnerable to? I haven't found any tools to crack AES, only WEP, does that mean it's secure or I just that I haven't looked hard enough?

AES itself is considered a strong encryption technology. How secure it will be for a WiFi connection is anyone's bet. It is the approved NIST standard. (US centric) see http://csrc.nist.gov/CryptoToolkit/aes for more information.

You could enhance it by putting in an SSH VPN to a seprate box on your network.

Connect your AP to the network through a firewall that only allows the SSH tunnel to communicate with the tunnel server, and drops all other traffic. The ap would provide it's own DHCP server to eliminate unnecessary load on the firewall.

Then again, I work in an environment where we do not allow any wireless networking.

-Rusty

What about ad hoc problems?

[KingOfBLASH]

If I understand wireless networking correctly, somebody can key in the info you give them for access to the network, and then allow unsecured, "ad hoc" network access -- meaning people could get into your network through their computer. Do you have control over all of the computers? I would worry about such a security hole if it's possible.

Re:What about ad hoc problems?

[UnseenEnigma]

they would also need to mimic the mac address of a currently offline system on the network though. Not a big deal but lets face it its not hard to plug a laptop with a packet sniffer or a port stealing or arp poinsoning equivelent. Unless u can trust the physical security or your entire wired environment i dont see a great deal or difference.

Re:What about ad hoc problems?

[petard]

Sure. And someone can add a second ethernet card to their machine, plug in a wireless access point, start a dhcp server and nat, and give the whole world wide open wireless access to your wired network. Or they could install a wireless card and run hostap wide open. Or use nocatauth and charge others for access to your network.

If you don't have control over every (wired or wireless) computer connected to your network, outsiders could be able to connect to it. This problem is not restricted to the wireless

secure

[AMystery]

I do some wardriving and I can tell you that I wouldn't even attempt to break into what you just described wirelessly. If I did want in, it would be much easier to walk in the front door and socially engineer the secretary. WEP has been broken, I seem to thing one form of WAP has been, not sure which, but it is so difficult that a physical attack would be much more likely. Is your wired network that secure or can anyone plug into an open port and have full access?

You should map the network, understand where the signal reaches and try to tune the power to only go where you want it.

If you are paranoid enough to want to try all of the layers of encryption, and you should be, its fun to do. Then go with the setup you have and put IPSEC on top, that will make it at least as secure as your wired side. Be aware that you won't get anywhere near 54MBs with all of the encryption loading down the system, so it will be slow.

I am not aware of any attacks that could brute force this setup, but it would be easier for someone to socially engineer it, MAC addresses can be cloned, VPN logins stolen, so some form of automated monitoring would be nice, checking for duplicate logins, unauthorized times. Why is Bob trying to authenticate at 3AM? That kind of stuff.

Re:secure

[duffbeer703]

I was socially engineering the secretary the other day and had a great time. I was too sleepy afterwards to hack any networks, though.

Re:secure

[Hektor_Troy]

I tried to hack the Penthouse computer facility the other day. Their firewall consists of 2 million images of centerfolds, so I never got past that.

Then I tried to social engineer the secretary to give me some passwords. I did manage to get some numbers from her, but they turned out to be her measurements (5'4, 120 lb, 34, 22, 33) and her phone number.

My conclusion is that it is impossible to gain access to their computer network. And that I don't really care anymore.

Re:secure

[Mr. Sketch]

Thank you. This is all I was really looking for, was if it would be enough to stop the casual wardriver. I'm sure that any network (wired or not) can be hacked by a determined individual. I'm sure that VPN would provided added security, but we don't have any VPN equipment and it would be fairly time consuming to set it up for only a marginal increase in security over the existing setup. I might consider putting IPsec in place. So, even if someone clones the MAC address, they would still need the PSK to

Why not use a VPN

[Masarand]

Don't rely on the 802.11x security features, just put a Contivity VPN box between your wireless infrastructure and your LAN.

This gives you bomb-proof security using proven technology, avoids key distribution problems and allows you to upgrade the wireless infrastructure with less effort.

http://www.nortelnetworks.com/products/01/contivit y/

Re:Why not use a VPN

[pinkocommie]

Quick question about how this would work. Most VPN solutions that i've seen (and yes i havent see NUTHIN :-D) are end to end and provide a simple network connection where I can hook up a pc or an access point etc. Now if the access point connection is promised even though the next link is encrypted it won't do anything for security. I mean if the client was authenticated with the vpn end point via a certificate or password or SOMETHING , it might make sense. and I wanna know how , not thread crapping. Than

Re:Why not use a VPN

[Masarand]

I think it works like this (I've seen it going, but didn't set it up myself:)

You link up all the access points to switches, which in turn pass packets up to the Contivity box. The Contivity box acts like a kind of bridge between the insecure wireless network and your secure LAN. You will also need a DHCP server on the wireless network.

It's best if you can get your switches NOT to pass packets between the access points so an intruder can't attempt to access your mobile laptops.

At the risk of getting fl

Re:Why not use a VPN

[pinkocommie]

No, the point I was asking was how does the access point know the laptop is the right one (if the key is compromised). Was wondering if there was a 2nd layer thing like certificates (someone else up there suggested ssh but obviously can't use that for win2k machines).

Re:Why not use a VPN

[Masarand]

Ah, sorry - misunderstood. The laptops are not authenticated. Experience suggests that it's simply not possible to distributes key/certificates to 10,000 machines and prevent them from escaping, Authenticating users is much easier!

Re:Why not use a VPN

[okallydokally]

The only way you'll get "bomb-proof security" out
of a Contivity box is if you give all your clients
a certificate.

The password option-- which most everyone deploys--
is insecure.

It uses a shared password in the IKE exchange and
then does an ineffectual username/password authentication.
It's ineffectual because it is not bound to the
phase 1 IKE exchange. The keys derived from phase 1
and phase 2 in IKE will not be authenticated and
therefore the security guarantee that IPsec gives
you has just been voided.

Really

WPA-PSK

[rlwhite]

If there is any weakness in this setup, it's probably in WPA-PSK. It's intended more for home use than for corporate WLANs. If the PSK password gets compromised, you could be in for trouble. Of course if the password is strong, the only attack I know of is to get physical access to one of the wireless nodes. I'm not all that familiar with the new protocals; the attacker may still have to find a way past AES to make use of the compromised PSK.

Don't foget reliability.

[rawg]

All this security stuff to keep people out of your network, but don't forget about people jamming up your network. It only takes one client to mess up everything.

I'm running a small WISP and have found that some radios can crash my access points. Make sure you get a real good AP, like Cisco or something. I've use the cheap ones. Linksys, D-Link, and I end up having problems. So I built my own with a Soekris board using Linux. Same problems. Switch to FreeBSD (m0n0wall). Same problems. The dam things crash almost every day. The biggest reason... Power Save Mode on a client computer.

One big problem

[fred fleenblat]

One of the most difficult problems is that since linksys boxes are so cheap these days, it's not unusual for a misguided employee to just bring his old one from home and plug it into the corporate network. Hey the super-secure ultra-locked down DMZ'd VPN one you provided didn't even show up in the pop-up menu so obviously it was his right to just get something working.

Some really high-end wifi equipment will scan the airwaves for unauthorized signals, plus scan the wired network for IP addresses that are act like access points and then notify you or even attempt to shut them down.

use 802.1x instead of PSK

[puneetb]

everything looks fine except for the WPA-PSK part. Use WPA with 802.1x authentication instead of pre-shared keys. Its more secure and makes overall management easier (want to lock a user out, just disable his account on the server; users can use the same password as they use on their VPNs or on your regular network, a new master-key is generated per session, you can allow users to login only at specific times or from specific access points). The only problem is that authentication takes a wee bit longer th

As much as any other...

[poofmeisterp]

It's only as secure as any new encryption method that comes out. WEP was thought to be secure until it was proven not to be. Now, WPA is said to be secure. It may or may not be. You won't know until you're either hacked or someone else is.

Be warned: Turning off SSID broadcasting, enabling MAC filters, or even lowering your AP power levels can result in unexpected behavior.

For instance, my Dlink access point/router has a firmware update that features WPA, but it doesn't work with my Gigabyte w/l card. A few small packets can get through, but large packets are right out of the question. Sometimes there will be windows of a few seconds where I can get traffic through, but they go away in 5 seconds or less.

I switched back to WEP and everything was peachy. I then turned off SSID broadcasting. My w/l cards (all of them) would no longer recognize my active network because they couldn't "see" it. There isn't a way to hard-code or static-set the SSID name, channel, etc into my cards. You'll need to find one with hardware or software that supports connecting to networks that don't have a visible SSID. Basically, one that remembers what channel it was last on.

It's frustrating. Also, if you're paranoid about security, run your traffic through a VPN. It's a pain in the butt to set up, but it should work. Get ready for lots of support calls, too. Calls like "It was working, but I rebooted my machine and now it can't see the network", "the network is slow", "Why does it say the signal quality is low a lot of the time and I'm using the network just fine?"

You'll hear lots of that :)

AES and WPA security

[aminorex]

AES probably won't be cracked any time soon. It's greatest practical vulnerability is from the emergence of quantum computation, and presumably the importance of your network traffic is not sufficiently long-lived so that it is worthwhile for anyone to archive the bits until QC decryption is practical.

What IS vulnerable in such a system is key management, and platform integrity. To help insure platform integrity, use open-source software via an in-house or trusted and certified build. Key management pol

Advice from the Inside Track

[RedLeg]

FWIW, I'm on the IEEE 802.11i standards committee that built WPA and the rest of it....

I would recommend that you implement (now) WPA with TKIP encryption. If you're a MS shop, and have an Active Directory infrastructure, adding MS IAS (internet authentication server) to that is very easy, and you're probably already licensed. Then you get to choose between authentication methods, and MS supports (and integrates into XP) EAP-MS-CHAP and EAP-TLS, basically login/passwd and digital certs, respectively. I would avoid Preshared Secret Keys (PSKs) due to their vulnerability to off-line dictionary attacks, unless you're willing to generate the PSKs in a cryptographically sound manner and push the length out quite a bit.

Likewise, I would counsel caution about using the AES encryption. If you purchase all of your gear from one vendor, you'll probably be OK, but there are a couple of gotcha's that you need to know about. First, the IEEE 802.11i standard which specifies CCMP (the AES crypto) is not yet final. It's extremely unlikely, but it _could_ change (we meet next week). Any vendor you choose today would likely provide updates in the event of a change, but who knows. More importantly, because the 11i is not final, the Wi-Fi Alliance has not yet integrated CCMP into their testing. So not only do you have absolutely no guarantee of interoperability, no one other than the vendor has tested the crypto implementation. Most crypto folks have a good feeling about AES, but no sane cryptographer trusts an implementation that hasn't been 3d party tested.

Unfortunately, if you need to support Linux, you're in for a hard time. I am not aware of a complete working set of client-side "stuff" to integrate into this lashup, although I did notice the beginnings of some support in the recent 2.6.5 kernel. Do NOT assume that you will be able to get linux working in this environment right now. It's comming..... but it's ain't there yet.

Now, on the subject of some of the other "advice" offered here....

• Disabling broadcast of SSIDs is useless. It will hinder the performance of you network, and offers no improvement to your security whatsoever. The reason for this is simple: the SSID functions as a name for the wireless LAN, to enable a client to differentiate. Think of multi-client office buildings. Now, you can disable the broadcast of the SSID on the AP(s), but that does not remove the SSID from ALL of the wireless frames. Specifically, disabling broadcast removes the SSID from the BEACON transmitted by the AP, but the SSID MUST remain in the PROBE, PROBE-RESPONSE, ASSOCIATE-REQUEST and a few others for the network to work at all. All you have done is hide from netstumbler, but not from many of the other "stumblers".
  
• As far as VPNs, if you already have one, integrate it into your plan. If not, don't sweat it.
  
• Make SURE you disable support of WEP. It is possible to support both WEP and WPA, but it's an extremely bad idea, and WILL lead to the compromise of your network.
  
• MAC screening is not a bad idea. MACs can be spoofed, so it's not foolproof, but it does help (some). It may not scale for you depending on the number of clients you have to support.
  
• Check and see if your APs support time-based access controls, and if they don't look into placing them on "burglar timers", available inexpensively at Walmart, etc. The idea here is simple: disable access during non-business hours.
  

There is a book out from Microsoft Press that gives a lot of background, and takes you step-by-step through getting all of this crap up and running in their environment. I have met the author, and know a number of the contributors from the committee. I highly recommend it, available here [amazon.com]. I sincerely hope all of this helps....

Re:Advice from the Inside Track

[RedLeg]

I'm sure it's centrally managed, probably through a radius server. This scales just fine, as you enter a MAC once, on the central server. Imagine doing that on EACH AP individually. For extremely large deployments like your university, it's easy to see that no AP would have the internal capacity to store that many MACs, so they more or less have to do it centrally.

You can also bet these are not consumer-grade access points like the original poster seemed to be leaning towards, but higher end units. Cons

Re:Advice from the Inside Track

[Mr. Sketch]

Thanks for the inside track information. I was aware of the AES concerns, but we've had pretty good luck so far and we will probably only have about 5 total wireless clients in our pretty small office. So the scaling issues with MAC filtering shouldn't be a problem. At the moment we have no plans for linux clients, but we aren't a 100% Microsoft shop, we have a few solaris boxes and one linux box, but none of them will ever be made wireless, and our servers aren't Win2k (yet), since the NT4 machines stil

Re:Advice from the Inside Track

[okallydokally]

There is no way that 802.11i is going to change
anything about CCMP. It's in sponsor ballot and
has something like 4 comments to deal with. CCMP
was not any of those comments. Repeat: there is
absolutely no way that TGi will change the draft
to affect CCMP. The cement is long dry on that.

There is also absolutely no reason why anyone
should worry about CCMP. The underlying AES
algorithm has received extensive cryptographic
review and the CCMP mode has also been reviewed.
It has proven security characteristics.

And C

Re:Advice from the Inside Track

[RedLeg]

There is no way that 802.11i is going to change anything about CCMP.

I agree, it's unlikely, but possible. Sponsor ballot (and I'm a voter there, too) is NOT the final stage, so a change might come, but again, it is unlikely.

I'm much more concerned about interoperability issues. One thing that I have learned is that if something isn't 3d party tested, it will not interoperate. In the course of operating a commercial interoperability testing and certification program for IPSec products, we have to date,

Re:Advice from the Inside Track

[okallydokally]

I'm not sure which commercial interoperability
testing and certification program for IPsec
products you work for but I have an idea. In
fact, I think I know who you are!

I used to work for a Very Large Router Company. I
wrote the IKE RFC and conveniently wrote the code
running on the routers for said company. When we
submitted for certification with a commercial
interoperability testing and certification group
for IPsec products, one of the testers called me
and told me my code was not compliant. Then he
proceeded to

The enemy within

[MrIrwin]

As has been noted here, the weakest link in any system is the employees (chatting up the receptionist!)

Point here is that having obtained a little bit of privileged information somebody can sit parked in a nearby van and sniff data to thier hearts content.

True you can (and some people do) attach network "bugs" to cables to relay traffic, but the extensive use of switches makes this much more difficult.

Wireless gives easier access to more traffic, and it is often the most interesting as it tends to be

Your network isn't secure ...

[jamesh]

... if I can use a baseball bat to extract passwords from the users.

On the other hand, if your neighbor has a less secure network then yours automatically becomes more secure.

Remember this joke:

Two lawyers walking through the woods spotted a vicious-looking bear. The first lawyer immediately opened his briefcase, pulled out a pair of sneakers and started putting them on. The second lawyer looked at him and said, "You're crazy! You'll never be able to outrun that bear!"

"I don't have to," the first lawyer

Remember the rogues

[Coos]

Not broadcasting SSID is pointless: A properly crafted packet can induce the AP to reveal its SSID, and scripts are available to do this.
Filtering on MAC is useless: many WiFi drivers have MAC-spoofing capability in the Windows GUI!

The way to go is VPN, or 802.1x with a mutually-authenticating EAP protocol.

Remember you have to guard against a rogue AP that presents a fake version of your login interface to harvest credentials...