Slashdot Mirror


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

9 of 45 comments (clear)

  1. Security by rusty0101 · · Score: 4, Informative

    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

    --
    You never know...
  2. Re:The same as it was last week... by Deffexor · · Score: 4, Informative

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

  3. secure by AMystery · · Score: 5, Informative

    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.

  4. One big problem by fred+fleenblat · · Score: 4, Informative

    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.

  5. Re:The same as it was last week... by innosent · · Score: 4, Informative

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

    --
    --That's the point of being root, you can do anything you want, even if it's stupid.
  6. use 802.1x instead of PSK by puneetb · · Score: 2, Informative

    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 than PSK each time, but unless you have users using voice-over-IP and walking around from access-point to access-point you wont notice any difference with 802.1x

  7. Re:The same as it was last week... by Bishop · · Score: 3, Informative

    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.

  8. Advice from the Inside Track by RedLeg · · Score: 4, Informative
    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. I sincerely hope all of this helps....

    1. Re:Advice from the Inside Track by okallydokally · · Score: 2, Informative

      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 CCMP is MUCH, MUCH, MUCH better than TKIP
      which uses a weak message integrity check. CCMP
      all the way. Don't worry a bit about it.

      The only problem in the proposed scheme is PSK.
      Because of the way the PSK is used in the 4-way
      handshake (which generates unique session keys)
      it is open to a passive attack. Someone could
      record the exchange between the client and AP and
      then go crunch numbers trying to guess the PSK.
      If your PSK is set by using a passphrase it's
      even more easy to guess. If it's a raw PSK then
      it's a bit harder. There are ways to come up with
      a pre-shared key authentication scheme that is not
      susceptible to a passive attack (IKE, RFC2409,
      defines one for instance) but the 4way handshake
      is not such a scheme.

      A VPN is not a solution for wireless security.
      IPsec was not designed to provide per-hop security,
      it was defined to provide end-to-end security
      over a routed network over many hops. When you
      have a hammer, though, lots of things look like
      nails and it is very tempting to use IPsec to
      provide link-level encryption. Better to use
      something designed for the task at hand.

      If you're going to go to the trouble of per-user
      authentication (and not group authentication
      using PSK) then use 802.1x.

      Another problem with IPsec is that most deployments
      use some sort of "password". This means that they
      use XAUTH and XAUTH is an INSECURE HACK on what
      was otherwise a cryptographically sound protocol--
      IKE. If your IPsec solution has clients entering
      some shared password-- and Contivity does this--
      then don't do it. If you want to use IPsec for
      clients then use certificates that is really the
      only secure way to go. Anything else is snake oil.