Small Campus Policy Configuration

In this small campus implementation, policy is enforced in two locations:

• The WAN gateway, where all wired and wireless traffic is routed. The policy enforced at gateways applies to all inter-VLAN traffic and Internet traffic.

• Wireless access points, which apply a role-based policy to wireless clients.

This chapter focuses primarily on role-based policies applied to wireless clients, with additional coverage on implementing roles to control the general behavior of authenticated wired access ports.

This chapter does not implement a comprehensive security policy, the requirements of which can vary greatly depending on organizational goals. Instead, it demonstrates a representative policy structure that operators can use as a reference when translating security intent into enforceable policy.

Some role and policy components created in this chapter are prerequisites for building wired and wireless element profiles in following chapters.

Table of contents

• Small Campus Policy Configuration
  • WAN Gateway Policy
  • AP Policy
  • User Roles
    • Create WLAN Roles
    • Create Wired Infrastructure Roles
      • AAA Fallback Roles
      • AP Uplink Role
  • Define Policies
    • Small Campus Policy Summary
    • Resources for Rule Creation
      • Aliases
      • Services
      • Applications
    • Policy Creation Procedure
    • Rule Creation Procedure
    • Policy Set Summary
      • AAA Role Distribution Policy
      • Network Services Policy
      • Organizational Applications Policy
      • Internet Access Policy
      • Deny All Policy

WAN Gateway Policy

The type of enforcement available on a WAN gateway is dependent on the type of device deployed. All firewalls support IP-based filtering. Additional next-generation criteria may be applied to permit or deny traffic, such as application control, reputation, and intrusion prevention.

Some HPE Aruba Networking and 3rd-party devices also support role-based policy enforcement on a WAN gateway device. EdgeConnect SD-WAN appliances can support role-based policy in this example topology by snooping the RADIUS assigned role during authentication.

An administrator could add User-Based Tunneling (UBT) to apply role-based policy to wired clients using an HPE Aruba Networking Gateway. When using Aruba campus or branch Gateways, role-based policy is managed in Central, which provides the administrator a single-pane of glass for both wired and wireless policy management.

Detailed policy configuration on gateway devices is outside the scope of this document.

AP Policy

Wireless client policy enforcement is based on user Roles and Role-based Policies managed by Central Policy Manager (CPM) in HPE Aruba Networking Central. This identity-based model enforces consistent access permissions regardless of client location or VLAN assignment. Role-based enforcement occurs directly on the access point for wireless clients.

CPM provides a flexible and highly granular policy engine. For a complete discussion of CPM concepts and capabilities, refer to the Central Policy Configuration chapter of the VSG.

User Roles

Roles are the foundational policy objects in CPM. A role’s associated policy governs permitted network traffic, and it may optionally apply VLAN assignment or rate limits. While VLANs can be assigned by role profile, this implementation dynamically returns both role and VLAN assignments from a RADIUS server during 802.1X authentication for wired and wireless users.

Most user and device roles are scoped to campus access points, because the small campus design does not apply role-based enforcement on access switches. However, the REJECT-AUTH, CRITICAL-AUTH, and ARUBA-AP roles are required to support AAA enhancements for authenticated access ports. Unlike the roles assigned to authenticated users, these roles specify VLAN assignments and access or trunk operation.

The BLACKHOLE wireless user role and the wired AAA roles must be defined prior to configuring wireless and wired services.

Note: A role is not pushed to an access point or switch unless it is referenced by at least one policy that is scoped to the device.

The following table summarizes the roles and policies that will be created in this chapter.

Create WLAN Roles

Wireless user roles are created with default parameters, as specific VLAN assignments is handled dynamically via RADIUS attributes during authentication.

Step 1 Click the Configuration icon in the dashboard.

Step 2 Navigate to Library in the left navigation pane and click the Roles & Policies tab.

Step 3 Under the Roles card, click Manage.

Step 4 Click Create Role.

Step 5 Input the following non-default values and click Create:

• Name: < Role Name >
• Description: < Role Description >

Step 6 Hover over the new role and click the ••• context menu icon.

Step 7 Click Assign.

Step 8 Under Device Function, check Campus Access Point.

Step 9 To the right of the Scopes heading, click the plus sign (+).

Step 10 On the Add Scope page, select the following values and click Add

Scope Level: Sites
Assign to Scope: SMALL-CAMPUS-SITE

Step 11 Click Assign.

Step 12 Repeat this procedure for each user role.

Create Wired Infrastructure Roles

The AAA-related roles on access switches require manual VLAN assignment and specific authentication modes.

AAA Fallback Roles

The CRITICAL-AUTH role is used to assign a limited-access VLAN, when the RADIUS server is down or unreachable. This ensures that critical business functions are not disrupted for wired users when authentication services are unavailable.

