Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
@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.
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.
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.
@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?
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
Mike Pruett
>>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.
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.
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
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1710 | |
1093 | |
752 | |
447 | |
231 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.