wing 5 how-to guide - test page for the nginx http server on epel

Configuration Guide for RFMS 3.0 Initial Configuration XXX-XXXXXX-XX

WiNG 5 How-To Guide Role-Based Firewall

June 2011

Revision 1.0

MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office.

Symbol is a registered trademark of Symbol Technologies, Inc. All other product or service names are the property of their respective owners.

© 2011 Motorola, Inc. All rights reserved.

Table of Contents:

1. Introduction: ........................................................................................................................ 4

1.1 Overview: ..................................................................................................................... 4

1.2 Distributed Stateful Inspection:..................................................................................... 4

1.3 Role Based Firewall ..................................................................................................... 5

1.4 Components: ............................................................................................................... 7

2. Use and Configuration: ....................................................................................................... 7

2.1 Scenario 1 ................................................................................................................... 8

2.2 Scenario 2 ..................................................................................................................17

3. Verification .........................................................................................................................26

4. Troubleshooting .................................................................................................................28

5. Reference Documentation: ................................................................................................30

WiNG 5 Role-Based Firewall How-To Guide

1. Introduction:

To augment the firewall services of WiNG 5, one may add on the Advanced Security license to enable role-based firewall. The Advanced Security licensing is included with the purchase of the RFS4000 series switches for smaller wireless deployments and can be purchased as add-on licensing for the higher-end models. Role-based firewall gives enhanced security to the standard firewall features of WiNG 5. Whereas the standard IP and MAC based firewall rules are applied to physical and logical interfaces as well as WLANs, role-based rules are applied to the wireless clients and follow them as they roam on the network. For further information on the standard Firewall features of WiNG 5, please see the document at: http://compass.mot-solutions.com/doc/392577167/WiNG5_Firewall_How-To.pdf

1.1 Overview:

Roles allow for dynamic assignment of IP and MAC firewall rules to wireless clients based on one or more match conditions that are evaluated when the client associates to the wireless network. These dynamic rules follow the clients, being migrated to other access points as the clients roam. If a role is established that would affect already connected clients, these roles will be evaluated immediately and put into effect against the client traffic. Match criteria include:

Location: AP or group of AP’s the wireless client is connected to

Authentication: The authentication method used by the client during association

Encryption: The encryption type used by the client (not configured on the WLAN)

Group Membership: The local group the wireless client is assigned to as obtained from AAA

Captive Portal Authentication State

MAC Address: MAC address or range of the wireless client(s)

SSID: The SSID the wireless client is associated to

1.2 Distributed Stateful Inspection:

The major new feature in WiNG 5 is distribution of services or services at the edge. Since controllers and access points alike run the same OS and thus feature set, processing of traffic for various services is pushed to the edge where it can be performed in real-time and done so dynamically.

http://compass.mot-solutions.com/doc/392577167/WiNG5_Firewall_How-To.pdf


Figure 1: Distributed Stateful Inspection

The distributed nature of the firewall allows stateful flows to migrate with clients as they roam between access points. Rules are made up of one or more traffic matching conditions, for which an action is then performed (permit, deny, mark, log). As is the case with firewalls, at least one permit action must be met in order for traffic to be forwarded and at the end of a rule set, there is an implied deny for all traffic not meeting a match condition.

1.3 Role Based Firewall

Roles based firewall was designed to meet the security needs of the mobile enterprise.


User Roles to Security Policies

Security Policies

User Role

Default

Location

Group Membership

Hot-Spot State

Encryption

Authentication

SSID

MAC-Address

Engineering

Location

Group Membership

Hot-Spot State

Encryption

Authentication

SSID

MAC-Address

Sales

Location

Group Membership

Hot-Spot State

Encryption

Authentication

SSID

MAC-Address

Guest

Location

Group Membership

Hot-Spot State

Encryption

Authentication

SSID

MAC-Address

Inbound ACLs

ACL

ACL

Inbound ACLs

ACL

ACL

Inbound ACLs

ACL

ACL

Inbound ACLs

ACL

ACL

It is possible from time to time that while a role is being evaluated, multiple matches may be found. In this case, the role with the lowest precedence will be assigned to the wireless client. For each user role administrators can define match criteria and values that can individually be ignored, matched and partially matched. For example a group name could be defined in a user role to exactly match the value Sales which would apply to all users in the Sales group. Likewise an ESSID could be defined to partially match the value Corp which would match any devices associated with the ESSIDs named CorpUsers and CorpGuest. Alternatively specific strings can be ignored by selecting a match of Not Contains or all criteria can be matched using a match condition Any. Role based firewall requires the Advanced Security licensing on the controller, which is an added cost. The Advanced Security licensing is not shared among devices in a cluster, so in order for dynamic rules to follow a wireless client that roams from an access point on one controller in a cluster to an access point on another controller in the cluster, both controllers must have the added Advanced Security license.


