policy basics

Basic Policy Configuration

<Chapter Title>

INTERNAL U

SE ONLY


2 © 2008 Juniper Networks, Inc. All rights reserved.

Security Policy Functionality

In ScreenOS software, a policy is a single statement that controls traffic from a specified source to a specified destination using a specified service. If a packet arrives that matches those specifications, the firewall/VPN device performs the action specified in the policy.

INTERNAL U

SE ONLY


© 2008 Juniper Networks, Inc. All rights reserved. 3

Security Zones and Policies

We mentioned the need for policies when traffic is sent between different zones, but we avoided going into detail on the subject.

Security policies apply only to traffic that crosses zones. In the example shown on the left side of the slide, a flow from Host A to Host B does not invoke a policy; although the traffic is crossing the firewall, it is staying within the Private zone. You can modify this behavior to check intrazone traffic; however, a session initiated by Host B to Host D is subject to the policy set associated with traffic coming from zone Private and going to zone External.

Policy sets are unidirectional. If Host D tries to initiate a session with Host B, the firewall examines the policies defined for traffic coming from zone External and going to zone Private. This policy set is different from the policy set examined if Host B initiates a session to Host D.

INTERNAL U

SE ONLY



Policy Components

Once you complete your zone and interface configuration, you can begin creating your security policies.

As stated earlier, you associate policies with a pair of zones and a traffic direction. This policy set consists of one or more individual policy statements (sometimes called rules or simply policies). Each statement includes a source address, destination address, service (which defines Layer 4–7 information), and action.

INTERNAL U

SE ONLY



Policy Configuration Procedure

Configuring policies on a Juniper Networks firewall consists of four basic steps, listed on the slide.

We break down the tasks in each step on the following slides.

INTERNAL U

SE ONLY



Step 1: Creating Address Book Entries

The first step in configuring a policy is to create entries in your address book. Each zone has an associated list of addresses—individual hosts, subnets, or both.

When you create your address book entries, remember to account for all hosts within a zone, not just the directly connected subnets. What actual entries you define depends entirely on your security requirements:

• Do you have individual hosts that have special access requirements?

• Do all users on a subnet have the same access?

• Can you group subnets together in a supernetted address book entry?

INTERNAL U

SE ONLY



Step 1: Creating Address Book Entries—CLI

The slide shows the CLI commands you use to display and create address book entries. You must have DNS configured on the ScreenOS device for DNS entries to work in address book entries.

INTERNAL U

SE ONLY



Step 1: Creating Address Book Entries—WebUI: Part 1

Address book entries are organized on a per-zone basis. To view the list of existing address book entries, click through the WebUI navigation on the left of the screen as follows: Policy > Policy Elements > Addresses > List. Then select the zone you want to view using the pull-down list circled on the slide.

When you configure an address book entry, you assign it a name. You can display a subset of entries alphabetically by name using the alpha-numeric links at the top of the screen.

The screen capture on the slide shows the two default address book entries that exist in every zone: Any, which includes all addresses, and Dial-Up VPN, which is only used for point-to-point, dial-up connections.

To add a new entry to the address book, click the New button in the upper right of the screen.

INTERNAL U

SE ONLY



Step 1: Creating Address Book Entries—WebUI: Part 2

After clicking New, the screen shown on the slide appears. Enter the following parameters:

• Address Name: This is the name displayed in both the address list and the policy list. You can use the address and mask combination for this particular address book entry as the name, although you can use other naming conventions—location names, workgroup names, and so on—as long as the name has meaning to your network and you deploy it consistently.

• Comment: This is an optional field that gives you an opportunity to add inline documentation to your configuration.

• IP Address/Domain Name: This is the actual address book entry. In this example we define a specific host entry, as indicated by the 32-bit mask. Another option is to enter a domain name and use DNS to resolve the address. Note that if DNS resolves multiple addresses, the ScreenOS software adds all addresses to the address book entry. Most other Juniper Networks functions that use name resolution, such as ping and syslog, only use the first address returned.

• Zone: This specifies the zone in which this particular address is found.

INTERNAL U

SE ONLY



Step 1: Creating Address Book Entries—Security Manager

You can add global address objects using this window.

INTERNAL U

SE ONLY



Step 2: Defining Services

The second step in policy creation is to define any custom services required for your network. A service definition consists of the protocol and port numbers associated with a particular application or protocol stack (for example, NetBIOS).

INTERNAL U

SE ONLY



Step 2: Predefined Services

