Re: IPS/IDS behavior with ISIC/UDPSIC/TCPSIC/ICMPSIC traffic

["Ravi Chunduru" <ravi.is.chunduru () gmail com>]

Hi,

What do you mean by "attacks must be detected at much earlier stages
when creating a NETWORK"?
If you seem to indicate that it is responsibility of victim company to
get more bandwidth, then  it would be still lot smaller than the
bandwidth botnets have or patriotic activists have (combined
ofcourse).

Ravi


On Mon, May 19, 2008 at 8:00 AM, Sanjay R <2sanjayr () gmail com> wrote:
> Hi..i think the mail was not delivered to the group. so i m resending.
> pardon for duplication to some.
>
> -sanjay
>
> On Sun, May 18, 2008 at 2:03 PM, Sanjay R <2sanjayr () gmail com> wrote:
> > hi Ravi:
> > I am not aware of whether NSS has or not the DDOS attacks in its list,
> > but coming to your question, i would say that detecting/stopping  DDOS
> > is not that straight forward. you can always set some filter based on
> > Rate of traffic (earlier i worked with Intoto IPS and it has this type
> > of filter). still there is a problem - different IPs are used (and
> > hence the name DDOS! ). if you go deeper, you will find that problem
> > does not lies (as far as IDS/IPS mis concerned) in detecting at DDOSed
> > victim's side (in your example CNN). there are other infected
> > computers that participated  in DDOS. if you analyze CNN attack, you
> > will find that there was an infected web page that in turn lwas
> > loading  CNN page (or some part of it). you can do this by crating a
> > hidden frame with img src (<img src="cnn.com/something/something">).
> > (very recently, it was termed as puppetnet also). if many people
> > (zombies) have this type of web pages and people are connecting to it,
> > CNN will be called again n again. This can also be done by XSS by
> > targeting a busy public forum. so, what i m trying to say is - such
> > attacks must be detected at much earlier stages when creating a
> > NETWORK.
> >
> > regards
> > -Sanjay
> >
> > --Computer Security Learner
> >
> > On Sun, May 11, 2008 at 12:47 AM, Ravi Chunduru
> > <ravi.is.chunduru () gmail com> wrote:
> > > tcpsic program today is not completing three way handshake.  What
> > > about tools and attacks that complete three way handshake?  recently
> > > cnn.com was DDOSed by  set of people in china during tibet unrest
> > > time.  This attack was not only completing three way handshake, but
> > > also downloading content from a specific URL.   My questions.
> > >
> > > Why is this not considered in NSS testing criteria? Is it not
> > > considered as an attack that need to be protected by IPS devices?
> > >
> > > Ravi
> > >
> > > On Wed, May 7, 2008 at 5:41 PM, Srinivasa Addepalli <srao () intoto com> wrote:
> > > > ISIC generates many packets with different IP protocols.  If you have
> > > > firewall, you can block the protocols which you don't require. Also, it
> > > > generates UDP, TCP packets with wrong checksum. Since IPS software drops the
> > > > packets with wrong checksum, this may not be the cause for either 100% CPU
> > > > utilization or running out of session entries.
> > > >
> > > > TCPSIC: Since many IPS boxes have SYN flood protection, this also may not be
> > > > the reason for the problem you are facing.
> > > >
> > > > UDPSIC: This can use up all resources. If you have connection rate limit
> > > > function, then utilize it to limit the rate. Typically, each session is kept
> > > > for inactivity timeout period. If number of new packets within this timeout
> > > > period exceed number of session entries the IPS box supports, then further
> > > > new connections are not entertained. If the connection rate limit is set to
> > > > less than <Number of session entries supported by IPS>/<inactivity timeout>,
> > > > then IPS session entries don't get exhausted.
> > > >
> > > > If you still see 100% CPU problem, you may like to check you log settings.
> > > > If connection logging (for NBA) is enabled, then for every packet it might
> > > > be generating a log message and that might exhaust CPU.
> > > >
> > > > Even though it is obvious, let me state it anyway :-). If the input packet
> > > > rate is more than the CPU (that is running IPS) can process, then you see
> > > > 100% CPU problem.
> > > >
> > > > Thanks
> > > > Srini
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On
> > > > Behalf Of Ravi Chunduru
> > > > Sent: Wednesday, April 30, 2008 8:22 AM
> > > > To: focus-ids () securityfocus com
> > > > Subject: IPS/IDS behavior with ISIC/UDPSIC/TCPSIC/ICMPSIC traffic
> > > >
> > > > According to NSS testing criteria,  the IPS/IDS devices are expected
> > > > to work normally even during the time *SIC traffic is sent at
> > > > 60000pkts/sec with each packet size of 690 bytes. I find that inline
> > > > snort IPS software based PC device stops passing any legitimate
> > > > traffic when this *SIC traffic is sent at very high speed.  As such I
> > > > also see this problem even if UDPSIC traffic (with random ports) is
> > > > passed with 50000 pkts/sec.   Once the traffic is stopped, it starts
> > > > working normally. Note that if I use UDPSIC with fixed port, then I
> > > > don't see the problem of 100% CPU utilization and other traffic passes
> > > > normally.
> > > >
> > > > I am using PC with P4 processor running at 2.8Ghz.
> > > >
> > > >
> > > > Is there any significance to 60000 pkts/sec NSS number? Also, what is
> > > > the expected behavior of IPS software during this load?
> > > > Does NSS test with random UDP ports? Or do they use one fixed port
> > > > while running UDPSIC and TCPSIC?
> > > >
> > > > Thanks
> > > > Ravi
> > > >
> > > > ------------------------------------------------------------------------
> > > > Test Your IDS
> > > >
> > > > Is your IDS deployed correctly?
> > > > Find out quickly and easily by testing it
> > > > with real-world attacks from CORE IMPACT.
> > > > Go to
> > > > http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=in
> > > > tro_sfw
> > > > to learn more.
> > > > ------------------------------------------------------------------------
> > > >
> > > >
> > > > ********************************************************************************
> > > > This email message (including any attachments) is for the sole use of the intended recipient(s)
> > > > and may contain confidential, proprietary and privileged information. Any unauthorized review,
> > > > use, disclosure or distribution is prohibited. If you are not the intended recipient,
> > > > please immediately notify the sender by reply email and destroy all copies of the original message.
> > > > Thank you.
> > > >
> > > > Intoto Inc.
> > >
> > > ------------------------------------------------------------------------
> > > Test Your IDS
> > >
> > > Is your IDS deployed correctly?
> > > Find out quickly and easily by testing it
> > > with real-world attacks from CORE IMPACT.
> > > Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw
> > > to learn more.
> > > ------------------------------------------------------------------------
>
>
>
> --
> Computer Security Learner

------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it 
with real-world attacks from CORE IMPACT.
Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw 
to learn more.
------------------------------------------------------------------------