Jeffrey,
 
very short of time yesterday. The issue is as you describe performance
against utilisation. I stand by my comments about a "majic box" to cure all
being unlikely. The ISS Guard does a great job of protecting networks and
devices being able to protect against the Code red's, Syn floods etc etc and
it DOES handle fragmented attacks but the attack mitigator also is a good
product, it is as you found not suitable for the busy networks whereas the
GFuard will work very well on a 100MBps link that is heavily utilised ---
and --- it forms part of the Fusion strategy of IDS.
 
I recently built a solution which I feel really does the job but it needed a
fair bit of product. We used Guards at the ISP portal and external;
semi-trusted links to defeat attacks from outside right doen to an attack
launched at ba desktop. We used network sensors just tn track any desktop to
desktop hacking, Server Sensor on Win and Solaris hosts and OS sensor on the
UX and AIX hosts. Finally we used System Scanner all hosts, Desktop
p[rotector on VPN connected remote laptops and tied it all together with
Fusion modules and Site Protector. Thius not only will we defeat attacks at
the network from outside and internally any attacks at any servers, but we
have also protected the remote laptops and correlated attacks against known
vulnerabilities to almost eliminate false positives and "information
overload. One neat thing about the Guards is they are bi-directional so if
anyone tries to hack out using the ISP link we will defeat it and know about
it! Neat huh?
 
JT
 

John Taylor | Director Security Products | Tolerant Systems Ltd | 01782
865026 | 07730 989255

This electronic message contains information from Tolerant Systems, which
may be privileged or confidential. The information is intended for use only
by the individual(s) or entity named above. If you are not the intended
recipient, be aware that any disclosure, copying, distribution or use of the
contents of this information is strictly prohibited. If you have received
this electronic message in error, please notify me by telephone or email (to
the number or email address above) immediately.

-----Original Message-----
From: Jeffrey Kok Chew Mun [mailto:ccekokjnus.edu.sg]
Sent: Friday, November 29, 2002 3:26 PM
To: SEdwardstoplayer.com; GlennPSTCG.net; issforumiss.net
Cc: CCE Net
Subject: RE: [ISSForum] Intrusion Detection vs Intrusion Prevention

Hi All,
 
I would like to share some experience that we had with Toplayer's Attack
Mitigator and
give a word of advise to anyone who is going to deploy the Attack Mitigator
(AM)
Our original plans was to deploy 6 units of AM into strategic network
locations to provide defence against DOS, DDOS and URL/URI protection.
 
The first look of the Attack Mitigator was pretty good and offered many
features that aren't avail in other network devices:
1) Session limiting based on IP or groups of IP which is very useful to
protect server against legitimate traffic DOS and DDOS.
2) ASIC based URL/URI filtering to counter the floods of Nimda and Codered
traffic
3) Syn floods protection with options to tweak the number of incomplete
sessions before being recogised as a DOS
 
After the the first unit was installed, everything looked normal enough and
the box's CPU utilization looked rather healthy too. After a couple of
hours, complaints were coming from all over the campus about connections
breaking, packet losses, takes a long time to connect, etc. Since the AM's
CPU utilization seemed healthy, we looked elsewhere and was troubleshooting
for a long time before isolating the problem to the AM.
 
After much pain, the problems were found and the following were our
findings:
1) ASIC are supposed to provide extremely high throughput but the ASIC on
the AM was rated to handle only 8000 sessions setup per second or 25,000
sessions setup in the event of a Syn Flood. The start of any TCP, UDP, ICMP
session setup is considered the starting of a session on the AM due to "flow
handling" On an average, our campus experience about 10,000 TCP sessions
setup per second. With UDP and ICMP, its way more than 10k. Thus packets
were dropped at random every second
2) The CPU utilization on the AM refers to the CPU of the AM which doesn't
indicate if there are any performance issues or packet drops on the AM since
these are on the ASIC.
3) The DOS that we had experienced come in the magnitude of about 800k per
seconds which is far beyond that of the capabilities of the AM. Toplayer's
advise was to use a load balancer to load balance a cluster of AM. Taking
cost out of the picture, its rediculous to deploy a farm of 10 or more AM
just to handle these attacks.
4) Even with nimda and codered filters enabled on the AM, nimda and codered
attacks were still slipping though the AM. It was later found this is
because the AM isn't able to recognised fragmented nimda and codered traffic
which is very easily done.
 
The idea behind the AM is really great and perfect for small WAN links of
SMEs
However, it will not have enough juice for ISP, IDC or campus networks which
are designed to handle millions of packets per seconds (even though it has
GE interfaces and ASICs)
After a one week stint with the AM and Toplayer's regional engineers, the
box was pulled out and all plans to deploy the AMs were scraped. Network
based Intrustion Protection is definitely very useful and we are still on
the lookout for suitable products for our environment.
 
cheers,
Jeffrey Kok
Systems Engineer
Computer Center
National University of Singapore
 

-----Original Message-----
From: SEdwardstoplayer.com [mailto:SEdwardstoplayer.com]
Sent: Wednesday, November 27, 2002 11:21 PM
To: GlennPSTCG.net; issforumiss.net
Subject: RE: [ISSForum] Intrusion Detection vs Intrusion Prevention

Hi Glenn,
 
The white paper we have produced has just gone up on our web site (the
proverbial ink is still wet on the PDF!) - it is entitled 'Beyond IDS :
Essentials of Network Intrusion Prevention' and can be got at through our
web site at www.toplayer.com <http://www.toplayer.com> via the 'Resource
Centre'
 
(I am afraid there is a customer registration form on there, if that is a
problem, let me know)
 
Cheers
 
Simon

-----Original Message-----
From: Glenn Ponich [mailto:GlennPSTCG.net]
Sent: 26 November 2002 11:35
To: issforumiss.net
Subject: [ISSForum] Intrusion Detection vs Intrusion Prevention

With all the posts I have seen lately regarding the subject line is there a
white paper available that explains the difference between the two and
possible pros and cons of each?

TYIA

Glenn Ponich

Network Security Administrator

Sierra Telephone

glennpstcg.net

_______________________________________________
ISSForum mailing list
ISSForumiss.net

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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]