Man-in-the-Middle Port Protection

I'm wondering if this idea could work as a generic solution to the "OMG, the printer's been hacked' problem".

There are a very large classes of important legacy IP devices that can be easily compromised and either used as "zombies" in a bot-net, as relay devices or like Infrastructure controllers, be high-value targets for disruptive hackers.

What they share in common is:

• their software can't be fixed or upgraded to current "hardness" levels and/or support current security protocols, like 802.1x, and
• full replacement, or "fork-lift upgrade", is deemed unwarranted or infeasible.

The "Man-in-the Middle" (MitM) single ethernet port protection solution comes in two parts:

• a dongle or wall-wart to connect in front of the printer, perhaps with Power-over-Ethernet (PoE) and
• a central server/filter/firewall that the dongle(s) connect back to.

The dongle needs two ethernet connections and the software has to learn two things:

• up-stream/down-stream traffic flows, which side is the printer, which is the network, and
• the IP number + MAC address of the device.

It's job is to transparently take over the IP number and MAC address of the printer.

First it must gain itself a second IP number for its work and authenticate itself to the network if 802.1x is in use.

Having done that, it establishes a secure tunnel, via SSL or SSH, back to the central security device where the real security measures are taken.
The central security device can be implemented as a cloud of local devices, centrally managed.

The device can be mimiced either locally or centrally, depending on network configuration, latency and traffic volume concerns and devices available. Note that the protected device is behind a dongle, it will never be seen 'bare' on the network again, so conflicts will not arise. To the printer or device-under-control, no change in the network or environment will be discernible. To all other devices on the network, the printer or device-under-control will appear to have had a firmware upgrade, but otherwise be identical.

First option is for all network traffic destined for the printer has to be shunted back to the central secure device, modulo trivial ipfilter rules. This includes preventing any unauthorised outbound traffic, or even directing all outbound packets for analysis through the central security device for Intrusion Detection analysis.

Once the traffic is back at the central secure device, it can be properly inspected and cleaned, then turned around on the same SSL/SSH tunnel.

Second option, the central secure device assumes both IP number and MAC address of the device-under-control by advertising it's IP and the same MAC addrs. It can also provide 802.1x-client facilities.

The central secure device then forwards only valid traffic to the dongle at the printer over SSL/SSH, and response traffic is tunnelled back and inspected over the same path.

The difference is where the impersonated IP number/MAC address now appears in the network:

• either exactly where it always has been, or
• in a central location.

A 2-port version of the Raspberry Pi would be able to do this, plus some tinkering in a firewall appliance.

If very short UTP leads are used on the MitM dongle, it will be very difficult to remove from the printer or device under control.

The Use Case is simple:

• get new secure server
• install 802.1x certificates for printers/devices-under-control in the secure server
• install 802.1x certs in dongles, setup in DHCP, don't have to be static IP numbers.
• egister SSH or SSL keys of dongle to secure server
• check locally the dongle works and correctly controls a test device
• go to printer, install dongle, check it works. Requires normal traffic and a scan for vulnerabilities.
• there might be a some outage as the double shuffle happens, the MAC address may now appears elsewhere in the network
• not sure how real-time swap might affects existing IP connections. If the disruption in traffic flow is under the TCP disconnect window, it won't be noticed. It's not an option to leave existing connections uninspected, they could Botnet control channel.

Do these things already exist? I don't know..
I can't believe something this simple hasn't already been built.

There are 2½ variants that might also be interesting.
For variant #2, I'm not sure what can already be done in switch software.

1. Plug 2-port MitM dongle directly into switch, capture all packets at the switch, not at the printer.

1A. Plug a multi-port MitM dongle into switch so that it acts like a switch itself, having one up-stream link via the switch, and provides multiple ports for controlled devices to be connected to. Needs the host switch to allow multiple MAC's per port.

Problem with remote dongle:

Printer/device-under-control can be relocated (physically or connection) and lose protection/filtering.

2. High-end Switches have "Port mirroring" software, can that be used or modified for the MitM packet redirection?

• Port-mirroring sends a copies of ingress and egress packets to another port, even on another switch.
• The remote Filter/firewall (FF) needs two ports, A & B, one ingress, one egress..
• Network egress traffic is redirected to Port-A of the FF, even on another VLAN.
• Network Ingress traffic is instead received from Port-A of the FF.
• Port-B traffic of the FF is sent back as egress traffic of the controlled port, and
• ingress traffic of the controlled port is sent to Port-B traffic of the FF.
• This achieves logically what the physical dongle+physical patch leads achieved, passing all traffic via an MitM Filter/Firewall.

2A. Multi-port filter/firewall.

• Can switch software multiplex multiple MAC addresses onto two ports, serving multiple devices under control with the same 2-port hardware, or
• does it need a pair of ports on the filter/firewall for each device under control, or
• 1 upstream link to capture all redirected traffic, and 1 ethernet port for each device under control.