
Building Your Own Data Diode with Open Source Solutions - walterbell
http://blog.cimation.com/blog/building-your-own-data-diode-with-open-source-solutions
======
technimad
The incompleteness of this article is stunning.... Replicate your database
over a one way link. The problem is that replication typically uses TCP, which
is a two way protocol, not compatible with a one way link.

You'll need to encapsulate the traffic in a one way protocol and fake the
responses required by higher level two way protocols on either side. Also
disconnecting one fiber, will result in a link down/no carrier link state with
default networking drivers, so some patches are needed in this area. Love to
see some open source software capable of this.

~~~
deutronium
If you do need to modify the network driver, has anyone seen any patches for
keeping the link active?

~~~
walterbell
A Linux patchset from 2010,
[http://thread.gmane.org/gmane.linux.kernel/1028699](http://thread.gmane.org/gmane.linux.kernel/1028699)

~~~
deutronium
Thanks a lot!

------
sargun
I'm pretty sure that this wont work. Auto Negotiation will fail. Without
getting link pulses from the other side, the MII / PHY will show as down.

More here:
[https://en.wikipedia.org/wiki/Autonegotiation](https://en.wikipedia.org/wiki/Autonegotiation)

You may be able to disable this feature, but it comes at great cost of losing
link monitoring.

Without bi-directional replication, there's no way of stopping replication
during failure, or inducing back pressure.

I'm inclined to think that this is a joke of some kind? I don't know.

~~~
walterbell
More information about data diodes:

[https://en.m.wikipedia.org/wiki/Unidirectional_network](https://en.m.wikipedia.org/wiki/Unidirectional_network)

[http://www.owlcti.com/pdfs/whitepapers/All_Diodes_Are_Not_Eq...](http://www.owlcti.com/pdfs/whitepapers/All_Diodes_Are_Not_Equal.pdf)

------
Animats
You need some one-way protocol with redundancy if you're using this to sync a
slave database to a master. You'd like to have a protocol with so much
redundancy that you can survive an N minute outage on the receive side, N
being larger than the reboot time. You could, for example, transmit a stream
of updates, plus a stream of old updates from N minutes ago. Plus, perhaps, a
slow transmit of the entire database, so if you lose a disk on the slave, you
can get synched up again over a period of hours.

------
structural
The (expensive) solutions here typically involve IP over ATM, with forward
error correction provided at the transport layer. This improves the
reliability of your UDP stream considerably, since you don't have the option
of application-level requests for retransmit.

Furthermore, you can implement a certifiably low-risk system for retransmits
using a separate ultra-low-bandwidth uplink that can raise a NACK on data
errors that FEC can't handle. This is sufficient for unidirectional TCP
streams to be wrapped.

I mean, sure, you can fake it if you're not worried about someone connecting
the wrong cable (potentially turning your system into a wonderful fountain of
all the data you were trying to protect) and if you're willing to write custom
application level protocols to handle significant amounts of data loss in
transmission.

------
synergist
Hey Hacker News, I am the original author of this article on the Cimation
website.

A few months ago I published a more detailed Whitepaper in the SANS reading
room that provides a working data diode (using off the shelf parts) and
PowerShell code that will transfer files unidirectionally as a proof of
concept. [https://www.sans.org/reading-
room/whitepapers/firewalls/tact...](https://www.sans.org/reading-
room/whitepapers/firewalls/tactical-data-diodes-industrial-automation-control-
systems-36057) It talks through the challenges of implementing a data diode on
an OSI layer basis. I hope you enjoy it and I would love to hear your
thoughts.

------
reitanqild
Serial cables work nicely as well and is less expensive (for now : )

As others have mentioned TCP goes out the window immediately. Luckily for lots
of applications sending updates work really well.

~~~
mseebach
Serial is also _ever so slightly_ slower than gigabit fiber.

But more importantly -- fiber network cards have clearly physically separated
transmitter and receiver ports. A transmitter port does not contain the
hardware for receiving data, and the receiver port does not contain the
hardware for transmitting.

A one-wire serial connection can (probably) be reversed by replacing the
firmware of the controller chip. A one-way fiber connection as described in
this article is _physically incapable_ of transmitting data in the opposite
direction.

~~~
upofadown
>A one-wire serial connection can (probably) be reversed by replacing the
firmware of the controller chip.

I would say; probably not. RS-232 uses fairly high positive and negative
voltages. There is always some sort of driver that can't be made to work in
reverse.

------
Kliment
Is there a reason you can't do that with an ethernet cable?

~~~
TheCondor
You could. Commercial diodes comes with special drivers and I've seen at least
one with a modified nic that could sync with only one way communication. There
are also software components they usually come with as the proxying is
somewhat tricky with one direction communication. The real advantage of the
fiber is the use can see that there is no way for a return signal, with normal
Ethernet you need to have a special cable, a very special one, if it's
replaced with something different the diode may be compromised. It becomes a
trust issue. The diodes from some companies are very expensive too, 6 figure
price tags with all the various defense type certifications.