The REJECT-AUTH role assigns a no-access or remediation VLAN, when the RADIUS server denies access. A remediation VLAN may provide a web portal with instructions to resolve common client misconfiguration issues and contact information for further assistance.

Create the following two roles using the same general procedure used to create wireless client roles.

Device Function: Access Switch
Scope: SMALL-CAMPUS-SITE

Configure the following non-default values:

• Name: < Role Name >
• Description: < Role Description >
• VLAN ID: < VLAN ID >
• Device Switch Parameters: check Switch
• Authentication Mode: Client
• VLAN: Access
• Access VLAN: < VLAN ID >

AP Uplink Role

The ARUBA-AP role automates assigning the complete set of VLANs needed on a trunk connected to a downstream AP. The small campus deployment uses bridged APs supporting multiple SSIDs. This type of deployment typically requires multiple tagged VLANs on a trunk. When used in conjunction with LLDP authentication criteria, administrators do not need to pre-configure specific ports for wireless APs.

Create the ARUBA-AP role with the same general procedure used to create wireless client roles.

Device Function: Access Switch
Scope: Global

Configure the following non-default values:

• Name: ARUBA-AP
• Description: Aruba wireless access points
• VLAN ID: 1
• Device Switch Parameters: check Switch
• VLAN: Trunk
• Native VLAN: 1
• Allowed VLANs: 1,25,30,40

Define Policies

Policies are unique to each organization’s security philosophy and requirements. The following procedures demonstrate Central’s general policy creation process, which can be applied to build the policies required at an individual organization. A complete security policy set is not created in this guide.

In Central, policies are intent-based, and an individual policy may contain rules that reference multiple roles. Central does the work of compiling the rules across all defined policies which are associated with an individual role to derive a resultant role policy, as described in the Central Policy Configuration chapter. The resultant policy rule set is constructed based on the order of policies and rules defined in Central.

A default sys_allow_all policy is applied at the bottom of Central’s policy set, which contains an allow any rule for each role defined in Central. By default, any traffic not explicitly blocked by a policy above sys_allow_all is permitted.

If an administrator prefers the approach of allowing only traffic that is explicitly permitted in their policy design, this can be accomplished by creating an explicit deny all policy directly above the default policy. This decision can be made on a per role basis, by including only a subset of roles in the explicit deny all policy.

Small Campus Policy Summary

Five policies are created to illustrate the policy build process for an organization. The goals and order of intent-based policies should be planned prior to implementation. The following table provides a summary of the policy names used in the small campus example, the roles included in the policy, a description, and its scope assignment. The policies are listed in the order they appear in Central. The default sys_allow_all policy is included in the list, as it must be considered in the policy planning process.

After planning is complete, the general process is to:

• create an individual policy container
• apply rules inside the container to achieve the intended goal

Resources for Rule Creation

Central provides administrators several shortcuts for referring to hosts, services, and applications when building policy rules. They are accessible by clicking the Named Objects tab in the Configuration’s horizontal menu.

Aliases

Aliases are re-usable objects that can be referenced by configuration profiles and policy rules. In a policy rule application, they are primarily used to define IPv4/IPv6 hosts and subnets.

This gives operators the flexibility of assigning a meaningful name to an individual IP address or subnet, and apply the alias to multiple policy rules. For example, an IP address might represent the destination address for an application.

Additionally, aliases simplify updating policy rules in the future by providing a single, logical object to modify. If the intended IP address or subnet changes in the future, only the alias needs to be modified. All associated policy rules will automatically be updated based on the changes made to the alias.

Our example rule set uses custom defined aliases to represent the RFC 1918 private address ranges, and the organization’s unique DNS and NTP servers. The RFC-1918 alias is depicted below:

Services

Network applications use well-known, standardized port and protocol numbers to provide their services. Service objects apply meaningful names to individual or sets of TCP and UDP port numbers. IP protocol numbers also can be assigned to service profiles to support non-TCP/UDP services, such IP protocol 89 for OSPF. Central offers a large, pre-built catalogue of common services.

This example implementation leverages the following pre-defined service profiles:

• svc-dhcp: UDP ports 67-68
• svc-dns: UDP port 53
• svc-ntp: UDP port 123
• svc-https: TCP port 443

The svc-dns service object is shown below.

Applications

Cloud-based applications are more difficult to identify, they typically use the same HTTP/HTTPS port numbers, and their associated DNS names and IP addresses can be a moving target. Some examples of cloud-based apps include Facebook, Slack, DropBox, and Microsoft Office 365. Central maintains a catalogue of cloud-based applications on the operators behalf, so that policy can allow or deny access to cloud-based applications with minimal effort.

In addition to referencing individual cloud-based applications, Central aggregates applications into categories such as Streaming Media, Social Networking, Cloud File Sharing, etc.

Administrators can leverage applications and application categories managed by Central to easily allow or deny cloud-based services, without having to manually manage lists of domains and IP addresses.

