Global Policy Overview

In a Junos OS stateful firewall, security policies enforce rules for transit traffic, in terms of what
traffic can pass through the firewall, and the actions that need to take place on traffic as it passes
through the firewall. Security policies require traffic to enter one security zone and exit another
security zone. This combination of a from-zone and to-zone is called a context. Each context
contains an ordered list of policies. Each policy is processed in the order that it is defined within
a context.
You can configure a security policy from the user interface. Security policies control traffic flow
from one zone to another zone by defining the kind(s) of traffic permitted from specific IP
sources to specific IP destinations at scheduled times. This works well in most cases, but it is not
flexible enough. For example, if you want to perform actions on traffic but do not care about the
zones (that is, you want to permit all traffic to access a given server in the DMZ), you have to
configure policies for each possible context. To avoid creating multiple policies across every
possible context, you can create a global policy. Global policies provide you with the flexibility
to perform actions on traffic without the restrictions of zone specifications.
Unlike other security policies, global policies do not reference specific source and destination
zones (from-zone and to-zone). Global policies allow you to regulate traffic with addresses and
applications, regardless of their security zones. Global policies reference user-defined addresses
or the predefined address any. These addresses can span multiple security zones. For example,
if you want to provide access to or from multiple zones, you can create a global policy with the
address any, which encompasses all addresses in all zones. Selecting the any address
matches any IP address, and when any is used as a source/destination address in any global
policy configuration, it matches the source/destination address of any packet.
Traffic is classified by matching the policys source address, destination address, and the
application that the traffic carries in its protocol header. Each global policy, as with any other
security policy, has the following actions: permit, deny, reject, log, count.

Note: Global policies do not support VPN tunnels because VPN tunnels require specific
zone information (from-zone and to-zone).

Global policies in one logical system are in a separate context than other security policies and
have a lower priority than regular security policies in a policy lookup. For example, if a policy
lookup is performed, regular security policies have priority over global policies. Therefore, in a
policy lookup, regular security policies are searched first and if there is no match, global policy
lookup is performed.

Similar to regular policies, global policies in a context are ordered, such that the first matched
policy is applied to the traffic.
You can define global policies for each logical system.
Global Policy Overview

In a Junos OS stateful firewall, security policies enforce rules for transit traffic, in terms of what
traffic can pass through the firewall, and the actions that need to take place on traffic as it passes
through the firewall. Security policies require traffic to enter one security zone and exit another
security zone. This combination of a from-zone and to-zone is called a context. Each context
contains an ordered list of policies. Each policy is processed in the order that it is defined within
a context. Traffic is classified by matching the policys from-zone, to-zone, source address,
destination address, and the application that the traffic carries in its protocol header. Each global
policy, as with any other security policy, has the following actions: permit, deny, reject, log,
count.
You can configure a security policy from the user interface. Security policies control traffic flow
from one zone to another zone by defining the kind(s) of traffic permitted from specific IP
sources to specific IP destinations at scheduled times. This works well in most cases, but it is not
flexible enough. For example, if you want to perform actions on traffic you have to configure
policies for each possible context. To avoid creating multiple policies across every possible
context, you can create a global policy that encompasses all zones, or a multizone policy that
encompasses several zones.
Using a global policy, you can regulate traffic with addresses and applications, regardless of their
security zones, by referencing user-defined addresses or the predefined address any. These
addresses can span multiple security zones. For example, if you want to provide access to or
from multiple zones, you can create a global policy with the address any, which encompasses
all addresses in all zones. Selecting the any address matches any IP address, and when any is
used as a source/destination address in any global policy configuration, it matches the
source/destination address of any packet.
Using a global policy you can also provide access to multiple source zones and multiple
destination zones in one policy. However, we recommend that, for security reasons and to avoid
spoofing traffic, when you create a multizone policy you use identical matching criteria (source
address, destination address, application) and an identical action. In Figure 1, for example, if you
create a multizone policy that includes DMZ and Untrust from-zones, spoofing traffic from
203.0.113.0/24 from the DMZ zone could match the policy successfully and reach the protected
host in the Trust to-zone.
Figure 1: Multizone Global Policy Security Consideration

Note: Global policies without from-zone and to-zone information do not support VPN
tunnels because VPN tunnels require specific zone information.
When policy lookup is performed, policies are checked in the following order: intra-zone (trustto-trust), inter-zone (trust-to-untrust), then global. Similar to regular policies, global policies in a
context are ordered, such that the first matched policy is applied to the traffic.

