Showing posts with label WPA. Show all posts
Showing posts with label WPA. Show all posts

June 16, 2009

How to configure Ubuntu 8.10 / 9.04 for 802.1x WPA TKIP environment

Sponsored Link

Sponsored Link


IIUM wireless environment implement WPA authentication and TKIP encryption. The overall using 802.1x authentication method which deploy protected EAP (PEAP) using EAP token. User database stored in a Radius server by using FreeRadius running on FreeBSD platform.

One of my user said, before upgrading his Ubuntu 8.10, he was using Ubuntu Hardy Heron 8.04. The previous Ubuntu is running well. Once he upgrade it to Ubuntu 8.10, he cannot get connected to our secure wireless environment anymore.

Hmmmmm... while other user with other stardard OS e.g Windows XP, Mac OS and Windows Vista doesn't have any problem, so I suspect, the WPA configuration in Ubuntu 8.10 something need to change drastically. It seems like doesn't works well in a secured wireless environment.

We have tried and yes, it does not work with IIUM wireless campus. I tried to switch to fedora 10, but the result is still the same. Then we tried to migrate to knoppix, my best linux distro ever, but still not working and become more worst when knoppix cannot detect Intel PRO/Wireless 3945ABG device. We dont want to use ndiswrapper since it finally could corrupt my entire OS. FYI, Suse linux will work smoothly with IIUM wireless.

When Ubuntu come out with new release, 9.04 and 9.10 alpha, my friend was exciting because the new relase might help student who really like ( dont know why, yet Ubuntu still look nothing for me) to have a great bonding with Ubuntu, but the result is still disappointing. The main issue is that since the release 8.10 version, Ubuntu has come with standard Network Manager with not support of PEAP/TKIP, the main authentication for IIUM wireless connection. So, the best solution for this is to swtich to Wicd, the open source Gnome-independency Network manager.

1. Get the Wicd either direct download by using command terminal sudo apt-get install wicd , or just download from Synaptic Package Manager for those who dont want to play around with command terminal.

using command





sudo apt -get install wicd


using synaptic package manager


2. Go to etc/wicd/encryption/templates/peap-tkip to customize the setting. Please take note that ubuntu has by default disable the root password. So you cannot just simple open form file browser. You can either open the file using command sudo ect/wicd/…../peap-tkip at terminal or just type on terminal “sudo passwd root” to enable you root password. Please also take not the file is located at the root folder, not home folder.

Change this:

name = PEAP with TKIP
author = Fralaltro
version = 1
require identity *Identity password *Password ca_cert *Path_to_CA_Cert
-----
ctrl_interface=/var/run/wpa_supplicant
network={
ssid="$_ESSID"
scan_ssid=$_SCAN
proto=WPA
key_mgmt=WPA-EAP
pairwise=TKIP
group=TKIP
eap=PEAP
identity="$_IDENTITY"
password="$_PASSWORD"
ca_cert="$_CA_CERT"
phase1="peaplabel=0"
phase2="auth=MSHAPV2"
}

to become this:

name = PEAP with TKIP
author = Fralaltro
version = 1
require identity *Identity password *Password
-----
ctrl_interface=/var/run/wpa_supplicant
network={
ssid="$_ESSID"
scan_ssid=$_SCAN
proto=WPA
key_mgmt=WPA-EAP
pairwise=TKIP
group=TKIP
eap=PEAP
identity="$_IDENTITY"
password="$_PASSWORD"
phase1="peaplabel=0"
phase2="auth=EAP Token"
}

3. After that, go to Application > Internet > Wicd Network Manager. select iium community and click on Advanced Setting. Tick Use Encryption and select PEAP with TKIP.


Then, just type your username and password….and thats it and it works…

Source: Solutions Architect

April 20, 2009

Securing Wireless Network

The security of wireless local area network (WLAN) solution works better with Wi-Fi Protected Access (WPA) WLAN protection compared to Wired Equivalent Privacy (WEP). 

Currently, ITD have to admit there are some potential difficulties faced by IIUM user with using WPA, which include: 