1.4 Components:

The components of role-based firewall are listed below:

Firewall Rules (Access Control Lists) o IP Firewall Rules o MAC Firewall Rules

Wireless Client Roles (Role-policy)

AAA Policy (optional based on match criteria)

1) CLI Role-Policy options

rfs4000# conf t

rfs4000(config)#role-policy firewalled-users

rfs4000(config-role-policy-firewalled-users)#?

Role Policy Mode commands:

default-role Configuration for Wireless Clients not matching any role

no Negate a command or set its defaults

user-role Create a role

clrscr Clears the display screen

commit Commit all changes made in this session

do Run commands from Exec mode

end End current mode and change to EXEC mode

exit End current mode and down to previous mode

help Description of the interactive help system

revert Revert changes

service Service Commands

show Show running system information

write Write running configuration to memory or terminal

2. Use and Configuration:

We will examine two scenarios; an easy method based on SSID followed by a slightly more complex method based on the user’s group assignment.

During the configuration of the role-policy, the necessary IP or MAC access lists will be specified, so it is helpful to have these created already. Thus, following is a preferred order-of-configuration. This assumes that the general configuration of the wireless switch and necessary WLAN’s already exist. In the case of our second scenario, this document will also include the configuration of AAA and RADIUS policies.

1. Configure IP / MAC based access lists

2. Configure the Role-policy

3. Apply the role-policy to the device(s)


2.1 Scenario 1

2.1.1 CLI Configuration

1) CLI IP Access List configuration

rfs4000# conf t

rfs4000(config)#ip access-list restricted-allow

rfs4000(config-ip-acl-restricted-allow)#permit icmp any any 8 0 log rule-precedence 10

rule-description icmp allow

rfs4000(config-ip-acl-restricted-allow)#permit tcp any any eq ssh log rule-precedence

20 rule-description ssh allow

rfs4000(config-ip-acl-restricted-allow)#deny ip any any log rule-precedence 30

rfs4000(config-ip-acl-restricted-allow)#commit write

In the above example we have created an ACL named “restricted-allow” and we are allowing ICMP echo-request traffic from the wireless clients, as specified by icmp type 8, code 0. We are also allowing SSH traffic as this will be the method of access to the wireless switch from the role-based user. Finally, we are denying any other IP traffic and logging hits.

Next we will create the role-policy and apply it to the access point profile:

1) CLI Role policy configuration

rfs4000# conf t

rfs4000(config)#role-policy firewalled-users

rfs4000(config-role-policy-firewalled-users)#user-role fw-role precedence 10

rfs4000(config-role-policy-firewalled-users-user-role-fw-role)#ssid contains vlan64

rfs4000(config-role-policy-firewalled-users-user-role-fw-role)#use ip-access-list in

restricted-allow precedence 10

rfs4000(config-role-policy-firewalled-users-user-role-fw-role)#exit

rfs4000(config-role-policy-firewalled-users)show context

role-policy firewalled-users

user-role fw-role precedence 10

ssid exact vlan64

use ip-access-list in restricted-allow precedence 10

rfs4000(config-role-policy-firewalled-users)#commit write

2) Access Point profile application

rfs4000(config)#profile ap650 default-ap650

rfs4000(config-profile-default-ap650)#use role-policy firewalled-users

rfs4000(config-profile-default-ap650)#show context


profile ap650 default-ap650

autoinstall configuration

autoinstall firmware

interface radio1

wlan packetstorm bss 1 primary

wlan vlan64-wlan bss 2 primary

interface radio2

wlan PacketStorm-5G bss 1 primary

interface ge1

ip dhcp trust

qos trust dscp

qos trust 802.1p

interface vlan1

ip address dhcp

ip dhcp client request options all

use firewall-policy default

ntp server 138.236.128.112 prefer

use role-policy firewalled-users

logging on

service pm sys-restart

rfs4000(config-profile-default-ap650)# commit write

2.1.2 Web UI Configuration

Following the order that was previously listed, navigate to “Configuration > Security > IP Firewall Rules” (or MAC Firewall Rules is so inclined). Click on “Add”


Web-UI: Adding role-based access list

Give your ACL a name and begin adding rules, clicking “+Add Row” for each new line.

Web-UI: Adding ACL Rules

Once you have added all of your rules, click “>> Ok”, then commit and save your work.


Web-UI: Adding ACL Rules

2.1.3 Role Policy Creation

