Re: Active response... some thoughts.

["mb_lima" <mb_lima () uol com br>]

 Folks,

   It is good to remember that many IDS implementations send
TCP RST to the two endpoints in the communication. So a
hacker can change the stack in your OS, but he is not able to
do the same thing in the network internal machines. This is
enough to abort attack.
[]´s
   Marcelo


> 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 signa
ture-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 (w
orm, 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 SIG
NATURE-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 o
n 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 automat
ed solution.
> > Let's keep this in perspective, and realize some basic pri
nciples 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 silve
r 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 al
erts.
> > 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 o
r 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 ju
st poor
> practices, laziness I don't know.  Security by obscecurity d
oes 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 b
alls...but it's
> > probably going to be a debate that continues.
> (SF2/7/03) Latest buzzword here is what people are calling d
efense in
> depth...security takes the use of multiple tools.  We even u
se 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 s
trictly 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 ne
t;
> > focus-ids () securityfocus com
> > Subject: RE: Active response... some thoughts.
> >
> >
> > Ralph
> >
> > I agree!  Most security experts I have spoken to agree wit
h you as well.
> > However, Netscreen IDS features TCP reset as a major featu
re 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 t
he 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 perso
n
> > to which it is addressed and may contain confidential mate
rial. Review or
> > other use of this information by persons other than the in
tended recipient
> > is prohibited. If you've received this in error, please co
ntact 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 igno
re 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 ha
ve 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 o
ut 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 client
s call me to
> tell
> > me my IDS has participated in a DoS against their 'net.  F
or this reason I
> > stick with NetworkICE's (ISS, who?, heh) Guard product.  I
t's in-line,
> fast
> > and does the trick.  I'm not sure if you guys have used In
truVert's
> product
> > large-
scale, but I'm working with them to do some testing...sounds l
ike 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.n
rw.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 atta
cker with
> > tcp-resets anyway.
> >
> > Some other reasons:
> > * Generating tcp resets can decrease the performance of yo
ur 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 a
nd lots of fake
> > attacks to several hosts. Thus the attacker can decrease t
he performance
> of
> > the IDS, DoS your servers and create so much noise (both o
n your network
> and
> > your IDS) that you will no longer be able to determine wha
t'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 dete
ction 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 intrusi
ons itself
> > (through the use of TCP resets, ICMP port and network unre
achable's, etc).
> > While discussing the benefits and drawbacks we both feel c
ome 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 h
e 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 discus
sing 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 lis
t than me, but
> I'm
> > curious to know what the community here thinks about this.
..
> > Basically, it's possible for an attacker to calculate wher
e 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 respons
e 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 se
nsor has a
> > signature that resets the connection when it sees the expl
oit he's trying
> to
> > use.  When the attacker sends his exploit to the target se
rver, it doesn't
> > work.  Since this is a smart attacker, he grabs a packet c
apture to find
> out
> > exactly what's happening and sees that his connection is b
eing 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 usi
ng 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 fa
vorite 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 */ , IP
PROTO_TCP,
> >                 0, 0, NULL, 0, tcp_pkt);
> >
> > libnet_build_ip(ICMP_UNREACH_H, 0,
> >                 libnet_get_prand(PRu16) /* IP ID */ ,
> >                 0 /* fragmentation */ , 255 /* TTL */ , IP
PROTO_ICMP,
> >                 0, 0, NULL, 0, icmp_pkt);
> >
> > He sees that these bits of code build the IP header for th
e TCP
> > reset and ICMP unreachable messages that the IDS uses for
active response.
> > Knowing from this code that the TTL is statically set to 2
55 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 segmen
t the sensor
> > resides by using simple addition!  This information is inv
aluable to the
> > attacker for future attacks against the network, and he no
w 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 c
ouldn'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 wo
uld see a whole
> > bunch of resets come back with TTL's that wildly jump arou
nd, that would
> be
> > a clue that the organization he is attacking is using Snor
t... and telling
> > an attacker what IDS you're using, is of course, a bad thi
ng.  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 b
ecause
> > 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, t
his is just
> > another good reason _not_ to use active response... or if
you must, just
> > break the connection on the internal side.  The attacker c
ould manipulate
> > his TCP stack not to honor resets anyway. Thoughts?
> >
> > Thanks,
> > Abe
> >
> > --
> > Abe L. Getchell
> > Security Engineer
> > abegetchell () qx net


---
UOL, o melhor da Internet
http://www.uol.com.br/