Tips on how to provide a secure public WiFi hotspot – Part 2

December 7, 2015

So lets start with tips on how to provide a secure public WiFi hotspot part 2. In the first part we concentrated on the wireless part, this time we take a look at the some layer 2 and 3 stuff you can do to protect your hotspot and your clients.

client 2 client traffic again

Yes, I know I’ve written about hat in the first part. But this was on the wireless side. Many access points block the traffic coming and leaving on the wireless interface but not traffic coming or leaving on the wired side.  So it is possible to think of an attacker finding it’s victims not on the same access point but on others in the same layer 2.  There are multiple way to achieve that once you think about it:

• Lets assume your client networks are all in 10.0.0/16 and you’re servers are in 10.1.0.0/24. You can simply filter with an ALC on the access points or switches which drop traffic where the source and destination host is within 10.0.0/16.
• If you’re using a VPN on you’re access points to tunnel the traffic back to a central controller, just don’t bridge/route traffic between them.
• If it’s one simple layer2 network on one switch, take a look at PVLANs. Many low cost managed switches have this feature.

Enforce DHCP usage

I’ve written a full blog post on why and how to enforce the usage of DHCP in any client network. Its even more important in an public WiFi setting. Following benefits are the most important in this setup:

• Protection against simple ARP spoofing
• That a client configures a fix IP address which an other client got via DHCP – be it by accident or malicious act.

Additionally to the example in the linked blog post, here is one where a Mikrotik router is the default gateway and DHCP server in a client network.

Disable the ARP learning on the router
/interface ethernet set 1 arp=proxy-arp

configure the DHCP server to add dynamic ARP entries
/ip dhcp-server set 1 add-arp=yes

Control the uplink bandwidth

This one is not directly a security point, but without it a user can use up all bandwidth and deny other clients access to the internet. I won’t stop long here, just use something similar like the PCQ on Mikrotiks. This will provide a fair distribution between the clients without looking at the traffic itself and classifying it. So you’re within the net neutrally rules if that matters for you.

Management of your devices

Make sure that no management interface of your devices is reachable via the customer/client networks. The easiest way to achieve this is to use a separate management network and make sure the management services of the devices only listen on this network. For access points it could be as easy as using the untagged VLAN to the switch for management and send the client traffic only as tagged traffic to the switch.

If this is not possible in your setup, make a least sure that a local firewall on the devices allow only administration from specify source IP addresses (e.g. the IP of your central management system, or the VPN IP range you use the remotely log into an router).

no default logins and encrypted management

This should be an no-brainer (but I’ll add it here so no one can say it was not on the list), but I’ve seen access points with the SNMP community public in the wild. And choose ssh over telnet and HTTPS over HTTP for management. Won’t write more lines about that basic stuff.

monitor the network traffic

Most routers provide plenty of data via netflow or sflow. Capture that with software like Ntop (open source)  or a commercial offering. Look at the traffic what is normal and what is not. An example for something like this would be if the average packet sizes goes way down for a client it is likely it is scanning something with a tool like nmap or zmap.  ps: Taking a look at the TCP retransmissions also helps to monitor the quality of your service.

After this layer 2 and layer 3 stuff only one part is still open for this series – the application level stuff. Stay tuned.

 

Tips on how to provide a secure public WiFi hotspot – Part 1

December 1, 2015

As I was travelling a little bit in the last few months I came across many public WiFi hotspots and most of them where not that good from a security perspective. So I thought lets write some articles with tips on how to build a secure public WiFi hotspot. This article is not for the end user on how to connect securely to a hotspot, but how to provide a secure hotspot.

The first part of this series talks about the wireless part and how to secure it, following posts will talk about other measures to secure your hotspot. So lets start with the security of the data transmitted over the air.

Encyption of the WiFi Traffic

All most all hotspots I cam across did use unencrypted WiFi , the exception where small hotels which used WPA2 PSK on the SOHO Router and told the guest the password at check in. From a security standpoint using WPA2 PSK with one password for all guest is better than an open network. Why do you ask?

1. With an open WiFi its trivial to sniff the traffic of other guests and if there are no other protections in the network a man in the middle attack is simply possible. There are really simple to use tools for “normal people” like Firesheep.
2. With WPA2 PSK each client gets its own session key during the association process. An attacker needs witness the associaton to eavesdrop on the connection. It is possible my an attacker to force a reassociations, by faking a disassociation packet in the name of the target.The disassociation packet attack is an attack at its own, we’ll talk later about it. With Wireshark you can decrypt all traffic if its sees the association process.

So using WP2 PSK is not perfect but its better than nothing. It is even easy to implement in some cases like in a hotel setting. Put the password in the folder in the guest rooms or tell it the customer at check in / arrival – so you can promote your service too.  An other way is to provide two SSIDs one named “Public WLAN open” and one “Public WLAN wps2psk” and tell the user on a captive portal site (if you have/need such an site anyway) to change to the encrypted one for more security.

Ok, that basic security but, you can do better.  Some hotels print a username and password on the receipts which you get on check in. You than need to connect to a insecure wifi and need to enter that in a HTTP website.  Some hotels also just tell you to use room number as username and your family name or your birthday as password, yes again over an insecure network and over HTTP … ok I’ll stop with the rumpling.

