I had a chance to test ManHunt, the biggest problem i had with it, that i have had with other IDS's is that i cannot see the packets or perform a session reconstruction. that 1 issue led me to blow it off (until this is "fixed"). i mean with any ids product, are we supposed to simply take the IDS's word that the attack was a legitimate attack? if so i would have already been discredited in my agency and no one would listen to me if i had a real attack. the engineer's response was to "look at the system logs". well i don't know about you, but the USDA has more than 3,000,000 IP addresses, and i am by no means have logins to even a small fraction of those machines. so, once i saw that 1 issue i stopped looking at it, it wasn't worth my time to evaluate anymore.
~ Karl

<EOF>
================================================
Karl Hill | Security Engineer
970.295.5293 | USDA OCIO NTSO WAN Team
"...firewalls are speed bumps not brick walls."

> -----Original Message-----
> From: Nelson, Marcus
> Sent: Friday, March 30, 2001 1:09 PM
> To: FOCUS-IDSSECURITYFOCUS.COM%inter2
> Subject: Re: IDS triggering (stick,snot,etc)
>
>
> Has anyone had any experience with ManHunt from Resource Technologies?
> (http://www.recourse.com)
>
> According to the sales pitch, it does protocol anomaly
> detection, does not
> rely on a signature base and can monitor in excess of 1GB of traffic.
>
> I would like to hear more from the community on this product.
>
> Thanks,
>
> Marcus
> -----Original Message-----
> From: Blake Matheny [mailto:blake.r.mathenyMAIL.SPRINT.COM]
> Sent: Friday, March 30, 2001 8:31 AM
> To: FOCUS-IDSSECURITYFOCUS.COM
> Subject: Re: IDS triggering (stick,snot,etc)
>
>
> I'm not sure how response checking could accurately work, and I don't
> think that it is any solution to our 'problem'. Response checking just
> makes things worse, because not only do you have all this traffic from
> the IDS flood, but now you are generating a bunch more traffic trying
> to validate hosts, etc. The only real issue I can see with following
> state is, that TCP packets can come out of sequence, so you could have
> in that case IDS probes ignoring many valid alarms, or having valid
> traffic set off false alarms. People can also spoof the initial 3 way
> handshake. IPF has stateful inspection, but only for traffic that
> originated from behind the firewall. This same concept can't truly be
> applied for inbound connections. It seems like a better idea would be
> developing better algorithms for anomaly detection. Signature
> based IDS
> software is OK, but you have to update it to include all the 0-day
> exploits, and there is always of course, an issue with people keeping
> exploits private. However if you have an IDS system looking for
> anomalies in traffic, you have software ignoring many more
> false alarms
> and focusing in on where the traffic could be coming from.
> Personally I
> think AI work is going to be the future of better IDS systems. For now
> though, I think Arthur Money has the right idea, write better
> software.
> -Blake
>
> -----Original Message-----
> From: elliot.tilley [mailto:elliot_tilleyCITADEL.COM.AU]
> Sent: Thursday, March 29, 2001 7:17 PM
> To: FOCUS-IDS
> Subject: IDS triggering (stick,snot,etc)
>
>
>
> It seems that the tools that are becoming available to trigger
> alerts on an IDS, such as stick and now snot, both generate packets
> that the
> IDS 'wants to see' ie they send a single tcp, udp or icmp packet that
> will
> match a snort rule, in the case of snot if you actually look at the
> packets
> generated, they look nothing like a real attack, but they have the
> string
> that snort is looking for in them, I guess the random timing and data
> in the
> payloads is an attempt to make it difficult to detect that the packet
> came
> from this tool (for the IDS anyway). If intrusion detection
> systems had
> some
> fundamental knowlegde of how any of the protocols it was monitoring
> worked,
> wouldn't it be able to distinguish between a single tcp
> packet designed
> to
> trigger an alert, and one that was part of an actual tcp
> connection? I'm
> sure keeping state of connections into your network would be no simple
> task,
> but it would allow the ids to disregard packets that had no chace of
> being
> part of an actual attack. Granted that udp and other
> stateless protocols
> would be more difficult to monitor, although having used ipf
> on openbsd
> as
> my firewall at home for some time now I'm impressed with the
> way it can
> *sort of* keep state of udp and icmp (in that it knows when
> to expect a
> udp
> response from a dns server, or icmp error messages in repsonse to tcp
> connections). Wouldn't it also be possible to use
> multiple rules to
> trigger a single alert? ie, a packet coming into the network
> looks like
> an
> attack, but the alert won't trigger until the IDS sees the response
> from the
> machine it was aimed at indicating that the attack is legitimate.
> The problem with these ids flooding tools is that it's
> too easy to
> generate packets with a spoofed address, and keeping state of the
> connections into your network, at least for tcp anyway, will mean that
> either these tools rely on stateless protocols, eliminating
> the ability
> to
> trigger tcp based alerts, or they use a real ip address and create
> connections to your network to trigger the alerts, which isn't
> impossible
> either, but certainly makes it a bit more difficult to trigger alerts
> from
> many different addresses from the one point.
> I know that this is by no means a solution, but these ideas have
> been floating around my head for a while now, I thought
> someone may have
> some comments about them.
>
> PS - I have heard that Network ICE does some kind of response
> checking,
> but haven't any experinace with this particular product, if anyone had
> any
> comments on this I would be interested to hear them. I would also be
> interested to know if anyone has tried snot or stick against anything
> other
> than RealSecure and Snort and what the effects were, as these are the
> only
> two I have access to.
>
> Elliot Tilley
> Technical Security Consultant
> Citadel Securix
>
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system administrator, mailto:mswcitadel.com.au.
>
> Feel free to visit the Citadel Securix website! Click below.
> http://www.citadel.com.au
> **********************************************************************
>

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