Next, navigate to “Configuration > Security > Wireless Client Roles” and click on “Add” to create a new role policy:


Web-UI: Role Policy Configuration

Name the role policy and then click “Add” to begin adding match criteria for the user role:



As can be seen, you may select a number of variations for match criteria. We have selected an exact match on the SSID, however other options exist as shown below:

Web-UI: Match Criteria


After selecting your match criteria, go to the “Firewall Rules” tab and select the previously configured IP access list or whatever firewall rules you have previously configured. Add additional rows for additional firewall rules as needed by clicking “+Add Row”

Web-UI: Adding Firewall Rules

One other note; on the “Default Firewall Rules” tab of your role policy, you may select default access lists to be applied whether or not match criteria have been met. Realize that these rules are applied at the level where the role policy has been applied (access point level). Exercise caution to ensure traffic is not interrupted inadvertently due to a default rule. In our case we have specified no defaults, as seen below:


Web-UI: Default Firewall Rules

2.1.4 Apply Policy

The final step is to apply the role policy to your devices. This will usually be done at the access point level (profile or device override) as that is the point of ingress for the wireless clients. It may also be done at an RFS4011, which has a built-in access point. Navigate to “Configuration > Profiles” and select / edit the profile you wish to apply the role policy to. Within the profile, navigate to “Security > Settings” and select your policy from the “Wireless Client Role Policy” drop-down box:


Web UI: Applying the Role Policy

Click “>>Ok: and then Commit and Save your work.

2.2 Scenario 2

Scenario 2 is the same basic setup, except for now our match criteria will be based on group-membership as gathered from AAA. The following sections will just show the configuration of the additional components (in order of configuration), which are:

Radius Services (Server, Group, and User-pool policies)

AAA Policy

WLAN Authentication


2.2.1 CLI Configuration

In this scenario, we configured RADIUS in the following order (due to later configuration):

1. Group policy 2. User-pool policy 3. Radius Server policy

1) CLI Running RADIUS Configuration

rfs4000# show running-config | begin radius-group no-internet-users

radius-group no-internet-users

policy ssid vlan64

policy day mo

policy day tu

policy day we

policy day th

policy day fr

policy time start 06:00 end 17:00

!

radius-user-pool-policy role-users

user user2 password 0 Password2 group no-internet-users

user user1 password 0 Password group no-internet-users

!

radius-server-policy local-rad-server

use radius-user-pool-policy role-users

authentication eap-auth-type peap-mschapv2

no ldap-group-verification

use radius-group no-internet-users

Following the radius configuration, we then create our AAA policy:

2) CLI Running AAA Policy Configuration

rfs4000# show running-config | begin aaa-policy local-aaa

aaa-policy local-aaa

authentication server 1 onboard controller

authentication server 1 retry-timeout-factor 150

accounting server 1 onboard controller

authentication eap wireless-client timeout 5


Then we modify the security on our WLAN to utilize EAP and the new RADIUS / AAA policies:

3) CLI Running WLAN Configuration

rfs4000# show running-config | begin wlan vlan64-wlan

wlan vlan64-wlan

ssid vlan64

vlan 64

bridging-mode tunnel

encryption-type ccmp

authentication-type eap

use aaa-policy local-aaa

Finally, we modify our role policy that was created in the first scenario to include the new match criteria. In this way, not all users who associate to the WLAN have the role policy applied to them; only users belonging to the specified group.

4) CLI Running Role-Policy Configuration

rfs4000# show running-config | begin role-policy firewalled-users

role-policy firewalled-users

user-role fw-role precedence 10

ssid exact vlan64

group exact no-internet-users

use ip-access-list in restricted-allow precedence 10


2.2.2 Web-UI Configuration

We will configure in the same order as was executed at the CLI. Navigate to “Configuration > Services > RADIUS > Groups” and add a new group policy. One item of note when configuring the group policy WLAN SSID – this box is for administrator-input. The SSID of your WLAN is what is needed, not the WLAN-name as WiNG 5 sees it. Ensure that the SSID is typed correctly, including case or it will be incorrect and the policy will not work. This is denoted in the screenshot below with the numbers 1 and 2: Type in your SSID and click the down-arrow to apply said SSID to the group policy.

Web UI: RADIUS Group Policy


Navigate to “Configuration > Services > RADIUS > User Pools” and create your pool of users. When creating your users, select the RADIUS Group they are to belong to, as shown:

Web UI: RADIUS User-Pool Policy

Navigate to “Configuration > Services > RADIUS > Server Policy” and add your new RADIUS server policy. The (1) RADIUS User Pool, (2) RADIUS Group (specified LDAP Group) and (3) Authentication source and type must be specified:


