Under Windows/Linux, client side. How can I ensure that I'm not connecting to a rogue AP?
Thank you!
|
|
|||||||||||||||||||
|
|
Speaking generally IMO man-in-the-middle attacks are almost unavoidable To make matters worse, 802.11x sessions can easily be forced to disconnect and re-authenticate, so the man-in-the-middle can appear at any time in the session. By using a radio-beam directed only at the client, it is very hard for intrusion detection systems to intercept this traffic. Don't worry The solution What can the attacker do? But keep your laptop safe Benefits of this approach To recap Now you only need to worry about that iphone..... WPA2 has a mitm attack vector called Hole 196, see: http://www.airtightnetworks.com/WPA2-Hole196 *) not all VPN solutions are and lots of them have configurations where an otherwise safe solution is still at risk, but there are safe options and if you have a good sysadmin it is not a difficult thing to setup correctly. |
|||||||||||||||||
|
|
The only way to be 'sure' you are connecting where you want to connect, is by having a root of trust beforehand, something shared with AP like symmetric keys or a the public key of the AP (and be trust the public key belongs to it) or trust some certificate. If you have this root of trust, you can form a basis of trusting the AP if it can provide assurances that it knows the private key or can use the shared key. Also, if the AP uses WPA/WPA2 then mutual authentication is used, so you can infer it is the correct AP by the fact that authentication succeeds or fails. |
|||||||||||||
|
|
The solution is alluded to in another answer but not explicitly stated. This is currently only possible using WPA/WPA2 Enterprise. Using EAP-TLS both the client and the authentication server (ie RADIUS) are authenticated via certificates. If you want to be sure you are connecting to the right AP secure mutual authentication is required. That being said this type of deployment is rare outside of the enterprise. |
|||||||
|
|
Here's what I suggest:
This seems good enough for most purposes. If you need high security, set up a VPN and ensure that all of the network traffic out of your machine is tunneled through the VPN: then you don't care what access point it is traversing. |
|||
|
|
|
My general advice would be to only connect to "secured" WiFi Access Points. This requires that you and the AP have knowledge of a PSK or other authentication process, by which your system otherwise will not connect to the AP. Additionally (and obviously) this does have the major added benefit of making sure that your wireless traffic isn't easily sniff-able by Eve. |
|||||||||||||||||
|
|
You cant and you should not worry to much about it. If the AP gives you internet connectivity it should be regarded with the same suspicion as any internet connection. So any sensitive information sent over the internet and the access point should be separately authenticated and encrypted.
|
|||||
|
|
This is a common issue at the security conferences I have attended in the past. One in particular provided all the delegates with the MAC address of AP. Users were instructed to enter static entries in the ARP table of your device to ensure that rouge APs would not work. As for determining prior to connection you could use something like Kismet/Kismac to ID the AP. |
|||||||||||||
|
|
You can't? You can be sure within some confidence level. The "secure" confidence level depends on your situation. But to be more helpful, Johan has answered it pretty comprehensively. I think the more important question might be "What are the relative strengths of the various ways to secure your APs?" And how much effort does it take to subvert the various levels of securing your AP? |
|||
|
If have root access to the wireless router then if running an SSHD on it, then you can check the ssh key stored in the "known_hosts" on the client that it matches the one you get when connecting to the SSHD on the wireless router. |
|||||
|