Junos OS

Hi,

As far as I know, when you apply policy rules via inheritance, these inherited rules get applied AFTER the context-specific rules.

Is there a way to change this behaviour, so that rules applied via the "apply-groups" directive get applied BEFORE the context-specific rules?

What I'm specifically trying to achieve is to have some kind of "global deny rules" that get applied before any other permit rules.

Best regards,

NDLR: I've selected the wrong article as "ACCEPTED SOLUTION". The actual solution I chose to implement is a litle bit under in the topic and is the one also posted by "aarseniev" but at "11-21-2013 09:14 AM"

Hello,

I'll give it a stab 🙂

I am not sure what do You mean by saying "context-specific rules"?

Are You doing apply-groups for SRX security policies as configured under [edit security policies]? 

Or is that routing policies as configured under [edit policy-options]?

In any case, groups are acting similar to REGEX, difference is not full REGEX functionality is supported in groups.

So if You structure Your groups in REGEX way, You could achieve precise application of desired config bits under exact position. Below is one example:

lab@JUNOSRTR# show | compare 
[edit groups]
+  MYPOL {
+      policy-options {
+          policy-statement <TST*> {
+              term t10 {
+                  from community 65534:65534;
+              }
+              term t20 {
+                  from community 65534:1;
+                  then {
+                      local-preference 200;
+                  }
+              }
+          }
+      }
+  }
[edit policy-options]
+  apply-groups MYPOL;
[edit policy-options]
+   policy-statement TST1 {
+       term t10 {
+           then accept;
+       }
+       term t20 {
+           then accept;
+       }
+   }
[edit]
lab@JUNOSRTR# show policy-options policy-statement TST1 | display inheritance    
term t10 {
    ##
    ## 'from' was inherited from group 'MYPOL'
    ##
    ##
    ## '65534:65534' was inherited from group 'MYPOL'
    ##
    from community 65534:65534;
    then accept;
}
term t20 {
    ##
    ## 'from' was inherited from group 'MYPOL'
    ##
    ##
    ## '65534:1' was inherited from group 'MYPOL'
    ##
    from community 65534:1;
    then {
        ##
        ## 'local-preference' was inherited from group 'MYPOL'
        ## '200' was inherited from group 'MYPOL'
        ##
        local-preference 200;
        accept;
    }
}

 HTH

Thanks

Alex

Hi,

thanks for your answer.

Though, it's not the information I'm looking for 😉

Say, I've defined the following group:

show configuration groups global_outbound_policies_to_internet
security {
    policies {
        from-zone <*> to-zone internet {
            policy block-specific-addresses {
                match {
                    source-address any;
                    destination-address addresses_to_block;
                    application any;
                }
                then {
                    deny;
                    log {
                        session-init;
                        session-close;
                    }
                }
            }
        }
    }
}

And have defined the following security policy:

show configuration security policies from-zone gtc to-zone internet
apply-groups global_outbound_policies_to_internet;
policy gtc2internet {
    match {
        source-address gtc;
        destination-address any;
        application any;
    }
    then {
        permit;
    }
}

 The resulting security policy, with inheritance, is the following:

show configuration security policies from-zone gtc to-zone internet | display inheritance
policy gtc2internet {
    match {
        source-address gtc;
        destination-address any;
        application any;
    }
    then {
        permit;
    }
}
##
## 'block-specific-addresses' was inherited from group 'global_outbound_policies_to_internet'
##
policy block-specific-addresses {
    ##
    ## 'match' was inherited from group 'global_outbound_policies_to_internet'
    ##
    match {
        ##
        ## 'any' was inherited from group 'global_outbound_policies_to_internet'
        ##
        source-address any;
        ##
        ## 'addresses_to_block' was inherited from group 'global_outbound_policies_to_internet'
        ##
        destination-address addresses_to_block;
        ##
        ## 'any' was inherited from group 'global_outbound_policies_to_internet'
        ## Warning: application or application-set must be defined
        ##
        application any;
    }
    ##
    ## 'then' was inherited from group 'global_outbound_policies_to_internet'
    ##
    then {
        ##
        ## 'deny' was inherited from group 'global_outbound_policies_to_internet'
        ##
        deny;
        ##
        ## 'log' was inherited from group 'global_outbound_policies_to_internet'
        ##
        log {
            ##
            ## 'session-init' was inherited from group 'global_outbound_policies_to_internet'
            ##
            session-init;
            ##
            ## 'session-close' was inherited from group 'global_outbound_policies_to_internet'
            ##
            session-close;
        }
    }
}

