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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

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

L6 Presenter

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:

 

12570_Zone TCP.PNG.png

 

 

nono-syn-tcp.PNG

 

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

 

 

1 accepted solution

Accepted Solutions

L6 Presenter

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

View solution in original post

13 REPLIES 13

Cyber Elite
Cyber Elite

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 ?

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

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:

 

 non.PNG

 

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

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

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)

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

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

 

 

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

L6 Presenter

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:

 

SYN.PNG

 

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

 

ACK.PNG

 

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

 

flow.PNG

 

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:

 

JUN-OS.PNG

 

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

 

Forgive me 🙂 

 

L6 Presenter

Still a grey area! Logged with TAC

L6 Presenter

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

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

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

I was indeed shadowing your case 😉
Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization
  • 1 accepted solution
  • 6992 Views
  • 13 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!