Re: Snort+flexresp

[Bamm Visscher <bamm () satx rr com>]

Jeff,

Okay, I think I finally see what you are driving at. Your concern is
that flex-resp will not be able to kill a connection before it can
establish a session. While my intent with these rules, is to kill a
session before any communcations (ie execed commands) can take place.
So, although snort will alert and attempt to use flex resp to kill the
connection on the initial syn packet (will flex-resp be able to use the
ack in the syn/ack to craft a reset?), it won't be successful until it
gets an (good) ack. This is not a problem since once the session has
been established and either end tries to send data, the connection will
be successfully killed. Yes, this will generate multiple alerts, but the
point of instituting an alert like this is to keep the perp from
communicating (execing commands etc) with the compromised server. This
of course all depends (like I said in each post) on the protocol doing
the "communicating". HTTP is not very reset friendly, while interactive
services like ssh, telnet, FTP, etc. are. 

BTW, maybe a better rule would use (flags: !RS;).

Bammkkkk




> Aloha,
>
> I understand users and administrators would like to use flexresp in
that
> fashion but the current state of the code isn't designed to do that.
>
> Right now, sp_respond doesn't evaluate the TCP flags of the packet
it's
> responding to, which would be required to calculate the correct ACK
> number for a SYN and for any other TCP flag that must be acknowledged
by
> advancing the ACK number forward one byte (FIN in particular).  So,
when
> a TCP packet is generated for an SYN in the case you mention above,
the
> ACK will be off by one and probably disregarded by the client IP
stack.
> If there is sufficient interest in providing this sort of
functionality,
> it would be considered but the likelihood of it being able to
> successfully snipe a session is slim.  Even though sp_respond pre
caches
> the response packet, it's still a little costly on your CPU.  Adding
> functionality to more carefully calculate the ACK number of a response
> packet will also slow it down further.  We're playing with such small
> tolerances here, adding latency could guarantee failure.
>
> See, we're hoping that snort can issue a RST before a state transition
> occurs on the client's IP stack and the ACK window advances.  If a
state
> transition doesn't occur and our ACK number is correct (or within the
> acceptable window) the RST will probably work.  If a state transition
> has occurred, our RST will be ignored.  So if snort doesn't send the
RST
> very very quickly, the RST will arrive after the client's IP stack has
> already transitioned state.
>
> -Jeff
>
> -- 
> http://jeff.wwti.com            (pgp key available)
> "Common sense is the collection of prejudices acquired by age
eighteen."
> - Albert Einstein



_______________________________________________
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