Third Idea for DeityGuard

The “third idea” is a tool for preventing data exfiltration. The basic idea is to have an Internet-connected “pusher” machine connected to a “client” through a one-way ethernet cable. It’s a very cheap and simple way to make a “data diode”, plus a software layer for sending incremental updates. This can be used, for instance, managing a Ubuntu installation on the “client” side – or for pushing the source files necessary for a DeityGuard build.

To create the one-way ethernet cable, solder two leads on the TX+ and TX- lines, and crimp the cable so that pairs TX+,RX+ and TX-,RX- are shorted on the “pusher” side of the cable. On the “client” side of the cable, crimp only the RX+ and RX- lines. This will work with most USB ethernet adapters at 100Mbit speed. Gigabit speeds are not possible because the gigabit ethernet protocol uses the pins bidirectionally.

When connected up, the “pusher” side of the ethernet will negotiate a link with itself (basically a loopback) and the “client” side will passively accept data. The “pusher” side will see all data sent reflected back but it will ignore the data since it seems to be targeted to a different IP address. The “client” side of things will not be able to send but this seems not to bother most USB ethernet adapters.

Note: Some no-brand imported ethernet adapters have been observed not to be compatible with a “third idea” setup. The one tested and recommended model of ethernet adapters is TRENDnet TU2-ET100. Update: It seems TRENDnet has been using the same model number over several generations of different ethernet adapter products. It’s rather inconceivable that all these different products use the same chipset so it looks like a toss-up as to whether you would get a compatible chipset by buying a TU2-ET100. Most brand-name USB ethernet adapters work fine with “third idea”.

To configure the interface on the “pusher” machine, do:

sudo ifconfig (interface) 10.183.215.(channel)01 netmask 255.255.255.252
sudo arp -s 10.183.215.82 02:00:00:00:00:0(channel)

And on the “client” machine, do:

sudo ifconfig (interface) down
sudo ifconfig (interface) hw ether 02:00:00:00:00:0(channel)
sudo ifconfig (interface) 10.183.215.(channel)02 netmask 255.255.255.252

The “channel” should be a single digit between 1 and 9 (inclusive). The IP ranges 10.183.215.(channel)00/30 were chosen arbitrarily; hopefully they will not conflict with other host addresses that you might have via DHCP, etc. At any rate, use of random /30 ranges from within 10.0.0.0/8 is recommended as this minimizes the chance of conflicts. The ethernet MAC addresses have the “locally administered” bit set, so they cannot conflict with normal “globally unique” addresses.

If you have a network manager running (e.g., NetworkManager on Ubuntu), you may need to disable it as it tends to deconfigure the interfaces.

Obviously, there is no way for the “client” machine to trigger retransmission. Bit errors are detected using strong cryptographic checksums, but they are quite rare. More commonly, entire packets sent by the “pusher” fail to arrive at the “client” end. By default, all data is sent in triplicate, and this seems to work pretty reliably. The multiplicity can be increased for higher levels of robustness (some form of ECC would be ideal but that is not implemented).

The example code for the “third idea” is in the 3-ithird directory of the DeityGuard source archive. It is optional to use, but highly recommended since using a “data diode” greatly increases the difficulty for an attacker to successfully command and control the build host.