Snort mailing list archives
Re: Stream5: RST handling + 'STREAM5_BAD_RST' alert
From: Bram <bram-fabeg () mail wizbit be>
Date: Thu, 19 Sep 2013 21:34:41 +0200
The question however is how the stream5 streamprocessor should be configured? What if it's a connection between a Linux system and a Windows system? The code in 'ValidRST' appears to be stricter for Windows than for Linux? What if the OS of one of the peers is unknown? And by extension: what if the OS of both peers is unknown? (a DHCP client connection to a server on internet for example)stream5_tcp bind_to and policy are available to tailor your configuration to your networks. You can configure stream5_tcp multiple times, once w/o bind_to (the default) and then with specific IP addresses/networks (non-default). The policy from the matching configuration or default will be used. See here for more: http://manual.snort.org/node17.html#SECTION00322700000000000000
I'm aware that this can be tailored, that wasn't the question. The question remains: what should the policy be set to if the OS of one of the peers - or both of the peers - is unknown? Setting it to any value will cause false positives...
Either way: the message of the alert 'Reset outside window' is at the very least confusing.. When the sequence number is inside the window but if/when the host ignores the RST then (IMO) a different alert should be generated. Right now it looks like an invalid RST packet is send/received which is not really the case..Actually, that should be the case. Do you have a pcap so I can see the specific scenario you are referring to? Per the RFC, a reset is valid if in window except in the SYN-sent state. So the message could be tweaked but it should still be a bad RST. Unless you have a more recent scenario the code does not address yet.
This all depends on the definition of 'bad'. Let's assume that the default policy is set to 'Windows' and that a connection is made from a Windows system to a server on the internet. The os of this server is unknown The peer can send a RST which is completely valid according to the TCP RFC but which will be marked as 'bad' because the implementation in snort does not check the TCP RFC but bases itself on the implementations (in this example the windows implementation). Assume this traffic: (window size 64K) windows > other: seq = 100, ack = 200 other > windows: seq = 200:205, ack = 100 windows > other: seq = 100:105, ack = 205 other > windows: seq = 220, RST flag set According to the RFC the RST packet send by 'other' is valid. It is inside the TCP window. According to the code in snort Windows ignores this RST (not actually verified): the code compares the sequence number of the reset packet (210) with 'r_nxt_ack' (205) => snort will generate a STREAM5_BAD_RST alert In this particular case I would expect to see a different alert ('STREAM5_RST_IGNORED_BY_HOST' or something). In my opinion the 'STREAM5_BAD_RST' alert should only be produced when the sequence in the packet is actually invalid according to the TCP RFC (= outside the TCP window). If the host chooses to ignore RFC-valid RST packets (which is/could be the case for windows) then it should show a different alert. Currently it uses the same alert for both which makes it less useful... Linking it back to the example above: For: 'other > windows: seq = 220, RST flag set' I do not expect 'STREAM5_BAD_RST' but something similar to 'STREAM5_RST_IGNORED_BY_HOST' For: 'other > windows: seq = 2200000000, RST flag set' I expect 'STREAM5_BAD_RST' because the sequence is completely outside the TCP window Does this makes sense to you?
* snort_stream5_tcp.c: 'Stream5GetWindow' function:
[...]
If window is non-zero then if the session is not midstream use the window .. Which reads correctly. If you have an example pcap, please send it along.
You are correct, this seems to have been a misinterpretation on my part.. More precisely how the window scaling is used, the bit that I was missing: when the window scaling option is set the 'l_window' is (already) adjusted and no longer refers to the raw window value in the tcp packet. -> this can be ignored, sorry for the confusion. Best regards, Bram ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ Snort-devel mailing list Snort-devel () lists sourceforge net https://lists.sourceforge.net/lists/listinfo/snort-devel Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel Please visit http://blog.snort.org for the latest news about Snort!
Current thread:
- Stream5: RST handling + 'STREAM5_BAD_RST' alert Bram (Aug 23)
- Re: Stream5: RST handling + 'STREAM5_BAD_RST' alert Bram (Sep 18)
- Re: Stream5: RST handling + 'STREAM5_BAD_RST' alert Russ Combs (Sep 19)
- Re: Stream5: RST handling + 'STREAM5_BAD_RST' alert Bram (Sep 19)
- Re: Stream5: RST handling + 'STREAM5_BAD_RST' alert Russ Combs (Sep 19)
- Re: Stream5: RST handling + 'STREAM5_BAD_RST' alert Bram (Sep 19)
- Re: Stream5: RST handling + 'STREAM5_BAD_RST' alert Russ Combs (Sep 23)
- Re: Stream5: RST handling + 'STREAM5_BAD_RST' alert Russ Combs (Sep 19)
- Re: Stream5: RST handling + 'STREAM5_BAD_RST' alert Bram (Sep 18)