Skip to main content

Wireless Network Security Recommendations

Wireless Networks are still causing businesses problems. By their very nature they are insecure, as they are a broadcast network that frequently extends beyond your physical boundary - remember radio signals don't stop at your door. There ARE security mechanisms to make them secure, but too often these are not implemented properly or are circumvented by users. It is vital that all traffic on the wireless network be encrypted, and connections authenticated, otherwise anyone with a laptop can view all your traffic. There are many mechanisms for achieving this, but at the very least you should use WPA with long pass phrases (not simple passwords) and MAC address authentication.

Don't use WEP; it can be broken easily. I won't bore you with details here, but I refer you to Google instead. However, there are several flaws such as using a linear Integrity Check Value, such that predictable bit-flipping can be used to send invalid messages that will appear to be valid. Secondly, the 40-bit shared secret is 'extended' by use of a 24-bit per-packet Initialising Vector. As any cryptographer will tell you, the more often you use the same key, the easier it is to recover the plaintext (particularly if you have known plaintext, which we do have in the headers of network packets of course). IV collisions happen surprisingly quickly, especially on corporate wireless networks, as they will usually have reasonably heavy load. TKMaxx found this out the hard way when they lost half a million credit card details to a hacker sitting in their car park. This also shows that they almost certainly didn't segregate the traffic and force it through a firewall.

So what can we do about this? Well, all modern equipment will support Wi-Fi Protected Access (WPA) and WPA2. A standard implementation of this is to use a Pre-Shared Key (PSK), i.e. a pass phrase, and the AES block cipher for encryption. This is the minimum requirement for a wireless LAN. Again, don't use simple passwords, as the security of your system is relying on them. You should use long complex pass phrases, with punctuation. Another idea is to encrypt a pass phrase using itself (or another) as a key in an encryption tool; then use the resulting base-64 encoded string as your PSK. However, automatic key negotiation and the use of digital certificates is a better option in a corporate environment (remember for wireless access you can run your own internal certificate server so that you don't incur additional costs).

This doesn't solve everything though. A little while ago the head of a department in an organisation I was involved with decided that he didn't want to have to use the docking station for his laptop as it constrained where he could work in his office. So, he didn't contact the IT department, but instead went to his local IT retailer and bought a cheap wireless access point. He plugged this into the network and, not only did he not configure any security, but he didn't even change the default password on the device. Do you categorically know that you don't have a rogue access point on your network? This can be stopped by using technologies such as 802.1X port-based authentication and a RADIUS server.

Wireless networks also need to be treated as insecure and separated from your wired network via a firewall, with real-time virus checking and an Intrusion Detection System. This doesn't mean that they have to be unprotected themselves; you should still protect them from outside attack by firewalling them off from the Internet. The important point is not to let traffic flow, unchallenged, from the wireless network onto the wired network. This is not often done though. I was in Vienna recently on business and the hotel I was staying at had free wireless access for guests. However, one night I couldn't get access and asked why. I was told that they had switched it off as someone was trying to access their servers (they weren't very proficient or experienced hackers fortunately). The point that I found more worrying was that their public wireless network was directly connected to their servers, which the hold names, addresses and payment details of guests and even the door card programming details! You can imagine what could happen if someone were to get into the servers...

Wireless networks and wired networks should not coexist on the same subnets. This is for two reasons. Firstly, it is easier to attack and, therefore, attach to a wireless network, so you don't know categorically that all stations are legitimate. Secondly, most wireless networks are used to connect mobile devices, such as laptops and netbooks, to the network. Do you know that these haven't picked up any malware whilst not connected to your corporate LAN? You can address the latter with network access control, but that's a different topic. However, all traffic from the wireless network should be treated with a level of suspicion and therefore separated. You don't have to have a separate Internet connection or new wiring to achieve this; VLANs (or Virtual LANs) can solve the problem by logically segregating the traffic into the firewall. This also allows you to provide public wireless access for visitors/customers as you can run two separate, VLANed wireless networks through the same access points onto the network - one with limited access to the corporate LAN and the other with none.

Wireless networks can be implemented securely, but remember to separate your wired and wireless networks and implement secure encryption and authentication.

Comments

Popular Posts

Trusteer or no trust 'ere...

...that is the question. Well, I've had more of a look into Trusteer's Rapport, and it seems that my fears were justified. There are many security professionals out there who are claiming that this is 'snake oil' - marketing hype for something that isn't possible. Trusteer's Rapport gives security 'guaranteed' even if your machine is infected with malware according to their marketing department. Now any security professional worth his salt will tell you that this is rubbish and you should run a mile from claims like this. Anyway, I will try to address a few questions I raised in my last post about this. Firstly, I was correct in my assumption that Rapport requires a list of the servers that you wish to communicate with; it contacts a secure DNS server, which has a list already in it. This is how it switches from a phishing site to the legitimate site silently in the background. I have yet to fully investigate the security of this DNS, however, as most

Web Hosting Security Policy & Guidelines

I have seen so many websites hosted and developed insecurely that I have often thought I should write a guide of sorts for those wanting to commission a new website. Now I have have actually been asked to develop a web hosting security policy and a set of guidelines to give to project managers for dissemination to developers and hosting providers. So, I thought I would share some of my advice here. Before I do, though, I have to answer why we need this policy in the first place? There are many types of attack on websites, but these can be broadly categorised as follows: Denial of Service (DoS), Defacement and Data Breaches/Information Stealing. Data breaches and defacements hurt businesses' reputations and customer confidence as well as having direct financial impacts. But surely any hosting provider or solution developer will have these standards in place, yes? Well, in my experience the answer is no. It is true that they are mostly common sense and most providers will conform

Trusteer's Response to Issues with Rapport

I have been getting a lot of hits on this blog relating to Trusteer's Rapport, so I thought I would take a better look at the product. During my investigations, I was able to log keystrokes on a Windows 7 machine whilst accessing NatWest. However, the cause is as yet unknown as Rapport should be secure against this keylogger, so I'm not going to share the details here yet (there will be a video once Trusteer are happy there is no further threat). I have had quite a dialogue with Trusteer over this potential problem and can report that their guys are pretty switched on, they picked up on this very quickly and are taking it extremely seriously. They are also realistic about all security products and have many layers of security in place within their own product. No security product is 100% secure - it can't be. The best measure of a product, in my opinion, is the company's response to potential problems. I have to admit that Trusteer have been exemplary here. Why do I