• Manual configuration of WPA settings: The support for setting Windows XP client WPA settings using group policy is not available in the versions of Windows earlier than Windows Server™ 2003 Service Pack 1. Until Service Pack 1 is available and you have deployed it in your organization, you will have to configure your clients manually (there is no way to script WLAN settings for Windows XP). You need to install Service Pack 1 only on the server on which you are editing the WLAN settings Group Policy object (GPO); it is not required on the clients, domain controllers, or IAS servers.

• Restricted availability of WLAN clients: At the time of writing, Microsoft only provides WPA support for Windows XP Service Pack 2 and later. PDA and Smart Phone operating systen running on Windows Mobile and Symbion does not support WPA yet. The only operating system that really support secured wireless environment is MacOS for iPhone and iPod. For those who want to get connected through SSID iium-gadgetmust comply with WPA requirement.

• Availability of WPA compliant hardware: Although WPA support is now mandatory for all Wi-Fi certified hardware, existing network equipment may need to be upgraded to support WPA. You will need to obtain firmware updates for any access points or network adapters that do not currently support WPA. In some (rare) cases, you may need to replace equipment if the manufacturer does not produce WPA updates. Again, it is a common problem to the low-end Microsoft product.

Manually Configuring Windows XP WLAN Settings for WPA
Until GPO support becomes available in Windows Server 2003 Service Pack 1, you must configure WPA settings on the client manually. WPA is supported on Windows XP Service Pack 1 with the WPA client download installed (or on Windows XP Service Pack 2).

Note: When GPO support becomes available, you can also use the following procedure to create a Wireless Network Policy using the same settings.

To manually configure WPA WLAN settings:

1. Open the properties of the Wireless Network interface. If the WLAN is displayed in the Available Networks list, select it, and click Configure…, otherwise click Add (in the Preferred Networks section).

2. Type the WLAN name into the Network Name (SSID) field (if it is not already displayed there) and, in the Description field, enter a description of the network.

Note: If you have an existing WLAN and you intend to run this side–by–side with the 802.1X–based WLAN of this solution, you must use a different Service Set Identifier (SSID) for the new WLAN. This new SSID should then be used here.

3. In the Wireless Network Key section, select WPA (not WPA PSK) as the Network Authentication type and TKIP as the Data Encryption type. (If your hardware supports it, you can choose the higher strength Advanced Encryption Standard (AES) in place of TKIP).

4. Click the IEEE 802.1x tab, and select Protected EAP (PEAP) from the EAP Type drop–down list. 

5. Click the Settings… button to modify the PEAP settings. From the Trusted Root Certificate Authorities list, select the root CA certificate for the CA. 

Important: If you ever need to re–install your CA from scratch (not just restore from backup), you will need to edit the client settings and select the root CA certificate for the new CA. 

6. Ensure that Secured Password (EAP-MS-CHAP v2) is selected in the Select Authentication Method and check the Enable Fast Reconnect option.

7. Close each properties window by clicking OK.

Configuring Pocket PC 2003/PDA/Smart Phone for WPA
WPA was not supported natively in Pocket PC 2003 using Windows Mobile and Symbion at the time of writing; however, this may be implemented in the future. Support for WPA on other type of Pocket PC available from other vendors such Mac OS (iPhone and iPod),

Original Post : ERM Blog

January 28, 2009

Wireless Network Security Overview

Currently, the Wireless Network Security standards and protocols are fall into 3 categories:

Encryption
It use to ensures privacy of data transmitted through the air
It can be done at Layer 2 (WPA2, WPA, WEP, TKIP, AES) or Layer 3 (VPN)

Authentication
It can ensures that only authorized users with proper credentials are allowed to use the network such as security certificate or LDAP matching attribute (login and password).
Authentication methods include EAP, captive portal, VPN

Access Control
Provides a policy enforcement structure to control the traffic of authorized users, including networks, bandwidth, time of day, and protocols. Some solutions preferred to integrate with Network Access Control (NAC) supported appliance for managing the access control.

March 4, 2008

Checklist for Planning a Voice Over Wi-Fi Network: Security and Performance

Security

