random-drop vs drop - zone protection

[raji_toor]

For TCP flood logs should only show "random-drop" with RED configured.

"drop" for TCP flood is this coming from options set under "TCP Drop" options under Packet Based Attack Protection. 

[S.Cantwell]

Good Day.

Flood Protection is typically only used for the TCP/UDP/IP/IPv6 protections under the first tab in the Zone Protection Profile.

It is recommended to do SynCookies vs RED for traffic from External zone.

Thank you.

[raji_toor]

@S.Cantwell  These are my flood protection settings. I should be seeing only random-drop in logs. What is causing the 'drop' logs?

[S.Cantwell]

That is a good question... I have my FW configured for Syn Cookies per PANW.  RED is typically only for UDP traffic, not TCP... so perhaps there is some internal logic at play here.  Best to swap it (correctly... ) to SYN Cookies.  This is per PANW recommendations.

Oh, I also think.. that proper 3 way TCP handshake will be random dropped, but if some src IP did not respond and sent a 2nd SYN packet, the FW will probably DROP that... that is what I think is happening...

Anything else I can assist with?

[raji_toor]

@S.Cantwell Thanks for your effort to answer this. I will probably ask support to have a good clarification.

And regarding your SYN-Cookie suggestion, I had it enabled recently but reverted back to RED when we found during an internal scan, that because firewall is replying SYN's on servers behalf it was also giving SYN replies when the servers did not even exist. We would not like to have that when we have /24 range facing internet.

[S.Cantwell]

Thank you for your info..

All I can say is that is correct and totally appropriate for the FW to complete a proper 3 way handshake from an outside entity (client, if you may) to allow the FW to do Zone Protection.  Random Early drop WILL drop perfectly good TCP connections, and SynCookies will drop ONLY those clients on the Internet who do not attempt to properly establish a 3 way handshake.     I would recommend that you review the Best Practices located here:

https://docs.paloaltonetworks.com/best-practices/9-1/dos-and-zone-protection-best-practices/dos-and-...

We are always striving to ensure your FW is properly configured, and if your company has your go into a different direction in terms of how to security environment, then I appreciate the time and effort to help guide you.

Thank you for your time and we are glad to assist you.

[raji_toor]

@S.Cantwell  If we do Syn-Cookes on Zone protection what is the practice for Dos Policies. I have gone through support on this before, when we had Syn-Cookies enabled for both Zone and DoS policies, DoS policies do not generate any logs even with an alarm rate of 1 and activate rate of zero in this scenario.

[S.Cantwell]

Hello Raji

I think the question I need to ask here is... What are your expectations of what and how the FW should work vs how it actually works?

Zone Protection is like water pressure... all the bad traffic is trying to get inside of the FW and the ZPP regulates how much is allowed in.  As I stated... internet traffic inbound is mostly TCP and TCP is best controlled by Syn Cookie.

DoS protection controls IF a session needs to established (that is happens before security policies are even evaluated).

So I  do not understand the comment about DoS do not generate logs.  Why would they?  Logs are done as END of session and DoS can PREVENT a session from even needing to started, if the packet does not do what you want it to do.

So someone from the Internet MUST be compliant is ensuring it responds to a 3 why handshake to make it through the ZPP and then you, as the FW Admin, determine IF a session from that Internet user should be allowed to connect inside of your network.. If YES, the a session is created... But.. if you do not want that session to be created... then DO NOT CREATE ONE, and logs will equally NOT be generated for UNWANTED traffic.  So to answer your question.... SYN Cookies should also be used for DoS in case that was not clear.

We seemed to have moved away from the original request of your query.  You asked why things have occurred and I believe I have properly answered them, as well as explained WHY this configuration should be implemented, based on my PS experience and based on PANW best practices.

What additional questions can I answer for you.

[raji_toor]

@S.Cantwell I do not disagree agree with you, let me explain what had happened. 

We had been trying to implement DP but that is not as straight forward as implementing security policies, and documentation mostly shows how to create a DP policy/profile. But the process on how reach at those values is not widely understood by most.. 

ZPP - Syn-cookies was enabled with activation threshold of 1.

DP - Syn-Cookies was enabled with activation threshold of 1

As for above ZPP was being processed likely before DP there were no logs of syn-cookie sent "DoS do not generate logs". I guess that is expected according to how the PA process packets, but it took a while to figure this out and engaging threat team. First level team was not able to identify this issue. I have queried here as well before.

After that we changed ZPP to RED and I see the logs which I stated above.

We have changed back to syn-cookie now for ZPP but thresholds are much higher than those used in DP. It seems to work as expected now.

[S.Cantwell]

@raji_toor   Thanks for reply.

Did you or your network team benchmark the number of connections per second that the FW would normally see?

How did you or anyone choose 1 as the correct number?

Here is a great screen capture to you help you:

If there is nothing more to add, can you like the post, Accept as a Solution? 

Thanks.