Fortigate Web Filtering Issue - RegEx

[MattIggo]

Hi Guys,

Trying to build out the fortigate filtering using regular expressions and I can't seem to make them do what I want.

We have an implicit deny policy in place so need to allow access to the CRL for microsoft, go daddy etc.

I have setup a policy as below:

config webfilter profile
    edit "Certificate_Revocation_Check"
            config override
                set ovrd-user-group ""
            end
            config web
                set urlfilter-table 10
            end
            config ftgd-wf
                    config filters
                        edit 1
                            set category 140
                        next
                        edit 2
                            set category 141
                        next
                    end
            end
        set log-all-url enable
    next
end

However, All I see are "passthrough".

Please can you offer some assistance?

[Dave_Hall]

Hi Matt.

Welcome to the forums.

Can you clarify what you mean by passthrough? As in not hitting the firewall policy?  Have you actually applied the web filtering profile to firewall policy?  Can you post a screenshot of the firewall policy in question?  If you have a web filter profile enabled on a firewall policy, you should be able to see "drilled down" session info, similar to the following screenshot (from 5.0.9 firmware)...

[MattIggo]

Hi Dave,

Yes I can see that, Please see attached screenshot.

I will reply in a second with my policy.

[MattIggo]

This is my Web Filter Profile

This is the Policy

This is the policy in detail

Using FortiOS 5.2.2

I have a set of profiles setup as shown below: (Not sure this is correct by the way!)

[ede_pfau]

(Not sure this is correct by the way!)

The 'all' address object makes all other addresses oblivious. I'd recommend you define the address spaces of your VLANs, group them and employ that in the policies. 'all' to 'all' is only rarely justified.

Just my 2 ct.

[MattIggo]

All to All has a perfectly valid reasoning in this deployment.

Yes, It should be cleared up "ideally" but first, Functionality....

[ede_pfau]

I'm not sure you see my point:

if you both specify 'all' and another address as source, that other address will never be looked at. I just want to make you aware of this.

[MattIggo]

Hi,

I kind of see your point but need some information qualifying if possible?

Are you saying the following? Packets come in from ip 1.1.1.1 destined to 2.2.2.2 tcp port 80.

The policy says: Permit internal any external any http

The incoming IP will match any and then it won't look at the destination? This is completely different to how I see it functioning in real world terms?

My understanding of packet flows is: Incoming Interface match

Incoming IP Match

Outgoing Interface match

Outgoing IP Match

Service Match

Permit / Deny

Matt

[Dave_Hall]

To be honesty, I can not tell from that firewall policy screen what does what without the column headings.  Also, not sure what the action "passthorough" means -- none of our fgt devices are on the 5.2 firmware path. 

Three things:

[ol]

The url profile/url filter looks ok. 

I agree with edu that the firewall policies could be cleaned up.

Web caching is enabled on the fw policy, which I suspect is what causing "grief" -- I know from 4.3.x no firewall policies are not actually hit if the requested object is stored in the cached. [strike](Perhaps this is what is meant by passthrough?)[/strike][/ol]

Edit: documentation on passthrough action is very lacking.  I loaded 5.2 on a 200D and played around with it, I can see the usual action messages, including passthough.  I'm assuming now it's just the fgt's way of saying the event (url filter allow action) is a hit and now it will "check other web filters". See this post.[strike][/strike]

[mramon79]

Hi,

in 5.2 is not possible universal reg expresion, here you have the answer from fortinet support to this issue:

I have information from developers that this behavior is by desing in
FortiOS 5.2, and will not be changed. For the performance reasons,
universal wildcard is no longer supported in URL filter. 

If you want to use the wildcard in the URL filter, you have at least
specify whether the string is part of the domain name, or path.