While Wi-Fi offers a number of different security options, many voice handsets only support a subset because of processing, cost and battery considerations. Therefore design of a WLAN for voice may entail compromising over-the-air security to accommodate available handsets. We believe the correct approach is as below: first choose a handset, then see if it can support the desired security model (the goal should be that voice and data work at the same level, e.g. WPA2/802.1x). If the handset cannot attain this level, the network designer should take steps to make sure that they can be allowed onto the network, but that special security measures prevent intruders from posing as voice clients to hack into the network, as explained below.

First, identify the desired handset or range of handsets. This is a general rule for adding voice services: start with the handset. Choice is often based on factors such as durability, aesthetics, PBX features supported, voice & data capabilities.

Now examine the security capabilities. While a few months ago many handsets were limited to WEP security, a new generation is now available and the network designer should aim for WPA/PSK as a minimum level of security. WPA2 is better, with WPA2/802.1x preferable to WPA2PSK, but performance, particularly handover performance will suffer as more sophisticated security is used. We favour Opportunistic Key Caching (OKC) with WPA2 for excellent security with fast handover.
Good security design requires a comprehensive approach, so it is important to examine other aspects of the network. Many networks use a separate VLAN to segregate voice traffic, although VLANs are not a good security tool and converged voice/data clients cannot be accommodated with this model.

Other approaches involve using firewall functionality to identify and police voice traffic, particularly when the voice handsets cannot offer the same level of authentication/encryption as Wi-Fi data clients. This is obviously Aruba’s approach, as we have an integrated, Wi-Fi aware firewall.

At Aruba, we have found that re-keying in an 802.1x network can stress a handset’s processor to the degree that it can interrupt voice calls. Therefore we now have a feature that delays re-keying till the handset is idle (not on a call). An alternative, but inferior approach is to use a longer re-keying interval for voice devices.

Handover performance

Handing over a voice call from AP to AP is a function of both the infrastructure and the client. While handover latency can be measured under laboratory conditions, there are many additional factors that affect real-life performance.

The target figure for interruptions in a voice call due to handover is 50-100 msec: at these levels the user will not notice the interruption. The state-of-the-art for lab tests is sub-20 msec.
Attention to AP spacing and RF planning as explained above will help to ensure that field experience is close to lab experience.
Security determines handover performance. Pre-shared keys allow much faster handover than 802.1x environments, although of course they are not as secure. There is not much inherent performance difference between WPA and WPA2 encryption levels, except that the latter requires more processing on the handset.
The ideal balance of security and performance today is when WPA2 is used with 802.1x and ‘opportunistic key caching’ in a centralised-controller WLAN.
802.11r is a new standard, intended to improve handover performance. In centralised WLAN architectures such as Aruba’s it offers only limited improvements, particularly if opportunistic key caching is used (see above). But 802.11r support should be on the checklist for the WLAN vendor.
Battery Life

Good battery life is an important usability consideration for voice-over-Wi-Fi installations. While much battery-saving technology depends on the handset, there are a variety of functions where the infrastructure can assist in extending battery life.

Determine desired battery life: this will depend on applications. For retail and hospital environments, where people pick up their phone in the morning or at the beginning of their shift, and return it to a charging cradle at the end of the day, a battery life of 12 hours may be adequate. This is quite easily achievable today.
However, a dual-mode cellular/Wi-Fi phone will be treated more like a cellphone, where users expect multiple days between charges. Performance is improving rapidly, but currently most dual-mode phones’ batteries will barely last for 24 hours with heavy business use. Handset vendors and WLAN infrastructure vendors, including Aruba, are innovating in this area.
U-APSD (Unscheduled, Asynchronous Power Save Delivery) is part of the 802.11e specification that the Wi-Fi Alliance is certifying as WMM-PS (Wireless MultiMedia Power Save). This offers considerable improvement in battery life over former protocols, and while few handsets support U-APSD today, any new Wi-Fi infrastructure must be U-APSD/WMM-PS capable.
ARP proxy. The key to extending battery life, particularly idle (not on-call) battery life is to reduce the LAN traffic the handset sees. The most significant type of traffic is ARP’s, and good WLANs now proxy to reduce this traffic to voice clients.
Traffic filtering. Some vendors offer features where extraneous traffic is not delivered to voice clients, thus saving the battery drain entailed in receiving and ack’ing such traffic. Many types of multicast fall into this category.
• Other features. Battery life is one of the few areas in voice-over-Wi-Fi where the standards (and drafts of future standards) are not sufficient for good performance. Therefore the customers should expect ‘proprietary’ extensions to standards in this area. Some of these require compatible clients, whereas others work with standard clients. At Aruba we have several of these, so please check with us and our competitors about the state of the standards and the state-of-the-art.

