DLP stopping single website

[lrob]

First post here... have enjoyed the information exchanged in the posts and the many different ways to tackle various issues. I am not new to Fortigate devices - have been installing them in small businesses for 5+ years. But I have an issue that I could use some input on. I have not used DLP much. Fortigate 100D, HA active cluster, running v5.2 OS. The system is performing well but I have a DLP snag. With DLP active on an outbound rule, scanning for CC info in files and email, using the built-in sensor a single website constantly is flagged and blocked by these DLP rules. The file it references is a .js file. Remove DLP and site access works. App, A/V and web filtering are also enabled on this rule. We have sought support from the site vendor and they confirm no CC data is embedded in the file. My question is: is there a way to exempt this one site from being flagged? It is a valid site that is required to be used by the business. Thanks in advance for any input.

[netmin]

The way we try to achieve this, is an urlfilter exemption:

 config webfilter urlfilter
  edit 0
   set name " Exempt_AV" 
    config entries
     edit 0
      set url " avupdate.example.com" 
      set action exempt
      set exempt dlp
     next
    end
   next
 end
 

I am just preparing some separate urlfilter lists for our next week' s test.

[lrob]

Thanks netmin for the suggestion. It looks like it should work. Will test this tomorrow.

[netmin]

It appears to do it' s job as intended - no more dlp messages but still webfilter rating, a.s.o.

[seadave]

Thanks for the info but man is this frustrating.  First off, why not put a check box "Exempt DLP" in the GUI.  Having to go to the CLI for this kind of stuff is maddening!!

That being said it would be much easier to have a DLP Allow and DLP Block in the same sensor.  That is sorely missed.

Create an allow filter first

Create a block filter second

It would be even better if you could associate hosts with files.  So entering:

Host: gstatic.com (This should support wildcards due to the number of CDN sites in use)

File: f.txt

Action: Allow

Is a lot easier that digging through regex guides.

[seadave]

I don't think this works on 5.2.2.  I just ran a test and if you choose "exempt" in the URL filter GUI, it enters the following in the CLI:

FG100D (37) # get

id : 37

url : download.piriform.com

type : simple

action : exempt

status : enable

exempt : av web-content activex-java-cookie dlp fortiguard range-block all

referrer-host :

What makes this confusing is if you review the FortiOS Handbook, it says the filters are processed in the following order:

Flow-Based

IPS

App Control

DLP

Email

Web Filter

AV

Proxy-based Inspection Engine

DLP

Email

Web

AV

So if I understand this correctly and you use Flow-Based (which appears to have all sorts of issues so I never do), it will process DLP before Web Filter with the same result if you use the Proxy-based engine.  So how is exempting a URL going to to allow a file if the DLP engine is getting to it first?

I've had a hard time getting my head around the 5.X logical flow.  4.X seemed more sensible to me.  Especially this:

Implicit fall-through feature for user authentication policies In FortiOS v5.2.0 user authentication policies have an implicit fall-through feature that causes policy matching to fall through to a policy lower on the list that can also match the traffic. In other words the first user policy that is matched in the policy list, based on standard policy criteria, isn’t the only policy that can be matched. To illustrate implicit fall-through, consider a FortiOS v5.2.0 policy list consisting of the following two policies: id 1: internal, (subnet1) ---> wan1, (all), service(all), has authentication id 2: internal, (subnet1) ---> wan1, (all), service(all), no authentication Since both policies have the same policy matching criteria the fall-through feature matches traffic with policy 2. The result of this policy list would be that no user would ever see a firewall authentication prompt. This is not the intention of the fall-through feature but a policy list like this could be created unintentionally. Especially after a firmware upgrade since this configuration was acceptable for FortiOS v5.2.0. Fall-through is intended to match users in different user groups with different policies. For example, consider an organization with two user groups where user group A requires a web filtering profile and user group B requires virus scanning. You could set up the following policy list: id 1: internal, (subnet1) ---> wan1, (all), service(all), user group A, Web Filtering profile id 2: internal, (subnet1) ---> wan1, (all), service(all), user group B, Antivrus profile In this configuration, all users from subnet1 will see an authentication prompt. If the user is found in user group A the traffic is accepted by policy 1 and is filtered by the Web Filtering profile. If the user is found in user group B the traffic is accepted by policy 2 and is virus scanned. The fall-through feature is required for users to be matched with policy 2. Without fall-through traffic would never be matched with policy 2.

Not sure how to resolve this DLP issue.  Time to open a ticket.