How to use App Control in policies

[cryptochrome]

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

[tanr]

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]

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

[CrisP]

I'm not really sure I understand your disappointment. Moreover, I couldn't find other major difference from the PA philosophy, except for the application dependencies (which is a really heavy-weight approach, but maybe not too difficult to introduce in FOS). But the main thing here is that everybody, not just PA and 40Net, must first allow/deny a session, and only then try to identify an application running over it. If you look at PA docs, they say that the app is triggered "at a certain moment" after opening a session, and no vendor can bypass this limitation unless a new technology inserts a L7 app id in every network packet, thus making your dream possible and putting the app at the base level of a FW rule. The rest seems to me just a different way of building the user interface, but with almost the same behavior behind the scenes. If we put aside the app dependencies, of course -- but this can be a matter of app database, yielding a set of app signatures at config time, not a dynamic behavior in face of the real-time traffic. Also, let's not forget that a lot of traffic is encrypted nowadays, so the same rule can be ineffective with a wrong certificate, because the app does not match anymore (or maybe you need to match on HTTPS in every rule, which is hilarious). Bottom line, I expect 40Net to issue app dependencies just before PA gets too much marketshare. The rest is silence (dropping).

I'm not an expert, sorry to contend but it's very interesting.

[cryptochrome]

No, the key difference between PA and the rest is that with PA you can in fact have the app as the base of the policy. Of course their system will have to receive a few packets before they can identify an app, but their approach still allows you to build a firewall policy solely based on apps. Apps are a full class citizen in the policy structure and you can actually use them to match traffic/rules, something you can't do with Fortinet.

I am not really disappointed in how Fortinet do it, it is just very limiting compared to PA.

[tanr]

@ede: Thanks for the confirmation.

So here's a possibly problematic scenario related to how AC profiles are used:

For a specific dmz -> wan situation, I want to allow only NTP, DNS, and Windows Update (through Application Control).  I can have one firewall policy that only allows NTP and DNS (limited to just trusted servers, etc. and yes, I should probably point them to local NTP and DNS).

The problem is the next firewall rule, which should allow ONLY Windows Updates for dmz -> wan.

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?

[CrisP]

Yes, I think you have a point, which I'd rather rephrase a little. In a model based on signature recognition, any firewall must allow some traffic (up to the longest sequence in the algorithm). After that, if you block unknown apps, the session is closed, and what passed is largely meaningless and hopefully harmless (unless some magic packet achieves DoS). You say PA needs "a few packets" to detect the app, maybe 40Net needs twice as much (????). In my opinion, the real quantum leap would be to use several parallel methods, not just signature/pattern detection. I heard, for instance, that some tools can detect encrypted P2P botnets or TOR by analyzing statistical parameters of the traffic. Such an approach is less predictable, as the relevant stochastic profile can emerge instantly or take longer to build up. How is this detection time variability compatible with the app as a basic fw rule parameter beats me. Another problem with delayed detection comes from the fact it favors the "everything passes except xxx" model, while the "block everything but yyy" approach is less efficient. 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). So you must study in real time and allow everything needed, various sites and wilcard domains (changing over time!) and auxiliary apps. Maybe PA offers all this in just a click, if so they are really good. 40Net must do it soon!

[MikePruett]

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]

>>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]

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]

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