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.

In HowTo, IT Security, Networking | 1 Comment

1 Comment »

RSS feed for comments on this post. TrackBack URI

[…] a secure public WiFi hotspot”. In the first two parts we concentrated on the wireless and layer 2 and 3 part, this time we take a look at the application layer stuff you should tune to provide a secure […]

Pingback by Tips on how to provide a secure public WiFi hotspot – Part 3 | Robert Penz Blog — February 4, 2016 #

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

1 Comment »

Leave a comment