Juniper Networks firewalls have a number of predefined services that are based on well-known ports and common applications. Before configuring a custom service, check this list to see if your service is already defined.

To view the list of existing service entries, click through the WebUI navigation on the left of the screen as follows: Policy > Policy Elements > Services > Predefined. Then scroll through the list. You can move the cursor over an icon to see more information, such as a brief description of the service, the transport protocol, and the port number.

The CLI command displays the details of the defined services if you include a service name. Without a name, a list of defined services similar to the WebUI output is displayed.

Although you can modify these existing service entries, we recommend that you do not do so and that you instead create custom services where needed.IN

TERNAL USE O

NLY



Step 2: Creating a Custom Service

If your network is using a custom application, or if you changed applications to ports other than well-known ports, you can create a new service so that the firewall can identify your unique traffic.

To create a custom entry, click through the WebUI navigation on the left of the screen as follows: Policy > Policy Elements > Services > Custom > Edit. Then enter the following parameters:

• Service Name: This is the name of the service. This name is displayed in the policy list. Therefore, we recommend a descriptive name.

• Service Timeout: This allows you to specify a timeout value for an inactive session, never time out a session, or allow the end-to-end protocol to determine when the session times out.

• Transport protocol: The options displayed vary depending on the version of ScreenOS software running on your firewall. Later versions allow you to select TCP, UDP, the Internal Control Message Protocol (ICMP), or another.

• Ports: These fields allow you to specify either a specific port or range of ports allowed for this application.

You can include multiple protocols in a single service definition. For example, the FTP service definition includes both FTP control (port 21) and FTP data (port 20).

INTERNAL U

SE ONLY



Step 3: Creating Policy Entries—CLI

After defining your address book entries and services, you can create policy entries for your zones. Configuration using the CLI requires the same parameters, but the address book entries and service entries are not readily accessible. You must remember the address book names when creating the policies.

INTERNAL U

SE ONLY



Step 3: Creating Policy Entries—WebUI: Part 1

After defining your address book entries and services, you can create policy entries for your zones.

To create a new policy, select the From and To zones from the pull-down lists at the top of the policy screen shown on the slide, then click New.

Clicking Go displays a list of current policies between the From and To zones.

INTERNAL U

SE ONLY



Step 3: Creating Policy Entries—WebUI: Part 2

For basic policy configuration, we are concerned with addresses, services, and the action selected for the particular combination of address and service.

Use the pull-down bars to select the appropriate entries from your address book, service list, and action for this policy statement. Keep in mind that the pull-down menus display the names of your address book and service entries. (This duplication is one reason why a good naming convention is so important.) Once you finish these selections, click OK to add the entry to your policy set.

In the example on the slide, the source address pull-down list only displays addresses and address groups defined in the private zone, including the preconfigured parameters Any and Dial-Up VPN. Likewise, the destination address pull-down list only displays addresses defined in the public zone. This display is determined by the zone combination selected before opening the policy statement configuration window.

The list of services includes all defined services and service groups, including predefined and custom. One of the predefined options is Any.

Selecting Permit for the Action setting allows traffic to flow. Deny drops the packet. Reject drops the packet and sends an unreachable message to the originating host. Tunnel is used for VPNs, which we discuss later.

INTERNAL U

SE ONLY



Step 3: Creating Policy Entries—Security Manager

The slide shows the process for creating a policy using Security Manager. What follows is simply a review of the process. Remember that a policy is a group of rules in Security Manager.

INTERNAL U

SE ONLY



Step 4: Policy Ordering—WebUI

The final step in policy configuration is placing your policy entries in the correct order for your network. Policy statements are processed in a top-down fashion. If a statement matches the packet being evaluated, the ScreenOS device executes the policy action and searches no more policy lines.

If the device finds no matches, it denies the traffic by default. If your policy list consists exclusively of deny statements, no traffic is allowed by your policy; you must have a permit statement somewhere in the list.

When you add new policy entries, the ScreenOS device adds them to the new policy entries at the end of the policy list—which is probably not the proper location.

A good rule to follow when configuring policies is to place the most specific entries at the top of the list and the more general entries at the bottom of the list. For example, place host-specific entries before subnets.

INTERNAL U

SE ONLY



Step 4: Reordering Policies—CLI

The graphic on the slide shows an example of using the CLI to reorder policies.

INTERNAL U

SE ONLY



Step 4: Reordering Policies—WebUI: Part 1

Using the WebUI, you have two options for sorting your policies—the move button or the move arrow. Using the move button allows you to specify a policy ID to insert the new policy above. The move arrow gives you a graphic display.

