One-Way Ethernet Cable and Data Transfer

Introduction

Sometimes you want to enforce a one-way data flow between computers on a hardware level.

While it is possible to configure one-way traffic in software, for example by using a firewall, there are various reasons why this solution might be impractical or not secure enough:

• You might not have access to network configuration on the host

• Firewall rules could be forgotten or defined incorrectly

• There could be a delay until firewall rules are loaded or reloaded, allowing traffic in both directions

• An authorized user or malware could force connecting in the opposite direction, for example by disabling the firewall

• Machines could still communicate 2-way on a level that wasn’t prevented by the firewall or that was below user’s direct awareness (e.g. ARP, DHCP, etc.)

One-way traffic implemented at the hardware level is the only guarantee that the data will indeed flow in one direction only.

Typical use cases for such hardware-level protection would include:

• Setting up a transparent network sniffer/monitor. The switch would be configured to replicate traffic to the device’s port, and the device would be connected using a one-way network cable to ensure undetectable and non-interfering operation

• Setting up a secure system for generating PKI keys and similar, where the master keys and code would be kept on a host that is unreachable from the outside, but is able to send generated keys, public keys, and challenges to clients. If needed, there could be two one-way links, one for commands to the secure device, and one for data sent from the secure device to clients

Well, it turns out that it is possible to convert an ethernet (LAN) cable into a physical 100 Mbps, half-duplex, one-way link simply by changing how the pins are connected. Then, it is possible to establish standard, high-level data flow over such a cable using the UDP protocol. This avoids the need for a custom solution and allows one to still use standard network protocols and commands, which is an appreciable, if not crucial, benefit.

Ethernet (LAN) Cable Basics

Ethernet cables are used to connect either two computers directly or to a network switch, so that they can all communicate as a larger group.

Most common ethernet speeds are 10Mbps, 100Mbps, 1Gbps, 2.5Gbps, 10Gbps, and 40Gbps. That’s “bits per second”, meaning you should divide by 8 to get approximate speeds in bytes per second. A 1Gbps network is thus theoretically able of transferring 125 megabytes per second.

To very roughly estimate the practical maximum data transfer rate over a link, you can then further subtract 10% on the account of TCP/IP overhead and general inefficiencies. As mentioned, we will be using UDP and not TCP, but it is still a good reference.

Ethernet cables consist of 8 wires, divided into 4 pairs of 2, some of which may be unused – it all depends on the standard used and speed negotiated on the connection.

