Juniper SRX Tips :: Altering Default-Deny Behavior

In our previous article, we looked at using apply-groups to alter all the security policies uniformly on an SRX device such that they would all have an implicit logging statement. And while this is fine for all existing policies, it doesn’t log traffic which doesn’t match any explicitly defined security policy.

The reason for this is due to the fact that in Junos, traffic which doesn’t match an explicitly defined security policy matches against the default-deny policy.  However, given the fact that the default-deny policy is implicitly defined, apply-group configurations are of little benefit as apply-groups can only be inherited by those elements which have been explicitly defined.

Often in these cases, administrators will simply choose to create their own deny policies with the desired options and place this deny policy as the last policy for traffic going from one zone to another. However, in instances where there are many zones, it might prove too cumbersome and time consuming to manually configure this to accommodate all zones.

Clearly it would be more beneficial to have something akin to the Global Zone in ScreenOS which can be used to match on all traffic which doesn’t match against any of the explicitly defined security policies.  However, at the time of this writing, Global Zone functionality doesn’t exist in Junos.

The good news is that we can use the power of apply-groups once again to our benefit, this time to create an explicitly defined deny policy which will be inherited at the tail-end of all security policies defined within our configuration. Note that this will encompass both Inter-zone as well as Intra-zone traffic.

For this example, let’s assume that we want to log everything that would normally hit the default-deny policy. Let’s start by taking a look at our baseline configuration:

Here you can see we have a policy allowing all traffic outbound from the Users-subnet in the Trust zone towards the Untrust zone, and another policy allowing inbound HTTP traffic from the Untrust zone towards the Web Server in the Trust zone.  Now, in order to change the default-deny behavior and add additional options, we will use an apply-group to inherit a new policy at the tail-end of all previously defined policies, as follows:

Finally, let’s apply our apply-group at the [security policies] stanza within our configuration:

Now that we’ve completed the configuration, let’s examine the results of the application of our apply-group by taking a look at our security policies, this time by displaying the inherited configuration:

Once again, with just a couple of lines of code we can streamline the configuration to a large extent, in this case creating an explicitly defined deny policy which logs all traffic that would otherwise be silently discarded.  And best of all, we can do so without having to resort to manual configuration of each and every one.

In small installations this technique might be of little benefit, but in larger implementations consisting of dozens of zones with a combination of Interzone and Intrazone and bidirectional security policies, the benefit of such an approach cannot be understated.  Not only will this ease configuration burden, but it will ensure that all traffic which doesn’t match any of the existing security policies will be handled in a consistent manner.  Of course, as with previous examples, if there are certain policies that we don’t want to inherit this new default-deny, we can simply utilize the apply-group-except statement for each of those respective policies.

In our next article we will examine changing the built-in Junos application defaults so that we can customize timers and other parameters.