Re: [Emerging-Sigs] TCP Portals: The Handshake's a Lie!

[Jason Brvenik <jasonb () sourcefire com>]

On Tue, Nov 24, 2009 at 12:01 AM, Frank Knobbe <frank () knobbe us> wrote:
> On Fri, 2009-11-20 at 11:12 -0500, Jason Brvenik wrote:
> > My casual read on it was that you would have to be dealing with a
> > malicious server which deliberately responds to a syn with a syn and
> > that the likelihood of that is not the greatest. If it does happen the
> > server is going to be doing a lot of other more malicious things.
>
>
> Hey Jason,
>
> I think the point is that it is not malicious, but actually permitted
> per RFC. If a server responds with a SYN to a SYN in order to
> synchronize sequence numbers through simultaneous initiation, it appears
> to be perfectly fine, even though unusual.

While fine and likely supported behavior in a few clients, it is not
normal. The only servers that would be responding with a SYN would be
malicious ones.


> >  My
> > presumptions are:
> >
> > - An inbound SYN that is not acknowledging a syn at the same time is
> > going to be blocked by firewalls if properly configured.
>
> Most likely the case, though I never tested for that. Would make for an
> interesting CS project. However, any such filtering of SYN in response
> to a SYN would be violating the RFC :)

ya, well...

I suspect this is why scanning with a SYN from common services ports
is sometimes successful. A more interesting CS project would be to
determine if in that case you can cause a connection to build to valid
internal services.

> > Who would like to provide a server on the net so that people can test
> > their devices in a full life cycle test? Simple web page returned that
> > says "It Worked!" would suffice.
>
> I got a box on the Internet without a firewall if you want to fire
> packets against it. Just make sure your test box is not protected by a
> firewall either.

As in responding to SYN with SYN?


> As far as Snort is concerned, I'd be interested in knowing how it
> affects Snort. Looking at the flow-chart of the Simultaneous Initiation,
> SYN-ACKs are part of the proper response. So if Snort checks for a
> --SYN--> and an eventual <--SYN-ACK-- and track the sequence numbers
> from there, there should be no issue. It may be the case that Snort sees
> the first SYN-ACK from client to server before the SYN-ACK from server
> to client, and then have the flow direction reversed. That would mean
> that any flow:established,to_server would not be valid.
>
> But if Snort tracks both (does catch the SYN-ACK from server to client),
> it sorta has a bidirectional flow where to_server and from_server are
> both valid. If you track the session with bits (bit0 =1 => to_server,
> bit1 =1 => from_server) and both bits are set, then the rules should not
> be affected (to_server is still true, while from_server is true also).
> But if Snort tracks flow with a single bit (bit0 =0 => to_server, bit0
> =1 => from_server) then there is the risk for evasion.
>
> A quick glance through the code (with a tired eye) indicates that two
> distinct bits (or bytes) are set, so Snort should handle it just fine.
>
>
> If you guys have any authoritative response to this issue please share.

That was my quick read as well but I'm not an authoritative source.
Regardless, it is anomalous and unexpected behavior and blocking would
be trivial and non-destructive and likely from a malicious server.

> Cheers,
> Frank
>
>
>
> --
> It is said that the Internet is a public utility. As such, it is best
> compared to a sewer. A big, fat pipe with a bunch of crap sloshing
> against your ports.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users