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

[Frank Knobbe <frank () knobbe us>]

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.

>  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 :)

> 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 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. 

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.

Attachment: signature.asc
Description: This is a digitally signed message part

------------------------------------------------------------------------------
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