RE: Use of Taps for IDS
From: Jonkman, Matthew A. (Matthew.Jonkman@umb.com)Date: 12/20/01
- Previous message: Ken.Williams@ey.com: "Re: Winxp, blackice and ie"
- Maybe in reply to: rob@puparoo.org: "Use of Taps for IDS"
- Next in thread: robert.d.turner@bt.com: "RE: Use of Taps for IDS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Jonkman, Matthew A." <Matthew.Jonkman@umb.com> To: "'Whitt,Laura A.'" <Laura.Whitt@cna.com>, "'Scott C. Kennedy'" <sck@s4r.com>, Frank Knobbe <FKnobbe@KnobbeITS.com> Date: Thu, 20 Dec 2001 11:05:59 -0600
My theories, someone please correct me if I'm wrong.....
The hub solution brings up concerns for full duplex and for multiple network
situations.
If you intend to aggregate more than one separate link (or tap) into the
same hub then you'll have issues. The tapped networks are intentionally not
aware of eachother and will undoubtedly be transmitting at the same time
along the way. Those packets will be lost in collision and since the hosts
aren't aware won't be retransmitted for the IDS's benefit. If you aggregate
more than one link into a switch then you can count on the switch buffering
packets. How far it can buffer I'm sure depends on the switch.
If you are running full duplex on the network you monitor then a hub can't
be inline at all. The taps will bring out 2 transmitting half duplex
connections. If you put both to a hub you'll see all the traffic *IF* the
network does not have a pcket being transmitted and recieved at the same
time. Since this is the purpose of full duplex you can count on collisions
even on a low capacity network, and thus the ids won't see everything.
I'd recommend looking at using span ports. Cisco's ability to do multiple
span ports/switch, vlan spans, and remote spanning have greatly improved in
recent ios and cat os's.
Again, if I'm mistalen someone please correct me.
Matt
-----Original Message-----
From: Whitt,Laura A. [mailto:Laura.Whitt@cna.com]
Sent: Thursday, December 20, 2001 8:59 AM
To: 'Scott C. Kennedy'; Frank Knobbe
Cc: rob@puparoo.org; focus-ids@securityfocus.com
Subject: RE: Use of Taps for IDS
We are purchasing Shomiti Century Taps and Cisco Catalyst 3550's...... are
we just going overboard or is the "hub" solution a viable one for a larger
network?
Thanks!
Lorie
-----Original Message-----
From: Scott C. Kennedy [mailto:sck@s4r.com]
Sent: Wednesday, December 19, 2001 11:52 PM
To: Frank Knobbe
Cc: rob@puparoo.org; focus-ids@securityfocus.com
Subject: Re: Use of Taps for IDS
The 2 port ShoMiti Network TAP needs the THG switch
but the TopLayer AppSwitch is a THG-like device.
THG is the Shomiti product name for the re-assembler.
As for using Hubs, I agree, except that you can do 100 Mb/s
full duplex through some hubs, but others you'd have to do half
duplex. Plus.... Some hubs have a uplink filter to prevent some
bad network issues from propagating. But, it's really annoying
when you come across them..
Which 100 Mb/s hubs do you like?
Scott
Frank Knobbe wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > -----Original Message-----
> > From: Scott C. Kennedy [mailto:sck@s4r.com]
> > Sent: Wednesday, December 19, 2001 1:22 PM
> >
> > Just an obvious note... Most (if not all) taps, will split off the
> > transmit lines of the two machines. So, for a standard two port
> > tap, you'll have port A, port B, tap A, tap B. The traffic going
> > from A to B shows up on tap A, and the traffic going from B to A
> > shows up on tap B.
>
> Scott,
>
> does that include Shomiti and TopLayer taps?
>
> > So, if you're doing any protcal analysis, like with an NFR or
> > other IDS that
> > need to follow the state of the connection, you'll need to
> > buy a THG device
> > to take those two ports and merge the traffic back together.
> > Otherwise,
> > you'd just see this..
> >
> > Attacker - SYN -> Target port 80
> > Attacker - ACK -> Target port 80
> > Attacker - HTTP 1.0 GET /etc/passwd -> Target Port 80
>
> One tap I know of does not use only one direction of traffic :) My
> favorite tap is a $30 4 port hub and a specially crimped Ethernet
> cable that only 'reads' data. Since the hub will pass all traffic on
> to the other ports, both directions are received by the IDS.
>
> For example, to tap a connection between a router and a firewall,
> plug the router into port 1 of the small hub. Port 2 goes to the
> firewall. Port 3 connects with following cable to the IDS:
>
> Hub IDS
> 1 -----\ /-- 1
> 2 ---\ | \-- 2
> 3 ---+-*------ 3
> 4 - | - 4
> 5 - | - 5
> 6 ---*-------- 6
> 7 - - 7
> 8 - - 8
>
> Basically, 1 and 2 on the IDS side are connected, 3 and 6
> straight through to the Hub. 1 and 2 on the Hub side connect to 3
> and
> 6 respectively. This fakes a link on both ends but only allows
> traffic from the Hub to the IDS. It also causes the 'incoming'
> traffic to be sent back to the Hub, so this cable only works well
> on
> a real hub. You can use it on a switch but you will get ...err...
> interesting results. Since the switch receives the packets back in
> on
> the port it sent them out, the MAC table gets confused and after a
> short while devices start to drop off the switch. Works like a
> charm
> on a hub though.
>
> Regards,
> Frank
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Personal Privacy 6.5.8
> Comment: PGP or S/MIME (X.509) encrypted email preferred.
>
> iQA/AwUBPCFUlpytSsEygtEFEQJ+mQCeP7nXbLmHd48Q2HlaREuDdq9Q6I8AoKWD
> 5aNstw/JA0m+dtOId883Ycy0
> =4FEU
> -----END PGP SIGNATURE-----
-- Scott C. Kennedy Chief Technical Officer S4R | The Managed Services Company 5135 Avenida Encinas Carlsbad, CA 92008 Office: (760) 804-8004 ext.105 Cell: (619) 318-4402 Pager: (760) 720-8853 E-mail: sck@s4r.com Web: http://www.s4r.com PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE27C1102
- Previous message: Ken.Williams@ey.com: "Re: Winxp, blackice and ie"
- Maybe in reply to: rob@puparoo.org: "Use of Taps for IDS"
- Next in thread: robert.d.turner@bt.com: "RE: Use of Taps for IDS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
