Unknown traffic log message

[Andrei_Feldman]

Hi all, I need help understanding the type and meaning of this message: log_id=0038000007 type=traffic subtype=other ... msg=" syned but no ack, drop" Another message that intrigues me: log_id=0038000005 type=traffic subtype=other pri=notice status=accept Both policies have a non ' 0' policyid. Thanks.

[ede_pfau]

That should probably have read " synced but no ACK" , referring to a connection attempt that has not been completed. Could be a form of " TCP ping" or just jabber. The second log entry is somehow a little short (of meaningful information). But no reason to be alarmed IMHO.

[Andrei_Feldman]

Thanks ede (again) I' m not alarmed, I' m interested in understanding those logs and packets flow of device through the logs. The first message has a https service. The policyid is accept with Nat. What could have been the reason the packet was dropped? I looked for the exact message type (0038000007), but there was no reference on it. here is the full log: date=2012-02-21 time=09:35:38 devname=***** device_id=******log_id=0038000007 type=traffic subtype=other pri=warning status=deny vd=" root" src= srcname= src_port=54997 dst= dstname= dst_country=" " dst_port=443 service=HTTPS proto=6 app_type=N/A duration=6 rule=13 policyid=13 identidx=0 sent=0 rcvd=0 shaper_drop_sent=0 shaper_drop_rcvd=0 perip_drop=0 shaper_sent_name=" N/A" shaper_rcvd_name=" N/A" perip_name=" N/A" vpn=" N/A" vpn_type=UNKNOWN(65535) vpn_tunnel=" N/A" src_int=" internal1" dst_int=" wan1" SN=42710335 app=" N/A" app_cat=" N/A" user=" N/A" group=" N/A" msg=" syned but no ack, drop" carrier_ep=" N/A" profilegroup=" N/A"

[ede_pfau]

Unless you can reproduce the event and take a copy of a sniffing session it' s wild speculation as to what was going on. But I' ll try anyway. When a TCP connection is established, the host sends a SYN packet, the server answers with SYN,ACK and the host answers with ACK again (3 way handshake). There has been an exploit circulating where the server answered with ACK only, thereby exchanging the roles of server and client, called TCP split-handshake exploit. FortiOS was partially vulnerable against this but has been fixed. Search for the discussions on the forum to find more info. Links: http://watchguardsecuritycenter.com/2011/04/15/what-is-the-tcp-split-handshake-attack-and-does-it-affect-me/ (including a recipe how to set up a Ruby script doing this) http://nmap.org/misc/split-handshake.pdf As I wrote earlier, this is wild speculation. Only a packet sniff can reveal what is going on.

[Andrei_Feldman]

Thanks a lot, this is helpful!