Note: If you have a global policy, make sure you have not defined a catch-all rule such
as, match source any, match destination any, or match application any in the intra-zone or
inter-zone policies because the global policies will not be checked. If you do not have a
global policy, then it is recommended that you include a deny all action in your intrazone or inter-zone policies. If you do have a global policy, then you should include a
deny all action in the global policy.
In logical systems, you can define global policies for each logical system. Global policies in one
logical system are in a separate context than other security policies, and have a lower priority
than regular security policies in a policy lookup. For example, if a policy lookup is performed,
regular security policies have priority over global policies. Therefore, in a policy lookup, regular
security policies are searched first and if there is no match, global policy lookup is performed.
https://www.juniper.net/documentation/en_US/junos12.1x47/topics/concept/securitypolicy-global-policy-overview.html

Example: Configuring Global Policy

Unlike other security policies in Junos OS, global policies do not reference specific source and
destination zones. Global policies reference the predefined address any or user-defined
addresses that can span multiple security zones. Global policies give you the flexibility of
performing actions on traffic without any zone restrictions. For example, you can create a global
policy so that every host in every zone can access the company website, for example,
www.juniper.net. Using a global policy is a convenient shortcut when there are many security
zones. Traffic is classified by matching its source address, destination address, and the
application that the traffic carries in its protocol header.
This example shows how to configure a global policy to deny or permit traffic.

Requirements

Overview

Configuration

Verification

Requirements

Before you begin:

Review the firewall security policies.

See Security Policies Overview, Understanding Security Policy Rules, and

Understanding Security Policy Elements.

Configure an address book and create addresses for use in the policy.

See Example: Configuring Address Books and Address Sets.

Create an application (or application set) that indicates that the policy applies
to traffic of that type.

See Example: Configuring Applications and Application Sets.

Overview

This configuration example shows how to configure a global policy that accomplishes what
multiple security policies (using zones) would have accomplished. Global policy gp1 permits all
traffic while policy gp2 denies all traffic.
Configuration
CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file,
remove any line breaks, change any details necessary to match your network configuration, and
then copy and paste the commands into the CLI at the [edit] hierarchy level.
set security address-book global address server1 www.juniper.netset
security address-book global address server2 www.mail.comset security
policies global policy gp1 match source-address server1set security
policies global policy gp1 match destination-address server2set security
policies global policy gp1 match application anyset security policies global
policy gp1 then permitset security policies global policy gp2 match sourceaddress server2set security policies global policy gp2 match destinationaddress server1set security policies global policy gp2 match application
junos-ftpset security policies global policy gp2 then deny
Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For
instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User
Guide.
To configure a global policy to permit or deny all traffic:
1. Create addresses.

[edit security]user@host# set security address-book global address

server1 www.juniper.netuser@host# set security address-book global
address server2 www.mail.com
2. Create the global policy to permit all traffic.
[edit security]user@host# set policy global policy gp1 match sourceaddress server1user@host# set policy global policy gp1 match
destination-address server2user@host# set policy global policy gp1
match application anyuser@host# set policy global policy gp1 then
permit
3. Create the global policy to deny all traffic.
[edit security]user@host# set policy global policy gp2 match sourceaddress server2user@host# set policy global policy gp2 match
destination-address server1user@host# set policy global policy gp2
match application junos-ftpuser@host# set policy global policy gp2
then deny
Results

From configuration mode, confirm your configuration by entering the show security policies and
show security policies <global> commands. If the output does not display the intended
configuration, repeat the instructions in this example to correct the configuration.
user@host> show security policies
Default policy: permit-all
Global policies:
Policy: gp1, State: enabled, Index: 4, Scope Policy: 0, Sequence number: 1
Source addresses: server1
Destination addresses: server2
Applications: any
Action: permit
Policy: gp2, State: enabled, Index: 5, Scope Policy: 0, Sequence number: 2
Source addresses: server2
Destination addresses: server1
Applications: junos-ftp
Action: deny

If you are done configuring the device, enter commit from configuration mode.
Verification

Confirm that the configuration is working properly.

Verifying Global Policy Configuration
Purpose

Verify that global policies gp1 and gp2 are configured as required.

Action

From operational mode, enter the show security policy <global>command.

SRX Global Policy
Options

04-27-2012 06:50 AM
Theres seemingly two ways to do global policy on SRX.
- One method comes from what NSM pushes out when you create a Global Policy from the
policy tabs.
- The other method comes from a Juniper PDF and also in the docs in juniper.net/techpubs (link
to PDF).

Id be tempted to go with the version specified in the PDF as I trust it more than NSM, but when
you use it in JUNOS CLI it doesnt import into NSM on device import, so is a bit useless!

Versions in question:
- JUNOS 11.4r2.14 on SRX1400
- NSM2010.3s4 on NSMXpress with DMI Schema 228

1) What NSM sets when you create and push a Global Policy to SRX...

set security zones security-zone global address-book address p1 192.168.1.13/32

