I have been researching about prevention of ARP spoofing in an individual's device (smart phone or laptop) in a public network.

If we save the MAC address of the default gateway at the time of connection establishment by checking the ARP table for the entry corresponding to the IP of the default gateway, and then monitor any changes in that address in the ARP table periodically will we be able to secure our device.

Are there any corner cases or special cases that this method is missing out on. Also will simply securing the connection to the gateway like this be enough for a general public wireless LAN network.

  • 1
    So, if the "fake default gateway" pre-exists the client on the network, what is to prevent the client from learning the fake first and not switching to the real gateway? The client device really doesn't have enough information to make a determination of which gateway is correct. ARP poisoning needs to be protected from on the network side of things, not the client side. – YLearn Jul 15 '15 at 0:57

EDIT: Clarified options to follow the flow of the question.

  1. It is not possible to protect against arp spoofing on a public network if the identity of the AP can't be established and the traffic is open and not encrypted.

    • What if the first arp request is spoofed, how would you prevent this ?
    • What if the AP is a fake ?
  2. Connecting and then runnig all traffic through a VPN tunnel would be the safest way to consume the public wifi, but introduces complexity and delay depending on breakout.

  3. The most pragmatic approach would be to only use SSL/TLS, the internet scale companies is working hard to make this more secure to protect there clients for snooping etc.

The point is that it is impossible to protect against a fake arp/gateway at a public Wifi hotspot, you need to protect the traffic, and ensure you don't have a active MITM, event if the correct GW is used there can be a attack on the traffic stream behind the AP.

Some Quotes related to SSL/TLS and newer HSTS protection.

HSTS is a security policy mechanism where a Web server tells a supporting browser that it can only connect to it over secure connections (i.e., SSL). HSTS allows website operators to force secure connections with users that are using an HSTS-supporting browser. Supporting browsers include: Google Chrome 4+, Firefox 4+ and Opera 12.

simplifies protection against cookie hijacking. e.g. Fire Sheep

the most important security vulnerability that HSTS can fix is SSL-stripping man-in-the-middle attacks

HSTS is supported/implemented for a lot of the major internet sites, including Google, Gmail, Facebook, Twitter, Paypal. HSTS Statistics

| improve this answer | |
  • SSL/TLS won't prevent ARP poisoning. Its meant to protect you in the case of someone establishing themselves as a Man-in-the-Middle (MITM). But its not fool proof. Specially with many vendors now selling technology that intentionally places their device "in the middle" of SSL/TLS conversations... – Eddie Jul 15 '15 at 0:26
  • Most corporates deploy MITM devices without any ARP poisoning, having the correct ARP does not prevent MITM. – Pieter Jul 15 '15 at 6:12
  • @Mike Pennington Not sure why you think i changed the question. Quoting from the question "Also will simply securing the connection to the gateway like this be enough for a general public wireless LAN network." – Pieter Jul 15 '15 at 7:19
  • @Mike Pennington I thought just answering with "NO" would not be sufficient, and offered some alternatives, and reasons as to why it is not practical to secure a public hotspot gateway. – Pieter Jul 15 '15 at 7:41
  • thanks for the feedback it does make me think about the issue again, i'm not always sure how much information is needed/relevant. I will keep improving/clarifying the answer based on feedback until a better one arrives. – Pieter Jul 15 '15 at 7:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.