Friday, 16 November 2012

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 pre-defined 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 end-time 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 the weekday statement (defined by entering day of week) is used to set day specific parameters. When using a combination of daily and weekday statements the weekday statement will take precedence. This scheduler named 'work_week' could be used to schedule a policy that would be active Mon-Fri 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 destination-ip 8.8.8.8 source-ip 192.168.1.10 destination-port 53 source-port 49152 from-zone TRUST to-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 source-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.


No comments:

Post a Comment