Creating a multiport man-in-the-middle network tap

November 21, 2016

The problem

During red teaming, once physical access has been obtained a typical next step is to connect to the internal network. While many tools (such as cobalt strike) provide excellent logging functionality, other tools are somewhat lacking. A solution to this problem is to locally log all network traffic thereby providing a complete overview of all actions performed on the network.

However, there are some potential issues with this approach:

  • Each time a new connection is established this manual log needs to be initiated
  • The virtual machine needs to be capable of performing said logging (memory, processing power, etc)
  • Each member of the testing team needs to consolidate their network logs daily
  • … it’s annoying

A solution for these issues is to create a separate man-in-the-middle network device which acts as an intermediary logger between testing clients and the network.

Finding appropriate hardware

The most appropriate device is the Banana Pi R1 (BPI-R1) which has a number of hardware features, however the most interesting for our scenario are the 4x Gigabit LAN and 1x Gigabit WAN ports on the board. Additionally, this device can run Debian and it completely configurable.

Plan of attack

All network interfaces on the BPI-R1 belong to the same physical interface (eth0), while configuration and separation is performed via VLAN tagging. During this post we will create a multiport network tap with the following functionality:

  • Constructs a transparent bridge between a maximum of 3 devices and the internal client network (rather than the hassle of NAT and firewalls)
  • Logs all traffic passed between this bridge to an external encrypted USB drive
  • Facilitates a management interface for ease of use, safer unmounts and debugging

Preparing the operating system

The first step is to download the Bananian distribution and install the operating system to an SD card:

dd bs=4M if=bananian-1604.img of=/dev/sda1

Once installed, insert the SD card into the BPI-R1 and initiate the configuration process. The initial login can be performed using the default root user with the password of pi. Next update the system and install the required utilities:

bananian-config
apt-get update
apt-get upgrade
apt-get install tcpdump bridge-utils isc-dhcp-server cryptsetup

Configuring the switch

Once the operating system is installed we can configure the switch. The physical sockets on the device are ordered as follows:

LAN        WAN
2 1 0 4    3

We will be using the following configurations for these ports:

  • Port 2 (VLAN 103); device management interface
  • Ports 1, 0, 4 (VLAN 102); testing devices connecting to the internal client network
  • Port 3 (VLAN 101); direct connection to the internal client network

With ports 1, 0 and 4 being bridged to port 3 thereby giving each device connected to our tap a direct and transparent connection to the internal client network.

This configuration can be achieved using swconfig by modifying the /etc/network/if-pre-up.d/swconfig configuration file:

#!/bin/sh
#---------------------------#
# BPI-R1 VLAN configuration #
#---------------------------#
ifconfig eth0 up
swconfig dev eth0 set reset 1
swconfig dev eth0 set enable_vlan 1
swconfig dev eth0 vlan 101 set ports '3 8t'
swconfig dev eth0 vlan 102 set ports '4 0 1 8t'
swconfig dev eth0 vlan 103 set ports '2 8t'
swconfig dev eth0 set apply 1

Once the VLAN tags are configured, we can directly configure the network interfaces via /etc/network/interfaces:

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

# 101 – internal client network
auto eth0.101
iface eth0.101 inet manual
up ifconfig eth0.101 up

# 102 – red team devices
auto eth0.102
iface eth0.102 inet manual
up ifconfig eth0.102 up

# 103 – management network
auto lo eth0.103
iface eth0.103 inet static
address 192.168.10.1
netmask 255.255.255.0

# bridge between 101 and 102
auto br0
iface br0 inet manual
bridge_ports eth0.101 eth0.102

After rebooting the device, we can confirm the interfaces and bridges are configured and enabled via ifconfig and brctl show:

bridge name    bridge id            STP enabled    interfaces
br0            8000.03130740c28c    no             eth0.101
                                                   eth0.102

Configuring the management VLAN

For ease of configuration and to facilitate usage on a site without an HDMI monitor and USB keyboard, we can configure a DHCP server on the management interface. Update /etc/default/isc-dhcp-server with INTERFACES="eth0.103" and /etc/dhcp/dhcpd.conf with:

ddns-update-style none;
option domain-name "tap.local";
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;

subnet 192.168.10.0 netmask 255.255.255.0 {
    range 192.168.10.100 192.168.10.110;
    option subnet-mask 255.255.255.0;
    option broadcast-address 192.168.10.225;
    option routers 192.168.10.1;
}

Also set up SSH to listen on this interface via /etc/ssh/sshd_config:

ListenAddress 192.168.10.1

Configuring the logging device

While it is possible to store logs on the SD card itself, a more portable and reliable mechanism is to write to an external USB device. Due to the potential of storing sensitive client data, this USB device should be encrypted before writing data:

#!/bin/sh
# unmount and close if device already mounted and logging
killall -9 tcpdump 2>/dev/null
umount /root/tap-log 2>/dev/null
cryptsetup luksClose tap-log 2>/dev/null

# setup the device for writing
mkdir -p /root/tap-log
cryptsetup --verify-passphrase luksFormat /dev/sda1 -c aes -s 256 -h sha256
cryptsetup luksOpen /dev/sda1 tap-log
mkfs.ext4 /dev/mapper/tap-log
mount /dev/mapper/tap-log /root/tap-log

# log packets between bridge
tcpdump -i br0 -nn -w /root/tap-log/log-`date +'%s-%d-%m-%Y'` &

Conclusion

By following this guide, you will have configured your BPI-R1 to transparently bridge connections between the ‘external’ client network connection on port 3 and any testing devices connected to ports 0, 1 or 4. Networking traffic transferred via this bridge will be stored on an encrypted USB drive protected by a password. Additionally, the device will lease an IP address and is configurable via SSH on the management interface via port 2.

The postings on this site are my own and don't represent my employer