Re: Stream5: RST handling + 'STREAM5_BAD_RST' alert

[Russ Combs <rcombs () sourcefire com>]

On Thu, Sep 19, 2013 at 3:34 PM, Bram <bram-fabeg () mail wizbit be> 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.
------------------------------------------------------------------------------
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!