Debian, OpenSourceSoftware, Security, Sguil, Ubuntu

Packetsniffing, VLAN tagging and bridging or bonding it together without the VLAN tags

Updated 2008-07-07 with perhaps a better alternative? Bonding.
Last week I stumped into the need for sniffing a tap with more than one VLAN using Sguil. Usually, I have just been handled straight Ethernet traffic, and didn’t need to do anything special on my sensors. Believing it should be easy, with small or non changes needed, I started to grab data. As I found out, data did not enter my squil console in the expected way. Sancp grabbed the data with VLAN tags (fixable), and snort dumped also the VLAN tags (fixable). Heading over to http://nsmwiki.org/NSM_and_VLANs seemed to face me with more patching of the tools I use, and I am not rely a fan of patching, if I don’t rely need to! I like using the tools like they come in a (Linux) distribution. So I was faced with patching Tcpxtract and Tcpflow, or work my way around.

Talking with a co-worker as we where leaving work, he rapidly mentioned using bridging etc. or I would have to patch. Searching my brain for the bridging solution, I found that I all ready had done this in Xen set-ups (Ubuntu Dapper (LTS) with Xen 3 on Dell 1855 x86_64 touches this issue). So when I got home, I had my set-up more or less figured out. Playing abit more with bridging, gave me the idea to use bonding instead, though I am not sure which method is best, performance wise. Bonding might just be wiser, due to the fact that it don’t mix

So, faced with one tap, and several VLANs, and just to sniff some, this is how you could go at it with:


Bonding on a Ubuntu/debian system:

# You need ifenslave:
aptitude install ifenslave

# I have my VLAN traffic on eth1,
# so I add my VLANs, etc 503 and 505

vconfig add eth1 503
vconfig add eth1 505

# Then I add bonding to the kernel

modprobe bonding
ifconfig bond0 up

# Then I add my VLAN’s to my bonded interface:
ifenslave bond0 eth1.503 eth1.505

# To check that you are happy, and it worked:

tcpdump -nn -i bond0

# This should give you only traffic from VLAN 503 and 505 without the VLAN tags.



Bridging on a Ubuntu/debian system:

# I have my VLAN traffic on eth1,
# so I add my VLANs, etc 503 and 505

vconfig add eth1 503
vconfig add eth1 505

# Then I bring them online

ifconfig eth1.503 up
ifconfig eth1.505 up

# If you want to at this point, you can just sniff eth1.50X
# and you will get the traffic of VLAN 50X without the vlan tag.
# But my issue is to sniff two VLANs out of XX VLANs.
# Then I make a bridge to add my two VLANs and brings it up

brctl addbr vlans
ifconfig vlans up

# Finaly I add my VLANs to the bridge

brctl addif vlans eth1.503
brctl addif vlans eth1.505

# To check that you are happy, and it worked:

tcpdump -nn -i vlans

# This should give you only traffic from VLAN 503 and 505 without the VLAN tags.

To sniff more VLANs, its just to add more VLANs to the bonding/bridge device. I want one interface for all traffic, but if you want to, you could make more virtual Ethernet devices, and just sniff each one. Preferably, you should probably just have one bridge for each physical Ethernet device.

Important: Im specifying a tap, as in a Network TAP and that by bridging interfaces together, hence, can not disturb traffic because of the nature of a Network TAP. So if you dont use a tap, be careful. You might just make a bridge between your VLANs :)

Advertisements
Standard

3 thoughts on “Packetsniffing, VLAN tagging and bridging or bonding it together without the VLAN tags

  1. Nicolai says:

    Odd. I think I’ve been told that snort has supported this for years.

    Anyway, this isn’t all that good an idea IMHO. Sometimes packets comes from surprising directions and now that you dropped the VLAN tag you’ll never know if it came from the expected direction or not.

    Nicolai

    Like

  2. Snort supports VLAN tagging, this is not what I’m trying to illustrate here. The problem is more that sguil, with the tools it uses, do not work straight out of the box. You need to patch common programs which comes with , which I try to work around.

    Edward

    Like

  3. Ross Potts says:

    Having used Snort (in the commercial form of Sourcefire up to 4.5), I might be able to shed some light on this. The default servers used were IBMs, from 1u systems for the sensors to 4u systems for the central database (I’ve got Doco somewhere if you want to get more info). The sensor came with multiple NICs before even upgrading the backplane (to which you could add fibre cards or more gigabit NICs if you so desired). As it was explained to me (I was a customer, so we were able to get a little more info), the main purpose for the extra NICs was FOR channel bonding, in fact the system came bonded. The reason for the bonding was originally for two purposes; one, to handle the inevitable dying NIC, and two, VLAN tagging.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s