Zone Protection Profile - testing

[LucaMarchiori]

I've setup a Zone Protection network profile and applied it to our DMZ zone.  I changed the default for port scan on the Reconaissance Protection tab to 30 events in 3 seconds.  TCP port scan is enabled, and the action is set to block-IP.

I run a test by scanning a host in the DMZ, 10,000 ports in 166 sec.  That's a rate of ~ 60 port / sec, and it should have triggered the ZP profile, but didn't.

Do security policies take precedence over ZP, or vice versa?

[reaper]

zone protection has precedence over security policies

where are you scanning from? the internet or your lan network?

Zone protection is applied to the ingress interface, so you need to apply the protection profile to the zone where your scans are 'entering' your network (as opposed to the final destination)

This to protect the network and the firewall at the very first instance where the attack can be detected

FYI: Zone Protection Recommendations

[LucaMarchiori]

Hi reaper,

I actually scanned both from the "tunnel" zone (a remote site) and the WAN.  I've been using this to test:

C:\Program Files\Nmap>nmap -PS -pT:1-9999 -r <destIP>

Starting Nmap 7.60 ( https://nmap.org ) at 2017-08-04 07:49 Pacific Daylight Tim
e
Nmap scan report for <fqdn> (<destIP>)
Host is up (0.00092s latency).
Not shown: 5050 filtered ports, 4946 closed ports
PORT   STATE SERVICE
21/tcp open  ftp
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 11.51 seconds

I can see all these packets in the logs, but ZP does not kick in.  Is there anything else you need to do, besides creating a ZP profile and assigning it to a certain zone?

[LucaMarchiori]

Hi reaper,

zone protection has precedence over security policies

---

Apparently this is not entirely accurate.  Turns out that if a security policy blocks the offending scans, ZP does not kick in:

https://live.paloaltonetworks.com/t5/Management-Articles/Zone-Protection-Profile-Not-Generating-Logs...

I run a test by allowing the source_ip in my security policies, run a new port scan, and the "scan" threat got triggered.  This seems inconsistent with the whole ZP has precedence over security policies idea.

I do hope this changes at one point

[BPry]

@LucaMarchiori,

What the article states is correct in the fact that you will not see threat logs generated by your Zone Protection profile because it's dropping the traffic right from the get go. So even though your traffic to your eyes should have registered the traffic is dropped before the limits are able to build up to trigger the Zone Protection profile. 

If you are trying to test a Zone Protection profile it needs to be legit traffic or you really need to throw traffic at the zone to actually get it to trigger. The Deny rule is being hit and the traffic is being dropped before your Zone Protection has a chance to trigger because it's thresholds are not being hit; which is what the article is trying to get across. 

You can still trigger your Zone Protection profile prior to the traffic being dropped but you need to throw enough traffic at the zone to the point where it doesn't have enough time to analyze the security policies before your limits are reached. That is a very hard task to accomplish and I don't think you'll hit it testing with one box. 

[Remo]

@BPry

But he is right with his point, at least for the port scans. The port scan protection in the zone protection is pretty much useless unless you have quite a few or all ports allowed or when you have an app in your poilicy with tcp/udp/dynamic as default ports and you did not manually restrict it to a few ports.

Or am I missing something?

[BPry]

Nope I misread what he was trying to convey, that's my bad. The Zone Protection Profile isn't where I would attempt to stop port scans or even really identify them. I find DoS policies to be far better at actually looking for port scans. The limitations of Zone Protection means that it's far more suitable in an ISP environment than most others.

[LucaMarchiori]

Hi BPry,

If I'm not mistaken, DoS profiles do not have reconaissance protection, (at least in 7.1.11); how do I stop port scan / host sweep with DoS?

To my previous post, I was just wondering what is the use-case of ZP protection recoinnassance as it is now?  99% of the time most ports from the outside are going to be already blocked, so ZP for port scan is... redundant?  If ZP kicked in no matter the security policies, I think that that would be useful.

One use for ZP could be to protect the LAN zone, but then I need a way to white-list some IPs. 🙂

[BPry]

@LucaMarchiori,

I would say ZP Protection recoinnassance is primarly used in ISP enviroments where you actually would have all ports open to your customers, and therefore the ZP can actually work as intended without having the Deny rule processing the traffic before the thresholds can be hit. I would guess that hosting enviorments would likely see the same benefits; but yes most customers won't have any real protection as the Deny rule will simply drop the traffic before the set threshold is reached which doesn't allow the ZP to actually ever hit the threshold within the interval setting. 

DoS protection doesn't offer a reconaissance protection but it does offer the ability to set a Session Limit specific to one IP address. In a way this will prevent a port scan as you can set the maximum session count a sole source should ever generate to that IP. Initiating a port scan would cause a sources session count to climb relatively quickly causeing the limit to trigger. In almost all cases the actual session limit value that I'm able to keep on my DMZ gear is very low on a classified DoS profile and in testing stops port scans relatively quickly. Of course the attacker will know a few of the most common ports status as that session limit is reached, but that's true with port-scan detection as well. 

[LucaMarchiori]

Hi BPry,

Thanks for explaining.  Is this the right command to count the current sessions for a specific IP:

> show session all filter count yes destination <dest_ip>

If, for instance, I get a typical value is 60-80 concurrent sessions for a specific server (our mail server), what max session count would you use to build a classified DoS object?  I understand that every situation is different, just looking for a starting point.

Maybe I'm looking at this wrong, does the total session count even matter in setting this up, since the classified DoS policy counts sessions for every source IP?

I'm trying to think in which scenario a single source IP would (legitimately) open multiple sessions...

[BPry]

@LucaMarchiori,

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 

RED

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:

• If the rate falls between 0 pps and the 'Activate' rate then the probability of a packet drop caused by RED is 0.
• If the rate falls between the 'Activate' rate and the 'Maximum' rate then the packet drop probability linearly increases from 0 to 1.

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

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. 

[LucaMarchiori]

Hi BPry,

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

 Action: Protect
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?

[BPry]

@LucaMarchiori,

Looks fine. 

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. 

[LucaMarchiori]

Hi BPry,

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?

 

[BPry]

@LucaMarchiori,

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?