Press "Enter" to skip to content

Building a network tap using off the shelf equipment (transparent Linux bridge) [closed]

        <strong>TL;DR</strong>: The goal is to build a <strong>network tap</strong> using a <strong>Linux bridge</strong>, that can be used to sniff traffic off the wire, and build a device that could also be used for red team engagements.

I am currently using a "router" PC with four ethernet ports like pictured below but the actual hardware is unimportant. I intend to replicate my setup on other hardware with dual (Gigabit) ethernet - think single board computers like Orange Pi etc. Current setup:
Port Interface MAC
LAN1 enp3s0 00:90:27:b4:40:58
LAN2 enp4s0 00:90:27:b4:40:59
LAN3 enp6s0 00:90:27:b4:40:5a
LAN4 enp7s0 00:90:27:b4:40:5b
Router computer In this example enp3s0 is the management interface for SSH etc, enp6s0 & enp7s0 are the bridged interfaces. The OS is Debian 11 (bullseye) with Network Manager. I created the bridge using nmcli like this:
# create bridge
nmcli connection add type bridge ifname br0 con-name br0  bridge.stp no ipv4.method disabled ipv6.method disabled autoconnect no

# allow all kinds of traffic
nmcli connection modify br0 65528

# add slave interfaces
nmcli connection add type ethernet ifname enp6s0 con-name br0-enp6s0 master br0
nmcli connection add type ethernet ifname enp7s0 con-name br0-enp7s0 master br0

# start the bridge
nmcli con up br0
Then I just use: tcpdump -n -i br0, or tshark on the device itself to sniff traffic right away. Network Manager is for convenience reasons too, because at some point I may want to drop the bridge, and reassign the interfaces for another purpose. I can also run pre-up scripts in /etc/NetworkManager/dispatcher.d/pre-up.d/ if necessary. Since I have a pure layer 2 bridge with no IP addresses, I expect it to be "nearly" silent. By tweaking the value of group_fwd_mask I am also making sure to relay types of traffic that are not carried by the Linux bridge by default, like CDP or EAP (Source). However I am aware that the bridge could still generate some traffic either by itself or by responding to queries, for instance ARP traffic. Indeed, when I start the bridge it emits some IGMPv3 packets as shown below (36:04:5f:8d:ac:55 is the MAC address automatically assigned to the bridge): Wireshark Therefore my question is: how can I make the bridge completely silent and passive, and achieve total isolation of the bridge from the other interfaces present on the device. To put it differently, a real network tap should not inject any frames of its own. I understand there are many options but I am not sure which one(s) to use. Some of the ideas I had in mind:
  • Use VLANs for the bridge interfaces but I guess this is not going to help when the bridged interfaces are themselves generating unwanted traffic
  • Running Network Manager in another namespace
  • Use tc or nftables to drop unwanted frames entering the bridge based on the MAC address
A project that is somewhat similar to what I am doing is phantap. But it is more of a man in the middle tool that works by cloning the IP address of the “victim”. Also, phantap is tailored for OpenWRT and I am using regular Systemd distros such as Debian instead. I have looked at phantap and it does at least two things possibly relevant in terms of isolation:
  • it uses nftables (source)
  • it use the following pre-up script for the bridge (source):

if [ "$ACTION" = add -a "$DEVICENAME" == "$BRIDGE" ]; then
    echo "phantap: Configuring bridge $BRIDGE (hotplug)..." > /dev/kmsg
    echo 65528 > /sys/class/net/$BRIDGE/bridge/group_fwd_mask
    ip link set dev $BRIDGE arp off multicast off allmulticast off
    echo "phantap: Bridge $BRIDGE configured (hotplug)" > /dev/kmsg


  • Does the ip link set dev $BRIDGE arp off multicast off allmulticast off statement above suffice to effectively "mute" the bridge?
  • Should the same be done on the slave interfaces as well?
  • Would it make sense to add more filtering rules, for example using tc or nftables?
  • What about the ip link isolated option?
  • Are there any useful options I have overlooked like the bridge.vlan-filtering option?
  • Is a bridge even the best way to go here? Could other interface types like macvlan achieve the intended purpose?

Additional references & related questions

Be First to Comment

Leave a Reply

%d bloggers like this: