Re: Active response... some thoughts.

 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)
.de>;
> <abegetchell@qx.net>; <focus-ids@securityfocus.com>
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
 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.
 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.
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.
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
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.
> > . . .
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.
 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
 the
> effectiveness
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
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
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
stack such that resets are being
> ignored
> >
> > IMHO TCP-

reset is a cool technology, but I would always prefer silent
> packet
device for this purpose, e.g. snort-inline
> with
> > iptables or RealSecure Guard.
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
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,
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
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]
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
 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
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/