Network Slug
A Network Slug, or "Slug", is a transparent layer 2 firewall running on a device with only two interfaces.
This firewall is intended to be invisible and not participate on the local IP network.So, while the device participates on the physical layer of the (probably ethernet) network, it does not have an IP address and cannot answer IP (or even ICMP) requests. Clients on the local network may be able to see the slug and it's physical (probably MAC) address. It would be very difficult, perhaps impossible, for clients outside the local network to detect the slug.
The slug optimizes for simplicity. We want to minimize the capacity for misconfiguration, unintended side channels and data leaks. For this reason, a slug is defined as a device with two, and only two physical interfaces. The slug must only act as a bridge.
Some examples of such a device:
Netgate SG-1000 PCEngines ALIX 6
Of course any general purpose computer with two and only two physical network interfaces will work.
The purpose of a Slug is to reinforce a security policy or to block uninentional leaks of information.
For instance: misconfigured VPN software on a client may send some traffic, inadvertantly, outside the VPN.
In this scenario, a Slug that only allowed traffic to the VPN endpoint makes these misconfigurations much less dangerous.
VPN software - especially VPN "tools" and "utilities" that are run and configured in userspace - can leak information about your real location and network addresses.This can be due to a misconfiguration, a software bug, or even something simple like the VPN tool crashing or failing to load. In many cases, your system continues to function on the network without any indication that your traffic is no longer on the VPN.
Of course there are many ways to mitigate these risks but those could fail (or be misconfigured) as well. If we follow this line of reasoning we see that even a standalone firewall is vulnerable to attack and misconfiguration - it participates on the network, is reachable by attackers and most likely runs some number of services. These are all points of failure that make it impossible to be sure - really, truly sure that your traffic is going to only your intended destination.
A slug addresses these concerns: it is an invisible chokepoint on the network that is hardcoded to either the VPN endpoint IP address or the VPN software TCP/UDP port or both. There are no options to configure once the device is deployed and the failure mode (the slug OS crashing) simply blocks ALL traffic.
A Slug has no IP address, cannot be reached on the network, and does not increment IP TTL.
I believe that it is impossible for hosts outside the local network to definitively detect a layer 2 device like this.A Slug has a simple ruleset that is enforced by default at startup time and should have no network services running.Because the device has no IP addresses configured, it should be safe to disable arp for the two interfaces.
Because the device is positioned as a chokepoint on the network, local Ethernet MAC spoofing (and related attacks) are not useful.
I use a collection of VPN endpoints that all answer on TCP port 50. Therefore, a useful slug for my use-case would be a "port 50 slug" that blocks all traffic except for TCP port 50.Peers on the network would not notice this device and attackers would find it difficult to subvert the rules that the slug enforces.This is less specific (and less secure) than a slug that defined both the VPN endpoint and the port. An improved configuration for me would be to block all traffic except for TCP port 50 to these X IP addresses.
[ tip ] [ wiki ] [ discussion ] [ changelog ] [ todo ]