[Snort-users] third party utility to kill ...
mkettler at ...4108...
Thu Jan 31 16:13:08 EST 2002
<I'm CCing back onto the snort list after some off-list exchanges because
others on the snort list may be able to correct some errors in my
statements. I'm not 100% sure my statements are entirely accurate, but I
belive them to be correct. I do not use flexresp or automated reset
reactions at all in my deployments of snort.>
Well, it is likely to be impossible to react to an attack detected by snort
faster than flexresp does. Definitely anything external to snort will be
many orders of magnitude slower because it will have the added overhead of
at least a context switch, and likely will have all kinds of other overhead
too (ie: process creation, reading an executable image from disk, etc).
Flexresp has the advantage of being internal to snort, being already in
memory, in the same process space, and directly callable by the code which
detects the offending packet.
As far as the limits of flexresp you are seeing... Are all three machines
(client, snort, webserver) running on the same ethernet network? You do
realize that if there is near zero propagation time from client to server
that TCP reset strategies are going to be a race condition at best. Snort
must get the tcp RST packet to one end before the client/server can
exchange ACKs in order to succeed. If network latency is low, it is
unlikely snort will be able to do so, and the RST will be ignored because
the TCP sequence number has moved on. (ignoring RSTs without the proper
sequence numbers is a security feature of TCP/IP stacks, if they didn't,
blind connection killing would be very easy).
Now realize that for real attacks the network latency experienced over the
internet from your attacker (or from your victim machine out to some
outside machine) is substantially greater than over a local ethernet LAN,
this greatly increases snort's chance of success. Even with this increased
chance of success, realize that snort's flexresp is really a limited
measure to try to control such attacks. Any sophisticated attacker who is
crafting packets can create an attack that will bypass any kind of TCP
reset reaction behavior in many cases.
Don't belive me that such a bypass is possible? Read a bit about how
purposefully sending tcp segments out-of-order helps this:
(interestingly that article pointed out a pcap latency bit on BSD variants
I was unaware of.)
flexresp is valuable, can slow an attacker down, will completely stop many
automated scripts, worms, etc over the internet, but it is *not* foolproof
and I would never depend on it as a sole source of protection. Treat it
with proper respect for the inherent limitations it has.
At 02:13 PM 1/31/2002 -0600, Ronneil Camara wrote:
>I'm using flexresp but it's a bit slow. I can see the RST sent by my snort
>But like with small GET request, I will still be able to view the site,
>like in case of unicode attack. If I do like this, GET
>I will still be able to see the directories.
>But if I added /s (all subfolders), like this, c+dir+c:\+/s then my
>request will totally be RESET.
More information about the Snort-users