I wasn't interested in protecting attendees from having their network activity monitored by other attendees, limiting the spread of viruses, or other sysadmin activities that make sense in a corporate setting. Rather, I wanted to make sure everyone could get to the Innurnet as quickly and reliably as possible. With this trick I'm trying to improve specifically availability, rather than a more general notion of ``securitah''.
Ettercap calls the attack I'm trying to resist ARP poisoning. I call it arp stealing throughout, because I wrote all this stuff without reading about ettercap.
I suspect another common problem is attackers who don't know how to use their tools, so they drop the packets they've snagged rather than forwarding them on to the real gateway as presumably they mean to. but I don't really know.
To accomplish this, spoofing arp can do two attacker-useful things on the MAC layer:
Of course there's also a problem if there is so much arp garbage on the broadcast subnet that it becomes congested, but I don't have any fantastic answer to that right now. I also haven't seen that problem in the wild.
There's a separate problem with disrupting MAC learning on L2 switched subnets.
Note that the manual reconfiguration on a new lease is only necessary to maintain arp-spoofing resilience. so this situation is no worse than an ordinary network. Further, ISC dhcpd will prefer to give clients the same address they had before, even if their lease on that address is expired. I think it's likely most attendees will have the same IP address throughout the whole conference, at least within a given physical subnet. probably not as they move between floors. :'
One problem with this approach is, attendees won't be able to communicate directly with each other in an arp-spoof-proof way. To solve this, I use interface ``aliases'' (BSD) or ``secondary'' addresses (Cisco), so there are many two-bit subnets on a single wire. Every attendee will be in his or her own subnet with a 255.255.255.252 netmask, and the only two hosts on this subnet will be the client and the gateway. However there may be hundreds of these subnets on a single VLAN or physical interface. That way, the gateway acts as a master repository of everyone's real MAC address, and the only MAC address that has to be statically configured into each client to be arp-spoof-proof is that of the gateway, not all the addresses of all other clients on the subnet.
This is convenient because it means the NOC staff will be able to monitor all traffic to diagnose problems, unlike a regular switched network where monitoring traffic can be pesky. It's also a simple design, without any proxy arp daemons or weird routing table entries.
This is bad because it means all traffic will have to flow through the BSD gateway. Hopefully it'll have no trouble handling this load. I envision typical use patterns would push all (non-attack) traffic through the gateway anyway, since an attendee browsing the Interweb or using an FTP mirror in the NOC to install some free Unix will probably be on a different subnet than his or her destination, even without the arpless trick.
It's also bad because there could be odd scalability problems with
having so many local interface addresses---on my box, I get
ntpd---too many open files. I think the latter problem
is easy to resolve with testing. The former problem is harder to
predict. We could arrange to have multiple BSD gateways, but I don't
think that makes sense unless we have some rough concept of the actual
conference load and gateway capacity.
I'm now using ifconfig.wi0 like this, so the gateway has
only one IP address on its interface, but uses choparp to collect
packets for all the IPs that used to be configured as aliases on the
gateway. The subnet mask of the clients doesn't match the gateway
under this scheme. There are some unclean consequenses---the gateway
sends ICMP redirects to the clients that it shouldn't, and the clients
unintuitively can't ping their default gateway which confuses people.
but, it basically works.
!wiconfig $int -s `hostname`
chan 1 nwid hackerhalfwayhouse.org mediaopt hostap
-arp up
inet6 3ffe:401d:203a:2::1 prefixlen 64 alias
inet 192.168.16.1 netmask 0xfffff000
inet 192.168.32.1 netmask 0xfffff000 alias
inet 192.168.15.1 netmask 0xffffff00 alias
# dhcp will hand out the above as about 2000 2-bit subnets. proxy arp for
# the default gateway in each of these subnets, except where we happen to
# actually have the IP in question assigned to the interface.
! exclude="$(ifconfig $int | \
awk '/inet alias/ { print $3; next; } /inet / { print $2 }')"; \
m=15; \
while [ $m -le 47 ]; do \
prefix=192.168.$m; \
n=1; \
while [ $n -le 254 ]; do \
for exc in $exclude; do \
if [ "$prefix.$n" = "$exc" ]; then \
n=$(( $n + 4 )); \
continue 2; \
fi; \
done; \
echo $prefix.$n; \
n=$(( $n + 4 )); \
done; \
m=$(( $m + 1 )); \
done | xargs nohup ksh -c "choparp $int auto \\$@ < /dev/null &" ksh > /dev/null 2>&1
I didn't find any performance problems with forwarding even with 2000 aliases on one interface. I eventually backed it out and replaced it with proxy arp as you see above for other reasons:
I could live with the first problem. Maybe someday I can clean up zebra and ntpd, and go back to 2000 aliases.