I was just wondering how I could build a private network where it is physically impossible to gain access from outside but still have the option to publish data to some remote server. As an example: Let's say I have a network of devices that controls some kind of critical infrastructure and I don't want anyone to be able to access it except for the people on-site. However, I'd still linke to send diagnostic information without notable delay to a remote server that can be accessed from the internet.

Assumptions about the attacker:

  • can break into any system that is connected to the internet
  • does not have physical access to the private network

So we can't just put a server that acts as a firewall between the public and private network, because every software has flaws and the attacker would gain access to the private network as soon as the firewall has been broken (except if we had a firewall where the rules are embedded in hardware or for some other reason impossible to be modified without physical access. Are there such devices?)

What could solve the problem is a device that physically allows only unidirectional communication (in our case from the private to the public network). I don't know if there are any such devices, but I came up with some ideas:

  • use any kind of write-only media, like CD-ROMs. Issues: high latency and requires specialized hardware to automatically move CDs between machines.
  • paper printer/scanner setup: Have a printer in your private network that feeds directly into a scanner that is connected to the public network. Latency reduced to just a few seconds, but error-prone due to OCR.
  • Fiber-optic communication: On the side of the receiver, physically remove the optical transmitter (or remove the receiver on the other side), therefore only unidirectional communication is possible. Probably won't work with Ethernet though (are there any network protocols that properly handle unidirectional communication?)

Before I continue to make a fool out of myself because I've missed the obvious solution, I'd love to hear your comments on this :)

  • 10
    wikipedia:Unidirectional network, Data Diodes: Super Security or Super Pain?, ... - keywords are unidirectional communication, data diodes and similar. Commented Dec 18, 2016 at 12:47
  • 6
    A serial port with only one of the data lines (plus ground) would work just fine. Commented Dec 18, 2016 at 16:55
  • 1
    "Rules embedded in hardware" is, probably, still software. Commented Dec 18, 2016 at 22:14
  • closed TCP ports seem to block most attacks, but you have denied that option.
    – Jasen
    Commented Dec 18, 2016 at 23:37
  • 3
    The OCR thing is not necessarily needed. You can use QR code or other such error detecting encoding method to make it easier for machines to read rather than letters.
    – Lie Ryan
    Commented Dec 19, 2016 at 15:43

7 Answers 7


You can use a serial port. By default there are two data lines, one per each direction, plus a ground wire (which is irrelevant here). By disconnecting the appropriate line you can prevent communication in a certain direction.

It's really easy to use it, at the very basic level I think you can run something like echo hello >> /dev/ttyS0 and receive it with cat /dev/ttyS0 at the other side. There is no complicated network stack to work around (which would prevent unidirectional communications as it would treat the lack of response as packet loss) and most languages have easy to use libraries to talk over serial ports.

Here's an example in Python on how to send some JSON over serial:

import serial, json
s = serial.Serial('/dev/ttyUSB0')
data = json.dumps({"status": "OK", "uptime": 60}).encode("utf-8") # make UTF-8 encoded JSON
s.write(data + "\n") # send the JSON over serial with a newline at the end
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Dec 19, 2016 at 20:08

I love how much my search performance increases as soon as I am done posting my question ;D

Wikipedia to the rescue:

  • "Sneakernet is an informal term describing the transfer of electronic information by physically moving media (...) from one computer to another; rather than transmitting the information over a computer network."
  • "A unidirectional network (also referred to as a unidirectional security gateway or data diode) is a network appliance or device allowing data to travel only in one direction, used in guaranteeing information security."
  • "An air gap, air wall or air gapping is a network security measure employed on one or more computers to ensure that a secure computer network is physically isolated from unsecured networks"
  • see also: Air gap malware

And there are actually companies selling hacked fiber-optic network links. They had to develop their own network protocols, though I wasn't able to find any specs on those so far...

  • 4
    “It turns out there is always an idiot around who doesn’t think much about the thumb drive in their hand,". This was supposedly said regarding this attack on an "unbreachable installation". Commented Dec 18, 2016 at 22:35
  • 2
    yeah, protecting your system against physical access / social engineering is an entirely different problem and pretty much impossible to do. But airgapping will protect you against any kind of infection that spreads over the internet. So while you can still penetrate individual systems (with considerable effort), it would be very hard to launch a large-scale attack against spatially distributed infrastructure (e.g. power grids, data centers, etc.).
    – Klamann
    Commented Dec 19, 2016 at 0:10
  • I feel the discussion only gains by mentioning the "world's first cyberweapon"[sic] attack on a airgap facility. Commented Dec 19, 2016 at 0:12


