Hi
JT,
I
guess great minds think alike.
We are
looking at the possiblity of deploy Server Sensors to all servers and
Desktop Sensors to all workstations. Internet Scanner will scan all servers and
selected desktops. Network Sensors will be positioned in strategic positions of
the network. Of course, SiteProtector will be used to manageall of these
devices and correlate all the info (to reduce the tons of
events)
We had
thought of putting Guards in place of the Network Sensors in those strategic
locations but at the time of evaluation, the highest end x86 machine wasn't
quite sufficent (or at least provide sufficient confidence level to us) to
effectively run the guard in those locations. With Hyperthreading, PCI-X and SMP
3Ghz machines coming over the horizon, I believe we will be relooking at the
Guards again in 2003.
Back
to the original point,
its
better to deploy a fleet of HIDS on servers and desktops than to deploy a magic
box on a strategic location. Then agian, it doesn't hurt to put another layer of
IDP just in case some jokers fail to deploy a HIDS.
cheers,
Jeffrey Kok
-----Original Message-----
From: John Taylor [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 03, 2002 6:59 PM
To: Jeffrey Kok Chew Mun; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: CCE Net
Subject: RE: [ISSForum] Intrusion Detection vs Intrusion PreventionJeffrey,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?JTJohn 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:[EMAIL PROTECTED]]
Sent: Friday, November 29, 2002 3:26 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: CCE Net
Subject: RE: [ISSForum] Intrusion Detection vs Intrusion PreventionHi All,I would like to share some experience that we had with Toplayer's Attack Mitigator andgive 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 traffic3) Syn floods protection with options to tweak the number of incomplete sessions before being recogised as a DOSAfter 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 second2) 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 SMEsHowever, 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 KokSystems EngineerComputer CenterNational University of Singapore-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 27, 2002 11:21 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [ISSForum] Intrusion Detection vs Intrusion PreventionHi 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 via the 'Resource Centre'(I am afraid there is a customer registration form on there, if that is a problem, let me know)CheersSimon-----Original Message-----
From: Glenn Ponich [mailto:[EMAIL PROTECTED]]
Sent: 26 November 2002 11:35
To: [EMAIL PROTECTED]
Subject: [ISSForum] Intrusion Detection vs Intrusion PreventionWith 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
Network Security Administrator
Sierra Telephone
[EMAIL PROTECTED]
