On Sat, May 24, 2008 at 11:40 AM, Ravi Chunduru <[EMAIL PROTECTED]> wrote: > Hi, > > What do you mean by "attacks must be detected at much earlier stages > when creating a NETWORK"?
Sanjay>> at the time of creating Botnet i.e detecting the infection of individual system. > 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). sanjay>> NO, i did not mean this. its clear now, i suppose. > > Ravi > > > On Mon, May 19, 2008 at 8:00 AM, Sanjay R <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >>> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >>>> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >>>>> Behalf Of Ravi Chunduru >>>>> Sent: Wednesday, April 30, 2008 8:22 AM >>>>> To: [email protected] >>>>> 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 >> > -- 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. ------------------------------------------------------------------------
