Wednesday, 14 November 2012

Security Policies - Overview

The security policy on the SRX, at a very basic level, is no different than any other firewall. Traffic is analyzed and a decision to allow or deny the traffic is made. I created the diagram below to help understand the structure of how the SRX evaluates the traffic and applies an action to the traffic. This will also help in understanding the configuration structure.

The SRX uses zones to quantify what rules the traffic needs to be inspected against. This limits some of unnecessary processing that happens when traffic is evaluated against rules that do not apply. All policies are configured under; "security policies from-zone ____ to-zone ___"

Policy order is important. Traffic is evaluated starting with the policy at the top, it will continue to be evaluated until a match is made. If a match does not happen on any of the configured policies the default policy will be applied which can be configured as 'allow' or 'deny'.

Within a policy the following sequence happens;
1. The scheduler statement allow the rule to be enabled or disabled based on a schedule. This could be on a recurring schedule such as a certain time of day or days of the week. This could also be for a specific period of with a start and finish time.
2. The match statement is where parameters can be set to match traffic. Applications can include the default applications that are pre-configured under JUNOS. They can also be custom applications that can be configured based on IP Protocols, ICMP Codes, TCP/UDP Ports or RPC identifiers. Source and destination IP can be a IPv4 or IPv6  host or network address. Also any of these match parameters can be set as 'any'.
3. The then statement is where the action parameters can be set. The two main actions are deny or permit, but there are also some other options such as log, count and reject. If the action is set as permit there are a number of additional parameters that can be configured such as application services, firewall authentication, tunneling, and tcp options.

Talk about what happens to existing traffic when rule change is made,

Basic Rule Configuration
The goal of this exercise is to configure to basic security policies. The first policy is allowing all hosts in the Trust zone access to the internet, and the second policy is blocking SMTP traffic from any host on the subnet. The following diagram outlines the basic topology used for this exercise.

1. Create Security Policy Allowing Internet Access
The following screenshot outlines the commands to create a policy allowing general internet access to all networks (in this case only in the Trust security zone. Logging is also configured to generate a log message when the session is established and also when it is closed.

2. Create Security Policy Blocking SMTP
The following screenshot outlines the commands to create a rule blocking the SMTP protocol from the network. An address book record is created so we can specify the network in the 'match source-address' statement. The pre-defined application 'junos-smtp' is used to match the application SMTP.

The output below displays the configured rules. Policy order is important, and when reviewing the order below the policy 'BLOCK-SMTP' will never be matched as source and destination addresses in the previous policy are 'any'. In order to fix this the policy 'BLOCK-SMTP' must be moved before the policy 'OUTBOUND-INTERNET-ACCESS'.

The screenshot below outlines the insert command. This command can be used to re-order policies. Once this command is completed a 'show' on the candidate configuration outlines that the policy re-order has taken place.

The goal of this post was to provide the framework used when configuring security policies. The next post will focus on advanced policy options.

No comments:

Post a Comment