Wi-Fi Alliance Certifications

The Wi-Fi vendors and other interested parties take standards developed and published by the IEEE 802.11 committee, but most vendors today tend to develop to certifications of the Wi-Fi Alliance, a group of vendors formed to develop the market for 802.11 (and the originator of the term ‘Wi-Fi’, Wi-Fi logos, etc). Wi-Fi Alliance certifications are nearly all derived from subsets of the IEEE standards, and result in standardized tests to ensure inter-vendor interoperability. The notes above identify the most important certifications, but they are re-stated below (this is a subjective rather than a complete list: these are most relevant to voice-over-Wi-Fi infrastructure for Enterprise). In selecting a WLAN vendor, it is more practical to ask for a roadmap for these certifications rather than references to IEEE standards.

Security certifications relevant to voice to include WPA and WPA2, which are derived from 802.11i.
WMM (Wireless MultiMedia) defines over-the-air QoS from subsets of 802.11e.
WMM-PS (Wireless MultiMedia Power Save) includes U-APSD from 802.11e.
WMM-AC (Access Control) is not yet finished, but will include T-Spec signalling from 802.11e for Call Admissions Control.
‘Voice over Wi-Fi for Enterprise’ (name may change) will include parts of 802.11e, 802.11k, 802.11r and others in an attempt to ensure good performance and inter-vendor interoperability in Enterprise networks with multiple APs and other Enterprise requirements.

November 12, 2007

Securing Wireless LANs with PEAP and Passwords

The wireless local area network (WLAN) solution described in this documentation works equally well with either dynamic Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA) WLAN protection. The implementation differences between the two are minor and are documented in this appendix.

Currently, there are some potential difficulties with using WPA, which include:

Manual configuration of WPA settings: The support for setting Windows XP client WPA settings using group policy is not available in the versions of Windows earlier than Windows Server™ 2003 Service Pack 1. Until Service Pack 1 is available and you have deployed it in your organization, you will have to configure your clients manually (there is no way to script WLAN settings for Windows XP). You need to install Service Pack 1 only on the server on which you are editing the WLAN settings Group Policy object (GPO); it is not required on the clients, domain controllers, or IAS servers.

Restricted availability of WLAN clients: At the time of writing, Microsoft only provides WPA support for Windows XP Service Pack 1 and later.

Availability of WPA compliant hardware: Although WPA support is now mandatory for all Wi-Fi certified hardware, existing network equipment may need to be upgraded to support WPA. You will need to obtain firmware updates for any access points or network adapters that do not currently support WPA. In some (rare) cases, you may need to replace equipment if the manufacturer does not produce WPA updates.


Using WPA in Place of WEP
Although the majority of the guide is applicable to both WPA and dynamic WEP, there are two main points in the documentation where the instructions differ:

• The “Creating an IAS Remote Access Policy for WLAN” section in Chapter 5, “Building the Wireless LAN Security Infrastructure.”

• The “Creating the WLAN Settings GPO” section in Chapter 6, “Configuring the Wireless LAN Clients.”


Creating an IAS Remote Access Policy for WLAN with WPA
To use WPA WLAN protection in place of dynamic WEP, you should set the client session time–out value to 8 hours instead of 60 minutes. WPA has an in–built mechanism to generate new WLAN encryption keys, so it does not need to force the clients to re–authenticate frequently. Eight hours is a reasonable value to ensure that clients have valid up–to–date credentials (for example, it ensures that a client cannot remain connected for excessive periods after its account has been disabled). In very high security environments, you can reduce this time–out value, if needed.

