- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
05-03-2013 12:47 PM
Hi,
Could someone help me understand the impact of enabling Flood Protection on legitimate connections. If I have a 3050 as an external firewall protecting a website having high transaction how do you make sure the TCP flood protection with "random drop" value set does not kill legitimate traffic.
Does is make any sense to have a flood protection value set to a value below the new sessions per second value of a firewall ?
For example : the new sessions per second for 3050 is 50,000 new sessions per second, would you set a zone protection profile with flood protection enabled for 40000 packets per second ? would this not kill legitimate traffic ? and are you not limiting the capability of the appliance by doing this ?
Kind Regards,
Sunil
05-10-2013 01:27 PM
I don't know if you have seen it yet, but a new document has been posted that goes a lot more in depth on setting DoS/Flood Protection:
https://live.paloaltonetworks.com/docs/DOC-5078
05-03-2013 01:25 PM
That is a good question. There is a very general document located here: https://live.paloaltonetworks.com/docs/DOC-3094
It does not really give best practices however. Almost everything I have ever read says "trial and error!" When I asked about best practices when we first set up our PAN, they recommended leaving the defaults until we analyzed session data and had a grasp on the environment.
Message was edited by: Corey Raymond If you are using IIS, I would recommend going through Microsoft's recommendations for hardening your TCP Stack located at : http://msdn.microsoft.com/en-us/library/ff648853.aspx
05-10-2013 01:27 PM
I don't know if you have seen it yet, but a new document has been posted that goes a lot more in depth on setting DoS/Flood Protection:
https://live.paloaltonetworks.com/docs/DOC-5078
05-12-2013 11:19 PM
That is a good document , I think this part answers my question , from below we should read packets per second as new connections per second , i.e. if the servers you are protecting can handle the 50000 new connections per second and is protected by a 3050 , you would not need a Syn flood protection using RED to be below the 50000 capable by the 3050. Maybe slightly lesser , but not significantly lesser ? The case is different for Syn cookies as they are more precise on what they drop, i.e. they just drop sessions from clients that do not respond to SYN cookies , most likely spoofed ones.
"That means that the packets-per-second metric actually stands for new attempted sessions-per-second. For example in the case of SYN
floods, 10,000 pps means 10,000 new SYNs per second. The reason we mention this as pps and not cps (connections per
second) is because the session has not been created in the session table yet. It is a half connection"
05-14-2013 12:17 PM
One thing that is not covered by Zone protection of course, is lower level DoS protection of particular servers, which will most likely have to be done at the policy level under the Dos Protection Profiles. So, if you are protecting your entire zone with specific DoS protection parameters, those may not be adequate for protecting a particular server in that zone. This also depends on how you "Zoned" in the first place, but there is also the DoS protection Profiles in the policies setup. You may have to create DoS protection profiles for particular web servers if the Zone DoS protection is not adequate. There are some built in mechanisms on most modern "Internet" servers, but you may find that these are not adequate protection against SYN floods and the like. The server's ability to work under heavy traffic also depends on system resources and configuration.
02-13-2014 09:06 AM
What is the easiest way to determine the Average Peak Traffic (packets per second) on the PA-200 so we can fine tune the Syn Flood settings for alert, activate, max?
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!