My next class:

Tap Gigabit Networks on the Cheap

Published: 2016-12-01. Last Updated: 2016-12-01 21:26:27 UTC
by Johannes Ullrich (Version: 1)
8 comment(s)

First a disclaimer: This method works for a home network, maybe a small business network. I do describe how to do this using a specific vendor's equipment. This isn't an endorsement of the vendor. 

Back in the 100 BaseT days, it was pretty easy to make your own tap. You could essentially just connect the network cable's transmit line to the receive pins of a "output" plug, and all it took was four network plug, a punch down tool and a bit of wire. Sadly, with Gigabit Ethernet, both pairs are used to transmit and receive. Tapping this type of network is a bit more tricky and requires more sophisticated circuitry.

You can buy some relatively cheap "Taps," but often a simple switch is cheaper, and provides similar capabilities. To monitor just a single network segment, a simple switch like this may be perfectly acceptable, and with port-based VLANs, you can even aggregate multiple segments. 

To get us started here is a little network diagram to illustrate some of the challenges you may run into

There are three possible spots to connect a sensor:

  1. Between Firewall and Modem: In this case, you will see all the traffic entering / leaving the network. But you will only see the "NAT'ed" traffic assuming that the firewall/router also does NAT. It will be difficult to assign traffic to a particular device on your network
  2. "LAN": This is the network we use to connect our workstations/mobile device. We can define a port on the "LAN" switch as a mirror port and at least mirror the port connected to the gateway. This should give us a nice spot to connect a sensor.
  3. "WAN": Same as for the "LAN" port, a mirror port on the switch will allow us to watch traffic to/from the servers connected to this switch

So how do we monitor traffic in both networks, the "LAN" and the "WAN" segment? There are a couple of options here:

Run the "sensor" on your Firewall/Router

If you are using a homemade Linux device or PF Sense, then it is pretty easy to install tools like snort or even bro on the device as well. Again: We are talking home network here. But even in a home network, I find that this type of setup quickly runs out of steam, in particular, if you are using less than state-of-the-art hardware.

Run a dedicated sensor, with multiple network cards

You will need a network card for each segment and one more for a management network. In the diagram this would require at least three (LAN, DMZ + management) or even four (LAN, DMZ, WAN + management) . Finding a small / low-cost system with more than two network cards is challenging. But luckily, with some port-based VLAN trickery, our cheap monitor switch can be coerced into aggregating multiple networks.

Aggregating Multiple Network Segments with a Switch

I am using the Netgear GS105Ev2 switch. This is a 5 port switch that offers port-based VLANs and port mirroring, the two features I am going to use here. Other switches that provides these two features should work as well. This switch currently sells for about $45.

First, figure out which port you would like to use how. In my example, I am using:

Port 1 to manage the switch
Port 2,3,4 to connect to the different network segments
Port 5 to connect to the sensor (and remember that the monitoring interface of the sensor has no IP address, but is just listening)
 

First, let's configure the "mirror" feature. We define ports 2,3,4 as "source" and port 5 as destination

Next, let's define the VLANs. Setting up port-based VLANs is CRITICAL since we do not want to "shortcut" the different network segments

So how bad is it? Does it work at all?

It does work pretty well. I still have to measure the exact throughput. The admin interface for the switch does become unresponsive pretty quickly, but well, once it is set up, you don't need to touch it anymore. There are better switches with more buffer memory that you can often get on eBay for not much more money. I am having a hard time finding "real" gigabit taps for less than a few hundred dollars on eBay. But you may get lucky. Many of the taps that you find around this same price are typically actually just switches that are preconfigured with a monitoring port.

Let me know if it works for you, or if you have better ideas to monitor multiple gigabit network segments. If you are just interested in using a switch as a tap, there are a couple of videos on YouTube walking you through the setup.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
8 comment(s)
My next class:

Comments

I am using almost the same set up. I have the Netgear GS105Ev2 monitoring my traffic after it leaves the router going to my home network. I did buy a dedicated box running Security Onion and with two NIC cards for maintenance and monitoring.
Thanks for sharing the span setup with this switch model, on the side note what kind of hardware did you use for the Security Onion setup?.
I use SharkTap to snort couple of internet facing RPI's, work like a charm.
Another method which works for a home router running DD-WRT, OpenWRT, or Tomato is to use an IPtables filter with the -tee directive like this:

iptables -A PREROUTING -t mangle -j ROUTE --gw 192.168.1.40 --tee <enter>
iptables -A POSTROUTING -t mangle -j ROUTE --gw 192.168.1.40 --tee <enter>

