<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 19, 2013 at 3:34 PM, Bram <span dir="ltr"><<a href="mailto:bram-fabeg@...3414..." target="_blank">bram-fabeg@...3414...</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The question however is how the stream5 streamprocessor should be<br>
configured?<br>
What if it's a connection between a Linux system and a Windows system?<br>
The code in 'ValidRST' appears to be stricter for Windows than for Linux?<br>
What if the OS of one of the peers is unknown?<br>
And by extension: what if the OS of both peers is unknown? (a DHCP<br>
 client connection to a server on internet for example)<br>
<br>
</blockquote>
<br>
</blockquote>
stream5_tcp bind_to and policy are available to tailor your configuration<br>
to your networks.  You can configure stream5_tcp multiple times, once w/o<br>
bind_to (the default) and then with specific IP addresses/networks<br>
(non-default).  The policy from the matching configuration or default will<br>
be used.  See here for more:<br>
<br>
 <a href="http://manual.snort.org/node17.html#SECTION00322700000000000000" target="_blank">http://manual.snort.org/<u></u>node17.html#<u></u>SECTION00322700000000000000</a><br>
</blockquote>
<br></div>
I'm aware that this can be tailored, that wasn't the question.<br>
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?<br>
Setting it to any value will cause false positives...</blockquote><div><br></div><div>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.<br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Either way: the message of the alert 'Reset outside window' is at the<br>
 very least confusing..<br>
When the sequence number is inside the window but if/when the host<br>
 ignores the RST then (IMO) a different alert should be generated.<br>
Right now it looks like an invalid RST packet is send/received which  is<br>
not really the case..<br>
<br>
</blockquote>
<br>
</blockquote>
Actually, that should be the case.  Do you have a pcap so I can see the<br>
specific scenario you are referring to?  Per the RFC, a reset is valid if<br>
in window except in the SYN-sent state.  So the message could be tweaked<br>
but it should still be a bad RST.  Unless you have a more recent scenario<br>
the code does not address yet.<br>
</blockquote>
<br></div>
This all depends on the definition of 'bad'.<br>
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<br>
<br>
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).<br>


<br>
Assume this traffic: (window size 64K)<br>
<br>
windows > other: seq = 100, ack = 200<br>
other > windows: seq = 200:205, ack = 100<br>
windows > other: seq = 100:105, ack = 205<br>
other > windows: seq = 220, RST flag set<br>
<br>
According to the RFC the RST packet send by 'other' is valid.<br>
It is inside the TCP window.<br>
<br>
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)<br>
<br>
=> snort will generate a STREAM5_BAD_RST alert<br>
<br>
In this particular case I would expect to see a different alert ('STREAM5_RST_IGNORED_BY_HOST' or something).<br>
<br>
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).<br>
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.<br>
<br>
Currently it uses the same alert for both which makes it less useful...<br>
<br>
Linking it back to the example above:<br>
<br>
For: 'other > windows: seq = 220, RST flag set' I do not expect 'STREAM5_BAD_RST' but something similar to 'STREAM5_RST_IGNORED_BY_HOST'<br>
For: 'other > windows: seq = 2200000000, RST flag set' I expect 'STREAM5_BAD_RST' because the sequence is completely outside the TCP window<br>
<br>
Does this makes sense to you?<br></blockquote><div><br></div><div>Sure, but in both cases the RST is ignored by the receiving host. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
* snort_stream5_tcp.c: 'Stream5GetWindow' function:<br>
</blockquote></blockquote></blockquote>
[...]<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
If window is non-zero then<br>
    if the session is not midstream<br>
        use the window<br>
..<br>
<br>
<br></div><div>
Which reads correctly.  If you have an example pcap, please send it along.<br>
</div></blockquote>
<br>
You are correct, this seems to have been a misinterpretation on my part..<br>
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.<br>


-> this can be ignored, sorry for the confusion.<div><div><br>
<br>
<br>
Best regards,<br>
<br>
Bram<br>
<br>
<br>
------------------------------<u></u>------------------------------<u></u>----<br>
This message was sent using IMP, the Internet Messaging Program.<br>
<br>
</div></div></blockquote></div><br></div></div>