Web UI: RADIUS Server Policy

Once RADIUS has been configured, we then add the AAA Policy. Navigate to “Configuration > Wireless > AAA Policy” and add a new policy:


Web UI: AAA Policy


Web UI: AAA Policy

We now apply this new security to our WLAN; navigate to “Configuration > Wireless > Wireless LANs” select to edit the WLAN, then navigate to “Security” in the middle working pane. Under “Select Authentication” apply the new method.


Web UI: WLAN Authentication

Remember to Commit and Save your work as you complete these tasks. Finally navigate to “Configuration > Security > Wireless Client Roles” and select to edit the “firewalled-users” policy that was created for scenario 1. We will add match-criteria for the user group and specify the “no-internet-users” group policy that was configured during the RADIUS setup:


Web UI: Role Policy Modification

3. Verification

The configuration has been completed and now we can test. We expect that clients connecting to SSID “vlan64” will match our role-policy and will thus only be allowed to send ping requests and perform SSH based sessions. We connect a client to our SSID and then view the role policy state:


1) CLI Role Policy Verification

rfs4000# connect ap650-85CD9C

~~~ login output omitted ~~~

ap650-85CD9C#show role wireless-clients

Role_policy: firewalled-users

Role: fw-role

00-27-10-94-B8-5C

Wireless Clients not matching any Role:

1C-4B-D6-55-D0-2C 00-25-00-48-BB-AE 64-A7-69-7C-71-A5

ap650-85CD9C#

Next we will test and verify that the rules are actually working. We will initiate a ping from our wireless client to the RFS, followed by an SSH session:

Web UI: Testing the Role Policy

Finally, we will attempt an HTTPS session to our RFS Web interface:


Web UI: Testing the Role Policy

4. Troubleshooting

Remember that the role policy has been applied to the profile for the access points. Thus, we can connect to an access point to which an expected role-based user is associating and determine if the role is being set:


1) CLI Role Policy Verification

ap650-85CD9C#show wireless client

--------------------------------------------------------------------------------------

---------------------------

MAC IP VENDOR RADIO-ID WLAN

VLAN STATE

--------------------------------------------------------------------------------------

---------------------------

00-27-10-94-B8-5C 192.168.150.126 Intel Corp 00-23-68-85-CD-9C:R1 vlan64-wlan

64 Data-Ready

--------------------------------------------------------------------------------------

---------------------------

Total number of wireless clients displayed: 1

ap650-85CD9C#show wireless client detail 00-27-10-94-B8-5C

ADDRESS : 00-27-10-94-B8-5C - 00-27-10-94-B8-5C 192.168.150.126 (vlan:64)

USERNAME : user2

WLAN : vlan64-wlan (ssid:vlan64)

ACCESS-POINT : Name:ap650-85CD9C Location:Gilbert, AZ

RADIO-ID : 00-23-68-85-CD-9C:R1, alias ap650-85CD9C:R1

RADIO-NAME : radio1 Bss:00-23-68-73-BA-11

STATE : Data-Ready

CLIENT-INFO : 802.11bgn, vendor: Intel Corp

SECURITY : Authentication: eap Encryption: ccmp

DATA-RATES : 1 2 5.5 6 9 11 12 18 24 36 48 54 mcs0-15

MAX-PHY_RATE : 300 M

MAX-USER_RATE : 225 M

802.11n : Short guard interval: Y Channel width (capability: 40Mhz Current:

40Mhz)

: AMSDU Max-Size: 7935 AMPDU Max-Size: 65535 AMPDU Min-Spacing: 0

uSec

QoS : WMM: Y Type: Non Voice

POWER-MGMT : PS-Mode: N Spatial-Multiplexing-PS: off WMM-PS/U-APSD: Disabled

ACTIVITY : Last Active: 00:00.00 ago

SESSION INFO : Session Timeout: 0 days 06:08.00 Idle Timeout: 00.:30.00

RF-DOMAIN : default

MCAST STREAMS :

ROLE : fw-role/firewalled-users

ap650-85CD9C#


5. Reference Documentation:

Description Location

WiNG 4 Wired / Wireless Firewall http://compass.mot.com/doc/316513023/WiNG_How_To_-_Wired_Wireless_Firewall.pdf

Role Based Firewall WiNG 5 Functional Spec

http://compass.mot.com/doc/316513023/WiNG_How_To_-_Wired_Wireless_Firewall.pdf

http://compass.mot.com/doc/316513023/WiNG_How_To_-_Wired_Wireless_Firewall.pdf

wing 5 how-to guide - test page for the nginx http server on epel

Documents