If you provide the user already with a custom login – why not use PEAP or EAP-TTLS to secure the log in.  The user chooses the network and gets prompted with an username/password dialog.  For this you need to run an RADIUS server against which the Users authenticates, with FreeRadius, which is provided with all major Linux Distributions, its quite easy, even on embedded devices using with OpenWRT. Such a setup is maybe not the best way for a small hotel, but for a big hotel chain, with a central IT department which already prints the login data on the invoices, this should be easily possible.  And if the marking persists (the legal stuff could be on the invoice .. as nobody reads the backside anyway) on a captive portal page, just make one where the terms of service needs to be accepted and put some nice marketing images there. 😉

There is also a way for you to use WPA2 Enterprise with PEAP / EAP-TTLS and the newer EAP-PWD  if you don’t know the customers and just want to provide a more secure WiFi. Just tell every user the same username / password – as with WAP2 PSK. With FreeRadius its even possible to accept any username / password combinations. With PEAP that works for most clients but not all of them as the returning hash is not correct, but for those the written down username/passwords works.  For example at the biggest European hacker congress from the Chaos Computer Club that setup was used 2 times already with over 9000 attendees.

Just to be sure to tell it. The use of PEAP is not recommend for authenticating users for an internal network (e.g. with BYOD) – Why? It is possible to intercept the wireless traffic using a roque accesspoint using the same (company) SSID-name and tools like freeradius-WPE and cloudcracker.  But for a free / cheep public WiFi it does seem to an common attack route.

At the end of this chapter I’ll provide you also with a really secure setup (that’s what you want to read if you read my blog? Yeah ;-)), which is not that easy to setup but makes sure you know the user which connect to your network – even if its free to use but you’re required to know the user by law.  I’ve not seen this setup in the wild, only told about it by a college.

1. Provide an open WiFi which only gets you to an HTTPS page where the user can enter his/her phone number
2. Generate a TLS key/cert in a format the mobile browser accepts and encrypt it with an random password
3. Send the password via SMS to the user
4. Let the User download the key/cert
5. Tell him to connect to the secure WiFi with the certificate.

As told above that’s not easy to do … but secure ;-). You can also provide the decrypt password via the HTTPS page, but than you can’t identify the user, but maybe that’s not necessary in your case. This solution is only workable if the user does this once and uses your Internet connection for a long time. e.g. you provide public Wifi in a public transport vehicle for commuters.  Otherwise I would stick with the WAP2 Enterprise and EAP-TTLS and as compatibility with PEAP.

rouge access points

Rouge access points in this context are devices an attacker normally uses near your hotspots with your SSIDs to get clients to connect to them. Specially if the WiFI is open or only secured with a know WPA2 PSK it’s easy to do so. Clients which have in past already been connected to your network will often connect automatically to the rouge access point using your SSID. If the attacker does a NAT and connects to your hotspot as client most users will not see a difference and their whole network traffic can be intercepted.

Most enterprise access points provide a feature to at least monitor for rouge access points and alert you if they see your SSID with an BSSID not from your access points. This helps but does not guard completely against it. To get the best protection against that attack you need to use EAP-TLS (certificates for every client – internal wifi setup) oder EAP-TTLS (certificate only for the RADIUS server and username/password for the client). But if the client does not validate the RADIUS server certificate (and there is no common name to check against, only the CA) you can’t prevent that attack, you need to monitor for it and act than.

Following measures can be taken to detect such access points on your network:

• Compare MAC addresses against know vendor IDs. An Apple or Samsung vendor looks more like a mobile phone than a Cisco or Mikrotik one as a client in your hotspot.
• Run an nmap finger print scan against new MAC addresses .. if the OS guess flags it as a WAP, or “Wireless Access”  take a look, also take a look at the open ports … telnet and ftp or snmp (with default community) are not common for phones. 🙂
• Look at the traffic with IDSes like Suricata for a X-Forwarded-For field and User-Agent strings associated with proxies
• Detect when one IP address is presenting itself as multiple operating systems e.g. via different TTLs (Linux uses an different than Windows) .. Take a look at this paper and look also at this Linux netfilter module.

denial of service

Depending on the surrounding of your hotspots it is possible that an attacker wants to deny your customers the access to your public WiFi or use the attack to force the client to associate again with the access point to capture the session key. An easy way to do this is to send faked disassociation packets.  In 802.11w (rolled up in the 802.11-2012 maintenance release) a protection against this disassociation packets has been implemented and is called protected management frames. Check your access points for support of it. On the client side all modern Linux/BSD distributions support it, starting with Windows 8 the support is also enabled by default.

client 2 client traffic

There is commonly no need for one client to talk to an other client –> block that traffic. Sure you can and should put some text into your terms of service that the user should only connect the network with a secure system and that you’re not responsible for any attack, but there is no harm in providing the user with some additional security against direct attacks and ARP spoofing and there like. Many access points provide this feature, it is often called client isolation –> so that’s a quick win.

dhcp replies / answers

This is connected to filtering client 2 client traffic but I’ve seen that some access points block normal unicast traffic but let broadcast through. With such traffic an attacker can provide the target with an wrong IP address, which is often not filtered by the client isolation feature as it is not within the local subnet and so the access points does not think about it as local traffic. More detail on how I filter that traffic can be found here.

That was the wireless part – I hope it was informative – … the next part will go up the chain to Layer2&3 an application stuff. Stay tuned!

ps: If you’ve ideas to increase the security even more, post a comment! I’m sure I forgot something.