In the "Modifying the WLAN Access Policy Profile Settings" section in Chapter 5, “Building the Wireless LAN Security Infrastructure,” use the following procedure to set the remote access policy profile settings:

To modify wireless access policy profile settings:

1. In the Internet Authentication Service MMC, open the properties of the Allow Wireless LAN Access policy, and then click Edit Profile.

2. On the Dial-in Contraints tab, in the Minutes clients can be connected (Session-Timeout) field, type the value 480 (480 minutes or 8hours).

3. On the Advanced tab, add the Ignore-User-Dialin-Properties attribute, set it to True, and then add the Termination-Action attribute and set it to RADIUS Request.


You also need to change the session time–out in the wireless access point (AP) to match (or exceed) the time–out value set in this procedure.

Manually Configuring Windows XP WLAN Settings for WPA
Until GPO support becomes available in Windows Server 2003 Service Pack 1, you must configure WPA settings on the client manually. WPA is supported on Windows XP Service Pack 1 with the WPA client download installed (or on Windows XP Service Pack 2).

Note: When GPO support becomes available, you can also use the following procedure to create a Wireless Network Policy using the same settings.

To manually configure WPA WLAN settings:

1. Open the properties of the Wireless Network interface. If the WLAN is displayed in the Available Networks list, select it, and click Configure..., otherwise click Add (in the Preferred Networks section).

2. Type the WLAN name into the Network Name (SSID) field (if it is not already displayed there) and, in the Description field, enter a description of the network.

Note: If you have an existing WLAN and you intend to run this side–by–side with the 802.1X–based WLAN of this solution, you must use a different Service Set Identifier (SSID) for the new WLAN. This new SSID should then be used here.

3. In the Wireless Network Key section, select WPA (not WPA PSK) as the Network Authentication type and TKIP as the Data Encryption type. (If your hardware supports it, you can choose the higher strength Advanced Encryption Standard (AES) in place of TKIP).

4. Click the IEEE 802.1x tab, and select Protected EAP (PEAP) from the EAP Type drop–down list.

5. Click the Settings... button to modify the PEAP settings. From the Trusted Root Certificate Authorities list, select the root CA certificate for the CA. (This is the CA that you installed to issue IAS server certificates—see Chapter 4 for more details).

Important: If you ever need to re–install your CA from scratch (not just restore from backup), you will need to edit the client settings and select the root CA certificate for the new CA.

6. Ensure that Secured Password (EAP-MS-CHAP v2) is selected in the Select Authentication Method and check the Enable Fast Reconnect option.

7. Close each properties window by clicking OK.


Configuring Pocket PC 2003 for WPA
WPA was not supported natively in Pocket PC 2003 at the time of writing; however, this may be implemented in the future. Support for WPA on Pocket PC may also be available from other vendors.

Migrating from WEP to WPA
If you have deployed a secure WLAN solution based on dynamic WEP and want to migrate to WPA, you need to follow the steps in this section. You must ensure that you have deployed WPA software support (for example, the Windows XP WPA component) and hardware support (AP firmware and network adapter driver updates) prior to the migration. References in this procedure to configuring WPA settings in GPOs are only valid when the GPO is edited from Windows Server 2003 Service Pack 1 or later. This service pack had not been released at the time of writing. If you are not using Windows Server 2003 Service Pack 1 or later, follow the instructions given in the “Manually Configuring Windows XP WLAN Settings” section in this appendix.

To migrate from WEP to WPA, if your APs support dynamic WEP and WPA simultaneously:

1. Configure all wireless APs to support both dynamic WEP and WPA.

2. Create a new WLAN client settings GPO. Create a Wireless Network policy that configures the correct settings for WPA (refer to the procedure provided in the "Manually Configuring Windows XP WLAN Settings" section in this appendix). Then disable the existing WEP GPO and enable the WPA GPO so that all WPA settings are sent out to all clients. The clients will start using WPA on the WLAN following the next GPO refresh.

