How the Interceptor Works
The Interceptor is a wired network tap which passes network data out over a wireless network so it can be sniffed on a network device on a remote machine.
First the the two wired NICs on the Fon+ are bridged. This allows it to be placed in-line on any network and the data to flow freely. Ideally the bridge doesn't have an IP address so it can't accidentally interfere with any traffic flowing through it. From simple experiments the bridge doesn't alter the TTL but does increase the time the data takes to flow between the machines.
With the Interceptor
robin@desktop ~ # ping 192.168.0.8
PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=1.15 ms
64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=1.08 ms
64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=1.03 ms
64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=1.09 ms
64 bytes from 192.168.0.8: icmp_seq=5 ttl=64 time=1.17 ms
64 bytes from 192.168.0.8: icmp_seq=6 ttl=64 time=1.03 ms
64 bytes from 192.168.0.8: icmp_seq=7 ttl=64 time=1.29 ms
64 bytes from 192.168.0.8: icmp_seq=8 ttl=64 time=1.13 ms
64 bytes from 192.168.0.8: icmp_seq=9 ttl=64 time=1.14 ms
64 bytes from 192.168.0.8: icmp_seq=10 ttl=64 time=1.14 ms
^C
--- 192.168.0.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 1.033/1.130/1.297/0.072 ms
Without the Interceptor
robin@desktop ~ # ping 192.168.0.8
PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.603 ms
64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.591 ms
64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.593 ms
64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.582 ms
64 bytes from 192.168.0.8: icmp_seq=5 ttl=64 time=0.597 ms
64 bytes from 192.168.0.8: icmp_seq=6 ttl=64 time=0.591 ms
64 bytes from 192.168.0.8: icmp_seq=7 ttl=64 time=0.593 ms
64 bytes from 192.168.0.8: icmp_seq=8 ttl=64 time=0.452 ms
64 bytes from 192.168.0.8: icmp_seq=9 ttl=64 time=0.594 ms
64 bytes from 192.168.0.8: icmp_seq=10 ttl=64 time=0.593 ms
^C
--- 192.168.0.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 0.452/0.578/0.603/0.053 ms
As you can see, there is a slight time increase but no TTL change.
The initial idea was to use iptables to clone the traffic from the bridge to the wireless network but I couldn't find a way to do this with the standard iptables features. I then started looking at DaemonLogger by Martin Roesch. This app takes traffic on an input interface and clones it to an output interface. I wanted the Fon+ to run as an AP so I set it up and had DaemonLogger clone data from br-lan to ath0. The problem with this is the AP mangled the traffic before sending it out so either sniffing the traffic on the air or on a client associated with the AP didn't give the right results. The next approach was to move the AP to the laptop and have the Fon+ associate with it. In this situation the client sent out the data correctly so it could be sniffed in the air but when it arrived at the AP the AP again mangled it so sniffing the wireless interface on the laptop gave corrupt data.
After a lot of frustration Pieter on the snort mailing list suggested tunneling the data over a VPN. I installed openvpn on the Fon+ and seeing as I already had a openvpn server running on the laptop I set the Fon+ to be the client. After some modification of the settings I found that I had to use Ethernet bridging rather than routing, i.e. tap rather than tun mode, and obviously alter the DaemonLogger setup to clone the data onto tap0 rather than ath0. After some fiddling I finally managed to see traffic while sniffing on tap0 on the laptop. After some celebrations I swapped round the VPN client and server to have the server on the Fon+ as that seems like the right place for it. Unfortunately that doesn't work, I assume this is because the server sees the data copied on to its interface, doesn't recognize the network the data is aimed at so just drops it. The other way round the client doesn't recognize the network so its default behavior is to send the data to its server.
So, the result is the Fon+ runs the wireless AP but has to be a client on the VPN. Assuming WPA/WPA2 is used to protect the wireless network the data is doubly encrypted. This improves security but increases the overhead of sending the data. It is possible to remove encryption at either stage to increase performace however removing WPA/WPA2 would leave the wireless network open to anyone to attach to and by running the VPN as encrypted it is possible to extend the sniffed data beyond the wireless client and route it to a VPN server anywhere you want.
If anyone is able to suggest any alternative ways to tunnel or transmit the data please get in touch.
One small problem I found when setting this up was the Fon doesn't back up the date when the power is removed. Because of this the date defaults to 1970 every time it is started up. If this isn't reset to todays date the certificates used for the VPN are noticed to have been created in the future and the VPN client rejects them. To counter this I pass the date from the start up script on the laptop to the start up script on the Fon.
