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.

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

sudo ifconfig (interface) 10.183.215.(channel)01 netmask
sudo arp -s 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

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