Note: If you are configuring your clients manually, you must disable the GPO that contains the WEP settings; if you do not do this, the manual WPA settings will be overwritten by the GPO.

3. Finally, you should update the IAS remote access policy session time–out and the client session time–out in the AP (as described in the "IAS Remote Access Policy" section earlier in this appendix).

To migrate from WEP to WPA, if your APs do not support simultaneous use of WEP and WPA:

1. Create a new WLAN SSID for the WPA network.

2. Edit the client network settings GPO and add the new SSID using WPA parameters (as described in the "Manually Configuring Windows XP WLAN Settings" section earlier in this appendix). If you are configuring your clients manually, you should configure them with the new SSID and WPA settings for that SSID. Do not remove the settings for the old WEP SSID in either case.

3. Working site–by–site, reconfigure your APs from WEP to WPA support, changing the SSID of the AP. As you reconfigure each AP, the clients will switch to the new SSID and use WPA.

4. Once you have reconfigured all APs, you can update the remote access policies on all IAS servers. You need to increase the session time–out value in the remote access policy (from 60 minutes to 8 hours) and change the same setting in the wireless APs (as described in the "IAS Remote Access Policy" section in this appendix).

5. Once the migration is complete, you can remove the WEP SSID from the GPO.


References
This section provides references to important supplementary information or other background material relevant to this appendix.

• The Cable Guy — March 2003, Wi-Fi Protected Access™ (WPA) Overview, available at the following URL:

http://www.microsoft.com/technet/community/columns/
cableguy/cg0303.mspx

• Microsoft Knowledge Base Article 815485, "Overview of the WPA Wireless Security Update in Windows XP," available at the following URL:

http://support.microsoft.com/?kbid=815485

• Microsoft Press Pass Announcement on WPA Availability, available at the following URL:

http://www.microsoft.com/presspass/press/2003/mar03/03-31WiFiProtectedAccessPR.mspx

• "Wireless 802.11 Security with Windows XP" white paper available at the following URL:

http://www.microsoft.com/windowsxp/pro/techinfo/
administration/wirelesssecurity/

Hack most wireless LANs in minutes!

by: George Ou

Even after two years of WPA certification and nearly one year after 802.11i ratification, you might be wondering why I’m still talking about WEP encryption. The fact is, I would love to stop talking about it if there weren’t such an overwhelming percentage of corporations, retail outlets, and hospitals still using WEP. Although WPA brought us TKIP (think of TKIP as WEP 2.0) encryption and 802.11i brought us AES encryption, the upgrade process has been extremely painful and many products still don’t support TKIP let alone AES. The sad state of wireless LAN security is that the majority of corporations and hospitals still use dynamic per-user, per-session WEP keys while the majority of retail outlets that I’ve seen still use a single, fixed WEP key.

In the past, a hacker was at the mercy of waiting long periods of time for legitimate traffic on a wireless LAN to collect 10 million of packets to break a WEP key. In my previous blog on this topic, which was based on Mike Ossmann’s WEP article, I alerted you to the startling fact that even wireless LANs that used 802.1x/EAP authentication to dynamically assign unique per-user, per-session WEP keys were no longer safe against WEP hacking since WEP cryptanalysis had improved 50 fold. Instead of waiting for hours or even days for those 10 million packets, you now only needed about 200,000 packets to break WEP. Even though dynamic WEP key rotation could change a user’s WEP key every few minutes or so (note that key rotation isn’t always implemented by default), the new WEP cryptanalysis techniques put even dynamic WEP in striking range. Now with the new active attacks on WEP described in Ossmann’s follow-up article, hackers no longer need to passively wait for legitimate packets on a wireless LAN because they can actively inject packets into a wireless LAN to ensure a speedy packet collection session. The end result is, any WEP based network with or without Dynamic WEP keys can now be cracked in minutes! If you’re scared, you should be and you’d better go back and read the recommendations in the end of my previous blog if you’re still running WEP in any form.
free counters
RP | CU | PH | RR | TCU | MFB | BM | BM | TAW | RM | SM | MLW | QL | QTS | SR | TR | TCR | HR I2U | PH | TAW | ID | AAB | FSB | AG |