Which is obviously not my goal.

I would like to know if it's possible to insert the inherited policy "block-specific-addresses" before the specific policy "gtc2internet".

Best regards,

Cyrille

Hello,

SRX it is then 

Of course it is possible, You have to think in terms of REGEX and its position. Below is one example where You configure a placeholder policy above:

[edit security policies from-zone gtc to-zone internet]
aarseniev@SRX# show                                            
Nov 21 18:11:36
policy block-specific-addresses {
    then {
        count;
    }
}
policy gtc2internet {
    match {
        source-address gtc;
        destination-address any;
        application any;
    }
    then {
        permit;
    }
}

[edit security policies from-zone gtc to-zone internet]
aarseniev@SRX# show | display inheritance | no-more 
Nov 21 18:11:41
policy block-specific-addresses {
    ##
    ## 'match' was inherited from group 'global_outbound_policies_to_internet'
    ##
    match {
        ##
        ## 'any' was inherited from group 'global_outbound_policies_to_internet'
        ##
        source-address any;
        ##
        ## 'addresses_to_block' was inherited from group 'global_outbound_policies_to_internet'
        ##
        destination-address addresses_to_block;
        ##
        ## 'any' was inherited from group 'global_outbound_policies_to_internet'
        ## Warning: application or application-set must be defined
        ##
        application any;
    }
    then {
        ##
        ## 'deny' was inherited from group 'global_outbound_policies_to_internet'
        ##
        deny;
        ##
        ## 'log' was inherited from group 'global_outbound_policies_to_internet'
        ##
        log {
            ##
            ## 'session-init' was inherited from group 'global_outbound_policies_to_internet'
            ##
            session-init;
            ##
            ## 'session-close' was inherited from group 'global_outbound_policies_to_internet'
            ##
            session-close;
        }
        count;
    }
}
policy gtc2internet {
    match {
        source-address gtc;
        destination-address any;
        application any;
    }
    then {
        permit;
    }
}

[edit security policies from-zone gtc to-zone internet]
aarseniev@SRX# commit check 
Nov 21 18:11:43
configuration check succeeds

[edit security policies from-zone gtc to-zone internet]
aarseniev@SRX# 

You can also do placeholder policy insertion using commit script if You have large # of policies.

HTH

Thanks

Alex

Interesting approach, not something I've seen or thought of before.  Not sure that it actually achieves the goal though.  The policy exists, albeit as just a stub, so the apply-group expansion is just populating the stub.  It also requires maintaining a stub for every policy that exists in the group and ensuring it is at the correct position.

If the goal is to simply add policies to the group and automatically update the security policy, it fails since it still requires putting a stub of each new policy added to the group into every security policy that applies that group.

Still, that is an interesting technique that I have filed away for potential use in the future.

-Chad

I did this in the opposite manner due to the inheritance order.

Instead of the policy being a default allow and using an apply-group for the denies, the policy is the list of denies and the default allow is applied via apply-group.  That ensures that the default action will always be at the end of the policy without having to remember to rearrange the term order when adding new terms later.

If you want to use that set of denies in multiple policies, move them over to an apply-group.  You can then apply both of them, just be sure the order you specify matches the order you want them processed.

You can use the same concept with default-deny as well.

Regarding getting an inherited policy put in front of the explicitly configured policy, no such luck.  Apply-group inheritance will always append to the explicit configuration.  The only way around it is to shift all of those configuration pieces to apply-groups and apply the groups in the order you wish them to be processed.  If I remember correctly though, you can't specify apply-group at the security / policies level, it has to be inside the specific policy.  At least I remember running into something like that on 10.4, not sure if that has changed.

-Chad