|Main Archive Page > Month Archives > snort-users archives|
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.