[Snort-devel] Stream5: RST handling + 'STREAM5_BAD_RST' alert

Russ Combs rcombs at ...402...
Thu Sep 19 17:02:40 EDT 2013


On Thu, Sep 19, 2013 at 3:34 PM, Bram <bram-fabeg at ...3414...> wrote:

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


You can pick only one default so, yes, false positives are possible.  Open
source Snort supports the attribute table for a more dynamic
configuration.  There are tools available like Hogger that automatically
update the attribute table for you.

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

Sure, but in both cases the RST is ignored by the receiving host.

>
>
>
>>>> * 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130919/bd8209a7/attachment.html>


More information about the Snort-devel mailing list