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 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.

Mini Howto for a simple way to block a MAC address on Extreme Network switches

September 12, 2015

Yesterday I needed to block a MAC address on an Extreme Networks switch (XOS) … sure, I could write an ACL for this but there is a better way:

To block a MAC address:

create fdbentry aa:bb:cc:dd:ee:ff vlan <VlanName> blackhole

To unblock a MAC address:

delete fdbentry aa:bb:cc:dd:ee:ff vlan <VlanName> blackhole

Howto configure a TG588 from A1 Telekom as VDSL modem and a Mikrotik device as router

September 11, 2015

Our big nation provider A1 Telekom went ahead and provided our house as first provider with VDSL – hoped FTTH makes the race … but anyway VDSL is better than the old stuff I had before.  So I went ahead and ordered it and I got send an TG588 modem/router where you can almost configure nothing. e.g. UPNP is enabled and you can’t even deactivate it – when was it a good idea that a clients tells a firewall what to do in the first place? So I had to 3 options

  • Buy a VDSL router like FRITZ!Box 3390, which is also a home router where I don’t like the configuration methods and feature set
  • Buy a VDSL modem/bridge like Vigor130, and connect via a real router over pppoe. But the system is not on the A1 Telekom vectoring devices whitelist. No change for vectoring than ….
  • Get the TG588 to play only modem and let my real router to do pppoe tunnel.

As you most likely already guested I opt for the last one. This howto shows you how to configure the TG588 as modem and an Mikrotik router as router (could be any other devices that supports pppoe in client mode). I was not that easy to gather all this information and so it maybe helps others to save time.

First lets connect the TG588 to the telephone line and the Mikrotik with one interface (in my case ether0) to it. Let everything boot up and connect your PC to the Mikrotik clients ports (in the default config). Log into the Mikrotik and configure the interface to the modem like this:

/interface ethernet set [ find default-name=ether1 ] name=ether1vlanTransitModem
/ip address add address= interface=ether1vlanTransitModem network=
/ip firewall nat add action=masquerade chain=srcnat comment="nat the traffic to the dsl modem web interface, only activate when needed" out-interface=ether1vlanTransitModem

This gives the interface a nice name, sets the IP address of that uplink interface and configures the router to perform an source NAT, so you’re able to configure the modem even if you’re behind the Mikrotik router.Make sure that there is not DHCP Client running on the Mikrotik (specially on the ether0 interface)

Now log into your TG588 by going to  Your default user has not the rights to change anything – so we need to change to an other default created user, with higher privileges. Click on the “admin” username:


Choose “change to other user”:


Provide following user data (worked at the time of writing, may got changed)

User: Telek0m

Password: Austria!Eur0


Now your user should have changed to following:


After that you will have more options to select from. Click onto “A1 WLAN Box” followed by “Configuration” and then choose “reconfigure A1 WLAN Box”


On the following page you need to select “single user” mode and click on reconfigure


Now you’re done with the TG588 – after rebooting it should be fine. Now you need only following two pages on the TG588 – the rest is done by the Mikrotik router

First the event log, here you can check if something does not work:


And following page shows you the speed you’re connected with the provider network


The easy part

Now after all that clicking the Mikrotik part is easy:

/interface pppoe-client add add-default-route=yes disabled=no interface=ether1vlanTransitModem max-mru=1492 max-mtu=1492 mrru=disabled name=pppoeDslInternet password=XXXXXXXX use-peer-dns=no/yes user=XXXXXX

Replace XXXX with the data you got from A1 Telekom.

Now you’re internet connection should be up … test it with


after that we only need some Firewall rules move the client traffic correctly to and from the Internet.

/ip firewall mangle add action=change-mss chain=forward comment="max MTU size for pppoe 1492" new-mss=1452 out-interface=pppoeDslInternet protocol=tcp tcp-flags=syn tcp-mss=!0-1452
/ip firewall nat add action=masquerade chain=srcnat comment="nat all traffic which goes over dsl into the internet" out-interface=pppoeDslInternet

Now you’re done. Hope this helped.

Unifi upgrade 2.4.6 to 3.2.10: maps not working

July 8, 2015

So after the migration itself worked and I’ve updated the access points I looked into the problem that my maps did not work anymore. Every map showed only white and I was not able to add new maps. After long googling I found part of the answer here.  My solution is a bit different and works on the fly:

  1. Unifi management needs to be running
  2. check where your mongod is running … on my system its ports 27117
    # netstat -pnl | grep mongod
    tcp 0 0* LISTEN 16760/bin/mongod
  3. login with /usr/bin/mongo --port 27117
  4. and type following
  5. use ace followed by"files_id_1_n_1")
  6. choose a new map in the drop down box and it should work again

