User Role Firewall Security Policies
User role firewall policies allows the administrators to permit or restrict network access for users based on the roles they are assigned. User role firewalls enable greater threat mitigation, provide more informative forensic resources, improve record archiving for regulatory compliance, and enhance routine access provisioning.
Understanding User Role Firewalls
Network security enforcement, monitoring, and reporting based solely on IP information soon will not be sufficient for today’s dynamic and mobile workforce. By integrating user firewall policies, administrators can permit or restrict network access of employees, contractors, partners, and other users based on the roles they are assigned. User role firewalls enable greater threat mitigation, provide more informative forensic resources, improve record archiving for regulatory compliance, and enhance routine access provisioning.
User role firewalls trigger two actions:
Retrieve user and role information associated with the traffic
Determine the action to take based on six match criteria within the context of the zone pair
The source-identity field distinguishes a user role firewall from other types of firewalls. If the source identity is specified in any policy for a particular zone pair, it is a user role firewall. The user and role information must be retrieved before policy lookup occurs. If the source identity is not specified in any policy, user and role lookup is not required.
To retrieve user and role information, authentication tables are searched for an entry with an IP address corresponding to the traffic. If an entry is found, the user is classified as an authenticated user. If not found, the user is classified as an unauthenticated user.
The username and roles associated with an authenticated user are retrieved for policy matching. Both the authentication classification and the retrieved user and role information are used to match the source-identity field.
Characteristics of the traffic are matched to the policy specifications. Within the zone context, the first policy that matches the user or role and the five standard match criteria determines the action to be applied to the traffic.
The following sections describe the interaction of user and role retrieval and the policy lookup process, methods for acquiring user and role assignments, techniques for configuring user role firewall policies, and an example of configuring user role firewall policies.
User Role Retrieval and the Policy Lookup Process
For policy lookup, firewall policies are grouped by zone pair (the from zone and to zone). Within the context of the zone pair, IP-based firewall policies are matched to traffic based on five criteria—source IP, source port, destination IP, destination port, and protocol.
User role firewall policies include a sixth match criteria—source
identity. The source-identity field specifies the users and roles
to which the policy applies. When the source-identity field is specified
in any policy within the zone pair, user and role information must
be retrieved before policy lookup can proceed. (If all policies in
the zone pair are set to any or have no entry in the source-identity
field, user and role information is not required and the five standard
match criteria are used for policy lookup.)
The user identification table (UIT) provides user and role information for an active user who has already been authenticated. Each entry in the table maps an IP address to an authenticated user and any roles associated with that user.
When traffic requires user and role data, each registered UIT is searched for an entry with the same IP address. If a user has not been authenticated, there is no entry for that IP address in the table. If no UIT entry exists, the user is considered an unauthenticated user.
Policy lookup resumes after the user and role information has been retrieved. The characteristics of the traffic are matched against the match criteria in the policies. The source-identity field of a policy can specify one or more users or roles, and the following keywords:
| authenticated-user | Users that have been authenticated. |
| unauthenticated-user | Users that have not been authenticated. |
| any | All users regardless of authentication. If the source-identity field is not configured or is set to any in all of the policies for the zone pair, only five criteria are matched. |
| unknown-user | Users unable to be authenticated due to an authentication server disconnection, such as a power outage. |
For example, consider user-c who is assigned to the mgmt role. When traffic from the trust zone to the untrust zone is received from user-c at IP address 198.51.100.3, policy lookup is initiated. Table 1 represents three policies in a user role firewall for the trust to untrust zone pair.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
trust |
untrust |
192.0.2.0 |
203.0.113.0 |
any |
http |
deny |
– |
P2 |
trust |
untrust |
any |
any |
mgmt |
any |
permit |
– |
P3 |
trust |
untrust |
198.51.100.3 |
any |
employee |
http |
deny |
– |
All policies for the zone pair are checked first for a source-identity option. If any of the policies specifies a user, a role, or a keyword, user and role retrieval must occur before policy lookup continues. Table 1 shows that policy P2 specifies mgmt as the source identity, making this a user role firewall. User and roles must be retrieved before policy lookup can continue.
User and role retrieval would not be performed if the keyword any or if no source identity was specified in all of the policies in the zone context. In such cases, only the five remaining values are matched to the policy criteria.
The UIT represented in Table 2 is checked for the IP address. Because the address is found, the
username user-c, all roles listed for user-c (in this case, mgmt and
employee), and the keyword authenticated-user become data used to
match the traffic to the source-identity field of a policy.
Source IP Address |
Username |
Roles |
|---|---|---|
192.0.2.4 |
user-a |
employee |
198.51.100.3 |
user-c |
mgmt, employee |
203.0.113.2 |
user-s |
contractor |
Policy lookup resumes and compares the match criteria in each policy in Table 1 to the incoming traffic. Assuming all other criteria match, the first policy that specifies user-c, mgmt, employee, authenticated-user, or any in the source-identity field could be a match for this traffic. Policy P1 matches one of the retrieved roles for user-c, but the source IP address does not match; therefore policy lookup continues. For policy P2, all criteria match the traffic; therefore the policy action is followed and the traffic is permitted. Note that the traffic also matches policy P3, but user firewall policies are terminal—policy lookup ends when the first policy match is found. Because policy P2 matches all criteria, policy lookup ends and policy P3 is not checked.
Policies can also be based on the classification assigned to a user from the user and role retrieval results. Consider a different set of policies for the same zone pair represented by Table 3. If traffic is received from user-q at IP 198.51.100.5, user and role retrieval is required because the source-identity field is specified in at least one of the policies.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
trust |
untrust |
any |
any |
un-authenticated-user |
http |
deny |
– |
P2 |
trust |
untrust |
any |
any |
mgmt |
any |
permit |
– |
P3 |
trust |
untrust |
198.51.100.3 |
any |
employee |
http |
deny |
– |
When the UIT entries in Table 2 are checked, no entry is found for IP address 198.51.100.5. Therefore, the user is considered an unauthenticated user. When policy lookup resumes, the traffic matches policy P1 and the traffic is denied.
Understanding the User Identification Table
On the SRX Series Firewall, the user identification table (UIT) contains the IP address, username, and role information for each authenticated user. Entries are ordered by IP address. When username and role information is required by a security policy, all UITs are checked. Finding the IP address in an entry in one of the UITs means that the user at that address has already been successfully authenticated.
Each authentication source maintains its own UIT independently and provides query functions for accessing data. Three types of UITs are supported—the local authentication table, the Unified Access Control (UAC) authentication table, and the firewall authentication table.
| Local authentication table | A static UIT created on the SRX Series Firewall either manually or programmatically using CLI commands. All users included in the local authentication table are considered authenticated users. When a matching IP address is found, user and role information is retrieved from the table entry and associated with the traffic. User and role information can be created on the device manually or ported from a third-party authentication server, but the data in the local authentication table is not updated in real time. |
| UAC authentication table | A dynamic UIT pushed from the Junos Pulse Access Control Service to the SRX Series Firewall. The UAC authentication table of a Junos Pulse Access Control Service contains an entry for each authenticated user. The data in this table is updated and pushed to the SRX Series Firewall whenever its authentication table is updated. Depending on the device configuration, authentication could occur on the Junos Pulse Access Control Service itself or on a third-party authentication server. If the Access Control Service is relaying data from a third-party server, the data is restructured by the Access Control Service to match the file format of its authentication table and pushed to the SRX Series Firewall. |
| Firewall authentication table | A dynamic UIT created on the SRX when The |
- Local Authentication Table
- UAC Authentication Table
- Firewall Authentication Table
- Policy Provisioning With Users and Roles
Local Authentication Table
The local authentication table is managed with CLI commands that insert or delete entries. A local authentication table can be used as a backup solution when a dynamic UIT is not available, or to assign user and role information to devices that cannot authenticate to the network, such as printers or file servers. The local authentication table can be used for testing or to demonstrate how a user role firewall works without firewall authentication or the Access Control Service configured.
The IP addresses, user names, and roles from a third-party authentication source can be downloaded and added to the local authentication table programmatically using CLI commands. If an authentication source defines users and groups, the groups can be configured as roles and associated with the user as usual.
To be compliant with the UAC authentication table, user names are limited to 65 characters and role names are limited to 64 characters. The local authentication table has a maximum of 10,240 authentication entries on SRX1500 devices and above, 5120 authentication entries on SRX650 devices and below, depending on the Junos OS release in your installation. The local authentication table has 5120 authentication entries on the vSRX Virtual Firewall. Each authentication entry can be associated with up to 200 roles. The maximum capacity is based on an average of 10 roles assigned to each user. This is the same capacity specified for a UAC authentication table.
Use the following command to add an entry to a local authentication table. Note that each entry is keyed by IP address.
user@host> request security user-identification local-authentication-table add user user-name ip-address ip-address role [role-name role-name ]
The role option in a single CLI command accepts up to 40 roles. To associate more than 40 roles with a single user, you need to enter multiple commands. Keep the following characteristics in mind when adding or modifying authentication user and role entries.
Role names cannot be the same as usernames.
Using the
addoption with an existing IP address and username aggregates the role entries. The table can support up to 200 roles per user.Using the
addoption with an existing IP address and a new username overwrites the existing username for that IP address.Role aggregation does not affect existing sessions.
To change the role list of an existing entry, you need to delete the existing entry and add an entry with the new role list.
To change the IP address of an existing entry, you need to delete the existing entry and add an entry with the new IP address.
An entry can be deleted by IP address or by username.
user@host> request security user-identification local-authentication-table delete (ip-address | user-name)
The local authentication table can be cleared with the following command:
user@host> clear security user-identification local-authentication-table
To display the content of the local authentication table, use
the following show... command:
user@host> show security user-identification local-authentication-table all (brief | extensive)
The brief option (the default) displays information
in a tabular format sequenced by IP address. User names and role lists
are truncated to fit the format.
user@host> show security user-identification local-authentication-table all
Total entries: 2 Source IP Username Roles 198.51.100.1 user1 role1 203.0.113.2 user2 role2, role3
The extensive option displays the full
content for each field. Other options limit the display to a single
username, IP address, or role.
user@host> show security user-identification local-authentication-table all extensive
Total entries: 3 Ip-address: 198.51.100.2 Username: user1 Roles: role1 Ip-address: 203.0.113.2 Username: user1 Roles: role2 Ip-address: 192.0.2.3 Username: user3 Roles: role1, role2
UAC Authentication Table
An SRX Series Firewall can act as an enforcer for a Junos Pulse Access Control Service. In this implementation, the SRX Series Firewall acts as a Layer 3 enforcement point and controls access to resources with IP-based resource policies that have been pushed down from the Access Control Service.
When implemented as a user role firewall, the SRX Series Firewall can access the UAC network in a similar way for user role retrieval. In this instance, user and role information for all authenticated users is pushed from the Access Control Service.
The SRX Series Firewall configuration is similar to that of an enforcer. To establish communication, both devices require configuration and password settings to recognize the other. From the SRX Series Firewall, connect the Access Control Service as an infranet controller.
[edit] user@host# set services unified-access-control infranet-controller ic-name address ip-address user@host# set services unified-access-control infranet-controller ic-name interface interface-name user@host# set services unified-access-control infranet-controller ic-name password password
From the Access Control Service, define the SRX Series Firewall as a New Enforcer. Use the same password specified on the SRX Series Firewall.
Users and passwords are defined on the Access Control Service as in a standard authentication configuration. One or more roles can also be associated with users. When a user is authenticated, an entry containing the IP address, username, and associated roles is added to the UAC authentication table on the Access Control Service.
The UAC authentication table is pushed from the Access Control Service to the SRX Series Firewall when the connection between the two devices is initialized. Whenever an entry is added, removed, or updated on the Access Control Service, the updated UAC authentication table is pushed to the SRX Series Firewall.
Resource access policies are not necessary on the Access Control Service for a user role firewall implementation. The access behavior is provided in the policy configurations on the SRX Series Firewall. If resource access policies are defined on the Access Control Service, they are pushed to the SRX Series Firewall, but they are not used unless a specific firewall policy implements UAC policies in the policy’s action field.
The following show services command displays the content of the UAC
authentication table on the SRX Series Firewall, confirming that the table has been
pushed from the Access Control Service successfully:
user@host> show services unified-access-control authentication-table extended
Id Source IP Username Age Role name 3 192.0.2.1 april 60 Users 6 192.0.2.2 june 60 Employeees Total: 2
The SRX Series Firewall monitors connections and detects if communication to the Access Control Service has been lost. Based on the UAC configuration, the SRX Series Firewall waits for a response for a configured interval before issuing another request. If a response is received, the Access Control Service is considered functional. If no response is received after a specified timeout period, communication is considered lost and the timeout action is applied. The following UAC command syntax configures the interval, timeout, and timeout action:
user@host# set services unified-access-control interval seconds user@host# set services unified-access-control timeout seconds user@host# set services unified-access-control timeout-action (close | no-change | open)
During a disconnection, if user and role lookup is attempted for the disconnected device, it returns a failure code regardless of the timeout action. If access to all authentication sources is lost, the keyword unknown-user is associated with the IP address. When policy lookup resumes, a policy with unknown-user as the source identity would match the traffic. By implementing a specific policy for unknown-user, you can create a method for handling the loss of authentication sources.
Firewall Authentication Table
Firewall authentication requires users to authenticate to the SRX firewall before permitting access between zones and devices. When traffic is received, the user is prompted for a username and password, and verified against a specified profile of valid users. Depending on the device configuration, firewall authentication verifies that telnet, HTTP, HTTPS (for SRX5800, SRX5600, and SRX5400 devices), and FTP traffic has been authenticated locally or by a RADIUS, LDAP, or SecureID authentication server.
If firewall authentication is in use on a device, the authentication
process can also provide the username and role information needed
for user role firewall match criteria. In this case, the information
is collected and maintained in a UIT called the firewall authentication
table. One or more access policies in the edit access hierarchy
define authentication methods to be used for firewall authentication.
The firewall authentication table must be enabled as the authentication
source for user role information retrieval. The priority option specifies the sequence in which all UITs will be checked.
user@host# set security user-identification authentication-source firewall-authentication priority priority
In a firewall policy for a given zone pair, the firewall-authentication service specified for the permit action initiates authentication
of matching traffic. The user-firewall authentication type
generates the UIT entry for the authenticated user. The name specified
in the access-profile option identifies the profile to
be used to authenticate valid users.
[edit security policies from-zone zone to-zone zone policy policy-name] user@host# set match source-identity unauthenticated-user user@host# set then permit firewall-authentication user-firewall access-profile profile-name
The UIT table entry contains the IP address of the traffic mapped to the authenticated user and the user’s associated groups. When the user is no longer active, the entry is removed from the table. Because entries are continuously added and removed as the traffic and authenticated users change, the firewall authentication table is considered dynamic.
When policies within the same zone pair specify the source-identity field as part of its match criteria, all enabled UITs are searched
for an entry corresponding to the IP address of the traffic. If found,
the associated username and groups are retrieved for source-identity
matching. (User authentication group names are considered role names
for source-identity matching.)
Policy Provisioning With Users and Roles
All users and roles, whether defined on the SRX Series Firewall or on the Access Control Service,
are maintained in a user role file on the SRX Series Firewall. To display all users
and roles available for provisioning, use the following show
security... commands.
Usernames and roles in the firewall authentication table are not included in the following displays.
To display all of the roles that are available for provisioning, use the
show security user-identification role-provision allcommand. Note that the roles from all UITs are listed together.To display all of the users that are available for provisioning, use the
show security user-identification user-provision allcommand.To display all of the users and roles that are available for provisioning, use the
show security user-identification source-identity-provision allcommand.
When a policy configuration is committed, the user role file is checked to determine if all users and roles specified in the policy are available for provisioning. If a user or role is not found, a warning identifies the missing user or role so that you can define it later.
The policy is committed even if a user or role is not yet defined.
See Also
Obtaining Username and Role Information Through Firewall Authentication
User role firewall policies can be integrated with firewall authentication both to authenticate users and to retrieve username and role information. The information is mapped to the IP address of the traffic, stored in the firewall authentication table, and used for user role firewall policy enforcement.
The following CLI statements configure firewall authentication for user role firewall enforcement.
Configuring a User Role Firewall For Captive Portal Redirection
To automatically redirect unauthenticated users to the Access Control Service, use the UAC captive portal feature. The following syntax defines the profile for the captive portal:
set services unified-access-control captive-portal profile-name redirect-traffic [unauthenticated | all] set services unified-access-control captive-portal profile-name redirect-url host-url
The Kerberos protocol, used for authentication encryption, identifies the Access Control Service only by its service principal name (SPN). The protocol does not accept an IP address. Therefore, the format for the redirect URL must be
service://hostname/options
In this implementation, the service is HTTP and the hostname is the FQDN of the Access Control Service. Options specified after the hostname pass additional information to the Access Control Service directing the user back to the original destination, to the SRX Series Firewall, or to the policy that originated the redirection. You can configure the options using the following keyword and variable pairs:
| ?target=%dest-url% | Specifies the protected resource which the user is trying to access. |
| &enforcer=%enforcer-id% | Specifies the ID assigned to the SRX Series Firewall when it is configured as an enforcer by the Access Control Service. |
| &policy=%policy-id% | Specifies the encrypted policy ID for the security policy that redirected the traffic. |
The following statements define the profile of the captive portal named auth-redirect. The captive-portal redirects unauthenticated users to the URL of the Access Control Service for authentication. After successful authentication, the traffic will be directed back to the SRX Series Firewall.
[edit] user@host# set services unified-access-control captive-portal auth-redirect redirect-traffic unauthenticated user@host# set services unified-access-control captive-portal auth-redirect redirect-url "http://ic6000.example.com/?target=%dest-url%&enforcer=%enforcer-id%&policy=%policy-id%"
A defined captive-portal profile is displayed as part of the UAC configuration.
[edit] user@host#show services
unified-access-control {
captive-portal auth-redirect {
redirect-traffic unauthenticated;
redirect-url "http://ic6000.example.com/?target=%dest-url%&enforcer=%enforcer-id%&policy=%policy-id%";
}
}
After the profile is defined, a policy can apply the captive portal as an application service when certain criteria is matched. Whenever a user role is unauthenticated, auth-redirect captive portal diverts the traffic from trust zone to untrust zone. The following example defines policy P1 to apply the auth-redirect captive portal profile to any HTTP traffic from the trust to untrust:
[edit] user@host# set security policies from-zone trust to-zone untrust policy P1 match application http user@host# set security policies from-zone trust to-zone untrust policy P1 match source-identity unauthenticated-user user@host# set security policies from-zone trust to-zone untrust policy P1 then permit application-services uac-policy captive-portal auth-redirect
Example: Configuring a User Role Firewall on an SRX Series Device
The following example configures a user role firewall on an SRX Series Firewall. The firewall controls access from the trust zone to the untrust zone based on active, authenticated users or their associated roles. User role firewall policies establish the following restrictions:
Only authenticated users are permitted from the trust zone to the untrust zone.
Unauthenticated users are redirected to an Access Control Service for authentication.
Traffic from IP 192.0.2.0 to IP 203.0.113.0 within the zone context is restricted. Only the traffic from users with the dev-abc, http-juniper-accessible, or ftp-accessible role is permitted. Permitted traffic is further evaluated by AppFW rules.
Permitted traffic identified as junos:FACEBOOK-ACCESS, junos:GOOGLE-TALK, or junos:MEEBO application traffic is denied.
Permitted traffic for any other application is permitted.
All other traffic from the trust zone to the untrust zone is permitted.
Requirements
Before you begin, ensure that the SRX Series Firewall with Junos OS Release 12.1 or later is configured and initialized.
In this example, user and role information associated with the IP address of the traffic is provided by an Access Control Service. For instructions on configuring the Access Control Server, see Acquiring User Role Information from an Active Directory Authentication Server.
Overview
Table 4 outlines a firewall that meets the requirements for this example. The user role firewall consists of four policies.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
user-role-fw1 |
trust |
untrust |
any |
any |
un-authenticated-user |
http |
permit |
UAC captive portal |
user-role-fw2 |
trust |
untrust |
192.0.2.0 |
203.0.113.0 |
dev-abc http-juniper-accessible ftp-accessible |
http |
permit |
AppFW ruleset RS1 |
user-role-fw3 |
trust |
untrust |
192.0.2.0 |
203.0.113.0 |
any |
http |
deny |
|
user-role-fw4 |
trust |
untrust |
any |
any |
any |
http |
permit |
Because the source-identity field is specified for
at least one of the policies in this firewall, user and role information
must be retrieved before policy lookup is conducted. The source IP
of the traffic is compared to the items in the UIT. If the source
IP address is found, the keyword authenticated, the username,
and any roles associated with this user are stored for later use in
policy lookup. If a matching entry for the IP address is not found
in the UIT, the keyword unauthenticated-user is stored
for policy lookup.
After retrieving the username, roles, and keywords, policy lookup begins. Characteristics of the incoming traffic are compared to each policy’s match criteria. If a match is found, the action specified in that policy is taken.
A policy match is a terminal event, and no policies after the match are checked. Policy sequence influences the action to be taken for matching traffic. In this example, policies are applied in the following sequence:
| user-role-fw1 | Applies the UAC captive portal service to matching HTTP traffic with the unauthenticated-user keyword, and redirects it to the Access Control Service for authentication. A UAC profile must also be configured to identify the captive portal specifications. |
| user-role-fw2 | Applies an AppFW rule set to any HTTP traffic from address 192.0.2.0 to address 203.0.113.0 that has a matching username or role. An application firewall must also be configured to define the rule set. |
| user-role-fw3 | Denies all remaining HTTP traffic from address 192.0.2.0 to address 203.0.113.0 for this zone pair. |
| user-role-fw4 | Permits all remaining HTTP traffic for this zone pair. |
Configuration
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 CLI User guide.
- Configuring Redirection For Unauthenticated Users
- Creating a User Role Policy With an Application Firewall
- Creating Remaining Security Policies Based on User and Role
Configuring Redirection For Unauthenticated Users
Step-by-Step Procedure
When an IP address is not listed in the UIT, the unauthenticated-user keyword is used in policy lookup. Instead of denying access to this traffic, a policy can redirect the traffic to a UAC captive portal for authentication.
It is important to position a redirection policy for unauthenticated-user before a policy for “any” user so that UAC authentication is not shadowed by a policy intended for authenticated users.
To configure redirection from the SRX Series Firewall to the Access Control Service:
From configuration mode, configure the UAC profile for the captive portal acs-device.
[edit] user@host# set services unified-access-control captive-portal acs-device redirect-traffic unauthenticated-user
Configure the redirection URL for the Access Control Service or a default URL for the captive portal.
[edit] user@host# set services unified-access-control captive-portal acs-device redirect-url “https://%ic-url%/?target=%dest-url%&enforcer=%enforcer-id%”
This policy specifies the default target and enforcer variables to be used by the Access Control Service to direct the user back after authentication. This ensures that changes to system specifications will not affect configuration results.
Note:When variables, such as
?target=, are included in the command line, you must enclose the URL and variables in quotation marks.Configure a user role firewall policy that redirects HTTP traffic from zone trust to zone untrust if the source-identity is unauthenticated-user. The captive portal profile name is specified as the action to be taken for traffic matching this policy.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match source-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match source-identity unauthenticated-user user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 then permit application-services uac-policy captive-portal acs-device
If you are done configuring the policies, commit the changes.
[edit] user@host# commit
Results
From configuration mode, confirm your configuration
by entering the show services and show security policies commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
[edit]user@host#show services unified-access-control { captive-portal acs-device { redirect-traffic unauthenticated; redirect-url “https://%ic-ip%/?target=%dest-url%&enforcer=%enforcer-id%”
user@host# show security policies
from-zone trust to-zone untrust {
policy user-role-fw1 {
match {
source-address any;
destination-address any;
application http;
source-identity unauthenticated-user
}
then {
permit {
application-services {
uac-policy {
captive-portal acs-device;
}
}
}
}
}
}
Creating a User Role Policy With an Application Firewall
Step-by-Step Procedure
This policy restricts traffic from IP192.0.2.0 to IP 203.0.113.0 based on its user and roles, and also its application. The configuration defines an application rule set and applies it to matching user role traffic.
Configure the AppFW rule set rs1. The following rule set denies junos:FACEBOOK-ACCESS, junos:GOOGLE-TALK, or junos:MEEBO application traffic. It applies the default setting, permit, to the remaining traffic.
[edit security 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 deny user@host# set default-rule permit
Configure a policy to apply the rs1 application firewall rule set to traffic from IP 192.0.2.0 to IP 203.0.113.0 with the dev-abc, http-mgmt-accessible, or ftp-accessible user role.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match source-address 192.0.2.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match destination-address 203.0.113.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match source-identity [dev-abc http-mgmt-accessible ftp-accessible] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 then permit application-services application-firewall rule-set rs1
If you are done configuring the policy, commit the changes.
[edit] user@host# commit
Results
Verify that the AppFW rule set is configured properly. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit]user@host#show security application-firewall rule-sets rs1 { rule r1 { match { dynamic-application [junos:FACEBOOK-ACCESS junos:GOOGLE-TALK junos:MEEBO] } then { deny; } } default-rule { permit; } }
Creating Remaining Security Policies Based on User and Role
Step-by-Step Procedure
The following procedure configures policies for the remaining traffic.
Configure a policy to deny traffic with the same source and destination address but with different user and role criteria than specified in the user-role-fw2 policy.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match source-address 192.0.2.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match destination-address 203.0.113.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match source-identity any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 then deny
Configure a security policy to permit all other HTTP traffic from zone trust to zone untrust.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match source-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match source-identity any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 then permit
Results
Verify the content and sequence of the user role firewall policies. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit]user@host#show security policies ... from-zone trust to-zone untrust { policy user-role-fw1 { match { source-address any; destination-address any; application http; source-identity unauthenticated-user } then { permit { application-services { uac-policy { captive-portal acs-device; } } } } } } from-zone trust to-zone untrust { policy user-role-fw2 { match { source-address 192.0.2.0; destination-address 203.0.113.0; application http; source-identity [dev-abc http-juniper-accessible ftp-accessible] } then { permit { application-services { application-firewall { rule-set rs1 } } } } } } from-zone trust to-zone untrust { policy user-role-fw3 { match { source-address 192.0.2.0; destination-address 203.0.113.0; application http; source-identity any } then { deny } } } from-zone trust to-zone untrust { policy user-role-fw4 { match { source-address any; destination-address any; application http; source-identity any } then { permit } } }
Configuring Resource Policies Using UAC
When using the user role firewall feature, resource policies are not necessary on the Access Control Service. If, however, resource policies exist, they are pushed to the SRX Series Firewall at connection. You can create policies that use these resource policies by applying the UAC application service in the policy configuration. Table 5 shows three firewall policies that use the UAC resource policies exclusively:
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
zone1 |
zone2 |
any |
192.0.2.1 |
any |
http |
permit |
Content Security |
P2 |
zone1 |
zone2 |
any |
net2 |
any |
http |
permit |
IDP |
P3 |
zone1 |
zone2 |
any |
any |
any |
any |
permit |
UAC |
The policies for traffic from zone1 to zone2 do not initiate user and role retrieval because any is specified in the source-identity field of every policy. In this example, traffic to the IP address 192.0.2.1 is permitted, but must meet processing requirements for the specified application service, in this case, Content Security. Traffic to net2 is permitted and processed by the IDP processing requirements. Any remaining traffic is permitted and processed by the UAC processing requirements.
The configuration for this firewall policy would be as follows:
[edit]user@host#show security policies from-zone zone1 to-zone zone2 { policy P1 { match { source-address any; destination-address 192.0.2.1; source-identity any; application http; } then { permit { application-services { idp; } } } } } from-zone zone1 to-zone zone2 { policy P2 { match { source-address any; destination-address net2; source-identity any; application http; } then { permit { application-services { utm; } } } } } from-zone zone1 to-zone zone2 { policy P3 { match { source-address any; destination-address any; source-identity any; application any; } then { permit { application-services { uac-policy; } } } } }
In this sample configuration, the action fields in P1 and P2 apply any requirements that have been configured for IDP and Content Security respectively. By specifying the uac-policy option, the resource policies pushed to the SRX Series Firewall determine whether the destination is accessible.
A user role firewall can implement both user role policies and the resource policies pushed from the Access Control Service. Table 6 shows the policies for three zone pairs.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
zone1 |
zone2 |
any |
any |
unauthenticated-user |
any |
permit |
UAC captive portal |
P2 |
zone1 |
zone2 |
any |
192.0.2.1 |
role2 |
http |
permit |
IDP |
P3 |
zone1 |
zone2 |
any |
net2 |
authenticated-user |
http |
permit |
Content Security |
P4 |
zone1 |
zone2 |
any |
any |
any |
any |
permit |
|
P5 |
zone1 |
zone3 |
any |
any |
any |
any |
permit |
UAC |
P6 |
zone2 |
zone3 |
any |
any |
any |
any |
permit |
UAC |
Traffic from zone1 to zone2 is subject to one of four user role policies. The first of these policies uses the UAC captive portal to redirect unauthenticated users to the Access Control Service for authentication.
The access of traffic from zone1 to zone3 and from zone2 to zone3 is controlled by the resource policies pushed from the Access Control Service.