Build a Passive Ethernet Tap – Ubuntu IDS Part 1

by on Apr.06, 2011, under Hardware, How-To's, Linux, Security, Software

Image courtesy of forums.overclockers.co.uk

One of the things that the GCIA study has taught me is that being able to monitor the network your computer is on is a critical necessity to maintaining a secure network. Corporate environments can set up IDS devices to monitor traffic however monitoring doesn’t work unless you have proper connectivity to what you want to monitor. Unfortunately, most of us don’t have central wiring in our house and expensive managed switches that can set up span sessions with which to monitor traffic in transit.  In this HOWTO, I will cover how to build your own monitoring connection that you can use on your own network to monitor traffic without breaking the bank. This article is first in a three part series on how to build your own home IDS for monitoring your network traffic. Look for the other two sections soon!

A little bit more info first…

In the early days of affordable Ethernet networking, devices called hubs (or repeaters) were used to bring the signals together from each workstation in order to allow the workstations to communicate with each other. When a packet was sent to the hub, the hub repeated the packet across all ports on the device and all other workstations would receive it, even if it was not destined for that particular workstation.  The hubs gave way to switches as networking technology became cheaper and faster. Unfortunately, the switches also changed the old way of signal transmission. When a workstation sends a packet to a switch, it is sent from the sender’s switch port  and arrives at  the switch port of the workstation that the packet is destined to. It does not get sent to other workstations’ switch ports unlike the hub’s transmission method.  Because of the need for network monitoring, more advanced switches started offering monitor ports (Cisco calls them span sessions) that are used to forward all traffic that goes through a switch out of this specifically configured port.  This port would then be connected to the monitoring device and would allow the monitoring device to “listen” to all packets that traversed the switch.

The good thing is that most if not all managed switches support a monitor port however the bad thing is that a managed switch is way outside the pocketbook of most home network users.

But why not use a hub?

A hub would allow us to listen in on network traffic however a hub would degrade your network’s performance thanks to it’s lack of proper high speed flow control and its susceptability to collisions.  In my testing, I used a 100baseT hub between my firewall and my network and found that my previously rock solid network connection had dropped well below speed and would barely support YouTube streaming, much less Netflix.  Instead of using a hub and risking continued degradation, I decided to research another solution.

So, what’s the solution and how do I use it?

The solution is the Passive Tap.  This device sits between a unmanaged switch and a computer or router and allows a monitor device to listen in on the network connection between a computer and switch.  The word passive in this instance means that there is no way to detect the device’s presence. It does not have a MAC address, it does not repeat. For all intents and purposes, the tap does not exist.

In the image above, we have connected the Passive Tap between a network switch and a monitored host in order to monitor traffic between the host and other machines on the network (in this case the Server).  This would be an ideal setup for monitoring traffic generated by the monitored host and the rest of the network with the focus being on the monitored host. In this configuration, the monitor device would pick up all traffic destined to or originating from the host and any broadcast traffic generated by the network.

Passive Tap Monitor Setup #2

This configuration is a bit different than the first image however the scope of the monitor device’s visibility has changed. Instead of just monitoring the Monitored Host, this configuration allows the monitor device to monitor any Internet traffic that passes between any host on the switch and the firewall. If there were additional devices connected to the switch (other desktops, an Xbox, a Wifi Access point, etc..) their communication with the Internet would also be monitored.  The only communication that would not get monitored would be communication between the devices plugged into the switch (for example the Monitored Host and a Wifi Accesspoint, etc.)

Parts List

In order to build a passive tap, you will need the following items.  The parts themselves cost me about $20 at a computer store which is a lot better than the $200 that some eBay sellers want.

  • A cat-5 patch cord
  • A surface mount biscuit jack / modular mounting box. (See picture below)
  • Two CAT5 keystones (they don’t have to be green/red like mine)
  • Screwdriver
  • Wire cutters/blade
  • A M110 punch down tool (If you have one, it makes the installation easier)
  • A monitoring computer with two network interfaces and Wireshark installed (windows) or tcpdump(linux)
  • A test computer (or device) with one network interface
  • A network switch.
  • Beer (optional)
Parts

Parts

Here’s an image of the parts. The biscuit jack on the left, the two keystones are in the center and the patch cord is on the right.

We’ll start off by first taking a look at the keystones up close.

Keystones

Keystones