Common 100mbit Ethernet can be easily be made physically unidirectional by cutting a few wires. The standard network protocols require bidirectional communications, and ensuring delivery is impossible in an unidirectional network (since the sender can't get any confirmation if a message was received or lost), but you can definitely write a small custom network stack yourself - an app on one side sending the data (possibly duplicating each message and including checksums that allow for error recovery) as raw ethernet frames; and an app on the other side that assembles a data stream from them. There are relatively high level libraries available to work with such data, e.g. http://www.secdev.org/projects/scapy/.

It's not something that will work out of the box, but not that hard as well, that could be within bounds of a college homework project.

  • 5
    If the cable does not have wires for communicating in both directions I don't think you will ever be able to get Ethernet hardware on either end to consider the link established. I don't think it would be possible to get any data through such a construct.
    – kasperd
    Commented Dec 18, 2016 at 21:01
  • 2
    @kasperd you certainly can use standard ethernet cards to listen to ethernet cables with half of wires missing, connecting with e.g. greatscottgadgets.com/throwingstar and monitoring the received data with e.g Wireshark. I haven't tried transmitting, but it should be possible - Ethernet has no stateful "established links", you can transmit arbitrary data "into the void" if you want. You can't use the OS network stack for a correct OSI layer 2/3 connection, but you can use the Ethernet hardware to handle the physical layer for you and transmit or capture the raw frames in your code.
    – Peteris
    Commented Dec 18, 2016 at 22:14
  • 1
    @Peteris There sure is some link state. When you connect a cable between two Ethernet devices they negotiate a link speed and light up LEDs to indicate which speed was negotiated. (How detailed information you get from those LEDs depend on the exact hardware.)
    – kasperd
    Commented Dec 18, 2016 at 22:18
  • 1
    @kasperd as far as I understand, this (autonegotiation) is a "new" (only since 1995) addition to the standard that is mandatory only for gigabit ethernet and optional for 10/100 mbit connections; but all the hardware should also work with the old 10-BASET "dumb" mode - if it doesn't get any response to this negotiation, that is also a valid mode of operation. But this is tricky and might be that it won't work, perhaps I need to try it in practice.
    – Peteris
    Commented Dec 18, 2016 at 22:30
  • 2
    @Klamann, CSMA-CD is only needed with broadcast ethernet (coaxial, wifi, and twisted-pair when hubs are used instead of switches) 10 megabit and 100 megabit ethernet use one pair for sending and the other for receiving, although recent hardware can swap those round, removing the need for cross-over cables, and probably complicating setup of a unidirectional connection.
    – Jasen
    Commented Dec 18, 2016 at 23:22

Couple of ideas:

  • What about something like the Electric Imp?


It seems to use a small opto diode to communicate.

  • Or what about this Javascript library that uses ultrasonic sounds emanating from your speaker. Just put a mic but no speaker on the receiving machine?


  • Here's a live implimentation of the off-channel way to unidirectionally communicate:


Apparantly the Google chromecast uses some of this. So that might be a fruitful codestack to browse. Though not for security applications but still might be relevant.

  • Check out the technology behind Yamaha's Infosound platform. This too seems unidirectional communication over a noisy channel:


Of course, finally it will all depend on what's the bandwidth you need?

  • I think you meant "put a speaker but no mic on the sending machine". The receiving machine will always have a way to produce sound. This is also far slower than a UART.
    – Ben Voigt
    Commented Dec 19, 2016 at 15:41
  • There's no reason to actually use a speaker and mic. The audio out port sends analog signal that can be connected to audio in of another machine directly. Also, using a speaker to play ultrasonic sound can potentially annoy a dog.
    – Lie Ryan
    Commented Dec 19, 2016 at 16:48
  • @LieRyan "potentially annoy a dog" Bug or feature?! :) Commented Dec 19, 2016 at 17:01

