RE: third party utility to kill ...

[Matt Kettler <mkettler () evi-inc com>]

<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:

http://www.securityfocus.com/infocus/1540

(interestingly that article pointed out a pcap latency bit on BSD variants 
I was unaware of.)

Bottom line:
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 
> in tcpdump.
> 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 
> /scripts/......cmd.exe?/c+dir+c:\
> 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.


_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users