INTERNAL U

SE ONLY



Step 4: Reordering Policies—WebUI: Part 2

Using the move button requires that you know the policy ID number. Policy ID numbers are assigned during policy configuration and do not reflect the precedence of a particular policy entry.

Clicking the move arrow for a particular policy entry brings up the display shown on the slide. Click the arrow in the location where you want the policy statement to move.

INTERNAL U

SE ONLY



Step 4: Reordering Rules—Security Manager

The title on the slide is correct; when using Security Manager, you reorder rules—not policies.

INTERNAL U

SE ONLY



Configuration Options

In large networks with complex security requirements, you might encounter this situation: you have ten network managers on five different subnets who must access three different data collection systems. You can create separate policy entries for each combination of network manager and data collection system—or you can use policy options to group the network manager and server entries, creating a single policy statement that includes all addresses.

Using groups not only makes administration easier, it also more efficiently allocates system resources. If not using groups, the configuration we described allocates memory for 30 policies (10 administrators x 3 servers = 30 policy entries). Grouped policy statements require fewer system resources.

INTERNAL U

SE ONLY



Address Groups

The address group option allows you to group existing address book entries into a single entry that you can then add to a policy.

The following constraints apply to address groups:

• Address groups can only contain addresses that belong to the same zone.

• Address names cannot be the same as group names. For example, if you use the name Paris for an individual address entry, you cannot also use it for a group name.

• If you reference an address group in an access policy, you cannot remove the group. You can edit the group, however.

• You cannot add the following predefined addresses to groups: Any, All Virtual IPs, and Dial-Up VPN.IN

TERNAL USE O

NLY



Creating Address Groups—CLI

The slide shows the CLI commands for creating address groups.

INTERNAL U

SE ONLY



Creating Address Groups—WebUI

The WebUI uses a standard add and subtract window for creating groups. The available members depend on the zone with which the address group is associated.

INTERNAL U

SE ONLY



Creating Address Groups—Security Manager

Adding address groups is very easy using Security Manager. You simply add all the hosts and networks that you will be using for your security policy rules.

INTERNAL U

SE ONLY



Viewing Address Groups

You can view your address groups on a per-zone basis using the WebUI. The CLI output separates address groups by zone.

INTERNAL U

SE ONLY



Creating a Service Group

Just as we grouped address book entries into an address group, we can group services into a service group. You can add both predefined and custom services to groups.

Grouping services provides the same advantages as grouping addresses: ease of administration and better utilization of system resources.

Service groups are subject to the following limitations:

• Service groups cannot have the same names as services. For example, if you have a service named FTP, you cannot have a service group named FTP.

• If you reference a service group in an access policy, you can edit the group, but you cannot remove it until you remove the reference to it in the policy.

• If you delete a custom service book entry from the service book, the ScreenOS software also removes the entry from all the groups in which it is referenced.

• You cannot add the static service ANY to groups.

INTERNAL U

SE ONLY



Viewing Service Groups

You can view a summary of your service groups using the commands or links shown in the graphic on the slide.

INTERNAL U

SE ONLY



Multicell Policies

The multicell policies option allows you to have multiple address book entries, service book entries, or both selected in an individual policy statement. Each entry appears as a separate listing within the policy display.

INTERNAL U

SE ONLY



Multicell Policy Creation—CLI

Using the CLI, you first create a basic policy entry using one of the addresses or services you want to add. Once the policy exists, you can enter a configuration sub-mode by using the set policy id command. Note the prompt change in the screen output shown on the slide.

In this sub-mode, you can add multiple addresses or services by using the set commands. Other policy options are also available in this sub-mode.

When finished, type exit to return to the main CLI mode.

INTERNAL U

SE ONLY



Multicell Policy Creation—WebUI: Part 1

In the WebUI, the address book and service options include a Multiple button. Clicking this button brings up a display similar to the group creation display; before you click the button, however, you must select a specific address book or service. If you leave the window at the default of Any, an error message appears saying that any cannot be combined with other entries.

After clicking the Multiple button, an add/subtract window is displayed. Entries on the right are available entries; entries on the left are added to the policy when you click OK.

Although this process looks similar to building groups, the end result is different; instead of displaying a single group name in the policy, the process displays the individual entry names.

INTERNAL U

SE ONLY



Multicell Policy Creation—WebUI: Part 2

