All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rein van Koten" <rein@vankoten.com>
To: bridge@osdl.org
Cc: shemminger@osdl.org
Subject: [Bridge] Mirroring an interface to an other by using bridge ?
Date: Thu, 25 Mar 2004 18:06:33 +0100	[thread overview]
Message-ID: <000e01c4128b$8c13f9d0$7f619082@simba> (raw)

[-- Attachment #1: Type: text/plain, Size: 3617 bytes --]

Hi,

Just wondering....

Currently i'm redesigning an intrusion detection system based on Snort / Linux (in this case Fedora Core 1).
Datastream is tapped physically by means of single-mode fiber taps from a dual path link between router pairs.
By using intel single mode fiber cards and bundling the four tapped streams to one virtual interface with the intel drivers i recreate a virtual mirror of the uplinks we are sampling. Works like a charm.
However, the created datastream is needed for other measurements as well. What I would like to do is to create a mirror port from the reassembled stream.
Normally you woud have one or more mirror ports on a switch/router but in this case the stream is only complete on the linux box.....
Also, as it is not a real stream a 100mb hub cannot be used as fanout (and this only as long as the aggregated load is below 100MB and is not a pure for ids use)

Looking for a solution to this I dug into ebtables / bridging and divert mechanisms currently available in the linux kernels.
But I did not find a reference to a real mirror solution. Maybe I'm looking in the wrong place.
Looking at the functionality I think I need, it looks like the bridge module is my closest bet.
If the bridge forwards everything without keeping mac tables or sending/receiving arp messages I'm in business.....

So, my question:

Is it possible to adapt the bridge code so it:
- copies all incoming traffic from one interface (in promisc mode) to an other, regardless of mac address etc
- does not do any sending itself (no proxyarp, arp, broadcasts etc)
- prefferably works one way (a mirror should be read only)?
- This as low as can be in the kernel (so not all the way up to ip/eb tables or high in userspace)
In fact this looks like the bridge module without all the more refined stuff (keeping tables, proxying etc)


Example with the envisioned version of bridge module and brctl:

# sniffing / ids on eth1, want to copy all traffic to eth2 for others to use without needing access to the IDS environment.
# setup bridge
brctl addbr <bridgename>
brctl addif eth1
brctl addif eth2
# set bridge type to copy thus creating a mirror port
brctl mode <bridgename> copy
# set the copy direction from eth1 to eth2 (can only be in one direction)
brctl setcopy <bridgename> in eth1
brctl setcopy <bridgename> out eth2
# enjoy...

so:
mode command has options copy or bridge
setcopy out provide the option to copy several interfaces' incoming data to a single (or even multiple?) interfaces.

currently I only see a solution like bridging, ebtables/divert replacing incoming macs with the mac of the sniffer attached to my semi mirror interface, blocking all arp traffic and this only works probably if you know all the mac addresses on the link you are sampling (in my case I do because it's the four mac addresses of the upstream and downstream routers). 
Also, possible trouble comes from :
    - I'm not sure that tools like divert etc work on a virutal interface like the one created when you bundle interfaces.
    - i/o speed, kernel resources etc
I saw that I at least had to hack the divert.o code to remove the check on interface names starting with "eth" as the intel drivers do not allow a virutal interface with a name like eth9...

Anyway,

I would appreciate your opinion on this or whether you know someone working along the same lines...
I myself am not C savvy enough to rewrite the bridge module without additional input on this idea.
And then again, maybe it already exists.

Regards,

Rein van Koten
The Netherlands.

[-- Attachment #2: Type: text/html, Size: 4764 bytes --]

             reply	other threads:[~2004-03-25 17:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-25 17:06 Rein van Koten [this message]
2004-03-29 17:48 ` [Bridge] Mirroring an interface to an other by using bridge ? Bart De Schuymer
2004-03-31 14:39   ` [Bridge] " Mike Andersen
2004-04-01 16:18     ` Bart De Schuymer
2004-04-02  7:23       ` Mike Andersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000e01c4128b$8c13f9d0$7f619082@simba' \
    --to=rein@vankoten.com \
    --cc=bridge@osdl.org \
    --cc=shemminger@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.