[Snort-devel] Stream5: RST handling + 'STREAM5_BAD_RST' alert
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
>>>> 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
>>>> 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
>> 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:
> 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,
> This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-devel