These keystone jacks are wired up and marked in such a way that all you need to do to wire it up properly is to follow the color code. A closer inspection will reveal that there are small numbers in between the symbols for the wire positions. In this page on twisted pair wiring, you can see that of the four pairs in a Cat-5 10/100 cable, only pairs 2 (white/orange) and 3(white/green) are used.  In order to properly receive both sides of the conversation on the wire, we will need to “tap” into both pairs and route them to the proper pins on the two keystones to each jack’s Pair 2 (receive pair) so that the data being sent can arrive at the NIC of our monitoring device.

If you scroll down to the section labeled “568A and 568 B Color Schemes”, you will see that the receive pair is on pins 3 and 6 of the diagram jacks.  Our keystones are similarly labelled and when we are done, we will have one pair of the Cat-5 patch cable going to pins 3 and 6 of one jack, and the other pair of the Cat-5 patch cable going to the other jack.

Let’s get started.

First off, it is important to understand that you must be able to do this WITHOUT NICKING OR CUTTING THE WIRES.  A cut or nick could result in either your tap not working properly or the tap getting all the data but your connected host doesn’t or any one of a whole handful of issues.  Thankfully, Cat-5 patch cords are not very expensive, but it still sucks to put a project on hold because a slip of the knife.

To start, lay out the patch cord and decide on where you want the tap.  Since the hosts are closer to my monitor machine, I’ve decided to create a short end and a long end with the tap being more towards one end.  You may want to have the tap in the middle or very close to one end of your patch.  It electrically does not matter.

Strip back about two to three inches of jacket so that you have something like below.

Stripped Wires

Stripped Wires

Mount the keystones in the surface mount box as shown below.

 

mounted keystones

mounted keystones

Now that they are mounted, we will then need to take a look at which pair of pins we need to match the wires up to. Below is a better side-view pic of the green jack in detail.  Please note, your jacks may appear different, but all CAT5 keystone jacks that I have seen have both a color designation and a numeric designation. Be sure to pay attention to which is which and where you are placing your wires otherwise it may not work.

Wire/Pin designations

Wire/Pin designations

You can click on the picture for a larger more detailed image.  In the above image (using the top set of colors as a guide) we see that the orange/white hash is pin 3 and the solid orange is pin 6. The same goes for the red jack (not shown).  That being said, untwist the orange and green wires, and place them into their respective slots. Make sure that the solid wire goes with the solid pin and the hashed wire goes with the hashed pin. A reversal here will cause the monitor port not to receive data and could affect your host/switch.

Wires ready to crimp

Wires ready to crimp

In the above photo, you can see that the white/orange pair are lightly inserted into the wire channels.  If you don’t have the M100 punch tool, you can get away with using the wire caps that came with your keystones.  These caps will push down the wire and crimp it into place over a metal pin that connects the wire to the pin in the jack.  When you are done, you will have something akin to the below:

Tap ready to close

Tap ready to close

Also of note: To act as a strain relief, I have added tiewraps on the cable. This will serve to protect the cable from getting yanked out and damaged.  In this picture, you can also see the two white caps that have punched the wires down in place. Reassemble the jack and make sure to install the screw in the lid if your jack has one.

Completed Passive Ethernet Tap

Completed Passive Ethernet Tap

Here’s the completed tap in all it’s glory!

Testing the Tap

In order to test the tap, we need at least two computers, one of which must have two network adapters.  The computer with one network adapter will be our “test host” and the other computer will be our monitoring host.  On the test host, I have assigned the IP address 10.0.0.2 and on the monitoring computer, I have assigned one interface (eth0) with the IP of 10.0.0.1.  The monitoring interface (eth1) will have no IP address assigned to it and will be for testing the tap.  Remember that as far as the test host is concerned, the tap is just a CAT-5 patch cable.

Before proceeding, mark the passive tap where the Ethernet cables come out as A and B.  This will be important as this test will also help us label which side of the conversation we are listening to.  One side will be considered “Network to Host” and the other will be considered “Host to Network”.  It is imperative that we get both sides of the conversation, each side represented by one of the two keystone jacks. While it might not be important now, later on when you use this tap for something else (like an IDS project), you will need to know which side of the conversation you are listening to.

