Skip to main content
cryptochrome
cryptochrome
New Member
May 16, 2016
Question

How to use App Control in policies

  • May 16, 2016
  • 5 replies
  • 42998 views
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).

5 replies

cryptochrome
cryptochromeAuthor
New Member
May 16, 2016

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

ede_pfau
SuperUser
ede_pfau
SuperUser
May 17, 2016

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).

cryptochrome
cryptochromeAuthor
New Member
May 17, 2016

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?

MikePruett
MikePruett
New Member
June 12, 2016

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

tanr
tanr
New Member
June 12, 2016

I appreciate the information in this thread.  I want to make sure I'm understanding this correctly, though.

 

1. Application Control profiles are not used to initially match a firewall policy rule.

 

2. The AC profile for a rule IS applied to whatever traffic has already matched the firewall rule.

 

3. The limitation this creates is that if you've got two rules with different Application Control Profiles, but with all the rest of the firewall rule the same, then only the first rule will ever get hit, so your second AC profile will never be checked.

 

Assuming this is correct, then the only real way to get (most of) the functionality of the two rules with different AC profiles, is to merge the two AC profiles by hand (ouch).

 

I wonder if Fortinet could allow you to stack AC profiles, in priority order, within a single firewall policy rule.  Tricky, though, as you'd have to decide if a high priority AC profile's "Allow" or "Monitor" values should be override lower priority profiles "Block"...

 

Might be time to write a script to merge AC profiles passed to it in priority order...

 

Cheers.

 

ede_pfau
SuperUser
ede_pfau
SuperUser
June 12, 2016

@tanr: IMHO 100% correct in all 3 points. I'm sure FTNT is clearly aware of the limitations of it's approach and thinking about how to change this. I'd love to be able to match traffic in a policy just by application recognition. OTOH UTM is highly streamlined in FortiOS to achieve high throuput and it might be quite difficult to change from one architecture to another. And each approach will have pros and cons as well.

MikePruett
MikePruett
New Member
June 14, 2016

Eh, I like and use both platforms (I Have always been a pretty big fan of PAN hardware with my only real complaint being the cost of the hardware and initial bug filled nature of the software.

 

I just built a whole bunch of tunnels between some PAN's and FortiGates today actually

    hmtay_FTNT
    Staff
    hmtay_FTNT
    Staff
    April 24, 2017

    >>Since the Windows Update servers change around, the rule needs to allow "any" destination IP.  (SSL Deep Inspection can be set to mark only microsoft and windows update as "reputable websites", but it will still allow other IPs.) The firewall rule can have an Application Control profile that has any and all Apps (including Unknown) set to Block, except for the Application "Windows Update."  However, I think the AC profile will block what it sees as applications, but let what it sees as "normal" non-application traffic through.  

    Can anybody confirm?  Does this seem like a valid concern?

     

    >>In your example (you should test it!) the real problem comes from app dependencies and site shifting: you should block in the same rule all site categories except the particular list used by MSupdates (with webfilter local exceptions) and allow only the update apps. But then your app is still not working, because there are other dependent apps that must be allowed (Network Services etc).

     

    In FortiOS 5.0 and below, we do not have support for this feature - let's call it whitelisting. To whitelist let's say "Windows Update", lower level signatures like SSL, HTTPS.BROWSER have to be set to Allow/Monitor. This is undesirable as it means all other SSL and HTTPS.BROWSER will be allowed too.

     

    In FortiOS 5.2 and above, we addressed this issue with our application dependency tree. You no longer need to set signatures like SSL, HTTPS.BROWSER or other lower level signatures to Allow/Monitor to allow the higher level signatures like "Windows Update". The FortiGate, through the dependency tree will know if it has to defer identification of a session.

    IAC
    IAC
    New Member
    September 18, 2017

    One more comment regarding this interesting post. We are running v5.2.7 on 2 FG500D. We are facing similar scenarios (Application Control, Web Filtering and exceptions) like those ones you have already explained in this post. As far as I have understood the key point is the way a traffic reaching FortiOS matches or not certain policies. It seems that Security Profiles perform actions once the traffic has matched a certain policy. This behaviour makes difficult to manage exceptions and/or different actions in a sequential mode (e.g. based on FSSO AD Groups). Might there be a way in which a traffic denied by a policy (this would be optional, not for all policies) could keep trying to match another subsequent policy (either sequentially or a specific policy id)? As far as I know some other firewall companies allow this option. Thanks. Ignacio.

    beltskyy
    beltskyy
    Visitor III
    December 7, 2021

    5 years spent since the initiation of this post so I am wondering whether there are any changes in development of Fortigate/FortiOS that could allow us to stack several policies for different applications one by one

      seaton
      seaton
      New Member
      January 31, 2024

      Use NGFW mode in FortiGate, that will match like a Palo. However, I think largely the concerns here are over blown, it just requires a different way of thinking about your rules in profile mode.  People are mentioning exceptions well, what makes an exception....Some other attribute being different (besides simply an app being allowed vs blocked), put that policy first in profile mode, your default policy should be last in the rule base.  As far as copying profiles it is copy and paste in the command line.

      Terms & ConditionsAccessibility statement