Hi Paul,

ok at first you have following problem. Your span post has 100mb so if you
are monitoring 3 ports on it with 100mb and 40% utilisation you are loosing
20% witch makes it unusable for IDS... (a lot of false positives or false
negatives). and you can*t send rskills on a span port. the next thing is,
you might have a retundant net so you need a sensor for each computer
center. another problem is asyncronus routing on loadbalancing. lets say you
have 2 servers that are loadbalanced. you have 2 packages comming
(multicast) and one package leaving -> false positive "ICMP onsolicited echo
reply" for example... so I recommend network tabs and a "IDS-Balancer" This
is kind of a switch but much better about "36gb backplane" i guess and with
gigabit... so you can monitor 10x100mb on one gb sensor... pretty cool and
totaly flexible to configure. i saw the toplayer and hat my handson. but we
are consider to take a other brand too. keep on asking if you have
questions....

http://netoptics.com/ 
http://www.toplayer.com "Attack Mitigator" and "IDS-Balancer"


Mit freundlichen Gr��en/ sincerely yours


Bernhard Fuchs 
Junior System-Engineer 
IT-Infrastruktur/IT-Security

ITELLIUM 
Systems & Services GmbH 
F�rther Stra�e 205 
90429 N�rnberg 

Tel.:   +49-911-14-27321 
Fax:    +49-911-14-22016 
mailto:[EMAIL PROTECTED] 
http://www.itellium.com

This email is confidential. If you are not the intended recipient, you must
not disclose or use the information contained in it. If you have received
this mail in error, please tell us immediately by return email and delete
the document. E-mails to and from the company are monitored for operational
reasons and in accordance with lawful business practices. The contents of
this email are those of the individual and do not necessarily represent the
views of the company. The company accepts no responsibility once an e-mail
and any attachments is sent. 


-----Urspr�ngliche Nachricht-----
Von: Paul Van Gurp [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 20. M�rz 2003 15:22
An: [EMAIL PROTECTED]
Betreff: [ISSForum] SPAN port for IDS monitoring - Cisco switches


Hi all.

I am not a network specialist by any means so please be gentle.  I am
currently attempting to deploy network sensors throughout our
infrastructure.  Since we have a switched environment, I have 2 options
(that I am aware of):

*       use the SPAN port of a switch for a network IDS
*       use network taps.

Many of our switches have several internal interfaces that I would like to
monitor...i.e. one switch will be used for traffic destined for 8 different
networks.  I would like to be able to plug an IDS into the SPAN port of the
switch and get the networking people to configure the SPAN port to accept
traffic from port 1, 3, and 8 for example because those are critical network
segments.  This would allow my IDS to monitor all 3 of those ports at the
same time.  The network guys say this is not possible and I can only span
one port on the switch to the SPAN port.  This means using the SPAN port is
out of the question for our environment.  I went to the Cisco site and it
seems that the switches are capable of doing what I want, so I am confused.

Question 1:  Who is right...i.e. can a SPAN port monitor traffic over
multiple incoming/outgoing ports on a single switch?  If not then why not?
Question 2:  If the network guys are right then why is the SPAN port a
widely used method of deploying network IDS?
Question 3:  If the network guys are right, what other options are open to
me...I mentioned taps but don't I run into the same issues...1 tap for 1
network segment and so in my example above, I would require 8 taps for the
switch with 8 ports.

Thanks in advance.

Paul



_______________________________________________
ISSForum mailing list
[EMAIL PROTECTED]

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo


_______________________________________________
ISSForum mailing list
[EMAIL PROTECTED]

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to 
https://atla-mm1.iss.net/mailman/listinfo

Reply via email to