the full communication looks like this:

# /usr/bin/mongo --port 27117
MongoDB shell version: 2.6.10
connecting to:
> use ace
switched to db ace
{ "nIndexesWas" : 2, "ok" : 1 }

Unifi upgrade 2.4.6 to 3.2.10: exception: remove needs a query at src/mongo/shell/collection.js

If you try to upgrade Ubiquiti Networks Unifi system from version 2.4.6 to 3.2.10 it is possible that you’ll run into following problem:

Exception in thread "launcher" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'class.super': Instantiation of bean failed; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: Factory method [public final$$EnhancerByCGLIB$$ad7756e2.class.super()] threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'Ø00000': Invocation of init method failed; nested exception is com.mongodb.CommandResult$CommandFailure: command failed [$eval]: { "serverUsed" : "/" , "errmsg" : "exception: remove needs a query at src/mongo/shell/collection.js:299" , "code" : 16722 , "ok" : 0.0}

when trying to start it like this

/usr/bin/java -jar /opt/UniFi/lib/ace.jar start

Searching through the Internet shows that more people have the problem but a working solution is not posted anywhere. So here is it:

The reason for the problem is quit easily found here. Basically the syntax of the command is not correct. So I started to search through the lib directory for a file that contains this incorrect string. It is within /opt/UniFi/lib/ace.jar so I installed the jar command line utility (on Centos 6)

yum install java-1.7.0-openjdk-devel

and extracted all files to search in which it was. As I found it, its easier for you just type:

jar xf ace.jar com/ubnt/A/ooOO/OOoO.class

Now you need a Java class editor – we use this Java one. Download and extract it and start it like this:

java -jar ce.jar

Now you need to find and change the values:

  1. Click on “Constant Pool”
  2. Type db.cache_device.remove in the search field and find the line 459
  3. Activate the “Modify Mode” and change the values


In the end it should look like this (the second one is a link to the fist,  just update):


Now save the file and update the jar file:

jar uf ace.jar com/ubnt/A/ooOO/OOoO.class

Now a restart and migration should work. Hope this helps others .. it took me one hour to find my solution, so I hope its now faster for you. 😉

Howto filter rogue DHCP servers on Ubiquiti Networks UniFi access points

June 25, 2015

This short post shows how to filter rogue DHCP servers, which are connected via the WiFi to the network. The UniFi management software allows you to block traffic between 2 clients connected to the same access point. This feature is often called “client isolation”. But for seamless handover to an other access point, all need to be in the same layer 2 network. So an rogue DHCP server can serve clients on an other access point.  This setup filters that traffic.

For this you need to put following lines into a file called (most likely you need to create the file).

config.system_cfg.1=ebtables.1.cmd=-A FORWARD -i ath* --protocol ipv4 --ip-protocol udp --ip-destination-port 68 -j DROP
config.system_cfg.2=ebtables.2.cmd=-A FORWARD -i ath* --protocol ipv4 --ip-protocol udp --ip-source-port 67 -j DROP
config.system_cfg.3=ebtables.3.cmd=-A FORWARD -i eth0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67 -j DROP

The location of the file depends on the version of your UniFi management software.

  • Version 2: /opt/UniFi/data/
  • Version 3+: /opt/UniFi/data/sites/the_site/ – to get the site id take a look at this article.

After that change you need to trigger the re-provision on the access points affected. You can do this by enabling and disabling the guest portal(for the entire site) or on a per access point basis, changing TX power one by one, for example.

To verify that the configuration got deployed, log into the access point via ssh and check the ebtables – it should look like this:

BZ.vx.x.x# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 3, policy: ACCEPT
-p IPv4 -i ath* --ip-proto udp --ip-dport 68 -j DROP
-p IPv4 -i ath* --ip-proto udp --ip-sport 67 -j DROP
-p IPv4 -i eth0 --ip-proto udp --ip-dport 67 -j DROP

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Securing your client network 2: Separate by device classes

June 16, 2015

The second article in the securing your client network series (after Enforce DHCP usage) is about separating different client device classes in the network. Typically enterprises separate different departments in separate VLANs. If the VLANs are routed in the same VRF and no ACLs separate them, the gained security is negligible. If you’re configuring ACLs for this, you have too much time on hand or the rules are not tight. And the setup works only good if you’re within one central office building and your network is not distributed over an city or even country.  So after I told you what is not a good idea – what setup do I recommend for bigger networks (> 500 client switch ports .. works great for > 10.000 ports and more).

