- Products
- Network Security
Next Generation FirewallNext-generation firewall for SMB, Enterprise, and Government
Security ServicesComprehensive security for your network security solution
Network Security ManagerModern Security Management for today’s security landscape
- Advanced Threat Protection
Capture ATPMulti-engine advanced threat detection
Capture Security applianceAdvanced Threat Protection for modern threat landscape
- Access Security
Cloud Edge Secure AccessDeploy Zero-Trust Security in minutes
Secure Mobile AccessRemote, best-in-class, secure access
Wireless Access PointsEasy to manage, fast and secure Wi-FI
SwitchesHigh-speed network switching for business connectivity
- Email Security
Email SecurityProtect against today’s advanced email threats
- Cloud Security
Cloud App SecurityVisibility and security for Cloud Apps
Cloud Firewall (NSv)Next-generation firewall capabilities in the cloud
- Endpoint Security
Capture ClientStop advanced threats and rollback the damage caused by malware
Content Filtering ClientControl access to unwanted and unsecure web content
- Product Widgets
- Product Menu Right Image
- Network Security
- Solutions
- Solutions Widgets
- Solutions Image Widgets
- Solutions Widgets
- Partners
- Partner Widgets
- Partners Image Widgets
- Partner Widgets
- Support
- Support Widget
- Support Image Widgets
- Support Widget
- Products
- Network Security
- Next Generation FirewallNext-generation firewall for SMB, Enterprise, and Government
- Security ServicesComprehensive security for your network security solution
- Network Security ManagerModern Security Management for today’s security landscape
- Advanced Threat Protection
- Capture ATPMulti-engine advanced threat detection
- Capture Security applianceAdvanced Threat Protection for modern threat landscape
- Access Security
- Cloud Edge Secure AccessDeploy Zero-Trust Security in minutes
- Secure Mobile AccessRemote, best-in-class, secure access
- Wireless Access PointsEasy to manage, fast and secure Wi-FI
- SwitchesHigh-speed network switching for business connectivity
- Email Security
- Email SecurityProtect against today’s advanced email threats
- Cloud Security
- Cloud App SecurityVisibility and security for Cloud Apps
- Cloud Firewall (NSv)Next-generation firewall capabilities in the cloud
- Endpoint Security
- Capture ClientStop advanced threats and rollback the damage caused by malware
- Content Filtering ClientControl access to unwanted and unsecure web content
- Product Widgets
- Product Menu Right Image
- Network Security
- Solutions
- Solutions Widgets
- Solutions Image Widgets
- Solutions Widgets
- Partners
- Partner Widgets
- Partners Image Widgets
- Partner Widgets
- Support
- Support Widget
- Support Image Widgets
- Support Widget
Complex App Rules with SSO
03/26/2020 
5 People found this article helpful
39,684 Views
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.
Related Articles
- How to Create Gen 7 Settings File by Using the Online Migration Tool
- DNS Resolution of Wildcard FQDN Address Objects
- All associated wildcard FQDN IP addresses do not display in the web browser
Categories
- Firewalls > NSa Series > Application Firewall
- Firewalls > NSv Series > Application Firewall
- Firewalls > TZ Series > Application Firewall
YES
NO