Any protocols that requires guaranteed delivery requires two-way communication.

A unidirectional communication channel have to either:

  1. sacrifice reliable delivery, or
  2. have a return path, to return ACKnowledgements.

A simple implementation of unidirectional delivery can be done with the 3.5mm audio jack. Using a software modulator, you convert octet data to a sound file and play the sound over an audio out port. You'd connect this audio out port using a male-to-male TRS audio jack to another computer's audio in. On the other machine, you use a software demodulator to interpret the sound back to octet data. At this point, you have a basic software modem.

If you don't need reliable delivery, this is sufficient.

If you want reliable delivery, you'll need to add a return path to transmit delivery receipts (ACKs) in a simple TCP-like stack. The sender should send the data packet and then wait for an ACK before sending the next packet of data, if no such ACK is received after a predetermined amount of time, the sender should resend the data. The return path can be a simple beep on another audio line.

If you don't need high throughput, this is sufficient.

If you want high throughput, you'll need to add a transmit window. At this point, you'll probably want to look at modifying a software implementation of a TCP stack.

  • 1
    There are ways of mitigating errors without feedback, see the entire field of electrical engineering called "Forward Error Correction". You're right that this is still not a guarantee of delivery... but feedback can't guarantee delivery within any finite time period either, it just lets you know about errors.
    – Ben Voigt
    Commented Dec 19, 2016 at 16:39
  • @BenVoigt: Forward error correction can resolve transmission errors (flipped bits), however it cannot resolve the situation where the cable(s) are temporarily disconnected. A feedback mechanism is necessary to self-resolve a temporary disconnection. But yes I agree that nothing can guarantee delivery when the cables are permanently disconnected. I agree though, that FEC is useful, they should be done in the modulation/demodulation step in my answer.
    – Lie Ryan
    Commented Dec 19, 2016 at 17:03

If your development (or production) network is truly air-gapped then an option is to have a sacrificial PC on the Internet that can be used to communicate with your hosting service.

You could use sneakernet to move files that need uploading, then SSH into your host using FileZilla or equivalent.

The sacrificial PC should be imaged before connection to the Internet (using Macrium or Acronis or equivalent) so you can always revert it to a known, good state.

There are stories of computers that get probed and/or hacked within minutes of being connected to the Internet, so a decent NAT router for it will at least give you one stage of protection. Be sure to disable uPnP, of course.

If you are truly paranoid, you could restore that PC's known, good image, every time you move files to it. Some malware can travel back inside via USB memory, and if that PC gets compromised you might infect the disconnected network.

One maxim is that the tallest trees are cut first for their lumber. So if you are a high-value target with a sophisticated attacker, you can be pwned.

All that being said, email to the outside is probably your biggest exposure, because your PCs literally invite that content inside. It is still unidirectional in the sense that your computers initiate the contact with the mail server. So it can keep worms out but not spear phishing attacks.

-- EDIT: @Gilsham suggests using a LiveCD to do the transfers. That is a great idea.

When I was using Kali Sana (based on Debian) it allowed a LiveCD in "persistent" mode, so you could use that to store the file on the CD and then boot it up on the sacrificial PC, do the upload, then destroy the CD.

If not using persistent mode, use just any LiveCD (read-only), then have the file(s) mounted on another CD-ROM.

That would truly be unidirectional.

  • 2
    You said "NAT router", but I think you mean "firewall". These are not quite exactly the same thing. Commented Dec 19, 2016 at 1:46
  • True enough. The prices are not quite exactly the same, either. Last time I bought a real firewall it was the Checkpoint Firewall-1 and was more than $20K. NAT routers are not the same, true, but much more cost effective for a sacrificial computer. I would probably be on the paranoid side and restore the known good image before using the computer each time, anyway. Or leave it shut off between uses.
    – SDsolar
    Commented Dec 19, 2016 at 5:00
  • 1
    Why not both using a live CD?
    – Gilsham
    Commented Dec 19, 2016 at 19:31
  • That's the best idea yet, @Gilsham. If you flesh that out as a full answer I will revert my edit (and delete this comment) and upvote you. You deserve it.
    – SDsolar
    Commented Dec 19, 2016 at 23:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .