User Role Firewall Policy

User Role Firewall Policy An SRX Series device can act as an Infranet Enforcer in a UAC network where it acts as a Layer 3 enforcement point, controlling access by using IP-based policies pushed down from the IC Series appliance. When deployed in a UAC network, an SRX Series device is called a Junos OS Enforcer. When implementing a User Role Firewall Policy, however, the SRX Series device uses the UAC network for user role authentication, but controls resource access with user role-based policies. Combining authentication with firewall services provides greater threat mitigation, more informative forensic resources, improved record archiving for regulatory compliance, and enhanced access provisioning than a firewall policy alone. This topic includes the following sections: Dynamic Authentication Provisioning on page 1 Authentication and Policy Lookup on page 2 Using Application Services on page 2 Using Resource Access Policy on page 3 Dynamic Authentication Provisioning An IC Series or MAG Series device acts as a relay of authentication information for the SRX Series device. The configuration is similar to an Infranet Enforcer. An authentication table contains entries with the source IP address and user roles of all users who have already successfully established a UAC session. (For details about setting up user roles, authentication and authorization servers, and authentication realms on the IC Series or MAG Series device, see the Unified Access Control Administration Guide.) Upon connection with the SRX Series device, the authentication table is pushed to the SRX where a mapping file is created from the table input. Whenever data is added, deleted, or changed, or when a new user is authenticated, the IC Series or MAG Series device refreshes its authentication table and pushes it to the SRX Series device again. The SRX Series device updates its file with the new content. If the SRX Series device drops a packet due to a missing authentication table entry, the device sends a message to the IC Series or MAG Series device, which in turn may provision a new authentication table entry and send it to the Junos OS Enforcer. This process is called dynamic authentication provisioning. A local authentication table is available on the SRX device for testing purposes and can be used to demonstrate how a user role firewall works without a live IC Series or MAG Series device. It can also be used as a backup solution when the IC Series or MAG Series device is not available. Third-party software is available to read IP/user/role mapping data from authentication source. It can be propagated to the SRX device using CLI commands. For authentication sources operating on users and groups, group is treated as role. 1

Authentication and Policy Lookup User role firewall policies authenticate the user role before policy lookup occurs. Authentication compares the source IP address to the authentication information received from the IC Series or MAG Series device. If the IP address is in the table, the user role is considered authenticated. The user role information associated with the IP address is then used for policy lookup. Policies are grouped by zone pair (from-zone and to-zone). Typically, a five-tuple match (source-ip, source-port, destination-ip, destination-port, and application) identifies the action to be taken for the matching traffic. A sixth tuple, source-identity, signifies a user role firewall policy. If the source-identity is specified for user role firewall policy within the zone pair, authentication is done before policy look up occurs. The source-identity is optional and is assumed to be if it is not configured in a policy. NOTE: For compatibility and increased performance, if none of the firewall policies within the zone-pair have the source-identity specified, only the first 5 tuples are matched. Possible match criteria for the source-identity are: Any user or role, as well as the keywords authenticated-user, unauthenticated-user, and unknown-user. authenticated-user All users and roles that have been authenticated. unauthenticated-user Any user or role that does not have an IP-address mapped to it and the authentication source is up and running (while the IC Series or MAG Series device is connected). unknown-user Any user or role that does not have an IP-address mapped to it and the authentication source is disconnected from the SRX device (if the IC Series or MAG Series device is disconnected). Using Application Services As with five-tuple matches, after a six-tuple match, policy lookup is terminal. This means that once a policy match is found, lookup ends. Matches are based on the order of the policy configuration. Therefore, the sequence of policies influences the resulting action. The following table shows a sequence of user role policy configurations for a single zone pair. Rule Name Source IP Dest IP Source Identity Application Action Services 2

Rule1 unauthenticated-user http permit UAC captive-portal Rule2 3.3.3.3 role2 http permit IDP Rule3 net2 authenticated-user http permit UTM Rule4 unknown-user permit Rule5 deny Rule1 matches HTTP traffic that does not have a matching entry in the authentication table. The action redirects the traffic to a captive portal on the IC Series or MAG Series device for authentication. The authentication table will be updated with the new authentication and further traffic from this IP address will be authenticated. Rule3 matches HTTP traffic that has been authenticated but is not role2. The configured UTM service will be provided. Rule 4 permits traffic that has not been able to be authenticated because of an IC Series or MAG Series device disconnect. An unauthenticated-user policy should be positioned before a policy for user. In the following table, Rule1 shadows Rule2. With this policy, an unauthenticated-user with a destination IP of 3.3.3.3 will not be redirected for authentication. Instead, they will be permitted access to the network. Rule 2 should be moved before Rule1. Rule Name Source IP Dest IP Source Identity Application Action Services Rule1 3.3.3.3 http permit Rule2 unauthenticated-user http permit UAC captive-portal Using Resource Access Policy Resource access policies from the IC Series or MAG Series device are pushed to the SRX device, as in an Infranet Controller implementation. Access decisions, however, are based on policy services indicated in the matching rule. A UAC service must be specified in the user role firewall rule to follow the resource access policies pushed from the IC Series or MAG Series device. Rule Name Source IP Dest IP Source Identity Application Action Services Rule1 3.3.3.3 http permit UTM Rule2 net2 http permit IDP 3

Rule3 http permit UAC Related Documentation Junos OS Feature Support Reference for SRX Series and J Series Devices Junos OS CLI Reference for SRX Series and J Series Devices Published: 2011-09-17 4

Example: Configuring a User Role AppFW Policy on an SRX Device This example implements user role authentication before an AppFW, UAC, or IDP policy is implemented. This implementation configures a MAG Series device to provide authentication. After authentication, the example demonstrates how application detection is used to identify a packet s origin, and to determine whether to permit or deny access to protected devices and networks. Requirements on page 1 Overview on page 1 Configuration on page 1 Verification on page 4 Requirements This example uses the following hardware and software components: MAG Series Junos Pulse Gateway device with software release 4.2 or greater An SRX Series device with Junos OS Release 12.1 or later Before you begin: Ensure that the SRX Series device has been configured and initialized. Configure the MAG Series device in a standard UAC deployment as specified in the Junos Pulse Access Control Service Administration Guide. Overview The following example configures the SRX device in four tasks: Connect the MAG Series device (MAG123). Set up the MAG Series device as the captive portal for unauthenticated users. Define an AppFW rule that allows specific users to access particular web sites while denying access to others. Create policies to apply the AppFW rule to specific authenticated users. Configuration To configure access to the SRX Series device from the MAG Series device, refer to Junos Pulse Access Control Service Administration Guide. 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 Junos OS CLI User Guide. Follow these steps to create a user role AppFW policy: 1. Configure the IP address and interface for the MAG Series device: 1

[edit] user@host# set services unified-access-control infranet-controller MAG123 address 10.208.131.138 user@host# set services unified-access-control infranet-controller MAG123 interface fxp0.0 2. Specify the password for securing interaction between the MAG Series device and the SRX device: [edit] user@host# set services unified-access-control infranet-controller MAG123 password Srxandmag123 NOTE: The same password, in this case Srxandmag123, must be configured on the Access Control Service device to allow interaction between the devices. 3. If you are done configuring the SRX Series device, commit the configuration from configuration mode: [edit] user@host# commit 4. Verify that the Access Control Service device is connected. [edit] user@host# run show services unified-access-control status Host Address Port Interface State MAG123 10.208.131.138 11123 fxp0.0 connected 5. Verify that the user roles have been pushed from the Access Control Service device to the SRX at connection time: user@host> show services unified-access-control roles Identifier Name 0000000001.000005.0 users 1228966955.312058.0 ftp-accessible 1228985516.343655.0 http-mgmt-accessible 1233735230.276590.0 peter 1233735257.437271.0 ceo 1234250964.660642.0 dev-abc 6. Set up the Access Control Service as a captive portal where unauthenticated traffic is to be redirected: [edit] user@host# set services unified-access-control captive-portal acs-device redirect-traffic unauthenticated-user 2

7. Enter the URL for the Access Control Service device or the default URL to be used as the captive portal. The following command specifies the default URL. [edit] user@host# set services unified-access-control captive-portal acs-device redirect-url MAG123 8. Configure the AppFW rule set rs1: [edit] user@host# set security application-firewall rule-sets rs1 [edit application-firewall rule-sets rs1] user@host# set rule r1 match dynamic-application [junos:facebook-access junos:google-talk junos:meebo] user@host# set rule r1 then permit user@host# set default-rule deny 9. Configure a policy to apply the rs1 application firewall rule set to authenticated user roles dev-abc, http-mgmt-accessible, and ftp-accessible: [edit] user@host# set security policies from-zone untrust to-zone trust policy user-role-fw1 match source-address 1.1.1.0 user@host# set security policies from-zone untrust to-zone trust policy user-role-fw1 match destination-address 2.2.2.0 user@host# set security policies from-zone untrust to-zone trust policy user-role-fw1 match application http user@host# set security policies from-zone untrust to-zone trust policy user-role-fw1 match source-identity [dev-abc http-mgmt-accessible ftp-accessible] user@host# set security policies from-zone untrust to-zone trust policy user-role-fw1 then permit application-services application-firewall rule-set rs1 NOTE: The source and destination ports in this example are inferred from the application http. Any standard HTTP port will match the port criteria. 10. Configure a policy to redirect all unauthenticated users to the MAG Series device for authentication: [edit] user@host# set security policies from-zone untrust to-zone trust policy user-role-fw2 match source-address 1.1.1.0 user@host# set security policies from-zone untrust to-zone trust policy user-role-fw2 match destination-address 2.2.2.0 user@host# set security policies from-zone untrust to-zone trust policy user-role-fw2 match application http user@host# set security policies from-zone untrust to-zone trust policy user-role-fw2 match source-identity unauthenticated-user user@host# set security policies from-zone untrust to-zone trust policy user-role-fw2 then permit application-services uac-policy captive-portal acs-device 3

NOTE: It is important to position the redirection policy for unauthenticated users before a policy for user so that the UAC authentication is not shadowed by a policy intended for users that cannot be authenticated. 11. Configure a policy to deny all other user roles. [edit] user@host# set security policies from-zone untrust to-zone trust policy user-role-fw3 match source-address 1.1.1.0 user@host# set security policies from-zone untrust to-zone trust policy user-role-fw3 match destination-address 2.2.2.0 user@host# set security policies from-zone untrust to-zone trust policy user-role-fw3 match application http user@host# set security policies from-zone untrust to-zone trust policy user-role-fw3 match source-identity user@host# set security policies from-zone untrust to-zone trust policy user-role-fw3 then deny Results Because the source-identity field has been defined for this policy, all traffic from the untrust zone to the trust zone matching the specified five tuples (source-address, source-port, destination-address, destination-port, and application) will be subject to user authentication before firewall policy lookup is conducted. Incoming traffic for the zone pair match is first compared against the local authentication table and the UIT pushed from the Access Control Service device. If the role is mapped to the user and source IP in one of the UITs, the traffic is specified as an authenticated-user. If the role is not mapped to the user role and IP in one of the tables, the traffic is specified as an unauthenticated-user. After UIT authentication, policy lookup begins. In this example, users with the role dev-abc, http-mgmt-accessible, or ftp-accessible match policy user-role-fw1 and the AppFW policy rs1 is applied. For an unauthenticated-user, policy user-role-fw2 is matched and traffic is redirected to the Access Control Service device for further authentication. All other user roles match policy user-role-fw3 and are denied access. Verification The following commands confirm the policy configuration, the sequence in which user role policies will be applied, as well as the configuration for the UAC captive portal and for the AppFW policy. Verifying the AppFW Rule Set Configuration on page 5 Verifying the Captive Portal Configuration on page 5 Verifying the User Role Policy Configurations on page 5 4

