Zone Protection - to or from

[jdprovine]

Is Zone protection applied from or too the zone?

[BPry]

It's specifically ingress.

It's also important to note when configuring zone protection that it's only evaluated on traffic that doesn't match an existing session, if it matches an existing session it'll bypass your zone protection settings. 

[jdprovine]

@BPry

I put it on my DMZ zone and so far I am not seeing anything.  But I have about 23 zones, and none of them are name untrust anymore so I am trying to determine what zones would I would see the best results from using zone protection. I did have a health check run last fall but it did not show all of my zones and its recommendations were based on a untrust zone that I do not even have.

[OtakarKlier]

Hello,

That is a it depends type of question. Obviously the untrust zone from the internet should have this, but it may also apply to certain internal zones, i.e. keeping kids from getting at your stuff.

Cheers!

[BPry]

,
They likely simply utilized the common zone names for their recommendations, which is rather lazy on their end. Untrust would be the zone that you utilize as an ‘outside’ zone; essentially wherever your ISP connection comes in should be a non-trusted zone, hence it being shortened to simply untrust.
I wouldn’t expect to really see any triggers on a DMZ for zone protection. You really shouldn’t have too much traffic with the DMZ as the ingress zone. I would caution trying to trip the zone protection profile however. Zone protection is really what I consider to be the last line of defense against a flood, simply because it will effect new sessions on the entire zone when tripped.

[jdprovine]

@BPry @OtakarKlier

Adding it to the outside/internet in/ISP untrusted zone is an easy choice, but I do I determine what other zones it would be most beneficial on

[Mick_Ball]

i would say only you can answer that as it's only you that really knows "your" network.

for me..  trusted LAN, no point.. the LAN itself is quite secure, no guest or BYOD connections. only domain members can connect.  even then these devices are policied to the hilt.

DMZ. no point.. as @BPry stated, DMZ ingress is a big no no.

internet (any untrusted) ... yes.

so... if you feel that any of your zones are vulnerable to such attacks then protect them...

[BPry]

@jdprovine

I would create a custom report that targets the Traffic Log database sorted by bytes and grouped by the Inbound Interface. This should give you a good idea of which zones you should actually target. 

[jdprovine]

@Mick_Ball

Definitely things coming in from the outside we need to protect against, but a majority of ours users are students and are not a part of our domain but have access to the internal network so it is tricky

[Mick_Ball]

@BPry

Hi.  you mentioned previously...

Zone protection is really what I consider to be the last line of defense against a flood, simply because it will effect new sessions on the entire zone when tripped.

if you have time could you elaborate,  not so much on Zone Protection but the "trip" part.

[BPry]

@Mick_Ball,

So what I meant by "trip" is when you actually trigger the Activate or Maximum values. So when you look at Flood Protection it's very similar to the DoS profiles where you'll have an 'Alarm Rate', 'Activate Rate', and a 'Maximum' rate. The major difference is that it triggers on the entire zone for any traffic that doesn't match to an existing session. So on UDP packets the 'Activate Rate' will trigger random drops and you may start dropping legitimate traffic across the entire zone; 'Maximum Rate' obviosuly will cause any number of packets exceeding this value to simply drop. Same for SYN, however you do get the option to set this action on 'Activate' to SYN Cookies instead of RED. 

DoS Protection Policies are more of the first line of defense in my mind, just because of how much more granular you can get when working with them. It's also easier to work with the 'Activate' and 'Maximum' values since you can generally work in a time to properly attempt to hit that value and verify the policy is working as intended, while only effecting connections to the specified host(s). 

I'd much rather see more aggressive DoS Protection Policies than aggressive Zone Protection Profiles simply because I never want to effect an entire zone of traffic. We host a lot of public websites; I would rather have one website be spotty or unreachable in the event of an attack over lossing all of them. Therefore I always try to set my Zone Protection to the point where my DoS Policiesshould prevent the Zone Protection from ever hitting the Activate rates. Currently you would have to trigger the majority of my DoS Policies before my Zone Protection profiles ever had a chance to activate. 

[Mick_Ball]

@BPry

OK, got it.

Many thanks for taking the time to elaborate.

[jdprovine]

@BPry

By granular on the DoS protection do you mean it is  because you can pick specific IP's and subnets not just full zones ?

[BPry]

@jdprovine,

Correct. Since you can choose to single out an IP address (or multiple) you can limit the impacts of the DoS Policies to those hosts. With a Zone Protection Profile you'll effect all unmatched traffic across the entire zone without any way to negate a particular address. 

[jdprovine]

so much to choose from on the PA sometimes its so overwhelming, I really wish I had a test system