Multicell policies not only allow you to group addresses in the typical manner; you can also create a group of addresses to exclude from the policy rule. By building a list of addresses and then clicking the Negate the Following box, you instruct the Juniper Networks device to apply the policy to all addresses except the policy listed in the cell.

INTERNAL U

SE ONLY



Multicell Rule Creation—Security Manager

Note again that in Security Manager, this is rule creation, not policy creation. Remember that Security Manager has one policy containing multiple rules.

INTERNAL U

SE ONLY



Viewing Multicell Policies

With multicell policies, individual entry names appear in the policy display in both the WebUI and the CLI.

INTERNAL U

SE ONLY



Modifying Multicell Policies

In the CLI, once you enter the policy, you can remove individual entries using the unset command.

Be careful; using the unset policy command in main mode removes the policy entirely.

INTERNAL U

SE ONLY



Common Configuration Problems

The most common problem with policy configuration is incorrect ordering, so completing Step 4 in policy creation (reordering policy entries) is essential. If you do not perform this step at the time of policy creation, you can perform it at a later time using the procedures we just described.

Two other common configuration problems relate to the use of names in policy creation.

INTERNAL U

SE ONLY



Names Not Equaling Addresses

When trying to troubleshoot policy issues, you must remember that in both Security Manager (top of slide) and the WebUI (bottom of slide), names are displayed in the policy displays, both in existing policies and in the policy configuration window.

Compare the name of the address book entry on the slide with the address entry itself. The masks are not the same. Does this cause a problem? It depends on your policy configuration, of course, but in general, if your intention is to allow traffic from a specific host and not from the subnet, your policy will not function the way you intend. You cannot modify an address book entry if it is being used by a policy.

INTERNAL U

SE ONLY



Group Membership

Using address and service groups can also introduce confusion when troubleshooting policies. The group names Security Managers and Allowed Services are only helpful if you know what addresses and services they contain. Troubleshooting might involve checking the actual group memberships to ensure that the correct hosts and services are included.

Multicell policies avoid the latter problem by displaying individual entries in the window. You still have the names problem, however, as the entries display address book names.

INTERNAL U

SE ONLY



Modifying or Removing Policies, Addresses, and Services

If you must modify a policy entry, an address entry or group, or a service entry or group, you can do so at any time. Use the edit option in the WebUI, or reset the set command in the CLI.

Removing an entry is more complicated. If an address entry, a group or service entry, or a group is in use by a policy, you do not have the option to remove it until you first modify or remove the policy entry referring to it.

INTERNAL U

SE ONLY



Disabling a Policy

A useful option when troubleshooting policies is the ability to manually disable a policy entry. The policy is still defined in memory, but it is no longer included in the policy evaluation. This feature is useful when troubleshooting ordering problems. If disabling a policy entry has no effect on traffic passing through the firewall, the policy entry is not effective when enabled and must either be moved or redefined.

INTERNAL U

SE ONLY



Global Zone

You can use the global zone to create default policies. If you have traffic that you always want to permit—whether it is from specific sources, to specific destinations, or to specific services—you can create a global policy to allow it

The policy checking process first checks for a policy match in the zones determined by the routing lookup. If no match is found, the global zone is checked.

If the ScreenOS software finds no match in the global zone, it takes the default action. The normal setting for the default is to deny traffic. You can set the system to default to permitting traffic, but we do not recommend this setting.

INTERNAL U

SE ONLY



Global Policy

We mentioned earlier that a global policy is searched if the ScreenOS software finds no specific zone-to-zone policy definition. The following information further explains the global zone:

• The get policy global command shows all the set global policies. The default setting is to deny all traffic, as shown on the slide.

• Next, we defined a global policy. The policy still denies all traffic; the only change is that we made a log entry for the action. (This is a convenient way to log all denys of traffic without having to make an entry in each policy.)

• When we view the global policy now, we see a policy ID 6 showing the details, including the logging.

• The debug output shows a ping packet routed from eth1 to eth7. A policy search from zone 1000 to zone 1002 (private to public) finds no policy. ScreenOS software searches the global policy next and drops the packet because of policy ID 6. The packet is logged.IN

TERNAL USE O

NLY



Verifying Policies

We now verify policies using the CLI get commands. Also, we review the debug flow basic command. The CLI get session command allows you to view the active sessions in the ScreenOS device.

INTERNAL U

SE ONLY



Zone and Policy Troubleshooting

To begin a discussion of troubleshooting zone issues, we review the initial configuration. All the predefined zones are in the trust-vr (except Null). The system-defined zones have ID numbers that start at zero. Consider two other points regarding the configuration:

