It is a requirement, and in some cases it is the law, to log session denies on firewalls for accountability. On the Juniper SRX firewalls there is no boolean option to log default drops, instead you have to create a policy that explicitly denies and then logs via then log session-init. This becomes an issue when creating new global policies as they are always applied to the bottom and therefore below the policy we create to explicitly deny and log traffic. We have been pushing Juniper via a Feature Enhancement Request to include logging in as part of the default set security policies default-policy stanza so we didn’t have to worry about managing a default drop policy.
Until that time a co-worker and good friend of mine, Doug Didier (@KegedViolence), had a great idea to use apply-groups to manage the global policy as they are by default applied last. To do this we create a group, called in this case DENY-WITH-LOGGING, and then create our default deny and log policy under that.
ryan@srx210a# set groups DENY-WITH-LOGGING security policies global policy DENY-WITH-LOGGING match source-address any
ryan@srx210a# set groups DENY-WITH-LOGGING security policies global policy DENY-WITH-LOGGING match destination-address any
ryan@srx210a# set groups DENY-WITH-LOGGING security policies global policy DENY-WITH-LOGGING match application any
ryan@srx210a# set groups DENY-WITH-LOGGING security policies global policy DENY-WITH-LOGGING then deny
ryan@srx210a# set groups DENY-WITH-LOGGING security policies global policy DENY-WITH-LOGGING then log session-init
Side note, notice there is no set groups DENY-WITH-LOGGING security policies global policy DENY-WITH-LOGGING then log session-close as the session does not get setup on a wing and therefor there is no session to close.
We then apply this group to the security policies section of the configuration.
ryan@srx210a# set security policies apply-groups DENY-WITH-LOGGING
After commiting the change there are two ways to validate this. First from the configuration we can display inheritance in the configuration.
ryan@srx210a# show security policies global | display inheritance
policy ICMP {
match {
source-address any;
destination-address any;
application junos-icmp-all;
}
then {
permit;
log {
session-init;
session-close;
}
}
}
##
## 'DENY-WITH-LOGGING' was inherited from group 'DENY-WITH-LOGGING'
##
policy DENY-WITH-LOGGING {
##
## 'match' was inherited from group 'DENY-WITH-LOGGING'
##
match {
##
## 'any' was inherited from group 'DENY-WITH-LOGGING'
##
source-address any;
##
## 'any' was inherited from group 'DENY-WITH-LOGGING'
##
destination-address any;
##
## 'any' was inherited from group 'DENY-WITH-LOGGING'
##
application any;
}
##
## 'then' was inherited from group 'DENY-WITH-LOGGING'
##
then {
##
## 'deny' was inherited from group 'DENY-WITH-LOGGING'
##
deny;
##
## 'log' was inherited from group 'DENY-WITH-LOGGING'
##
log {
##
## 'session-init' was inherited from group 'DENY-WITH-LOGGING'
##
session-init;
}
}
}
Secondly we can can also validate this in operational mode.
ryan@srx210a> show security policies global
Global policies:
Policy: ICMP, State: enabled, Index: 29, Scope Policy: 0, Sequence number: 1
Source addresses: any
Destination addresses: any
Applications: junos-icmp-all
Action: permit, log
Policy: DENY-WITH-LOGGING, State: enabled, Index: 30, Scope Policy: 0, Sequence number: 2
Source addresses: any
Destination addresses: any
Applications: any
Action: deny, log
Though you could also do this in a zone-to-zone fashion this is the type of time that global policies were designed to handle. Whether you manage ten or ten thousand security policies you will realize what a time and troubleshooting saver this can be.