Re: Snort+flexresp

[Jeff Nathan <jeff () snort org>]

Bamm Visscher wrote:
> Jeff,
>
> Thanks for the explanation about how flex-resp works. Although to me it
> seems you mixed "how it works" with "when/how to use it" and I disagree
> with some of your assertions. You seem to imply that flex-resp will only
> work with content based signatures. That is where I disagree. For
> example, rules like these:
>
> alert tcp 192.168.1.1 any <> any any (msg: "LOCAL Attempted session from
> perp."; flags:!R; resp:rst_all;)
>
> and
>
> alert tcp any any <> 10.1.1.1 1524 (msg: "LOCAL Attempted session to
> perps backdoor."; flags:!R; resp:rst_all;)
>
> will attempt kill any session to/from the "bad guy" or his backdoor, and
> as long as the protocol is "reset friendly" (ie ssh, FTP, SMTP, most tcp
> backdoors, etc), it will be very successful.
>
> Why would anyone use a rule like this? Because in some organizations
> (MSSPs, larger companies, etc), the individuals doing network security
> monitoring aren't necessarily handling the management of the
> firewalls/routers. With flex-resp, the analyst who detect a successful
> compromise can institute some type of "protection" until those
> responsible for the compromised system and/or the engineers responsible
> for FW management can be contacted and they can take the appropriate
> actions.
>
> 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