Security Policies - Advanced Policy Options

The previous post outlined basic security policy configuration. The purpose of this post is to
cover the topic of 'Advanced Policy Options'. The following subtopics will be reviewed in this
post.
1.
Applications (Predefined & Custom)
2.
DNS Address Book Entries
3.
Policy Scheduling
4.
TCP Options with Security Policies
5.
Application Services
6.
Policy Testing
The diagram below outlines the basic topology used for the exercises in this post.

Applications
View Pre-defined Applications
A number of applications are predefined in Junos operating system, default applications
have the name 'junos-application'. To see a list of predefined applications run the command
'show configuration groups junos-defaults applications'. The screenshot below displays
the partial output of the command.
Hint: The predefined application list is long, if you want to find a specific application you
could pipe this command with the match statement to search the output. For example to find
FTP you could use the following command 'show groups junos-defaults applications |
match ftp'

Changing Parameters on Pre-defined Applications

Pre-defined applications can be modified if needed. To do this simply edit the application
name under the 'edit applications application' hierarchy. The following example
demonstrates this by increasing the predefined application 'junos-ftp' to have a longer
inactivity timeout of 4500 seconds.

Keep in mind that only configured parameters will show up under the configuration for predefined applications.
Creating Custom Applications
New applications can be defined for applications that don't exist in the predefined list, or for
different policies that require the same application but with different settings. These are
called custom applications, and they can have the following parameters defined;
1. Name: Application name can be defined.
2. ALG: Application Layer Gateway can be associated with this application
3. Protocol: Protocol can be defined, usually TCP or UDP.
4. Destination Port: Destination TCP/UDP port the application is listening on (can also be a
range).
5. Source Port: Source TCP/UDP port the application is listening on (if not configured
source port will be entire 1-65535 range)
6. ICMP Code/Type: If specifying ICMP protocol ICMP message types can be defined.
7. Timeout: Defines length of time before application is determined to be inactive. The
session will be closed once this timer expires.
8. RPC Object ID: Defines Remote Procedure Call unique identifier. Used only for RPC
applications.

In the example below I have created a custom application named 'SFTP-BACKUP'. This
application runs SFTP/SSH to back up some servers on a non-standard tcp port of 9999. In
the configuration below no Source-port was defined as the source port is randomly
generated in a TCP connection and therefore when this is not configured will allow any
source-port. I have also increased the inactivity time out from the default TCP timer of 1800
seconds to 3600 seconds.

DNS Address Book Entries

Specifying an FQDN (fully qualified domain name) in the address book allows security
policies to be created using FQDNs for source and destination addresses. The example
below outlines the use of DNS based security policies.
Create Address Book Entry & Firewall Policy
The screenshot below outlines the creation of a DNS based addresses book entry for
www.bbc.com. The second part of the screenshot outlines configuration of a security policy
which uses this newly created address book entry. The security policy is blocking ICMP Ping
requests from the LAN subnet to the FQDN of www.bbc.com.

This screenshot summarizes the configuration.

Verify the Actual IP Address Used in the Security Policy

I originally thought that the SRX device would complete a DNS lookup on FQDNs within the
security policy each time the policy was hit, but this is not the case. The SRX will complete
an initial DNS lookup and will continue to use this IP address until the DNS (time to live) TTL
value expires. Once this TTL time expires the SRX will complete another DNS lookup for the
FQDN and store the IP address for the length of the TTL value. The command 'show
security policies policy-name NAME detail' can be used to view the actual address that
the security policy will use for www.bbc.com.

Policy Scheduling
Policy scheduling allows security policies to be enabled based on a pre-configured schedule
or timer. Each security policy can have only one scheduler, however each scheduler can be
referenced in multiple security policies. These schedules can be set for a single one time
event or recurring event. The JUNOS documentation outlines the methods a scheduler can
be configured:
Scheduler can be active for a single time slot, as specified by a start date and time
and a stop date and time.

Scheduler can be active forever (recurrent), but as specified by the daily schedule.
The schedule on a specific day (time slot) takes priority over the daily schedule.
Scheduler can be active within a time slot as specified by the weekday schedule.
Scheduler can have a combination of two time slots (daily and timeslot).
Example - Non-recurring (single time slot)
In this example a 'one time' schedule is configured. The statement start-time and endtime are used to configure this type of scheduler. The specific start time is Friday November
11th at 8am. The specific end time is Friday November 11th at 5pm. This scheduler named
'onetime_Fri' could be used to enable a configured security policy for the specified time. In
the example below the scheduler is added to an existing security policy allowing general
outbound internet access.

