- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-20-2017 04:11 AM - edited 01-20-2017 12:40 PM
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
04-25-2017 04:17 AM - edited 04-25-2017 04:18 AM
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
01-20-2017 04:37 AM
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 ?
01-20-2017 05:01 AM
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:
01-20-2017 05:20 AM
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
01-20-2017 05:36 AM - edited 01-20-2017 06:00 AM
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
01-20-2017 07:35 AM
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)
01-20-2017 07:43 AM - edited 01-20-2017 07:44 AM
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
01-21-2017 09:42 AM - edited 01-22-2017 04:05 AM
@BPry Can you add something to this please? Cannot figure it out.
01-22-2017 05:04 AM - edited 01-22-2017 08:24 AM
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:
Forgive me 🙂
01-24-2017 11:08 AM
Still a grey area! Logged with TAC
04-25-2017 04:17 AM - edited 04-25-2017 04:18 AM
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
04-25-2017 05:56 AM
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
04-25-2017 06:39 AM
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!