IDS mailing list archives
Re: Active response... some thoughts.
From: "mb_lima" <mb_lima () uol com br>
Date: Tue, 11 Feb 2003 08:06:53 -0200
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.
Thesesignature-
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
networktraffic 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
butwe 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
packetsbetween your attacker and your IDS, effectively decreasing
the
effectivenessof 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
thatway. How trivial would it be to write a script (for those
that can code)
tocontinue 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
quantitiesof 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
tellme 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,
fastand does the trick. I'm not sure if you guys have used In
truVert's
productlarge-
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
ignoredIMHO TCP-
reset is a cool technology, but I would always prefer silent
packetdropping by using an inline-
device for this purpose, e.g. snort-inline
withiptables 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
increasesthe 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
ofthe IDS, DoS your servers and create so much noise (both o
n your network
andyour 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
andactive response; the use of IDS sensors to detect attacks
and either make
apolicy 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,
Ican'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
thinkof this, because there are much smarter people on this lis
t than me, but
I'mcurious 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
ofthe 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
touse. 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
outexactly 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
responseto 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
bea 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
goodidea 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
easilypull 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/
Current thread:
- Re: Active response... some thoughts., (continued)
- Re: Active response... some thoughts. Ali Saifullah Khan (Feb 05)
- RE: Active response... some thoughts. Abe L. Getchell (Feb 06)
- Re: Active response... some thoughts. fr0ck9 (Feb 05)
- RE: Active response... some thoughts. Rob Shein (Feb 07)
- RE: Active response... some thoughts. Ralph Los (Feb 07)
- Re: Active response... some thoughts. SecurityFocus (Feb 10)
- RE: Active response... some thoughts. Ralph Los (Feb 07)
- Re: Active response... some thoughts. andre (Feb 08)
- Re: Active response... some thoughts. Frank Knobbe (Feb 10)
- RE: Active response... some thoughts. Rob Shein (Feb 11)
- Re: Active response... some thoughts. andre (Feb 08)
- Re: Active response... some thoughts. Ali Saifullah Khan (Feb 05)
- Re: Active response... some thoughts. mb_lima (Feb 11)
- RE: Active response... some thoughts. Steven Richards (Feb 12)