[Snort-users] [Emerging-Sigs] TCP Portals: The Handshake's a Lie!
jasonb at ...1935...
Tue Nov 24 00:30:49 EST 2009
On Tue, Nov 24, 2009 at 12:01 AM, Frank Knobbe <frank at ...9761...> 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
>> 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 :)
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
>> 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.
> 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.
More information about the Snort-users