Verifying the AppFW Rule Set Configuration Purpose From the operational mode, enter the following command to verify that the AppFW rule set has been configured properly. Action [edit] user@host# show security application-firewall... rule-sets rs1 { rule r1 { match { dynamic-application [junos:facebook-access junos:google-talk junos:meebo] then { permit; default-rule { deny; Meaning The output shows that HTTP traffic from junos:facebook-access, junos:google-talk, and junos:meebo is permitted and all other traffic is denied. Verifying the Captive Portal Configuration Purpose From the operational mode, enter the following command to verify that the captive portal has been configured properly. Action [edit] user@host# show services... unified-access-control { captive-portal acs-device { redirect-traffic unauthenticated; Meaning The output shows that traffic with an unauthenticated user role will be redirected to the captive portal named acs-device for user role authentication. Verifying the User Role Policy Configurations Purpose Enter the following command to verify the content and sequence of the user role policies. Action [edit] user@host# show security policies... from-zone untrust to-zone trust { policy user-role-fw1 { match { 5

source-address 1.1.1.0; destination-address 2.2.2.0; application http; source-identity [dev-abc http-juniper-accessible ftp-accessible] then { permit { application-services { application-firewall { rule-set rs1 from-zone untrust to-zone trust { policy user-role-fw2 { match { source-address 1.1.1.0; destination-address 2.2.2.0; application http; source-identity unauthenticated then { permit { application-services uac-policy { captive-portal acs-device from-zone untrust to-zone trust { policy user-role-fw3 { match { source-address 1.1.1.0; destination-address 2.2.2.0; application http; source-identity then { deny Meaning In the output of the show security policies command, user role policies will be applied in the sequence displayed to all traffic matching the specified zone pair and the six tuples (source-address, source-port, destination-address, destination-port, application, and source-identity). Related Documentation Published: 2011-09-17 6

source-identity Syntax source-identity [ role-name role-name ] Hierarchy Level [edit security from-zone zone-name to-zone zone-name policy policy-name match] Release Information Description Statement introduced in Release 12.1 of Junos OS. Identifies the user role match criteria for a policy. This option is used in user role authentication before policy lookup occurs. The source-identity is found in the local authentication table or in a UIT pushed to the SRX Series device from an authentication device. The source-identity and associated user and IP address in the table are compared to the values in the packet. A match signifies that the user has been authenticated. Required Privilege Level Related Documentation security To view this statement in the configuration. security-control To add this statement to the configuration. Junos OS Security Configuration Guide Published: 2011-09-17 1

user-identification Syntax user-identification { authentication-source { local-authentication-table { disable; priority value; authentication-source unified-access-control { disable; priority value; Hierarchy Level [edit security] Release Information Description Statement introduced in Release 12.1 of Junos OS. Identifies one or more tables to be used as the source for user role authentication. Options local-authentication-table An authentication table created on the SRX Series device using the request security user-identification local-authentication-table add command. unified-access-control An authentication table pushed from a configured authentication device, such as the MAG Series Junos Pulse Gateway device. priority value A unique value between 1 and 65535 that determines the sequence for searching multiple tables to authenticate a user role. Each table is given a unique priority value. The lower the value, the higher the priority. A table with priority 120 is searched before a table with priority 200. The default priority value of the local-authentication-table is 100. The default priority value of the unified-access-control table is 200. disable Keyword used to disable a local authentication table or a unified access control table. Remove the keyword to re-enable the table. Required Privilege Level Related Documentation security To view this statement in the configuration. security-control To add this statement to the configuration. Junos OS Security Configuration Guide Published: 2011-09-17 1

request security user-identification local-authorization-table add Syntax request security user-identification local-authorization-table add user user-name ip-address ip-address roles [role-name role-name] Release Information Command introduced in Junos OS Release 12.1. Description In user role authentication, a user s role is first authenticated by entries in the local authentication table. If a user s role cannot be authenticated with this table, then secondary sources, such as a UIT device, can be used. A match of a user with a particular IP address and an acceptable role authenticates the user, verifying that the user is who he says he is. The user still must meet firewall policy authorization to obtain access to the protected device or network. Each authentication entry in the local authentication table specifies the user name, IP address, and a list of acceptable user roles. To add an authentication entry, enter the user name, the IP address, and up to 40 roles to be associated with this user. Subsequent commands for the same user and IP address aggregates new roles with the existing list. An authentication entry can contain up to 200 roles. NOTE: To change the user name of an entry or to remove or change entries in a role list, you must delete the existing entry and create a new one. An IP address can be associated with only one user. If a second request is made to add a different user using the same IP address, the second authentication entry overwrites the existing entry. Options user user-name Specify the name of the user to be added to the table. ip-address ip-address Specify the IP address of the user. roles role-name-list Specify the role or list of roles to be added to the table. If the specified user and IP address already exist, roles specified in the command are added to the existing role list. Required Privilege Level Related Documentation maintenance List of Sample Output request security user-identification local-authentication-table add on page 2 Output Fields When you enter this command, an entry is added to the local authentication table or the roles of an existing entry are aggregated with additional roles. 1

Sample Output request security user-identification local-authentication-table add user@host> request security user-identification local-authentication-table add user user1 ip-address 1.1.1.1 roles role1 user@host> request security user-identification local-authentication-table add user user2 ip-address 2.2.2.2 roles [role2 role3] user@host> request security user-identification local-authentication-table add user user2 ip-address 2.2.2.2 roles role1 user@host> show security user-identification local-authentication-table all Total entries: 2 Ip-address: 1.1.1.1 Username: user1 Roles: role1 Ip-address: 2.2.2.2 Username: user2 Roles: role2, role3, role1 Published: 2011-09-17 2

request security user-identification local-authentication-table delete Syntax request security user-identification local-authentication-table delete ip-address user-name Release Information Command introduced in Junos OS Release 12.1. Description Remove an entry from the local authentication table. You can identify the entry by IP address or user-name. To change the user name of an entry or to remove or change entries in a role list, you must delete the existing entry and create a new one. Options ip-address The IP address of the entry to be deleted. user-name The user name of the entry to be deleted. To change the user name of an entry or to remove or change entries in a role list, you must delete the old entry and create a new one. Required Privilege Level Related Documentation maintenance Output Fields The specified show command verifies the table content before and after an entry has been deleted from the local authentication table. Sample Output user@host> show security user-identification local-authentication-table all Total entries: 2 Ip-address: 1.1.1.1 Username: user1 Roles: role1 Ip-address: 2.2.2.2 Username: user2 Roles: role2, role3, role1 user@host> request security user-identification local-authentication-table delete 2.2.2.2 user@host> show security user-identification local-authentication-table all Total entries: 1 Ip-address: 1.1.1.1 Username: user1 Roles: role1 Published: 2011-09-17 1

clear security user-identification local-authentication-table Syntax clear security user-identification local-authentication-table Release Information Description Command introduced in release 12.1 of Junos OS. Remove all existing local authentication table entries. Required Privilege Level Related Documentation clear List of Sample Output clear security user-identification local-authentication-table on page 1 Output Fields When you enter this command, all entries are cleared from the local authentication table. Sample Output clear security user-identification local-authentication-table user@host> clear security user-identification local-authentication-table user@host> show security user-identification local-authentication-table all Total entries: 0 Published: 2011-09-17 1

show security user-identification local-authentication-table Syntax show security user-identification local-authentication-table [ all ip-address ip-address role role-name start value count value user user-name] Release Information Description Command introduced in release 12.1 of Junos OS. Display the content of the local authentication table. all (Optional) All entries displayed from the beginning of the table or from the specified starting entry. count value (Optional) The total number of entries to display. ip-address ip-address (Optional) The IP address of the entry to display. role role-name (Optional) The role name of the entries to display. start value (Optional) The first entry to display. user user-name (Optional) The user name of the entry to display. Required Privilege Level Related Documentation view List of Sample Output show security user-identification local-authentication-table all on page 2 show security user-identification local-authentication-table ip-address on page 2 show security user-identification local-authentication-table start on page 2 show security user-identification local-authentication-table role on page 2 Output Fields Table 1 lists the output fields for the show security user-identification local-authentication-table command. Output fields are listed in the approximate order in which they appear. Table 1: show security user-identification local-authentication-table Output Fields Field Name Field Description Total entries The number of entries in the table. IP address IP address of the associated user. NOTE: Only one user can be associated with an IP address. Username User associated with the specified IP address. Roles A comma-separated list of all roles associated with this IP address and user. 1

Sample Output show security user-identification local-authentication-table all user@host> show security user-identification local-authentication-table all Total entries: 4 Ip-address: 1.1.1.1 Username: user1 Roles: role1 Ip-address: 2.2.2.2 Username: user2 Roles: role2, role3, role1 Ip-address: 3.3.3.3 Username: user3 Roles: role2, role3 Ip-address: 4.4.4.4 Username: user2 Roles: role2, role3 Sample Output show security user-identification local-authentication-table ip-address user@host> show security user-identification local-authentication-table ip-address 2.2.2.2 Ip-address: 2.2.2.2 Username: user2 Roles: role2, role3, role1 Sample Output show security user-identification local-authentication-table start user@host> show security user-identification local-authentication-table start 2 count 2 Total entries: 2 Ip-address: 2.2.2.2 Username: user2 Roles: role2, role3, role1 Ip-address: 3.3.3.3 Username: user3 Roles: role2, role3 show security user-identification local-authentication-table role user@host> show security user-identification local-authentication-table role qa3456 Total entries: 3 Ip-address: 2.2.2.2 Username: dev-grp-3 Roles: qa432, qa3456, qa84, qa794 Ip-address: 3.3.3.3 Username: dev-qa Roles: qa3456, qa3985, qa23 Ip-address: 2.2.2.2 Username: brandall Roles: qa3456 Published: 2011-09-17 2

show services user-access-control roles Syntax Release Information Description show services user-access-control roles Command introduced in release 12.1 of Junos OS. When implementing user role firewall policies, display a summary of the roles that have been pushed to the SRX Series device from the MAG Series device. Required Privilege Level Related Documentation view List of Sample Output show services user-access-control roles on page 1 Output Fields Table 1 lists the output fields for the show security user-identification local-authentication-table command. Output fields are listed in the approximate order in which they appear. Table 1: show security user-identification local-authentication-table Output Fields Field Name Field Description Identifier Unique identifier for a user role. Name Name of the associated user role. Total Total number of user roles specified in the table. Sample Output show services user-access-control roles user@host> show services user-access-control roles Identifier Name 0000000001.000005.0 Users 1292865519.590331.0 Employees Total: 2 Published: 2011-09-17 1

show security match-policies Syntax show security match-policies from-zone zone-name to-zone zone-name source-ip ip-address destination-ip ip-address source-identity role-name source-port port-number destination-port port-number protocol protocol-name protocol-number result-count number Release Information Description Command introduced in Release 10.3 of Junos OS. Command updated in Release 10.4 of Junos OS. Updated with source-identity in Release 12.1 of Junos OS. The show security match-policies command allows you to troubleshoot traffic problems using the match criteria: source port, destination port, source IP address, destination IP address, and protocol. For example, if your traffic is not passing because either an appropriate policy is not configured or the match criteria is incorrect, then the show security match-policies command allows you to work offline and identify where the problem actually exists. It uses the search engine to identify the problem and thus enables you to use the appropriate match policy for the traffic. The result-count option specifies how m policies to display. The first enabled policy in the list is the policy that is applied to all matching traffic. Other policies below it are shadowed by the first and are never encountered by matching traffic. NOTE: The show security match-policies command is applicable only to security policies; IDP policies are not supported. Options from-zone from-zone Name or ID of the source zone of the traffic. to-zone to-zone Name or ID of the destination zone of the traffic. source-ip source-ip Source IP address of the traffic destination-ip destination-ip Destination IP address of the traffic. source-identity role-name Source role name of the traffic. Only one role can be specified. source-port source-port Source port number of the traffic. Range is 1 through 65,535. destination-port destination-port Destination port number of the traffic. Range is 1 through 65,535 protocol protocol-name protocol-number Protocol name or numeric value of the traffic. 1

ah or 51 egp or 8 esp or 50 gre or 47 icmp or 1 igmp or 2 igp or 9 ipip or 94 ipv6 or 41 ospf or 89 pgm or 113 pim or 103 rdp or 27 rsvp or 46 sctp or 132 tcp or 6 udp or 17 vrrp or 112 result-count number (Optional) The number of policy matches to display. Valid range is from 1 through 16. The default value is 1. Required Privilege Level Related Documentation view clear security policies statistics List of Sample Output Example 1: show security match-policies on page 4 Example 2: show security match policies... result-count on page 4 Example 3: show security match policies... source-identity on page 4 Output Fields Table 1 lists the output fields for the show security match-policies command. Output fields are listed in the approximate order in which they appear. 2

Table 1: show security match-policies Output Fields Field Name Field Description Policy: Name of the applicable policy. Action or Action-type: The action to be taken for traffic that matches the policy s match criteria. Actions include the following: permit firewall-authentication tunnel ipsec-vpn vpn-name pair-policy pair-policy-name source-nat pool pool-name pool-set pool-set-name interface destination-nat name deny reject State: Status of the policy: enabled: The policy can be used in the policy lookup process, which determines access rights for a packet and the action taken in regard to it. disabled: The policy cannot be used in the policy lookup process, and therefore it is not available for access control. Index: An internal number associated with the policy. Sequence number: Number of the policy within a given context. For example, three policies that are applicable in a from-zonea-to-zoneb context might be ordered with sequence numbers 1, 2, and 3. Also, in a from-zonec-to-zoned context, four policies might have sequence numbers 1, 2, 3, and 4. From zone: Name of the source zone. To zone: Name of the destination zone. Source addresses: The names and corresponding IP addresses of the source addresses for a policy. Address sets are resolved to their individual address name-ip address pairs. Destination addresses: The names and corresponding IP addresses of the destination addresses (or address sets) for a policy as entered in the destination zone s address book. A packet s destination address must match one of these addresses for the policy to apply to it. Application Name of a preconfigured or custom application, or if no application is specified. IP protocol: Numeric value for the IP protocol used by the application, such as 6 for TCP or 1 for ICMP. ALG: If an ALG is associated with the session, the name of the ALG. Otherwise, 0. Inactivity timeout: Elapsed time without activity after which the application is terminated. 3

Table 1: show security match-policies Output Fields (continued) Field Name Field Description Source-port range: Range of matching source ports defined in the policy. Destination-port range: Range of matching destination ports defined in the policy. Source identities Rules defined in the matching policy. Sample Output Example 1: show security match-policies user@host> show security match-policies from-zone z1 to-zone z2 source-ip 10.10.10.1 destination-ip 30.30.30.1 source-port 1 destination-port 21 protocol tcp Policy: p1, action-type: permit, State: enabled, Index: 4 Sequence number: 1 From zone: z1, To zone: z2 Source addresses: a2: 20.20.0.0/16 a3: 10.10.10.1/32 Destination addresses: d2: 40.40.0.0/16 d3: 30.30.30.1/32 Application: junos-ftp IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800 Source port range: [0-0] Destination port range: [21-21] Example 2: show security match policies... result-count user@host> show security match-policies source-ip 10.10.10.1 destination-ip 20.20.20.5 source_port 1004 destination_port 80 protocol tcp result_count 5 Policy: p1, action-type: permit, State: enabled, Index: 4 Sequence number: 1 From zone: zone-a, To zone: zone-b Source addresses: sa1: 10.10.0.0/16 Destination addresses: da5: 20.20.0.0/16 Application: IP protocol: 1, ALG: 0, Inactivity timeout: 0 Source port range: [1000-1030] Destination port range: [80-80] Policy: p15, action-type: deny, State: enabled, Index: 18 Sequence number: 15 From zone: zone-a, To zone: zone-b Source addresses: sa11: 10.10.10.1/32 Destination addresses: da15: 20.20.20.5/32 Application: IP protocol: 1, ALG: 0, Inactivity timeout: 0 Source port range: [1000-1030] Destination port range: [80-80] Example 3: show security match policies... source-identity user@host> show security match-policies from-zone untrust to-zone trust source-ip 10.10.10.1 destination-ip 20.20.20.5 destination_port 21 protocol 6 source-port 1234 source-identity role1 4

Policy: p1, action-type: permit, State: enabled, Index: 40 Policy Type: Configured Sequence number: 1 From zone: untrust, To zone: trust Source addresses: a1: 20.0.0.0/8 Destination addresses: d1: 21.0.0.0/8 Application: junos-ftp IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800 Source port range: [0-0] Destination port range: [21-21] Source identities: role1 role2 role3 role4 Per policy TCP Options: SYN check: No, SEQ check: No Published: 2011-09-17 5

Security Configuration Statement Hierarchy Use the statements in the security configuration hierarchy to configure actions, certificates, dynamic virtual private networks (VPNs), firewall authentication, flow, forwarding options, group VPNs, Intrusion Detection Prevention (IDP), Internet Key Exchange (IKE), Internet Protocol Security (IPsec), logging, Network Address Translation (NAT), public key infrastructure (PKI), policies, resource manager, rules, screens, secure shell known hosts, trace options, Unified Threat Management (UTM), and zones. Statement descriptions that are exclusive to the Juniper Networks devices running Junos OS are described in this section. security { address-book [book-name global] { address address-name (ip-prefix dns-name dns-address-name wildcard-address ipv4 address/wildcard-mask); address-set address-set-name { address address-name; address-set address-set-name; attach { zone zone-name ; alarms { audible; potential-violation { authentication failures; cryptographic-self-test; encryption-failures{ threshold failures; key-generation-self-test; non-cryptographic-self-test; idp; decryption-failures { threshold failures; encryption-failures { threshold failures; ike-phase1-failures { threshold failures; ike-phase2-failures { threshold failures; policy { source-ip { threshold failure; duration interval; size count; destination-ip { 1

ca-profile ca-profile-name { administrator { e-mail-address e-mail-address; ca-identity ca-identity; routing-instance routing-instance-name; enrollment { retry number; retry-interval seconds ; url url-name; revocation-check { crl { disable { on-download-failure; refresh-interval hours; url url-name; disable; traceoptions { file filename <files number> <match regular-expression> <size maximum-file-size> <world-readable no-world-readable>; flag flag; policies { default-policy { (deny-all permit-all); from-zone zone-name to-zone zone-name { policy policy-name { match { application [application-name-or-set]; destination-address { address-name ; source-address { address-name ; source-identity role-name; scheduler-name scheduler-name; source-identity [source-name source-name]; then { count { alarm { per-minute-threshold number; per-second-threshold number; (deny reject); 30

permit { application-services { application-firewall { rule-set rule-set-name; application-traffic-control { rule-set ruleset-name; uac-policy { captive-portal url-name; destination-address { drop-translated; drop-untranslated; firewall-authentication { pass-through { access-profile profile-name; client-match match-name; web-redirect; web-authentication { client-match user-or-group; tcp-options { sequence-check-required; syn-check-required; tunnel { ipsec-group-vpn group-vpn; ipsec-vpn vpn-name; pair-policy pair-policy; log { session-close; session-init; policy-rematch; traceoptions { file filename <files number> <match regular-express> <size maximum-file-size> <world-readable no-world-readable>; flag flag; screen { ids-option screen-name{ alarm-without-drop; icmp { flood { threshold number; 31

fragment; ip-sweep { threshold number; large; ping-death; ip { bad-option; block-frag; loose-source-route-option; record-route-option; security-option; source-route-option; spoofing; stream-option; strict-source-route-option; tear-drop; timestamp-option; unknown-protocol; limit-session { destination-ip-based number; source-ip-based number; tcp { fin-no-ack; land; port-scan { threshold number; syn-ack-ack-proxy { threshold number; syn-fin; syn-flood { alarm-thresholdnumber; attack-thresholdnumber; destination-threshold number; source-threshold number; timeout seconds; syn-frag; tcp-no-flag; tcp-sweep { threshold number; winnuke; udp { flood { threshold number; udp-sweep { threshold number; 32

traceoptions { file filename <files number> <match regular-expression> <size maximum-file-size> <world-readable no-world-readable>; flag flag; ssh-known-hosts { fetch-from-server fetch-from-server; host hostname { dsa-key base64-encoded-dsa-key; rsa-key base64-encoded-dsa-key; rsa1-key base64-encoded-dsa-key; load-key-file key-file; traceoptions { file filename { <files number>; <match regular-expression>; <size maximum-file-size>; <world-readable no-world-readable>; flag flag; no-remote-trace; rate-limit rate; user-identification { authentication-source { local-authentication-table (disable priority value); unified-access-control (disable priority value); traceoptions { file filename; flag all; utm { custom-objects { filename-extension { value [list]; mime-pattern { value [list]; custom-url-category { value [list]; protocol-command { value [list]; url-pattern { value [list]; 33