TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
I have made for a client a configuration with ISS sensors, taps and
toplayer.
This configuration is rather good but there is a big problem!!!!
If you want to use the kill response of iss sensors you must use hubs.
If you want to use some switches, you must disable the MAC address learning
or some packets will be lost.
But this tip is not possible on all the switches. For exemple in cisco
products it is possible from the catalyst 4000....
If you want more informations about this configuration, don't hesitate to
mail me...
------------------------------------------------------------
Laurent Cabal
Ing�nieur S�curit�
ALTHES "L'expertise s�curit�"
53 rue Albert Samain
59650 Villeneuve d'Ascq
tel: 33 (0) 3.20.33.84.40
fax: 33 (0) 3.20.33.84.31
http://www.althes.fr
-----Message d'origine-----
De : Jason Renard [mailto:[EMAIL PROTECTED]]
Envoy� : lundi 15 avril 2002 21:38
� : [EMAIL PROTECTED]
Cc : [EMAIL PROTECTED]
Objet : Re: How to merge several switched LAN segments
TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any
problems!
----------------------------------------------------------------------------
On Mon, 15 Apr 2002 09:29:10 +0200, you wrote:
>I am looking for a trick to merge the traffic of about 5 switched Fast
>Ethernet LAN segments together in order to monitor the total traffic
>with only one RS Network Sensor. Most of the LAN segments are on
>different physical switches (DMZ, RAS, WAN Segments), but in the same
>physical location.
Watch out for how much load you have on these segments compared to how much
you can monitor, in terms of (a) whatever you use to 'merge' the traffic (b)
the NIC on your network sensor (c) the CPU on your network sensor.
>All links are Full-Duplex - and we would like to keep that up to the
>IDS Interface (to prevent packet loss due to collisions).
Ok, here when you say "IDS interface" you don't necessarily mean the network
sensor NIC do you? You mean whatever device / technology is used to merge
the five full duplex ethernet connections into one stream?
>All this traffic should then be collected on a single 'IDS-Switch',
>which then mirrors all the incoming segments/traffic to the IDS
>interface port.
I assume you've done the maths, such that it is theoretically possible to
merge the total network traffic of your five full duplex segments out on to
a single wire? After all, whatever device you use to merge the traffic, if
you've only got ONE network sensor then it will only be able to process the
traffic on its RECEIVE wire which is essentially half-duplex. (In other
words, even if you combine 200 Mbps of full-duplex traffic, when you squirt
it at the sensor it will be down a wire rated at 100 Mbps - and that's
assuming 100% utilisation).
As a technical aside I believe Network Sensors support more than one NIC
(possibly two, not sure if three's official) so if you had a single
full-duplex wire to be monitored then you could tap both directions and feed
each into a NIC on the same network sensor - although of course (a) would
both be loading the CPU etc on the sensor
(b) would lose some functionality because each NIC's would be examined
separately and you'd have problems with 'syn flood' detection etc.
Incidentally i've not dabbled with dual sniffing NICs on a Network Sensor so
don't take anything i've just said as the word of an experienced man!
>As this IDS switch (Cisco 2924) does not support *unidirectional* port
>mirroring (SPAN), we need another solution to prevent the mix-up or
>backflow of traffic to the source switches (also for security reasons).
>I've heard something about cutting the TX lines in the Twistet-Pair
>patch cables that lead to the IDS switch, to prevent the back-flow of
>traffic. Has anyone done this already, and if so, how do I trick the
>switch to keep the port 'up', despite the cut TX line?
I've heard of cutting the TX line but haven't done so myself.
Interesting, yes, I'd never thought what the switch would do in that case -
hopefully some other readers will have done this and know.
I am a little confused here - is the Cisco 2924 a normal switch without
SPAN, or does it have SPAN abilities but you can't customise it to prevent
injection of packets?
You can buy "wire taps" which are little boxes that you can think of as
going instream into an ethernet cable and presenting copies of both the
wires to you. I think they're called Schomiti or something like that. For
example you could plug a cable between your switch and the tap, then take
one of the feeds and connect it to your sensor. The only thing I'm not sure
of is whether the tap would needed to be connected to something else,
properly, since it's designed to sit "instream". I've not used these taps
so, once again, am only talking from what i've picked up from others.
>Any other ideas or tricks to merge multiple switched LAN segments onto
>the IDS network interface?
"Top Layer" switches used to be mentioned a lot alongside ISS - I've never
used them but apparently they can take multiple feeds and present them to a
network sensor or stripe them across several sensors. Again, i should say
that i've not used these switches personally.
>Many thanks!
>Andres
Don't forget...
- if you use a span port to combine multiple segments, make sure that span
port can handle the combined amount of traffic
- make sure the final wire to the network sensor, and the sensor itself, can
handle the final amount of traffic
- if you split TX and RX to different sensors then you will lose a little
functionality
- bear in mind whether now, or in the future, you might want the ability to
send TCP resets
Um, that's it for now...
Jason
Jason Renard
Warning - all views expressed are my own.
I cannot guarantee the accuracy of everything
I've said - use it at your own risk.
*---------------------------------------------------------------*
* Cet e-mail et toutes les pi�ces jointes sont destin�s aux *
* seules personnes auxquelles ils sont sp�cifiquement adress�s *
* et n'engagent que le signataire de ces documents et non la *
* structure dont il d�pend. *
* Leur existence et leur contenu ont un caract�re confidentiel. *
* Toute utilisation ou diffusion non autoris�e est interdite. *
* Si vous avez re�u cet e-mail ou si vous d�tenez sans en �tre *
* le destinataire, nous vous demandons de bien vouloir nous en *
* informer imm�diatement. *
* Cette note assure que ce message a �t� contr�l� et ne *
* comprenait aucun virus connu � ce jour, n�anmoins tout *
* message �lectronique est susceptible d'alt�ration. *
* Nous d�clinons toute responsabilit� au titre de ce message *
* s'il a �t� alt�r�, d�form� ou falsifi�. *
*---------------------------------------------------------------*