Each pair contains two wires twisted around each other, with one wire of solid color (a “ring” wire) and one white wire with stripes of the same color (a “tip” wire). (The terms “ring” and “tip” are legacy, referring to the tip of the old 1/4" telephone plug and the ring around the shaft that makes the connections.)

Most network cards today can autodetect whether a cable is connecting one network card to another card or to a network switch, and work correctly in both cases. However, strictly speaking, when connecting two computers directly, the send and receive pins on one side of the cable need to be crossed-over, i.e. connected in the opposite order. That type of cable, specifically intended for direct connections, is called a crossover cable and must be used when either side does not support autodetection.

Cable wires are color-coded for easier identification, but there is nothing special about the color — the normal, non-crossover order is to connect the wires in the same order on both ends (1-1, 2-2, …, 8-8), and as long as they are connected that way, the cable will work.

However, two standards named T568A and T568B define the default ordering of colors in 8-wire cables.

Hardware Setup

Standard Pinout

Let’s review the details of standard cable wiring, provided in the table below (the same can also be seen on the mentioned T568A and T568B page).

Notice that the pairs are not simply arranged in order 1, 2, 3, 4, but are untwisted at the connector and connected in a slightly different way. Also notice that for 10 and 100Mbps links only 4 out of 8 wires are used, the other half are marked “unused”.

Creating a One-way Cable

To create a one-way, 100Mbps cable, we need to take a straight (not crossover) network cable and cut and reconnect two pins.

The setup is actually pretty straightforward:

The Sending Side

The sending side is always only sending data. In the use cases suggested above that is either a secure computer, or a switch (if the setup is for a sniffer device).

For wiring, we are not affected by T568 standard and/or color-coding; we are only interested in wire numbers, which are always the same.

Reconnect the wires as follows:

• Connect wire 1 to wire 3. Just for reference, in T568A that would be connecting white/orange to white/green, or in T568B connecting white/green to white/orange

• Connect wire 2 to wire 6. Just for reference, in T568A that would be connecting orange to green, or in T568B connecting green to orange

For best performance, make the connection as close as possible to the connector itself (the RJ45 jack). Here is an illustration:

The Receiving Side

The receiving side is always only receiving data. In the use cases suggested above that is either a client computer, or a sniffer device connected to a switch.

On the receiving side reconnect the wires as follows:

• The wires 1 and 2 will have no purpose since they have been cut on the sender side. Just leave them as-is or cut them off

For best performance, i.e. to minimize the risk of wire crosstalk and consequently packet loss, it is advised to cut them off and remove the whole twisted pair out of the cable

Connecting a One-way Cable

As mentioned, the end of the cable with all 8 pins/wires should go to the side that needs to send data. The sending side needs all wires. That is the secure computer or a switch.

The other end of the cable with 6 connected pins should go to the side that needs to receive data. The receiving side only needs the incoming wires. That is the client computer or a sniffer device.

Software Setup

Data Channel

Since we have a one-way physical link, using TCP/IP is not possible because it requires a handshake and traffic in both direction to establish a connection and acknowledge packets. However, it is possible to use UDP/IP which does not use handshaking nor packet acknowledgment.

The tool we will use to establish the data channel will be a variant of netcat, a venerable Unix utility that was first released in 1995 and has been often described as a networking “Swiss army knife”.

Data Format

Netcat will give us a data channel for sending bytes from one side to the other. That could be satisfactory if the data is an endless stream, but usually we also want to apply some higher-level logic and protocol.

So what we will do is show how to use an application for transfer of files.

For that we will, of course, use tar (tape archiver), which will enable us to transfer files in a very robust and configurable way.

Thanks to tar, we will be able to transfer files and metadata, as well as use any other, accompanying features of tar if needed.

Server side

When speaking of software, the “server” and “client” side are the opposite of hardware. The server side is actually the receiving one. It is called the “server” side because that is where the service listening for data will be running, and to which data will be sent to. In other words, the hardware client is the software server and vice-versa.

Server with Ncat

The first variant of netcat that we will show will be ncat, which itself has often been described as the “Netcat for the 21st century”.

On the client computer, run the server:

ncat -lvnuk --recv-only -c 'tar xf -' 8000

The above command will start ncat listening in UDP mode on port 8000, and will, for every new connection, pipe its input into a new process tar xf -.

Starting a new process for every connection may also be specifically desirable, to auto-recover from errors in data.

Since ncat option -k is used, ncat will keep listening for incoming connections, rather than terminate after the first connection ends.

With ncat option -m, which is not used in the example, it would be possible to limit the maximum number of concurrent connections, e.g. to a value of 1.

With the default options as shown, any duplicate filenames will overwrite previous ones. The overwriting can be disabled with tar option -k (keep). (Note that this is about option tar -k, not ncat -k.)

Note that ncat will start the subprocess tar with its stdout connected to the remote end, so it is not possible to use tar option -v to conveniently print the filenames being extracted to the screen.

Server with Socat

The second variant we will show will be socat, which is a further extension of the original idea of netcat.

On the client computer, run the server:

socat -u udp-listen:8000,fork STDOUT | tar ivxf -

Note that with the above command, there will only be one tar process started, and all clients will be sending their data into it. Tar will be running in “continuous” mode and there will be no new process started for every connection.

That may be more efficient, but it also makes it harder to recover from errors in tar data. If invalid input is sent, tar appears unable to continue processing later valid data even if it is started with options such as -B or -M.

In this case it is possible to use tar option -v, to see filenames of extracted files printed to the screen.

Client side

The software client side is the hardware server side, that is, the software client is either the secure computer or a network switch.

Client with Ncat

Run the following command:

tar cf - FILES* | ncat -nu --send-only SERVER_IP_ADDRESS 8000

The above command will pack FILES* into a tar archive and print it to stdout, which is then passed using ncat in client mode to the remote side.

Client with Socat

Same as with the server side, instead of ncat we can also use socat. Both methods are compatible, and we can mix socat and ncat on both server and client side.

tar cf - FILES* | socat STDIN UDP:SERVER_IP_ADDRESS:8000

The effect of this command would be the same as above, just using socat.

Example

Here is an example of a complete session in which a file with content “This is a test.” is transferred from the secure server to client over a one-way ethernet link:

On the hardware client which will receive data (that is, on the software server), run:

cd /tmp
mkdir SERVER
cd SERVER
ncat -lvnuk --recv-only -c 'tar xf -' 8000

On the hardware server which will send data (that is, on the software client), run:

cd /tmp
mkdir CLIENT
cd CLIENT
echo 'This is a test.' > myfile
tar cf - myfile | ncat -nu --send-only 192.168.7.14 8000

After the transfer, on the client computer we can test for presence and content of myfile:

cd /tmp/SERVER
cat myfile

This is a test.

Note that we are using tar and are not limited to sending one file at a time; that was just an example. You can freely specify multiple files, shell globs, etc.

Additional Options

Ncat supports various additional options. They are best summarized in Netcat’s quick help:

$ ncat -h
Ncat 7.70 ( https://nmap.org/ncat )
Usage: ncat [options] [hostname] [port]

Options taking a time assume seconds. Append 'ms' for milliseconds,
's' for seconds, 'm' for minutes, or 'h' for hours (e.g. 500ms).
  -4                         Use IPv4 only
  -6                         Use IPv6 only
  -U, --unixsock             Use Unix domain sockets only
  -C, --crlf                 Use CRLF for EOL sequence
  -c, --sh-exec <command>    Executes the given command via /bin/sh
  -e, --exec <command>       Executes the given command
      --lua-exec <filename>  Executes the given Lua script
  -g hop1[,hop2,...]         Loose source routing hop points (8 max)
  -G <n>                     Loose source routing hop pointer (4, 8, 12, ...)
  -m, --max-conns <n>        Maximum <n> simultaneous connections
  -h, --help                 Display this help screen
  -d, --delay <time>         Wait between read/writes
  -o, --output <filename>    Dump session data to a file
  -x, --hex-dump <filename>  Dump session data as hex to a file
  -i, --idle-timeout <time>  Idle read/write timeout
  -p, --source-port port     Specify source port to use
  -s, --source addr          Specify source address to use (doesn't affect -l)
  -l, --listen               Bind and listen for incoming connections
  -k, --keep-open            Accept multiple connections in listen mode
  -n, --nodns                Do not resolve hostnames via DNS
  -t, --telnet               Answer Telnet negotiations
  -u, --udp                  Use UDP instead of default TCP
      --sctp                 Use SCTP instead of default TCP
  -v, --verbose              Set verbosity level (can be used several times)
  -w, --wait <time>          Connect timeout
  -z                         Zero-I/O mode, report connection status only
      --append-output        Append rather than clobber specified output files
      --send-only            Only send data, ignoring received; quit on EOF
      --recv-only            Only receive data, never send anything
      --allow                Allow only given hosts to connect to Ncat
      --allowfile            A file of hosts allowed to connect to Ncat
      --deny                 Deny given hosts from connecting to Ncat
      --denyfile             A file of hosts denied from connecting to Ncat
      --broker               Enable Ncat's connection brokering mode
      --chat                 Start a simple Ncat chat server
      --proxy <addr[:port]>  Specify address of host to proxy through
      --proxy-type <type>    Specify proxy type ("http" or "socks4" or "socks5")
      --proxy-auth <auth>    Authenticate with HTTP or SOCKS proxy server
      --ssl                  Connect or listen with SSL
      --ssl-cert             Specify SSL certificate file (PEM) for listening
      --ssl-key              Specify SSL private key (PEM) for listening
      --ssl-verify           Verify trust and domain name of certificates
      --ssl-trustfile        PEM file containing trusted SSL certificates
      --ssl-ciphers          Cipherlist containing SSL ciphers to use
      --ssl-alpn             ALPN protocol list to use.
      --version              Display Ncat's version information and exit

See the ncat(1) manpage for full options, descriptions and usage examples

Links

• https://en.wikipedia.org/wiki/Ethernet

• https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair

• https://en.wikipedia.org/wiki/Ethernet_physical_layer

• https://web.archive.org/web/20050221103207/http://www.robertgraham.com:80/pubs/sniffing-faq.html

• https://www.sentinelsecurity.com.au/whitepapers/onewaycable.pdf