Skip to content

Security Model and Hardening

Jump to bottom
bmwl edited this page Nov 20, 2025 · 1 revision

Security Model and Hardening

This page details the security model and hardening procedures for the Soft Data Diode Tools. For basic setup, see the main README.

Security Model

This system differs from a pure hardware Data Diode in that all parts of the system are implemented in software in order to achieve the same goal at zero cost. This means that there is no physical "air gap" like a true unidirectional diode/opto-isolator would provide. Certified Hardware Data Diodes are expensive for a reason! The tradeoff is that the savings come with a need to vet the configuration in order to guarantee correctness. A defence-in-depth approach is discussed below in the Security Considerations and Hardening sections.

The security model relies on:

  • Application-level unidirectionality (sender never binds to listening ports)
  • Network-level blocking (firewall rules and ACLs prevent return traffic)
  • Infrastructure-level detection (logging and alerting on suspicious attempts)

If you are looking for an actual hardware data-diode, there are inexpensive ways to get there:

Any of these projects can be used in conjunction with the tools in this repo to create a true physical unidirectionality interlock.

Security Considerations

Due to the way that modern, stateful firewalls work, there is the possibility that an attacker that has taken control of the "Cloud Server" could abuse incoming UDP connections to send traffic back into the secure network. This is further compounded by the fact that the Internet, as it was designed, will attempt to route around blocks in order to deliver traffic.

This system is designed to be reasonably secure by default, but you should know your risk profile and manage it appropriately. This can be a major rabbit hole if you decide to be "as secure as possible".

There are a number of mitigations possible:

  • Firewalls that support SNAT may be configured with a return address of something like 192.0.2.x (often used as a blackhole address) or an unused internal address as a canary
  • Switch ACLs to prevent these specific return UDP traffic flows may be created at a choke point
  • OS level firewalls may be used to attempt to block specific types of traffic. Linux iptables is flexible enough to do exactly what we want (statefully deny return traffic)
  • Use a packet forwarder that mangles the packets and breaks return state

These mitigations can generally "stack", allowing a defence in depth approach that approaches a guarantee of security.

You might think that block rules on your hardware firewall preventing return traffic would be a possible mitigation, but contrary to intuition these will generally not work. The packet will be part of an established flow and hit the fast-path before any rules are evaluated. YMMV with your specific firewall platform, but be prepared for disappointment.

All this said, if the sender is behind a NATting firewall then it is highly unlikely that the receiver would be practically able to send a packet back on a different port. The firewall would have chosen a random port to forward the traffic from, and if the receiver doesn't send the return packets to the same port, then it would be dropped. If the receiver does send packets back to that same randomized port, then it is mapped back to the original port, where there is nothing listening if implemented as per this guide.

If the sender and receiver have a firewall between them but no form of NAT (ie. sender and receiver can route to each other with no address translation), then suddenly an attacker can choose arbitrary ports, and your job gets somewhat harder. This is also true of some kinds of NAT that map a host in a more sophisticated way, like symmetrical NAT or various cone NATs. STUN/TURN/ICE/NAT-PMP/PCP/UPnP or other dynamic NAT translation helper protocols or programs being in play may also make the situation more complex and require careful consideration. If the host is specified as the "DMZ" host, then it probably has only light protection and should be treated as fully exposed.

If there can be no hardware firewall in place at all or it is running in Layer 2 "bump-in-wire" mode, you can either try to use the iptables rule in the mitigations section to block at the OS level or risk-manage. Really, at that point you will not be able to build a data-diode in any real sense and have probably chosen the wrong tool.

Any return traffic attempting to reach the sender from the receiver is provably malicious and will be blocked by network controls. This creates clear security events that can be monitored and investigated.

Hardening

Since this process relies on the behaviour of many systems between the sender and receiver, it is recommended that the path be hardened at as many points as possible. The below list includes both general techniques and ideas, but also specific implementation information.

Hardware Firewall

Source-NAT rules

SNAT is a common firewall feature that lets you control the return path of packets for a number of well-known scenarios, but we can exploit it for our uncommon purposes. Basically the sender's packets leave the firewall with a dummy source IP, which is the IP that a compromised cloud server would try to respond to. As long as this can be configured to a non-functional or blackhole style address (192.0.2.0/24 is traditional), then the return path will be fundamentally broken outside the network's perimiter. Substitute in a valid-but-unused address, and you have created a tripwire you can monitor and alert on.

Next-Gen Firewall protocol inspection

If all else fails, your NGFW will hopefully notice that the return packets are malformed and will log, block and drop malicious packets. Best not to rely on this, as attackers could be using valid protocol streams. Still, any extra protection that you can turn on in your firewall will make it that much harder to exploit.

Source/destination/protocol/port rules

This is usually a dead end. Modern firewalls are stateful, and are architected in a way that will actively fight with attempts to block established sessions using traditional firewall rules. Its safe to assume most will be impossible to harden in this way.

Network Switches

Access Control Lists

Switch ACLs that operate at Layer 3 should be able to block arbitrary traffic, with no relation to established sessions or flows.

Reference your switch vendors documentation for specific configuration procedures.

Software, OS or XDR agent Firewalls

Linux iptables/nftables

iptables can be set up in exactly the way we want:

Optionally start by logging blocks. This is a valuable signal as this traffic should never happen outside of testing (needs to be first or the packet will be dropped before being logged):

iptables -A INPUT -p udp -s 1.2.3.4 --sport 5005:5020 -m state --state ESTABLISHED,RELATED -j LOG --log-prefix "BACKPROPAGATION DROP: " --log-level 7

Then create the actual rule:

iptables -A INPUT -p udp -s 1.2.3.4 --sport 5005:5020 -m state --state ESTABLISHED,RELATED -j DROP

This will track the session state for the outgoing packets to your cloud server (1.2.3.4) and drop anything returning from this session on the ports that the senders are using (between 5005 and 5020 in this example). Perfect!

Now that you have a tight rule to just catch the specfic traffic you're looking for, you can use a test script from the mitigations section below and watch the iptables counters with iptables -v -n -L. The counters should go up on the rule you specified if they're being caught. You can sanity check this with tcpdump or wireshark to see if anything from the receiver is being seen on the sender side. As a side-note: tcpdump/libpcap sees packets before they hit the iptables firewall, so you may see the traffic even if its getting dropped, which is why looking at packet-counts for your rules is important.

In addition, we can probably just drop all traffic returning from the cloud server in a final catchall rule:

iptables -A INPUT --source 1.2.3.4 -j LOG --log-prefix "BACKPROPAGATION DROP: " --log-level 7
iptables -A INPUT --source 1.2.3.4 -j DROP

Linux eBPF modules

You can use a packet forwarder to limit the service's ablity to talk to the general network, as well as mangle the packet in a way that breaks network state, making return traffic impossible.

Others

Windows (and other host/agent firewalls) may be able to do something similar by positioning the return block rule at the top of the ruleset, but this requires further investigation. These will need to be verified and documented system-by-system.

Cloud Server Hardening

Be sure to harden your cloud server as much as possible!

While we have been concentrating on ways in which we can prevent lateral movement, an attacker that gained access to the cloud server could also do nasty things like serve malware to users of the cloud server, use it as part of a botnet, use it as a spam host, mine crypto and many other things that you would not want to happen.

Security Monitoring

Monitor for these log signatures indicating potential compromise attempts:

  • SUSPICIOUS RETURN TRAFFIC in system logs
  • Blocked UDP packets from cloud server IPs
  • Unexpected ICMP responses to sender

These events should trigger security alerts as they represent clear attack attempts.

Next Steps

Clone this wiki locally