It really depends on the service; it's not uncommon to see one source has a couple sessions on our servers. For example exchange servers could have multiple connections if the user has the email sync'd across multiple devices. I wrote this a while back, but it describes how to get started.
How do you determine a starting pps rate?
When you initially configure the DoS profile set your 'Alarm' rate to something reasonable that you know is likely to be hit; you'll want this value low enough that you actually get alerts. The 'Activate' and 'Max' settings you'll want to keep artifically high until we have actually established a baseline. Since the 'Alarm' rate doesn't actually do anything that would affect traffic we don't care if this threshold is reached. The 'Activate' and 'Max' rates on the other hand will affect traffic, I generally set 'Activate' at 10000 and 'Max' at 10500.
As alerts are logged for the DoS profile hitting the 'Alarm' rate (this can be seen in the Threat log via the query 'subtype eq flood') adjust the 'Alarm' rate ever so slightly ( such as 25 pps) higher until the trigger is no longer hitting the threshold. Keep adjusting the 'Alarm' threshold under normal everyday traffic no longer hits this value at all.
Once you have established the 'Alarm' rate for everyday traffic and have tested this pps rate for multiple days/weeks you can use the 'Alarm' rate to specify the 'Activate' and 'Max' rates. I will generally take the 'Alarm' rate and give it a fair amount of pps difference from my 'Alarm' rate. For example if my 'Alarm' rate was 15 pps then my 'Activate' rate would be 50 pps and my 'Max' pps would be set at 100; in addition if my 'Alarm' rate was already 100 pps then my 'Activate' limit would be 150 pps while my 'Max' pps would be 200 pps. Keep in mind that my goal here is to not actually trigger the 'Activate' or 'Max' rate unless an attack is actually happening, as long as you receive the alerts in email for example it should be fairly clear when this limit is routinely getting hit by traffic that would not necessarily be coming from a normal location.
Random Early Drop (RED) or SYN Cookie?
*When in doubt, use SYN Cookie
First realize that RED is nothing more than an Active Queue Management technique, one that is the most common method to protect against SYN floods. RED is rather simple, given a packet rate within one sampling interval:
You can calculate the number of dropped packets, given rate X in [A to M], where A is the activate threshold, M is the maximum, then roughly (M – A) * sum (1/N, N in [M-X, M-A]) – (X – A). This means that when X is less than A, the probability of a packet being dropped is 0 and if X is M the probability is 1 (100%). So after you go beyond A, probability linearly grows from point where at A no packets will be dropped to M where all packets will be dropped. If more packets are sent more will be dropped.
RED has a number of downsides with it's largest being that it does not have a way of distinguishing between legitimate or non-legitimate traffic. This means that legitimate traffic has just as high of a risk of being dropped as non-legitimate traffic until the 'Activate' rate is no longer being hit or the 'Max' rate is triggered. In attempting to keep your policy from triggering the 'Maximum' rate limit RED simply drops packets at a specified rate and will de-activate once the pps rate is below the 'Activate' rate.
SYN Cookie is a near stateless SYN proxy mechanism. Essentially when a SYN segment is received SYN cookie does not set up a session or do policy or route lookups. It also doesn't maintain a connection request queue. This allows the firewall to maintain optimal CPU loads and prevent exhaustion of packet buffers. With SYN Cookie, the firewall acts as a man-in-the-middle for the TCP handshake. If SYN cookie is activated and the connection is found to be legitimate, the firewall does the sequence number translation for established connections. SYN Cookie is a recommended method as opposed to RED for its obvious advantages of fairness for legitimate traffic and less CPU overhead.
Why not always use SYN Cookie?
While this is a question in and of itself, I'm not going to separate this out of the RED or SYN Cookie question. There are reasons why you wouldn't want to use use SYN Cookie. First and foremost while SYN Cookie doesn't actually put any additonal load on the packet buffers of the firewall, it does cause a higher CPU load when triggered than RED. Second in some instances if you set things up correctly you wouldn't necessarily care if traffic, regardless of it being legitimate, was dropped. For example if you run a public DNS server that replicates upstream you don't need every DNS query to be successful; if you drop queries from your upstream server it will keep your current records until your TTL has passed
Should I set the Activate rate to 0?
It's possible to set the 'Activate' rate to 0 and simply set the 'Maximum' rate to what you would normally to start dropping traffic. Keep in mind that this should only be used with SYN Cookie to determine legitimate traffic and keep traffic flowing, this should never be used with RED. The tradeoff of an 'Activate' rate of 0 is that this causes a much higher CPU load as SYN Cookie requires some processing to properly send an ACK back to the original sender, however it will keep your session table lower as all non-legitimate traffic will be dropped. With RED you could keep non-legitimate traffic in your session table and drop legitimate traffic as the actual traffic is never differentiated in the RED process.
How do You Configure a Zone Protection Profile?
You can actually follow all of the above steps you just need to configure the Zone Protection profile under Network > Network Profiles > Zone Protection. Once the Zone Protection Profile has been created you then need to assign that profile to the Zone under Network > Zones. The exact same information follows except you can only build a Zone Protection Profile as an Aggregate profile, meaning that this profile will take all packets into account and will not specify a Classified profile. For this reason 'Activate' and 'Max' limits should be kept at a rate limit that you are highlyunexpected to ever hit unless you are actively being attacked.
Great info, thank you. It's a lot to unpack, but I have a few questions, to confirm I got this right.
- I'm starting to test this by allowing:
5 concurrent sessions
Alarm Rate (packets/s): 20
Activate Rate (packets/s): 10000
Max Rate (packets/s): 11000
Dest. zone: DMZ
does that sounds OK (I think so as policy should not be activated)?
- in the DoS policy, I selected source-ip-only - does this mean if an attacker sends 20 packets to host A and 10 to host B it should hit the policy, right?
The Classified profile where you get the options of source IP, destiantion IP, or source+destination is how it's actually specified. So if you apply it to source-ip only then 20 packets to multiple different hosts would trigger the alarm. That of course would be continguent on the destination hosts actually falling under the same DoS policy.
I enabled the DoS policy, and immediately saw that some outside IPs were getting blocked (see screenshot) - type "flood", name "session limit event". I reversed the change for now.
These may as well be actual scans, but I thought that the policy would not apply (actually drop these packets), since the "activate rate" in the classified profile was set to 10,000 pps, max rate to 11,000.
What am I missing?
It's mapping on your Session Limit, not your pps. With your session limit set to 5, and the policy applying across your entire DMZ from the sounds of things, that would mean that any one source IP can only have at max 5 sessions across your entire DMZ. Depending on your enviroment that's fine, but if you have an email server in your DMZ then depending on your volume that limit could easily be hit if you have multiple users signed up to the same mailing list.
Session limit you have to be a little more careful with but it also depends heavily on what you actually configure within your DoS policy and what type of enviroment you are in. Are you applying this one classified DoS policy across your entire DMZ?
Hmm session limit, that should have been a clue... :-) Yes I was testing the policy on the DMZ. I'll raise the session count and test again. Thanks again for helping me out, it's very much appreciated.
This is amazing. Already 4 flood events logged in 15 minutes or so... I'm putting these guys in my EDL by hand, for now. It'll be tricky to be patient enough to build a good baseline.
If you're adding all of them to an EDL you have a good reason to upgrade to PAN-OS 8. With the new features in the llg forwarding profile settings you could easy automate what you're now doing manually and the EDL.
But this is a point where you have to be careful, because floods from spoofed IP addresses, could let you block IPs from legimate addresses.
I would look into incorporating MineMeld into the mix then. Doing it manually will get kind of boring, so the more you can automate the process the better. Flood IPs I generally specify that they need to be introduced x amount of times before they'll be blocked.
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!