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

[Frank Knobbe <frank () knobbe us>]

On Tue, 2009-11-24 at 00:30 -0500, Jason Brvenik wrote:
> 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.

Or systems that run 30 year old TCP stacks :)

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

Nope, that's a different issue. Scanning with source port set to 20 can
bypass lame firewalls. Not just stateless firewall, but I've even sailed
past a Checkpoint that had the FTP proxy thingy misconfigured.

Keep in mind that the SYN from the server to the client uses the IP:port
pairs on both sides of the packet. The only difference is that the ACK
flag is not set and it doesn't include the initiators sequence number.
This is not a "rogue" SYN that has a different port or even IP (as being
sent from a different device).

Now, if you intercept the SYN from the client to the server and know the
IP:port quartet, and you spoof a packet back from a different host with
the expected IP:port values, you would interfere with the TCP session
setup between client and server, nothing more. You won't be able to
establish a new session from a different host to the client, since the
clients internal parameters (socket/TCB) are different. There is no
in-progress session setup from the client to that rogue box, so why
would the client care? It would just drop the packet, most likely
respond with a SYN-RST.

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

Blocking yes, and firewalls may do that already. See, the client
(initiator) sends a SYN, a firewall in the middle sees that and begins
to track state of that session. The server (receiver) responds with a
SYN-ACK, which the firewalls sees and enters that session into its state
table.

Now, the server might send a SYN-RST if the port is closed. The
firewalls seems that and stop tracking this session. 

If the server sends a SYN, the firewall can either move the session into
an established state (waiting for ACK for example) and enter it in a
state table, or stop tracking the session.

Either way, no harm done. It either behaves as expected by marking the
session as established, or drop it. It reacts safely.

An IDS however doesn't have the luxury of failing safe. It either tracks
the session (which it sounds we believe Snort does), or it doesn't. But
when it doesn't, it means that there is an established session that will
fly past the IDS. It fails in an undesireable fashion.


Anyway, this whole thing is more of a curiosity of a nearly 30 year old
TCP stack behavior then a threat to systems or firewalls. But it may
cause session tracking devices to ignore a session.

Gotta run to meetings. 

Cheers,
Frank

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