Access Control Policy - traffic rule matching

[Nele Valjak]

Hello, I am a little bit confused with traffic matching some rule when all conditions are NOT met in that rule on defense center v5.4.1.5.

So, I have a case on DefenseCenter (AccessPolicy) where all conditions were NOT met but rule is applied to traffic.
I have one example where condition is to allow only Applications with Very Low, Low and Medium risk for certan AD users. But when I try to open some torrent site which is classified as Very High risk application, and it is recognized as "Very High" risk app, rule is applied to this traffic, and I am able to open this torrent site with no problems.

As I understand, all conditions have to be met to apply rule to some traffic. In this example, application Risk is NOT met, but rule is applied to traffic.

When I create rule with same conditions (security zones, AD users, ports), but with opposite application risk condition "High and Very High risk applications" "and opposite action "Block with reset", and I insert this rule above allow rule, then torrent site is recognized as "Very high  risk" and it is blocked.

Now I am insecure with rule creation, and each and every rule I have to test twice.

Any idea?

[Dennis Perto]

Are you certain that you do not use the default rule, eg. Intrusion Prevention, because it does not meet the conditions in your allow rule?

[Nele Valjak]

Yes, I am using default intrusion policy (with a little change), but still, as you can see in pictures, I have a policy "Internet pristup" and rule "SITT-pristup" which allows ONLY very low, low and medium risk applications (accessrule.png). After I apply access policy, in connection events I can see that High risk applications are matched with this rule (connectionevents.png)

[Dennis Perto]

That it strange. Can you please make a "report" of your Access Control policy, and copy all the text from the rule "SITT-pristup" and paste it here. 

[Nele Valjak]

Hi, DNS is OK (checked with cat /etc/resolv.conf and with pinging internal and external names)

In attachment you can find rule...

[Dennis Perto]

Do the traffic eventually get blocked while surfing the kastatic.com website?

You might be affected by this, in the documentation:

Speed of Application Identification

The system cannot perform application control before:

• a monitored connection is established between a client and server, and

• the system identifies the application in the session

  This identification should occur within 3 to 5 packets, or after the server certificate exchange in the SSL handshake if the traffic is encrypted. If one of these first packets matches all other conditions in an access control rule containing an application condition but the identification is not complete, the access control policy allows the packet to pass. This behavior allows the connection to be established so that applications can be identified. For your convenience, affected rules are marked with an information icon ( ).

  The allowed packets are inspected by the access control policy’s default intrusion policy (not the default action intrusion policy nor the almost-matched rule’s intrusion policy). For more information, see Setting the Default Intrusion Policy for Access Control, page 25-1.

  After the system completes its identification, the system applies the access control rule action, as well as any associated intrusion and file policy, to the remaining session traffic that matches its application condition.

[Nele Valjak]

Tested but no. (Browsed through site)

Tried on some other "very high risk" sites with or without encryption but it is same.

[Dennis Perto · Accepted solution]

For me it seems like a TAC case is the only way out of this uncertainty. 

The manual states that; "If you can write one rule that covers it all then you should not write two rules for it"

[Dennis Perto]

I just saw another post where the solution to a similar problem (URL filtering) was to check the DNS settings on the sensors. 

"Log in to the appliance's CLI as admin

on the '>' prompt, type 'configure network dns servers <ip addresses of DNS servers separated by commas>

Once this is done, type in expert, and type 'sudo /etc/rc.d/init.d/nscd restart'

Put in the admin password when prompted"