[Snort-devel] Stream5: RST handling + 'STREAM5_BAD_RST' alert
bram-fabeg at ...3414...
Thu Sep 19 15:34:41 EDT 2013
>>> 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 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:
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
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
-> this can be ignored, sorry for the confusion.
This message was sent using IMP, the Internet Messaging Program.
More information about the Snort-devel