Separate not by department, separate by device class

Yes, that’s the basic idea behind it. Why is that better?

  • less work
    Employees and departments move around. You need to keep your configuration up to date and if part of a department moves to an other location you need to extend the layer2 network think about something else
  • simpler and more secure firewall rules
    If your VoIP phones, PCs and printers of an department are in the same Layer2 network you need to keep track of the devices for the firewall rules or allow a printer the same access as an PC or an VoIP phone. If you separate your printers in a separated network the firewall rules for them are easy, every device in that network is a printer. The firewall rules can be much more strict than in the PC network – a printer needs to talk to the print server (and dns, dhcp, ntp) but nothing else – a PC needs much more
  • network authentication tailored to the device class
    MAC authentication works for any device, but 802.1x only works if the device supports it. Switching 802.1x on for all devices at the same time won’t work, but if only one device is allowed into a network area with only MAC authentication – It does not help that all others use 802.1x, the attacker just fakes that MAC address. With a separation by device classes you can  implemented 802.1x for some networks and others not. e.g. 802.1x for Windows PCs with AD integration is not that complicated – so for the PC network 802.1x could be required, but for the printer network MAC authentication is Ok.  This is specially valid if the firewall rules in the printer network are much more strict – even if someone gets access to that network he is not able to connect to the Exchange, database or file server … only the print server is allowed to connect to the printers and not the other way round
  • separate systems with different patch intervals
    Most likely your Windows clients get an update very month but when did your company the last time update the firmware of the printers? Separate them and attacker can’t jump systems that easy any more.
  • block client to client communication
    If a network area is only used for devices classes that don’t need (or should) communicated directly with each other, you can just block that communication with ACLs. The ACLs are the same for all Layer 2 client access switches and are maintenance free. A classic example for this would be the printer network … why should one printer talk with an other printer – just the print server needs to be able to reach the printers.  So if one printer gets pwned it does not affect the other printers. The same is true for building automation networks (like cameras, access control systems, attendance clock) or maybe your PCs don’t need to talk to each other – VoIP most likely needs to 😉

I hope I convinced you its an good idea, but how is it technically done.

Dynamic VLAN assignment

I recommend to use dynamic VLAN assignment via MAC or 802.1x authentication (via RADIUS Server) .Lets assume you’ve following setup:

  • Edge: Layer 2 edge switch to which the clients are connected to
  • Distribution: Layer 3 switch which aggregates multiple Layer 2 edge switches in the same building
  • Core: aggregates the distribution switches in the data center
  • Firewall: firewall between DMZ and between the different client network areas


The names of the VLANs on every edge switch are the same, just the VLAN IDs are different. This allows the RADIUS server to return the name of the VLAN the switch should assign to a port or MAC. As the name is the same for all switches, the RADIUS server does not need to know the VLAN IDs. The RADIUS server just has a table that tells it which MAC or common name (in case of 802.1x EAP-TLS) does go into which VLAN. All your switches are configured exactly the same, just the management IP address and the VLAN IDs are different … that makes deploying and maintaining really easy.

For getting the traffic from the edge to the data center I recommend using VRF (Virtual Routing and Forwarding) and OSPF. Just assign the PC VLANs in one VRF and vlanPrinter in an other VRF. The link from the core to the firewall is also tagged. The firewall is now the only way to get from the PC network to the printer network.

I hope that example makes the setup clear, if now just write a comment.

Securing your client network 1: Enforce DHCP usage

June 14, 2015

In my last blog post I talked about going the full Layer 3 way and not building complex Layer2 subnets throughout your network. As many have the argument of security for building their networks this way I thought I write down how I secure client networks. With client networks I mean the part of the network client systems like PCs, phones, printer, … are connected to. Some of the articles and setups can also be used for the data center networks but thats an other story … 😉

All setups I describe in this series I have implemented in productions networks over the years and are therefore not stuff that only works in theory but they work in real life and solve real world problems. So lets start with something easy but which has real benefits not only for security – enforcing DHCP usage by all client systems.


