Complex App Rules with SSO

03/26/2020 5 8849

DESCRIPTION:

SSO, aka Single Sign-on, is a stand-in term for any kind of user authentication within SonicOS. SSO users can exist on LDAP, for instance Active Directory or Novel/eDirectory, on RADIUS, or locally configured on the firewall. SSO can also reference groups, however, nested groups on LDAP or RADIUS are not supported. In order to implement a nested group like behavior, LDAP/RADIUS groups needs to be nested within a locally configured group.

Users can be attached to both Stateful Inspection (SPI) Access Rules, as well as to Deep Inspection (DPI) App Rules. However, the user within the rule is not part of the match criteria. The match criteria for Access Rules are src-ip, dst-ip and service. Those for App Rules are src-ip, dst-ip, sockets (service), and a match object. A match object can contain various application layer match conditions from matching a specific regular expression within the data stream, to  context matches, such as the subject line of an email or a file name, to applications or functions within applications. Most often, match objects contain application categories (SOCIAL-NETWORKING), applications (Facebook), and Application Signatures (Like and Comment 1).

Access Rules are applied between a set of ingress and egress security zones, while App Rules are general applied global, but can be restricted to a defined ingress zone.

Only if a match criteria is satisfied, the user is being checked. The behavior is a little bit different for Access Rules compared to App Rules: the user is only checked one time in the entire rule base on satisfying the match criteria. For both Access Rule and App Rules, if a match criteria is found, the rule’s action is executed. The difference lies in a user NOT matching. For an Access Rule for all non-matched users, the action is inversed. For instance an Allow becomes a Deny, and either a Deny or Discard, becomes an Allow. For App Rules, all non-matched users are no further processed. Per SonicOS definition, App Rules are always negative matches. This functionality is aligned on how application inspection engines work internally. While a user match condition typically leads to an enforcement action for the matched user, there is absolutely no action for users that are not matched. In other words, non-matching users are excluded from further processing on the same match object.

Both rule bases are processed top down, whereas rule order for App Rules is non-deterministic and can change. This implies that we cannot write rules that apply to one user group, and then another set of rules that applies to another user group. Instead of doing this, we need to identify the overlap of denied applications (or any other match object) that is common to two or more users groups. Put all these user groups into a (local) nested group, and deny them for the entire nested group. Then deny applications that are individual to each user group successively.

Instead of writing two rules, one rule that denies access to Netflix and Facebook to one group, and another that denies access to YouTube and Facebook for the second group, we write one rule that denies access to Facebook for a (local) user group called users-a&b, and two other rules, one that denies Netflix to users-a and another that denies YouTube to users-b.

Note that App Rules are always negative matches, because this is how application engines work: they need to detect the application in order to apply an action to it. You cannot allow what you do not know, yet. In order to permit an application, you want to deny all denied applications within an Application Category - with the exception of the permitted application. For instance in order to allow Facebook, you deny the entire category SOCIALNETWORKING - with the exception of Facebook. Likewise, if you want to allow Facebook and Twitter, you deny SOCIAL-NETWORKING with the exception of one single match object that contains Facebook and Twitter. Remember, you can only match once on any given rule.

RESOLUTION:

To view the App Rules recipes please see the following PDF: Complex App Rules with SSO - Configuration Guide.