The command 'show schedulers' outlines the configured schedulers and there current
status. The current status is listed as 'inactive' meaning that any security policy that has this
scheduler configured would currently be disabled. The current time of this exercise is
Wednesday at 4pm which is why the scheduler is inactive.

The command 'show security policy from-zone NAME to-zone NAME' also confirms that
the security policy 'OUTBOUND-INTERNET-ACCESS' is disabled by the scheduler.

Example - Recurring Schedule

In this example a recurring schedule is configured. The statement daily is used to configure
a recurring daily schedule, and in addition to this theweekday statement (defined by entering
day of week) is used to set day specific parameters. When using a combination
of daily and weekdaystatements the weekday statement will take precedence. This
scheduler named 'work_week' could be used to schedule a policy that would be active MonFri from 8am-5pm. In the example below the scheduler is added to an existing security policy
allowing general outbound internet access. Keep in mind that the previous example was
undone as the security policy cannot have multiple schedulers.

The command 'show schedulers' outlines the configured schedulers and there current
status. The current status is listed as 'inactive' meaning that any security policy that has this
scheduler configured would currently be enabled. The current time of this exercise is
Wednesday at 4pm which is why the scheduler is active.

The command 'show security policy from-zone NAME to-zone NAME' also confirms that
the security policy 'OUTBOUND-INTERNET-ACCESS' is enabled by the scheduler.

Example - Recurring Schedule (alternate configuration)

In this example the same recurring schedule is configured as the previous example, but in a
different way. In this example only the weekday statement is used, and start and stop times
are configured under each weekday statement. The purpose of this example was to highlight
another configuration option of the scheduler where start and stop times are defined on a
specific weekday.

The command 'show schedulers' outlines the configured schedulers and there current
status. The current status is listed as 'inactive' meaning that any security policy that has this
scheduler configured would currently be enabled. The current time of this exercise is
Wednesday at 4pm which is why the scheduler is active.

Again, the command 'show security policy from-zone NAME to-zone NAME' also
confirms that the security policy 'OUTBOUND-INTERNET-ACCESS' is enabled by the
scheduler.

TCP Options within Security Policies

A number of TCP options can be configured at the global level (see screenshot below).

Of these global TCP options sequence-check and syn-check can also be configured on a
per policy basis as an extension of the 'then permit' statement. More specifically, if
sequence-check or syn-check are disabled at the global level they can be enabled on a per
policy basis. If sequence-check or syn-check are enabled at the global level then these
parameters cannot be configured under the security policy. In other words you cannot
disable sequence-check or syn-check for specific security policies.
The screen shot below outlines the commands to disable sequence-check and syn-check at
the global level, and enable at the policy level.

The following screenshot summarizes the configuration.

Application Services
Application services is another extension of the 'then permit' statement. Intrusion Detection &
Prevention (IDP) and Universal Threat Management (UTM) policies can be configured here.
These items will be reviewed in the Attack Prevention and UTM posts.

Testing the Security Policy

There is a handy command called 'show security match-policies' that can be used to test
a traffic condition against the configured policies. The following parameters must be
specified when issuing this command;
from-zone
to-zone
protocol
source-ip
destination-ip
source-port
destination-port
Below is an example of the command and output. In this example I want to test the security
policies configured on the device to see if DNS is allowed to my configured DNS server of
8.8.8.8 (Google DNS). The screenshot was truncated due to the length of command. The
command entered was "show security match-policies protocol udp destinationip 8.8.8.8 source-ip 192.168.1.10 destination-port 53 source-port 49152 from-zone TRUST t
o-zone INTERNET". Note that source-port 49152 was used in this example, the source port
is randomly generated and will be different for each session. The screenshot outlines that
this traffic would match the OUTBOUND-INTERNET-ACCESS policy.

Below is another example of the command and output. In this example I want to test the
security policies configured on the device to see if RDP is allowed to my internal host of
192.168.1.10 from the internet. The screenshot was truncated due to the length of
command. The command entered was "show security match-policies
protocol tcp destination-ip 192.168.1.10 source-ip 200.200.200.1 destination-port 3389 sour
ce-port 49152 from-zone INTERNET to-zone TRUST" The screenshot outlines that this
traffic would match the default-deny policy.

Conclusions
This concludes the post on Advanced Policy Options. If anyone feels I have missed
subtopics within the Advanced Policy Options please leave comments. My next posts will be
focusing on the application layer gateways (ALGs) available on the SRX platform.