Announcement

Collapse
No announcement yet.

authenticatat security rules or not using implicit deny

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • authenticatat security rules or not using implicit deny

    With security policies with authentication, the implicit deny is not handy.

    For example:
    If you use multiple groups (of users) and every group can access a group of servers (address object) then all other users have a implicit deny.
    This is very unhandy (think about it)

    Feature request:
    Option with "Authenticated" rules to Allow something but not using the same rule implicit as a deny rule if the authentication is false.
    The block at the end of all rules can be made by the firewall administrator manually if needed.

  • #2
    GTA appreciates your valued feedback. However, I believe that we are not fully understanding what the feature would accomplish.

    Do you mean the implicit deny for users who are indeed Authenticated but not in a proper group which allows access? Or are you referring to the deny given to the Users who are not Authenticated? What is the security goal of requiring authentication for one Security Policy but having another which would allow access? We believe that this then would defeat the purpose of requiring authentication on the upper policy.

    Comment


    • #3
      We have groups of users (departments) and groups of servers (different projects)

      In [Configure -> Security Policies -> Outbound] we cannot give users simple access to this servers, for example
      Authentication required "user-group-finance" destination address "finance-servers-object"

      If we use this rule, than other departments (administrators) are ruled out, because we cannot add a second rule (or last rule) for administrators to access al server-objects.

      What we now do is a "workaround", we make a rule "Allow-Finance-Servers" with authentication required and make a group member of a group, so these are department-finance en administrators.

      This is just a example, but this is done in a complex infrastructure with 20+ departments and 40+ server groups.
      The rules for access are now to complex and cannot be made simpler because some departments have to access differtent server groups and ruling out others.

      What I mean to tell is that normally with security rules you can make more "allow rules" which are processed after each other (all the allow rules are processed) till it reaches a block rule.
      This mechanism is not possible with the current implementation of "authenticated" security policies. And that is what we need ;-)
      Last edited by Freddy; 2016-02-18, 18:17.

      Comment


      • #4
        Thank you for this additional information. We now understand this configuration goal and think that it makes sense in the case of Outbound Security Policies.

        We have created a feature request for our development team to examine.

        Comment


        • #5
          This feature will be included in the next release of GB-OS, GB-OS 6.2.2. If Authentication on a particular Security Policy fails, the firewall will trickle down to the next Security Policy rather than implement the implicit deny on the Authentication Required policy.

          Comment

          Working...
          X