RE: Active response... some thoughts.

 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).

>

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

        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.liesen@lds.nrw.de [mailto:detmar.liesen@lds.nrw
.de]
> Sent: Tuesday, January 21, 2003 2:17 AM
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.
er with
> tcp-resets anyway.
 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.
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.

        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:
[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:
OTO_TCP,
> 0, 0, NULL, 0, tcp_pkt);
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.
>

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

        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?
 

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