1. The Private zone has ID number 1000, the External zone has ID number 1001, and the Public zone has ID number 1002. These ID numbers are useful when using the debug utility.

2. Currently, only two policies are defined—policy ID 3 (from external to private), and policy ID 4 (from private to public). Again, the ID numbers are useful because the debug utility uses zone ID numbers and not zone ID names.

INTERNAL U

SE ONLY



Debug Procedure Review

Consider the following sequence of events for effective use of the debug utility:

1. Enable the debug utility for the desired option. You can enable multiple options but doing so might produce output that is difficult to analyze. In most circumstances it is better to use one option at a time.

2. Clear the debug buffer. The debug buffer displays the oldest information first. Clearing the debug buffer avoids having to search through old output.

3. Issue the ping command (or whatever command is being used to generate traffic). The result is captured in the debug buffer.

4. Disable debug to terminate output going to the debug buffer.

5. Use get dbuf stream to analyze the output form the debug utility.

6. Check to see if the problem is resolved. If it is, use the unset ffilter command. If it is not resolved, go back to Step 2 and start the debug process.IN

TERNAL USE O

NLY



No Policy Configured

Any time network traffic flows from one security zone to another, a policy is required. If no policy is present from zone to zone, look for a global policy, which serves as a default policy for the system.

INTERNAL U

SE ONLY



Intrazone Block

If two (or more) interfaces are in the same zone, no policy is required for packets to travel between these interfaces. However, you can force policy checking to occur. This scenario is illustrated in the following sequence:

• Intrazone block was enabled for the zone Private. Thus, a policy must be present in packets that go between interfaces in this zone (eth1 and eth2).

• A packet comes in on eth1.

• The packet is routed to eth2.

• Because intrazone block is enabled, ScreenOS software performs a policy search. First, a policy search from zone 1000 to zone 1000 (private to private) occurs. Next, a search for a global policy is performed. Because no match exists in the global policy, the packet is dropped due to intrazone block.

The solution to this problem is to configure an exception policy for the zone in question, or to disable intrazone blocking if all traffic should be allowed.IN

TERNAL USE O

NLY



Snoop Utility

Another utility that is available for more detailed analysis of ScreenOS operations is snoop. Where debug shows the sequence of events in the device, snoop is similar to a traditional packet analyzer; the utility decodes and presents information in the packet header at Layer 2, Layer 3, and Layer 4. The recommended output, as before, is to the debug buffer. Like debug, this utility can produce significant output, so filters are available to make the information more specific to a troubleshooting situation.

Also like debug, the CPU must handle packets captured by snoop. Any packets handled solely by ASIC on devices with distributed ASICs cannot be viewed with snoop.

INTERNAL U

SE ONLY



Snoop Enable/Disable

The snoop info command shows the current snoop configuration including the following information:

• Whether snoop is on or off;

• What filters are defined and active; and

• Whether detailed output (raw packet contents) is on or off.

The snoop command activates the snoop utility. Notice that you can then turn off snoop with the Esc key or the snoop off command.

INTERNAL U

SE ONLY



Snoop Filter Options

Since snoop examines every packet on every interface by default, it is advisable to use filters in conjunction with the snoop utility. You can apply filters at the Ethernet level, at the IP packet level, or at the TCP/UDP segment level.

INTERNAL U

SE ONLY



Snoop Settings

The slide shows an example of two filters applied to the snoop utility. Similar to debug, filter statements on the same line represent a logical and statement, while statements on separate lines represent a logical or statement. In this example, we capture any IP packets (EtherType 0800) or any packets on ethernet1 in either direction.

INTERNAL U

SE ONLY



Snoop Filters—IP Address

The slide shows snoop filters applied based on the destination IP address having a value of 10.1.1.254

INTERNAL U

SE ONLY



Snoop Output Example—ping

In the example shown on the slide, we initiate a ping from the device to address 10.1.1.254. This ping results in a packet sent outbound on interface index number 0, indicated by the 0 (o) in the output. The index number corresponds to the first interface on the device. The remainder of the output shows the Layer 2 and Layer 3 headers, plus additional ICMP-specific information.

The next packet arrives on the same interface, indicated by 0 (i)(that is, interface 0, inbound).

INTERNAL U

SE ONLY



Snoop Output Example—HTTP

The example on the slide shows a snoop capture of HTTP traffic with the detail setting turned on. Notice that the output with detail ON provides raw packet information.

INTERNAL U

SE ONLY

policy basics

Documents