Re: Active response... some thoughts.

["SecurityFocus" <securityfocus () mitchelhome com>]

Please see my comments below (SF2/7/03)
Take care,  SF
----- Original Message -----
From: "Ralph Los" <RLos () enteredge com>
To: "'Alan Shimel'" <alan () latis com>; <detmar.liesen () lds nrw de>;
<abegetchell () qx net>; <focus-ids () securityfocus com>
Sent: Thursday, February 06, 2003 11:41 PM
Subject: RE: Active response... some thoughts.


> Alan, all,
>
> Without getting too much into single-vendor bashing, praising,
> otherwise, let me take a step back and talk to iPs(es).  I've heard a lot
of
> "buzz" lately from vendors (again, they will go un-named) about Intrusion
> Prevention Systems.  Well, the majority of these are signature-based.
These
> signature-based IPSes can actively BLOCK an attack from coming into the
> system, even single packet attacks.  This is useful in the following
> scenario:
> A single-packet attack (UDP or TCP) comes down the wire, the IDS
> accepts it, finds a pattern matching a malicious packet (worm, etc) and
> drops the packet on the wire before it gets past the in-line IDS.
> However...and I say a BIG however, this ONLY WORKS for SIGNATURE-BASED
> detection.  I can't even fathom putting an IDS/IPS in-line currently that
> does "anomaly detection" and active drops.  If all of the sudden my
network
> traffic changed, say for the sake of argument that this is legit traffic
> pattern changes, and the IPS drops these?  That's my job on the line and
> real dollars down the drain.
> I agree whole-heartedly that Intrusion Detection/Prevention has yet
> a lot of maturation to become useful as more of an automated solution.
> Let's keep this in perspective, and realize some basic principles here as
> security professionals:
> 1. Security is a process not a product, right?
(SF2/7/03) You hit that one on the head....there is no silver bullet.
> 2. We would rather see LESS false-positives...at least I'd like it
> 3. Active-response is great if you have a signature for it
> already... (on-the-wire drops)
(SF2/7/03) Signatures cant really be trusted...i.e. false alerts.
> 4. Most major (real-world) threats are NON-SIGNATURE-READY attacks.
> To clarify, SLAMMER was something an in-line IPS could drop if we were
> psychic and were dropping packets based on a non-existant signature.
(SF2/7/03) Signatures don't detect encrypted, undocumented or morphing
attacks so they are only helpful to a degree.
> 5. Firewalls are still our friends.  They're a commodity!  It still
> baffles me that people are allowing all traffic EXCEPT x, y, z into their
> network...WHY?!
(SF2/7/03) Had me scratching my head here as well...is it just poor
practices, laziness I don't know.  Security by obscecurity does not
work...implement real policy that mean policy on what comes in AND dont
forget about what goes out.
> I see potential in both types of IDSes/IPSes.  On-the-wire fits some
> topolgies, and span-port (TCP-RST) fits in some.  I can't really tell you
> which is better because we're comparing apples to cannon balls...but it's
> probably going to be a debate that continues.
(SF2/7/03) Latest buzzword here is what people are calling defense in
depth...security takes the use of multiple tools.  We even use multiple
layers of firewalls that are different vendors on purpose....this way we
hope that if there is a vunerability that exits on one brand the other wont
have the same vunerability.
> ...just my $0.02.  Standard disclaimer about these being strictly my
> opinions and not that of any of my employers applies.
>
> /Ralph/
>
> -----Original Message-----
> From: Alan Shimel [mailto:alan () latis com]
> Sent: Sunday, January 26, 2003 11:45 PM
> To: Ralph Los; detmar.liesen () lds nrw de; abegetchell () qx net;
> focus-ids () securityfocus com
> Subject: RE: Active response... some thoughts.
>
>
> Ralph
>
> I agree!  Most security experts I have spoken to agree with you as well.
> However, Netscreen IDS features TCP reset as a major feature of their
> product and sell prospective customers on it.  I don't get it personally
but
> we were forced to implement and support it just to match the feature for
> those customers who demanded it
>
> alan
>
> Alan Shimel
> VP of Sales & Business Development
> Latis Networks, Inc.
>
> 303-642-4515 Direct
> 516-857-7409 Mobile
> 303-642-4501 Fax
>
> www.stillsecure.com
> Reducing your risk has never been this easy.
> . . .
> The information transmitted is intended only for the person
> to which it is addressed and may contain confidential material. Review or
> other use of this information by persons other than the intended recipient
> is prohibited. If you've received this in error, please contact the sender
> and delete from any computer.
>
> -----Original Message-----
> From: Ralph Los [mailto:RLos () enteredge com]
> Sent: Friday, January 24, 2003 10:39 AM
> To: 'detmar.liesen () lds nrw de'; 'abegetchell () qx net';
> 'focus-ids () securityfocus com'
> Subject: RE: Active response... some thoughts.
>
> Gentlemen,
>
> I can't agree more.  I implement and support IDSes at some very
> large companies and even some small ones, and TCP-Reset is not a widely
> popular nor, IMHO, effective strategy.  First off, as the email mentions
> below, the attacker can just simply hack his stack to ignore the
> resets...hey, it's possible.  Also, TCP-Resets can create a storm of
packets
> between your attacker and your IDS, effectively decreasing the
effectiveness
> of the IDS you have.
>
> Picture this...you have an attacker who figures our you have an
> IDS...woo hoo, right?  Well, the attacker then proceeds to think that it's
> better to just wipe you off the 'net than to hack your box, less effort
that
> way.  How trivial would it be to write a script (for those that can code)
to
> continue to supply large-quantities of packets at the target host.  These
> packets get intercepted by the IDS and it starts to send out huge
quantities
> of TCP-Resets.  The router in-between starts to see utilization go up, up,
> up until you have a saturated circuit - and what's worse, you're partly to
> blame.  I can't afford to have an instance where my clients call me to
tell
> me my IDS has participated in a DoS against their 'net.  For this reason I
> stick with NetworkICE's (ISS, who?, heh) Guard product.  It's in-line,
fast
> and does the trick.  I'm not sure if you guys have used IntruVert's
product
> large-scale, but I'm working with them to do some testing...sounds like a
> competitor to Guard.
>
> Anyway - the point sir, we well made, and well taken.  But I have to
> say that in 75%+ of my managed networks, I don't care because I wouldn't
> implement at TCP-Reset product anyway :)
>
> Just my personal, very humble opinion
> Ralph
>
> -----Original Message-----
> From: detmar.liesen () lds nrw de [mailto:detmar.liesen () lds nrw de]
> Sent: Tuesday, January 21, 2003 2:17 AM
> To: abegetchell () qx net; focus-ids () securityfocus com
> Subject: AW: Active response... some thoughts.
>
>
> You already outlined the drawbacks very well.
>
> As you said
>
> * You give valuable information to the hacker
> * The attacker could modify his IP-stack such that resets are being
ignored
> IMHO TCP-reset is a cool technology, but I would always prefer silent
packet
> dropping by using an inline-device for this purpose, e.g. snort-inline
with
> iptables or RealSecure Guard.
>
> It's better to create a "blackhole" than flooding the attacker with
> tcp-resets anyway.
>
> Some other reasons:
> * Generating tcp resets can decrease the performance of your IDS a great
> deal, especially on fast links. Depending on the protocol in use you
> probably have to reset lots and lots of resets (check out VNC as an
> example). To be sure you must reset both client and server, which
increases
> the performance issues.
> * As you outlined, tcp-resets can tell the attacker that your site is
> running an IDS, whatever flavour shall be irrelevant right now. If the
> attacker knows that your IDS is sending out resets he can use this
> information in order to blind the IDS by generating lots and lots of fake
> attacks to several hosts. Thus the attacker can decrease the performance
of
> the IDS, DoS your servers and create so much noise (both on your network
and
> your IDS) that you will no longer be able to determine what's the real
> attack. At least it's getting much more complicated.
>
> IMHO the drawbacks of tcp-reset exceed the pros by far.
>
> Greetings,
>
> Detmar Liesen
>
>
>  -----Ursprüngliche Nachricht-----
> Von: Abe L. Getchell [mailto:abegetchell () qx net]
> Gesendet: Donnerstag, 16. Januar 2003 19:37
> An: focus-ids () securityfocus com
> Betreff: Active response... some thoughts.
>
> Greetings all,
> Yesterday I was discussing one of my favorite topics with a friend
> who works at Enterasys.  We were discussing intrusion detection systems
and
> active response; the use of IDS sensors to detect attacks and either make
a
> policy change on a firewall or actively respond to intrusions itself
> (through the use of TCP resets, ICMP port and network unreachable's, etc).
> While discussing the benefits and drawbacks we both feel come along with
> this technology, I mentioned a specific issue I had with a sensor directly
> responding to detects, and he said it was something that he had never
> thought of before.  After poking around for a while in the list archives,
I
> can't find anywhere where it's mentioned, even when discussing this
> particular topic.  I find it hard to believe that I'm the first one to
think
> of this, because there are much smarter people on this list than me, but
I'm
> curious to know what the community here thinks about this...
> Basically, it's possible for an attacker to calculate where an IDS
> sits on an organization's network by looking at the TTL in the IP header
of
> the TCP reset or ICMP error message he receives in response to an attack.
> For example, let's say we have the following network setup:
>
> [Server]--[Router]--[Router]--[IDS]--[Firewall]--[Router]--[Router]--[At
> tacker]
>
> The attacker is trying to break into the server and the sensor has a
> signature that resets the connection when it sees the exploit he's trying
to
> use.  When the attacker sends his exploit to the target server, it doesn't
> work.  Since this is a smart attacker, he grabs a packet capture to find
out
> exactly what's happening and sees that his connection is being reset.  He
> notices that in the resets the TTL in the IP header is 252 compared to 250
> for normal responses.  Knowing now that an IDS must be using active
response
> to keep him from exploiting the target server, he wants to find out where
> this sensor resides. Referencing the source code of his favorite IDS (and
> mine - Snort 1.9.0 from http://www.snort.org/ (SHAMELESS PLUG)), he finds
> the following bits of code in sp_respond.c:
>
> libnet_build_ip(TCP_H, 0,
>                 libnet_get_prand(PRu16) /* IP ID */ ,
>                 0 /* fragmentation */ , 255 /* TTL */ , IPPROTO_TCP,
>                 0, 0, NULL, 0, tcp_pkt);
>
> libnet_build_ip(ICMP_UNREACH_H, 0,
>                 libnet_get_prand(PRu16) /* IP ID */ ,
>                 0 /* fragmentation */ , 255 /* TTL */ , IPPROTO_ICMP,
>                 0, 0, NULL, 0, icmp_pkt);
>
> He sees that these bits of code build the IP header for the TCP
> reset and ICMP unreachable messages that the IDS uses for active response.
> Knowing from this code that the TTL is statically set to 255 and hence,
> that's what it was when the reset left the NIC of the IDS, he can then
> easily trace the path backwards through each hop (assuming there's no
> asymmetric routing happening) and determine on what segment the sensor
> resides by using simple addition!  This information is invaluable to the
> attacker for future attacks against the network, and he now knows where he
> should focus his attack if he wants to disable the sensor itself.
> I posted a message about this on the Snort developers list quite
> some time ago, which got a good discussion going, but we couldn't come up
> with a good solution to this problem.  I believe the best idea that we can
> up with was to randomize the TTL, though if an attacker would see a whole
> bunch of resets come back with TTL's that wildly jump around, that would
be
> a clue that the organization he is attacking is using Snort... and telling
> an attacker what IDS you're using, is of course, a bad thing.  Another
good
> idea was to let the user specify (in a configuration file somewhere for
> those that don't build from source) a TTL that they wanted to use...
> obviously you'd want to use some off-the-wall number like 213 or so.  The
> attacker wouldn't know what hop to count back too because he wouldn't know
> what the TTL was originally set too.
> Please note that I'm only using Snort as an example here because
> it's the only IDS software that I have the source code for and could
easily
> pull an example from.  I believe, but am not _sure_, that probably all IDS
> software is affected by this specific issue.  Of course, this is just
> another good reason _not_ to use active response... or if you must, just
> break the connection on the internal side.  The attacker could manipulate
> his TCP stack not to honor resets anyway. Thoughts?
>
> Thanks,
> Abe
>
> --
> Abe L. Getchell
> Security Engineer
> abegetchell () qx net