topic Re: TCP SYN/FIN from port 37892 to port 0 in Network Security

TCP SYN/FIN from port 37892 to port 0

shadow.cipher — Sun, 10 Mar 2019 09:49:21 GMT

Has anyone seen the TCP SYN/FIN 3140 signature trigger on TCP traffic from port 37892 to port 0? I have seen this many different times including from traffic coming from a VPN client to a Cisco VPN Concentrator. Just today I saw it coming from a client to an unknown(to me) host in which later I observed the two communicating via SSL. I am wondering if this is a bug in the Cisco VPN client software or possibly a bug in the way the IDS is decoding certain encrypted packets. Any ideas?

Re: TCP SYN/FIN from port 37892 to port 0

jlimbo — Wed, 04 Jan 2006 06:06:06 GMT

I assume you mean 3041-0. You should not see SYN and FIN flag set as the description denotes. This is not normal however a deeper look into this maybe warranted.

The VPN client should be using IPSec or SSL encryption so you should not normally see this at all. You possibly have any further information like a traffic sample I can have a further look at?

Re: TCP SYN/FIN from port 37892 to port 0

shadow.cipher — Thu, 05 Jan 2006 00:03:40 GMT

Yes, subsig 0. I know SYN/FIN is not RFC compliant and it was used to circumvent poorly coded packet filtering firewalls back a few years ago. These packets however have been seen coming from different networks, but usually having a similiar M.O.(dealing with encryption and NAT). I am thinking these are network artifacts which can and do occur, but the fact that I have seen it so many times is making me think it's a bug. I"ll try to dig up some packet captures for you to look at.

Re: TCP SYN/FIN from port 37892 to port 0

jlimbo — Thu, 05 Jan 2006 05:29:10 GMT

The signature itself has been released quite a long time ago and it has not changed. So I would attribute the change in frequency of alerts to a change in network traffic.

Re: TCP SYN/FIN from port 37892 to port 0

mepenzien — Mon, 16 Jul 2007 14:27:00 GMT

I have noticed this same sort of traffic on a network containing a Cisco VPNc 3030 v4.7.2 VPN concentrator. Is this expected of the VPN traffic? Or, like the original poster suspected, is it a bug with how the packets are encrypted?

Thanks!