The above commands will make a copy of all of the traffic entering and leaving your network to the gateway IP address 192.168.1.40 (use whatever IP you assigned to your Linux or Unix system on Ethernet 0 (eth0/em0/wm0)).

If you want to stop mirroring traffic (examples would be shutting down SNORT, or rebooting your Linux or Unix system), execute the following commands in the DD-WRT,OpenWRT, Tomato GUI or via SSH/Telnet while logged into the router:

iptables -F -t mangle <enter>

The above command will flush the 'mangle' table and stop mirroring traffic to IP address 192.168.1.40 without rebooting the router.

This does work in a home environment and can be done on the cheap :)
I've run the gamut from full desktop computers being dedicated to firewall duty to migrating to OpenWRT installed on a range of different Belkin Wireless Pre-N Routers (F5D8230-4) to IBM thin clients (NetVista 2800 8364) on which I'd installed pre-Brocade Vyatta to Mikrotik RB750GL and a RB2011UAS-RM with OpenWRT installed. I use virtualized environment now, although I have the Mikrotik stuff configured with Openflow for a SDN/Opendaylight test environment. Having actual hardware for that test environment I like. Guess it's tangible that way. The controller is in a VM, however.

Much of my motivation from 10-15 years ago arose from the fact I had little disposable income, so I had to be flexible and creative.

I now have two 1U Supermicro servers with 32GB RAM on one, 64GB on the other running CentOS and Virtualbox. My VyOS firewall runs on a VM. Since I migrated to the virtualized environment I haven't done very much with Snort/monitoring. I do run Splunk and OpenNMS, so there is that, and have for several years, but have concentrated my time on other projects. Recently I installed a Security Onion (https://securityonion.net/) VM that has a lot of tools/services that I find very useful, and on top of that Sguil (https://bammv.github.io/sguil/index.html) is installed which I installed several years ago -- not an easy task. It works very very well on install and I must say I'm impressed. I haven't installed it in several years, so it might not be as bad as I recall.

I do considerable testing/development work in this environment. It allows access to traffic and a wide range of services that can be used to analyze it. My network includes the two aforementioned Supermicro servers, two Baytech DS4-RPC units, three Beaglebone Black SBCs, a Hak5 Pineapple, the two OpenWRT Mikrotiks (HATED the RouterOS they had originally) and a cable modem. This is all designed for allowing the best possible control over the environment via remote access. An OpenVPN server is hosted on an AWS instance. My next step will be a Sierra Wireless AirLink Raven RV50 for a secondary access line. The BB Black and Hak5 stuff is more for endpoints on the SDN environment presently, although I'm working on some robotics stuff with one of them and a motor cape.

I have to say I like the Mikrotik RouterBoard RB750GL. Installing OpenWRT on it isn't especially easy, for as I recall you have to compile two instances of the firmware to do it, but it's worth it as opposed to using the RouterOS that comes with it. Lots of RAM and flash, reasonably powerful CPU, and fairly cheap.
I expected to learn you were putting *two* switch ports into each port-based VLAN, then forcing transit traffic *through* the switch.

But it sounds like ports 2,3,4 are each in their own VLAN and attached to different network segments?

Why are the LAN switches that implement those segments delivering traffic to the netgear device?

If you were using the netgear for transit purposes, then this would all make sense.

Pictures aren't loading currently. Maybe they'd help clear things up.
Personally I would be hesitant to use such a Netgear switch, in particular when monitoring multiple (V)LANs (in particular DMZ), as the switch mentioned (unfortunately) was riddled with security vulnerabilities. For example, see:

(20140708, by me) https://isc.sans.edu/forums/diary/Hardcoded+Netgear+Prosafe+Switch+Password/18357/#31419

(20101211) http://whiteboard.ping.se/Security/NetgearSwitch

(20160127) http://seclists.org/bugtraq/2016/Jan/147

I don't know in how far all mentioned vulnerabilities have meanwhile been patched. If the password is still "encrypted" (actually obfuscated) when passed via the network by XORing with "NtgrSmartSwitchRock" (the account can probably be used to log on to the switch via /any/ port) then IMO this should cause all alarm bells to ring.


Tip w.r.t. Wireshark sniffing when using Windows: it is quite easy to prevent the sniffing PC from sending any packets itself by DISABLING all items in the adapter properties, typically being:
- Client for Microsoft Networks
- QoS Packet Scheduler
- File and Printer Sharing for Microsoft Networks
- Internet Protocol Version 6 (TCP/IPv6)
- Internet Protocol Version 4 (TCP/IPv4)
- Link-Layer Topology Discovery Mapper I/O Driver
- Link-Layer Topology Discovery Responder

This seems to work fine on W7 and W10.

Diary Archives