Sure, everybody knows for what DHCP is used but lets talk a little bit about the benefits besides not needing to configure each clients manually.

  • If clients get their IP address via DHCP its easier to move the client systems to other subnets. So the need to extend your subnet over multiple switches decreases.
    Result: Helps you to a more routed network and so simpler and more stable network. Clients can move through out your network and it just works.
  • It is also easier to change the client subnet if needed it for an upgrade/change of the network architecture.
    Result: Makes much more flexible to change your network.
  • If you enforce the use of DHCP you also get an log file which client had which IP address at a given time and also to which switch port the client was connected. If there are static IP addresses in your network which you don’t control your log file ins incomplete.
    Result: Audit logs in case you need to do a forensic investigation on how and by what systems an attack was carried out. Most systems log the IP address and you need to map that to a specify systems/location.
  • Also if you enforce the usage of DHCP, you can use the DHCP requests/replies for protection against of ARP spoofing (or at least mitigation) in your network.
    Result: An attacker can not sniffer the traffic from an other client system in the same subnet.
  • If enforced, no idiot configures an IP address static which is also used dynamically.
    Result: Quieter life for you. 😉


To enforce DHCP usage we need to make sure that not using DHCP does not work. How can we do that? Simple – disable ARP learning on the Layer 3 switch, which is the default gateway of a client subnet. ARP (Address Resolution Protocol) is used to resolve IP addresses to MAC addresses, so if the default gateway needs to send a packet to a client systems and it does not know the MAC address (in its ARP table) – its not able to send the packet.  Of course the setup needs to work for systems that use DHCP. How is this done? Also simple, the default gateway is most likely already configured as DHCP relay for the central DHCP server so it gets every request and reply. The DHCP reply contains the IP address assigned by the server and the MAC address of the client. The layer 3 switch just needs to write that into its ARP table. From this time on the IP address resolves always to that MAC address until a new DHCP rely provides and not MAC address for a given IP address.

For Extreme Networks switches (XOS) it is as simple as typing that lines per client VLAN/subnet:

enable ip-security dhcp-snooping vlan <vlanClient> port <ClientPorts> violation-action drop-packet snmp-trap
configure trusted-ports <UpLinkPorts> trust-for dhcp-server  (only once needed)
enable ip-security arp learning learn-from-dhcp vlan <vlanClient> ports <ClientPorts>
enable ip-security arp gratuitous-protection vlan Default
disable ip-security arp learning learn-from-arp vlan <vlanClient> ports <ClientPorts>

If the clients are connected directly to the layer 3 switch (default gateway for the client subnet) I recommend changing the first command to

enable ip-security dhcp-snooping vlan <vlanClient> port <ClientPorts> violation-action drop-packet block-port permanently snmp-trap

So that guy who did start a DHCP server in your network needs to call you, before it works again – otherwise I recommend configuring that this way on the switch the client is connected to.


Following setups / configurations should be done to increase the security in this part still more:

  • Save the DHCP log file for a longer time period as is default for Windows DHCP servers which rotate every week and make sure all information you need is in the log file.
  • Enable ARP spoofing protection also on the clients systems where possible (most likely on on PCs possible). Most enterprise endpoint protection systems allow such a configuration.
  • Integrate the configuration of DHCP reservations (e.g. for printers) into your network authentication solution. It already needs to know the MAC address of the client so adding the IP address there is simple. It keeps also the DHCP scopes clean, so if a client is removed from the network authentication, it automatically removes the reservation from the DHCP server. The side benefit is that your service desk employees could also use this to create DHCP reservations without needing DHCP administrator privileges – and its often easier to have an audit log of the changes than on the Windows DHCP server.

Ghostery – prevent browser tracking

May 14, 2015

Sorry for not posting for a long time, but today I’ve again something for you. Its a Firefox plugin which allows you to easily block tracking sites. First what are tracking sites?

Lets say you want to visit and your browser goes to that page. It loads the HTML page and that includes 1×1 pixel pictures from other domains or it loads java script code from other domains. e.g. like shown here (Adition – which is an advertising company):


These have mostly no other purpuse but to track you and get as much information about your system and you as is possible. The big tracking sites are not only used by but also by So by using cookies and more subtle techniques they are able to track you over multiple sites and generate a profile about you.  Only after installing the plugin I’ll show you, you’ll see how manny different tracking sites big sites are using to get you.

The software is called Ghostery and can be downloaed directly from the Mozilla guys here. Just click on the green button, no restart of Firefox is required.


Click on the light blue ghost image on the right upper side of your browser. Click through the tuturial and than I recommend to set all sites to block and only unblock sites that you need. For this click on the Ghostery icon and than on the settings icon followed by options.


Now scroll down and click on select all and if asked if you want also new sites to be blocked and then click on save.


Now visit a big, prominent site and check the count. 4 sites like in this screen shot is low …. my personal record was 14 for one site – can you top it? Write in the comments.


Powered by WordPress
Entries and comments feeds. Valid XHTML and CSS. 86 queries. 0.296 seconds.