set security zones security-zone global address-book address p2 192.168.1.14/32
set security zones security-zone global address-book address h1 192.168.1.11/32
set security zones security-zone global address-book address h2 192.168.1.12/32
set security zones security-zone global address-book address-set p-bgp-router address p1
set security zones security-zone global address-book address-set p-bgp-router address p2
set security zones security-zone global address-book address-set h-bgp-router address h1
set security zones security-zone global address-book address-set h-bgp-router address h2
set security policies from-zone global to-zone global policy 15 match source-address p-bgprouter

set security policies from-zone global to-zone global policy 15 match destination-address h-bgprouter
set security policies from-zone global to-zone global policy 15 match application junos-bgp
set security policies from-zone global to-zone global policy 15 then permit

2) What the PDF and docs tell you to do (NSM seems unaware of this method, as when you
configure this I the JUNOS CLI and import to NSM, nothing is imported for policy) ...

set security address-book global address p1 192.168.1.13/32

set security address-book global address p2 192.168.1.14/32
set security address-book global address h1 192.168.1.11/32
set security address-book global address h2 192.168.1.12/32
set security address-book global address-set p-router address p1
set security address-book global address-set p-router address p2
set security address-book global address-set h-router address h1
set security address-book global address-set h-router address h2
set security policies global policy 14 match source-address p-router
set security policies global policy 14 match destination-address p-router
set security policies global policy 14 match application junos-bgp
set security policies global policy 14 then permit

Creating a global firewall policy on Juniper SRX

Submitted by Bart on Tue, 06/29/2010 - 21:15
Blog Category:

juniper

SRX

Firewall

apply-groups

Juniper firewalls, both netscreen and SRX, use a concept of security zones. Each interface is
assigned to a zone and firewall policies are created between zones to permit traffic. This is very
useful as you can safely use the "Any" object in firewall rules without unexpected results.

However, sometimes its useful to create policies regardless of the source and destination zones.
The most common reason is to create a default deny rule with logging enabled.
On netscreen firewalls, there was a global rulebase which was evaluated if there was no
matching rule in the regular rulebase. On SRX series however, there is no global rulebase. So in
order to create default deny rules with logging enabled, you have to create rules for each possible
combination of source and destination zone. This can be a lot of work as the number of policies
required increases exponentially.
Tired of creating so many rules, I figured there had to be an easier way. This device is running
JUNOS, there must be some feature or script that can help simplify this, and there is. Its a feature
called configuration groups which makes it easy to repeat a piece of configuration multiple
times. This following example create a firewall rule that drops and logs all traffic. This rule is
then appended to each rule set:
set groups global-policy security policies from-zone
default-logdrop match source-address any
set groups global-policy security policies from-zone
default-logdrop match destination-address any
set groups global-policy security policies from-zone
default-logdrop match application any
set groups global-policy security policies from-zone
default-logdrop then deny
set groups global-policy security policies from-zone
default-logdrop then log session-init

<*> to-zone <*> policy

<*> to-zone <*> policy
<*> to-zone <*> policy
<*> to-zone <*> policy
<*> to-zone <*> policy

set security policies apply-groups global-policy

This can easily be extended to create address objects in multiple zones at once, or modified to
apply only to select rule sets.
The apply-group is not entirely the same as the global policy on netscreen, it will only create a
default log+drop rule in each existing rule set. So if there are two zones for which no policy
exists yet, no drop rule will be installed either.
Juniper SRX global security policy - revisited
Submitted by Bart on Sun, 04/29/2012 - 21:32
Blog Category:

juniper

SRX

security

Quite a while ago I wrote about creating a global policy using apply-groups. It works, but its
main disadvantage was that it only logs traffic if there is at least one permit rule between the
source and destination zones.
As of Junos 11.2, a global firewall rulebase can now be configured. Just like the netscreen global
rulebase, this only gets evaluated if there is no match in the regular rulebase. So, it can be used to
create a default logdrop rule like this:
[edit security policies global]
policy default-logdrop {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
}

When traffic does not match any of the permit policies, it is now logged in the following format:
RT_FLOW - RT_FLOW_SESSION_DENY [junos@2636.1.1.1.2.39 sourceaddress="10.199.6.91" source-port="5947" destination-address="194.178.10.7"
destination-port="80" service-name="junos-http" protocol-id="6" icmp-type="0"
policy-name="default-logdrop(global)" source-zone-name="trust" destinationzone-name="untrust" application="UNKNOWN" nested-application="UNKNOWN"
username="N/A" role="N/A" packet-incoming-interface="fe-0/0/8.6"]

The global policy works fine for a default logdrop rule, but when you want to specify specific
source or destination addresses in a rule, things get more interesting. The addresses need to be
defined in the new global address book at [security address-book] instead of the zone-specific
ones. Unfortunately, the two cannot be combined. If you try to commit this change, you'll see
error messages like this:
[edit security zones security-zone untrust]
'address-book'
Zone specific address books are not allowed when there are global address
books defined

So you will have to convert all your address books to the new style, which is quite a
bit of work.