Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
cryptochrome
New Contributor III

How to use App Control in policies

Hi,   I am not new to Fortigates, but I am new to Application Control. I am struggling to understand how to properly make use of it in the context of firewall policies.   I understand I can't simply create a firewall policy based on Apps (e.g. put an app in there as a matching criteria instead of a port-based service). I have to use Application Control profiles instead and attach them to the firewall rule. And that's where it leaves me.    For example: Let's say I want to allow Facebook for source IP 10.10.10.1, but no other apps. What would the App Control profile look like and what would the corresponding firewall rule look like? In the profile, I would block all App Categories and then use Filter and/or Application Overrides (which one), only selecting Facebook? And then add that to a firewall rule that allow source 10.10.10.1 ANY service (or just HTTP(S)) and attach the profile?   If that's the way to go, how do I go granular?   Let's say I want a rule that disables logging for a certain app (let's keep Facebook here)? On a "traditional" firewall, I would simply create a rule with source IPs, destination IPs, services, action:allow and set it to no log. However, with app control and the above example, wouldn't that rule match for any other traffic as well? I wouldn't be able to have a second rule that allows Dropbox, for example (for the same source), because the previous Facebook rule matches all apps (blocks them) AND Facebook (allow it).    As you can see, I am struggling with the concept.   I hope I am making sense (excuse my non-native english).
20 REPLIES 20
cryptochrome
New Contributor III

BTW: I am already on FortiOS 5.4 (E-Model firewall with no option to downgrade). 

ede_pfau
Esteemed Contributor III

hi,

 

you're right, policies are not application specific in FortiOS. With AC you can control the flow of data only - in your second example, logging is a feature of the policy, not pertaining to the flow of data, and thus not AC dependent.

 

In a way, UTM profile are application specific for certain most-used applications, namely HTTP, FTP, and their secure variants. In profile settings, you can specify that they would be recognized using any port, not only the wellknown ports. But again, this is in no way comparable to an application-aware firewall like PA (so I've been told).


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
cryptochrome

Thanks Ede. So if I understand you correctly, app signature cannot be used as a matching criteria in a firewall rule.

 

Let's say I want to apply two different app control profiles to the same source IP subnet, one that allows Facebook, another one that denies Botnets, it would not work, because the second rule wouldn't be triggered once the first rule has matched. E.g.:

 

Rule 1:

 

Source: 10.10.10.0/24

Destination: Any

Service: Any

Action: Allow

App Profile: Allow_Facebook

 

Rule 2:

 

Source 10.10.10.0/24

Destination: Any

Service: Any

Action: Allow

App Profile: Block_Botnets

 

I realize that my examples wouldn't make much sense in real life, but I think you get my point. In this case, rule 2 would never fire for a source IP in 10.10.10/24, since rule nr. 1 already matched the traffic, regardless of what is in the app profile.

 

Am I getting this right?

ede_pfau
Esteemed Contributor III

Right, AC cannot be used to match traffic like you can with other criteria (port, address, time). Your example of 'stacking' policies indeed shows where the limit is: AC is not about matching (control flow) but applying UTM once traffic is matched.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
cryptochrome

That's.... Meh.... 

 

Thanks for helping me understand. And I also now understand why Palo Alto leads the pack when it comes to NGFW. 

CrisP
New Contributor III

Hello Please take a look here, especially at the last comment: https://live.paloaltonetw...tly-Allowed/ta-p/61893 Best regards
MikePruett

cryptochrome wrote:

That's.... Meh.... 

 

Thanks for helping me understand. And I also now understand why Palo Alto leads the pack when it comes to NGFW. 

Yeah, it is one of my ongoing complaints with Fortinet. I have told them directly several times. Unfortunately, the limitation would require a complete rewrite of some things to make it work this way. I reference it here Where Fortinet Is Messing Up

Mike Pruett Fortinet GURU | Fortinet Training Videos
cryptochrome

Good write-up, Mike. I agree with everything that you wrote on your blog. To be fair though, Palo Alto's NGFW approach was a surprise to every player in the industry. When they saw that PA was successful, they baked something into their own offerings. The "Me too" approach, I guess. Even Checkpoint's application filtering sucks big time. They even need an entirely different policy for application filtering that'S separate from the firewall policy. But they have realized that and with their new release R80, they did a total rewrite and now have a single, consolidated policy that works much like PA's. 

 

The only thing that bugs me with Palo Alto is their choice of appliances. The low end devices like the PA-200 and PA-500 are seriously underpowered and cost a ridiculous amount of money compared to other vendors lower end devices. Heck, a small Fortigate 50E outperforms even middle-tier appliances of PA. Nonetheless, Palo Alto have surpassed Fortinet in the last Gartner quadrant. Go figure.

 

MikePruett
Valued Contributor

I agree. I used to run Palo's for the DOD. I like the software. Damn expensive for the various versions of hardware though.

Mike Pruett Fortinet GURU | Fortinet Training Videos
Labels
Top Kudoed Authors