To get your test rig set up, connect the long side (side A in my case) of the tap cable to the switch.  Connect the short side (side B in my case) to the test host.  Connect the ethernet interface on the monitoring machine to the switch, but leave the  unmonitored interface disconnected.  Keep in mind that on my monitoring machine, eth0 was the interface with the IP address, and eth3 was the interface that will be used for monitoring. I’m using Linux on my system, you may need to make adjustments where needed.

  • On the monitoring host, ensure that you can ping the test host before hooking up the monitoring interface to the tap.
  • On the monitoring host, open two terminal windows
  • In the first window, start tcpdump using this command:  sudo tcpdump -i eth3 -nvs0 -c 10 ip[9]=1This translates to start tcpdump on eth3, no host resolution (-n), verbose mode (v), no snapshot length (s0), for a count of 10 packets (-c 10) and only on ICMP protocol (ip[9]=1).
  • Attach the monitoring interface to one of the two keystones.  I picked the red jack.
  • In the second window, ping the test host using the -c 5 parameter:  ping testmachine -c 5 The -c 5 tells ping to try 5 times.
  • You should see the below text in your ping window:

 

$ ping  testmachine -c 5
PING testmachine (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=7.25 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.685 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.719 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.746 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=0.704 ms

 

  • Your TCPDUMP window should show something like this:

 

21:48:59.093624 IP (tos 0x0, ttl 64, id 27270, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 24899, seq 1, length 64
21:49:00.088502 IP (tos 0x0, ttl 64, id 49871, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 24899, seq 2, length 64
21:49:01.087486 IP (tos 0x0, ttl 64, id 36772, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 24899, seq 3, length 64
21:49:02.086630 IP (tos 0x0, ttl 64, id 27025, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 24899, seq 4, length 64
21:49:03.085505 IP (tos 0x0, ttl 64, id 28037, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 24899, seq 5, length 64

 

  • Keep in mind that there are two packets associated with ping. One is an ICMP Echo Request and the other is an ICMP Echo Reply In this case I received the echo reply which means that the red jack is for “Host to Network” monitoring or B->A. If you got ICMP echo request, then your jack is A->B.
  • Mark the jack as B->A and continue testing. At this point, we know that our tap at least hears half the conversation.
  • Switch the monitor interface to the other jack (Mine is green) and rerun the ping.  Your ping should show the below just like before:

 

$ ping 10.0.0.2 -c 5
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=9.69 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.705 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.663 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.722 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=0.714 ms

 

  • This time, however, the TCPDUMP output should have changed:

 

22:00:28.084339 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.1 > 10.0.0.2: ICMP echo request, id 40269, seq 1, length 64
22:00:29.077220 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.1 > 10.0.0.2: ICMP echo request, id 40269, seq 2, length 64
22:00:30.076215 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.1 > 10.0.0.2: ICMP echo request, id 40269, seq 3, length 64
22:00:31.075218 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.1 > 10.0.0.2: ICMP echo request, id 40269, seq 4, length 64
22:00:32.074214 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.1 > 10.0.0.2: ICMP echo request, id 40269, seq 5, length 64

 

  • Just like before, I received 5 packets however last time I got the ICMP echo reply, this time I got the ICMP echo request.  This means that the green jack is the A->B connector, that is Network to Host. Mark it as appropriate.

If you’re at this point, then you have demonstrated that the tap works.  It allows the test host to communicate with the network unimpeded, it also allows the monitoring of host to network and network to host data.  My passive tap looks like the one below:

Finished Passive Tap

Finished Passive Tap

Now what to do?

At this point, with a good passive tap in hand, you have a whole bunch of things you can do. You could:

  1. Establish an IDS for your network (my original plan)
  2. Monitor a host’s traffic exchange with the network/Internet.
  3. Perform traffic reconstruction for analysis.
  4. Monitor network communication between your Wireless access point and the rest of your network

Troubleshooting

Unfortunately, I can’t account for every situation however there may be some situations where the tcpdump test doesn’t exactly work as planned.  Here’s some common solutions if your tests don’t work quite right:

I can see the A->B traffic, but can’t see the B->A traffic. The ping window shows the host responds. (or)

I can see the B->A traffic but can’t see the A->B traffic. The ping window shows the host responds. (or)

I can not see any traffic, but the ping window shows the host responds.

Check your wires on the keystone and make sure the wire went down onto the metal pin. Sometimes when using the caps to crimp down the wires, one of the wires will shift at the last second.

I can see the ICMP Echo Request  on one port but I see nothing on the other. The ping window shows that the host does not respond.

Check to see that the wires didn’t rip apart or that they were not nicked in the construction process.

Last Thoughts

Even if you don’t plan on building a home IDS, having a passive tap in your toolbox is a good idea.  You never know when you will need to intercept and analyze traffic between two devices on a network. This device will allow you to do so with minimal effort and cost all while allowing the host to chatter away unimpeded by the monitoring.

Happy Hacking!

FIRESTORM_v1

:, , ,

12 Comments for this entry

  • OK Ima Jerk

    Very nice article and you’ve put a lot of hard work into it.

    I feel like and probably am an a** for pointing this out, but the phrase is “for all intents and purposes” not “for all intensive purposes”

  • firestorm_v1

    Hello!

    You’re correct. It is “intents and purposes”, not “intensive purposes”. Admittedly, I am not the best proofreader when it comes to publishing posts however I do try to correct mistakes when they are found or pointed out.

    Thank you.

    FIRESTORM_v1

  • ICH

    Hello,

    nice article! I wanted to buidl such a Tap by my own. Have you tested your Version with much traffic on the line? Does it work then fine, too, or is there a loss of packages then?
    Thanks a lot so far and sry for having not the best englisch!

  • firestorm_v1

    Hello ICH:

    I have successfully used this tap up to the 100mbps wireline speed with no drops in traffic. Mine were in full use until I replaced the taps with a Cisco switch that could do span session monitoring.

    Thank you.

    FIRESTORM_v1

  • Ade Dunkan

    Hi, I am struggling with this. I am trying to do it with only one jack and connecting the orange pair and the green pair in to it so I can monitor both using one ethernet card. The cabling seems fine as I can connect directly using this cable. The problem is when I connect my monitor device, the connection to the host from the switch keeps dropping in an endless cycle.

    Any thoughts on what is wrong?

    Thanks, Ade.

  • James Barker

    First i would like to say thankyou for your post i find it very interesting and have not seen such an approach to monitoring.

    However i am having some trouble with my setup.

    I am using cat5 cable running from PS3 ( Playstation ) going straight to my modem/switch/router ( all-in-one). I have cut the cable casing in the middle and re-wired through my 2 keystone jacks.

    The is no problem with the PS3 it connects to the internet fine, I even CUT the brown and blue cables.

    The problem is my monitor computer when i plug in the monitor ethernet cable wont connect it says ” ACTIVATION OF NETWORK FAILED ”

    Even in Wireshark i cannot see any interface.

    I am only using 1 ethernet cable because i dont care about capturing both traffic just one way i want to test.

    I have tried to put my eth0 up in promisc but still not connecting and still not showing any interface in wireshark.

    Can you help me in any way ? Why is my computer not connecting to the tap and why is no interface showing in wireshark

  • firestorm_v1

    Hello James:

    I would recommend you check your keystones and the datasheet that came with it. Some keystones reverse the polarity of the two wires so where you would expect wires 4 and 5 actually come out of the jack as 5 and 4. I would also check your ethernet card and make sure you have a link light. Remember, this is for monitoring only, you won’t be able to pull an IP on this connection. If you are using Ubuntu or something with NetworkManager with it, stop the Network Manager service as this will almost certainly lead to failure as NetworkManager doesn’t understand monitoring mode for ethernet nics. Regardless of the state of your computer, you should at least have a link LED on the network card itself.

    Good luck!

    FIRESTORM_v1

  • firestorm_v1

    Hello Ade:

    There is no way this can be done with one ethernet card. When you join the green and the orange wires, you are effectively looping TX(orange) and RX(green) into itself and the switch senses an endless loop condition and shuts the port off. You have to use two ethernet cards so you can hear both sides of the conversation (Target to Switch on card A and Switch to Target on card B). Aggregating Card A and Card B gives you both sides of the traffic flow.

    Good luck!
    FIRESTORM_v1

  • Jonas

    Hey,
    You mention the color schemes for 568A and 568B. I cant find them here… I was hoping to make a device with two boxes piggyback which means I can make a sleek looking device with neat cables in it, but hopefully a can find that info somewhere!

    Jonas

  • djdumbass

    Cheap lan tap, works for 10/100/1000 :)

    http://greatscottgadgets.com/throwingstar/

  • firestorm_v1

    Added to my wish list. Good find!

    FIRESTORM_v1

  • firestorm_v1

    The difference between 568A and 568B are the locations of the orange and green wires. If you have a cable with 568A on one end and 568B on the other, you have a crossover cable.

    Here’s an image I found that has the difference between 568A and 568B, hopefully this helps: http://www.zytrax.com/images/cat5_color.gif

    Good Luck!

    FIRESTORM_v1

Leave a Reply