The DropBox application definition below illustrates the value of Central’s predefined applications. The operator doesn’t need to find the 103 currently used DNS names for the DropBox service. They can simply allow or deny DropBox by referencing the application object in a rule.

This example implementation leverages the following application-related profiles:

• Application: Microsoft Office 365
• Application Category: Cloud File Sharing

Policy Creation Procedure

The procedure below outlines the steps used to create a policy, which is a container for a set of rules to achieve a specific intent.

After policies are created, they can be re-ordered to ensure that resultant policies are built correctly.

Step 1 Click the Roles & Policies tab.

Step 2 Under Security Policies card, click Manage.

Step 3 On the Role-based Policies card, click Manage.

Step 4 On the Role-based Policies page, click Create Policy.

Note: After a policy is created, its ••• contextual menu can be used to add a new policy above or below its location as an alternative to the Create Policy button.

Step 5 Enter a name and description, then click Create.

Step 6 Hover over the policy, then click the ••• context menu icon.

Step 7 On the context menu, select Assign.

Step 8 Under Device Function, click Access Switch, and then click the plus sign (+) to the right of Scopes.

Step 9 On the Add Scope page, select the following values and click Add.

Scope Level: Sites
Assign to Scope: SMALL-CAMPUS-SITE

Step 10 Click Assign.

Step 11 Repeat steps 4–10 to create the following policy blocks.

Rule Creation Procedure

After policy containers are created, a set of rules is constructed to achieve the intent of each policy. After rules are created, they can be re-ordered to ensure that resultant policies are built correctly.

The procedure below outlines the steps used to create a rule within a policy.

Step 1 In the Role-based Policies table, hover over a policy and click the ••• context menu icon.

Step 2 In the context menu, select Add Rule.

Step 3 On the Create Rule page, enter the following non-default values and click Create.

• Description: Allow DNS to DNS-SERVER-1
• Access Role: EMPLOYEE, FINANCE, GUEST-USER, HR, IOT, IT
• Destination: Host
• Check User Alias
• Alias: DNS-SERVER-1
• Service/Application: Service
• Service: svc-dns

Policy Set Summary

A description of each small campus policy is provided below. A sample set of rules demonstrates the types of rules that could be included to match a policy’s intent. A complete rule set is not provided.

AAA Role Distribution Policy

Central does not push roles to a network device, unless a corresponding policy that references the role is also pushed to the same device.

The AAA authentication process on an access switch utilizes some roles without any corresponding policy. The function of the role is to dynamically assign VLANs to a port under specific conditions. In this deployment, the following AAA roles are used:

• CRITICAL-AUTH assigns a limited access VLAN, when the authentication server is unresponsive.
• REJECT-AUTH assigns a blackhole VLAN, when authentication fails.
• ARUBA-AP assigns an untagged management VLAN and tagged VLANs for WLAN SSIDs, when an access point is attached.

A mock policy is created to push these roles to access switches. The policy itself does not govern the treatment of network traffic. The policy is created for the purpose of referencing roles required for AAA functions. Creating this reference triggers Central to push the associated role configuration to devices.

Device Function: Access Switch
Scope: Site : SMALL-CAMPUS-SITE

Network Services Policy

This policy allows access to critical network services such as DHCP, DNS, and NTP for wireless clients. When additional network services are required, add the appropriate rules to this policy.

It is best practice to explicitly permit required network services in a policy at the top of the policy set. This prevents unintentionally blocking access to key services, when creating rules that block traffic in subsequent policies.

Device Function: Campus Access Point
Scope: Site : SMALL-CAMPUS-SITE

Organizational Applications Policy

This policy defines access to on-premise and cloud-based applications used by an organization.

It is best practice to explicitly allow applications to avoid unintentionally blocking access by lower policies.

Device Function: Campus Access Points
Scope: Site : SMALL-CAMPUS-SITE

Note: Denying all RFC 1918 addresses for the GUEST-USER role does not block access to local DNS services, because those were explicitly allowed in the policy above. However, the rule above will block pings to upstream gateways, which may be desired for troubleshooting purposes. An additional policy or rule above the one shown in this policy is required to allow pings or access to any other local resources.

Internet Access Policy

The following rules are examples that might be included in a general Internet access policy.

Device Function: Campus Access Point
Scope: Site : SMALL-CAMPUS-SITE

Deny All Policy

An explicit deny all policy at the end of the policy set will block any access that is not explicitly granted in a policy higher in the policy set. Administrators can assign all roles to the deny all rule, if the security philosophy is to deny all traffic that is not explicitly permitted.

It is common to highly restrict access for IoT devices, because they are highly susceptible to compromise and commonly participate in DDoS attacks. The following default deny policy blocks all traffic not explicitly permitted for devices assigned the IOT and BLACKHOLE roles. All other roles will fall through to the sys_allow_all default policy.

Device Function: Campus Access Point
Scope: Site : SMALL-CAMPUS-SITE

---