Hi Ralph,

>
        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

  I worked in a company where TCP-Reset was not used only in
the signatures with high possibility to false positives.

> popular nor, IMHO, effective strategy. First off, as the em
ail 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

 I don´t agree because TCP RST is sucessful to stop script
kiddies. Attacks more sofisticated are few and we know that
there are many ways to bypass IDS sensors (more easy ways).

>
        Picture this...you have an attacker who figures our yo
u have an
> IDS...woo hoo, right? Well, the attacker then proceeds to t
hink 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 t
hat 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-

 Really, this is a problem. But again, here we have a more
sofisticated attacker.
Best Regards,

   Marcelo Lima.

>
> -----Original Message-----
> From: detmar.liesenlds.nrw.de [mailto:detmar.liesenlds.nrw
.de]
> Sent: Tuesday, January 21, 2003 2:17 AM
> To: abegetchellqx.net; focus-idssecurityfocus.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 p
acket
> 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 attack
er 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 VN
C 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 n
ow. If the
> attacker knows that your IDS is sending out resets he can us
e 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:abegetchellqx.net]
> Gesendet: Donnerstag, 16. Januar 2003 19:37
> An: focus-idssecurityfocus.com
> Betreff: Active response... some thoughts.
>
> Greetings all,
>
        Yesterday I was discussing one of my favorite topics w
ith a friend
> who works at Enterasys. We were discussing intrusion detect
ion systems and
> active response; the use of IDS sensors to detect attacks an
d either make a
> policy change on a firewall or actively respond to intrusion
s itself
> (through the use of TCP resets, ICMP port and network unreac
hable's, etc).
> While discussing the benefits and drawbacks we both feel com
e along with
> this technology, I mentioned a specific issue I had with a s
ensor 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 l
ist archives, I
> can't find anywhere where it's mentioned, even when discussi
ng this
> particular topic. I find it hard to believe that I'm the fi
rst 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 t
he 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 th
e sensor has a
> signature that resets the connection when it sees the exploi
t he's trying to
> use. When the attacker sends his exploit to the target serv
er, it doesn't
> work. Since this is a smart attacker, he grabs a packet cap
ture to find out
> exactly what's happening and sees that his connection is bei
ng reset. He
> notices that in the resets the TTL in the IP header is 252 c
ompared 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 f
ind out where
> this sensor resides. Referencing the source code of his favo
rite 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 */ , IPPR
OTO_TCP,
> 0, 0, NULL, 0, tcp_pkt);
>
> libnet_build_ip(ICMP_UNREACH_H, 0,
> libnet_get_prand(PRu16) /* IP ID */ ,
> 0 /* fragmentation */ , 255 /* TTL */ , IPPR
OTO_ICMP,
> 0, 0, NULL, 0, icmp_pkt);
>
>
        He sees that these bits of code build the IP header fo
r the TCP
> reset and ICMP unreachable messages that the IDS uses for ac
tive 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, h
e can then
> easily trace the path backwards through each hop (assuming t
here's no
> asymmetric routing happening) and determine on what segment
the sensor
> resides by using simple addition! This information is inval
uable 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 it
self.
>
        I posted a message about this on the Snort developers
list quite
> some time ago, which got a good discussion going, but we cou
ldn't come up
> with a good solution to this problem. I believe the best id
ea that we can
> up with was to randomize the TTL, though if an attacker woul
d 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 so
mewhere for
> those that don't build from source) a TTL that they wanted t
o 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 he
re because
> it's the only IDS software that I have the source code for a
nd could easily
> pull an example from. I believe, but am not _sure_, that pr
obably all IDS
> software is affected by this specific issue. Of course, thi
s is just
> another good reason _not_ to use active response... or if yo
u must, just
> break the connection on the internal side. The attacker cou
ld manipulate
> his TCP stack not to honor resets anyway. Thoughts?
>
> Thanks,
> Abe
>
> --
> Abe L. Getchell
> Security Engineer
> abegetchellqx.net
>
>
>
>
>
>

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

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