non-syn-tcp global, zone protection profile but still Allow in the traffic logs.

[TranceforLife]

Hi All Experts,

Looking for advice here. Want to block non-syn-tcp packets. Global settings are:

> show session info | match non-SYN

  TCP - reject non-SYN first packet:             True

Zone protection profile in place:

But still Allow in the traffic logs. Is it normal? If yes, why? One more question. When configuring a zone protection profile reject Non-SYN TCP option is set to global, doest it means that profile will inherit global settings? 

P.S PA-3050 PAN-OS 7.1.7 

Thx,

Myky

[reaper]

Hi

you need to look at the traffic log as a result of what a security policy decides a session is allowed to do, just like the threat log contains decissions made by a threat prevention/AV profile

so a session may get allowed in the security policy (by a simple 5-tuple match source zone,source ip, destination zone, destination ip, destination port) but the underlying tcp sanity check may decide that this packet is not 'sane' and drop the packet, but the log has already been created and now there is no further action that could lead to a policy allow or deny, so the log is created as is

the global setting means that non-syn-tcp is rejected by the system by default, even without a zone protection profile in place

you can either change the global setting for the whole platform, or you can create a zone protection profile with it's own setting, or which complies to the global setting (global reject, zone protection allow or global allow, zone protection  reject or global reject, zone protection global etc. )

hope this makes sense ?

[TranceforLife]

Hi Reaper,

Thanks!

This stuff is not the best of my side:-)  So if policy allows the traffic based on 5 criteria you mentioned earlier why the logs suggest the different (still confused). And is it actually normal to see these logs and is there a way to disable these logs (but leave good logs on)? Doest that mean that the traffic Non-SYN TCP traffic is hitting the destination or not? 

On second point l understood if l choice allow Non-SYN TCP, the non-syn-tcp traffic will be allow regardless of the global config, right?

From the CLI l can see traffic dropped:

 

[reaper]

since the log popped up, i'm assuming you may have the non-syn-tcp-drop disabled for a while maybe ?  (see now i'm doubting myself 😉 )

normally the packet would get discarded even before a policy check is performed and so no log would appear

if you do allow non-syn, it will hit security policy and be passed through to the final destination, but be identified as non-syn-tcp because there was no handshake

if you set the zone protection to something else than global, zone protection setting will take precedense over global for that specific zone

flow_tc-_non_syn_drop counter will indicate if you re dropping or not, flow_tcp_non_syn will keep incrementing even if you do not drop

[TranceforLife]

Hi Reaper,

This is what l want to understand why wold Palo log this non-syn-tcp  when globally and even with ZPP its says drop )) 

No non-syn-tcp-drop  was on all the time but still see new entries. Must be something in the config as l am sure that the firewall is doing what l have asked it to do, this is not always  the same as what l want 🙂 Anyway how l can confirm these packets are not actually hitting the destination (PCAP on the box)?

Cheers all,

Myky

[reaper]

what version of PAN-OS are you using?

to my knowledge the non-syn-tcp packets should only show up in traffic log when reject-non-syn-tcp is disabled globally or through zone protection (so we see the packet, but forward it anyway)

my semi-educated guess is that these packets arrive during  specific stage of a session teardown, but you'll want to try to collect a flow basic to see what happens exactly (or at least a packetcapture to try and folow the flow logic)

[TranceforLife]

Hi Reaper,

Thanks as always. PA-3050 PAN-OS 7.1.7. Will do PCAP (for all stages) and see what l can see. 

Thx,

Myky

[TranceforLife]

@BPry  Can you add something to this please? Cannot figure it out.

[TranceforLife]

l think it is normal behaviour as it makes sense now. Reading the KB article Palo Alto Networks firewall will, by default, reject the first packet that does not have the SYN flag turned on as a security measure. Normal TCP connections start with a 3-way handshake, which means if the first packet seen by the firewall is not the SYN packet, it is likely not a valid packet and discards it.

So for the new session first packet must be SYN:

If the first packet other than non-SYN flag — such as ACK, URG, RST, FIN:

and there is no existing session PA will drop the packet. If the session exists it will allow.

A bit strange still that it is appearing  in the logs for the already existing session (will confirm on Monday the session details)

Found a bit better explanation on Juniper website:

https://www.juniper.net/documentation/en_US/junos15.1x49/topics/concept/reconnaissance-deterrence-at...

Forgive me 🙂 

[TranceforLife]

Still a grey area! Logged with TAC

[TranceforLife · Accepted solution]

FYI:

Raising the Activate threshold on the SYN flood protection from 0 to 10,000 has resolved the issue. This is out of my knowledge :0

[reaper]

i would venture you had random early drop set instead of SYN cookies ?

RED should indeed start no earlier than 80% of your limit, preferably even later

syn cookies should start as soon as possible

[TranceforLife]

@reaper l think you were cc`d , PA case ref 00608626 for more details 😉

[reaper]

I was indeed shadowing your case 😉