Configuration Guide for RFMS 3.0 Initial Configuration. WiNG 5 How-To Guide. Role-Based Firewall. June 2011 Revision 1.0

Transcription

1 Configuration Guide for RFMS 3.0 Initial Configuration XXX-XXXXXX-XX WiNG 5 How-To Guide Role-Based Firewall June 2011 Revision 1.0

2 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 Motorola, Inc. All rights reserved.

3 Table of Contents: 1. Introduction: Overview: Distributed Stateful Inspection: Role Based Firewall Components: Use and Configuration: Scenario Scenario Verification Troubleshooting Reference Documentation:...30

4 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: 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.

5 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.

6 User Roles to Security Policies User Role Default Engineering Sales Guest Location Location Location Location Group Membership Group Membership Group Membership Group Membership Hot-Spot State Hot-Spot State Hot-Spot State Hot-Spot State Encryption Encryption Encryption Encryption Authentication Authentication Authentication Authentication SSID SSID SSID SSID MAC-Address MAC-Address MAC-Address MAC-Address Inbound ACLs Inbound ACLs Inbound ACLs Inbound ACLs ACL ACL ACL ACL ACL ACL ACL ACL Security Policies 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.

7 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-ofconfiguration. 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)

8 2.1 Scenario 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

9 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 prefer use role-policy firewalled-users logging on service pm sys-restart rfs4000(config-profile-default-ap650)# commit write 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

10 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.

11 Web-UI: Adding ACL Rules Role Policy Creation Next, navigate to Configuration > Security > Wireless Client Roles and click on Add to create a new role policy:

12 Web-UI: Role Policy Configuration Name the role policy and then click Add to begin adding match criteria for the user role:

13 Web-UI: Role Policy Configuration WiNG 5 Role-Based Firewall How-To Guide

14 Web-UI: Role Policy Configuration 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

15 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:

16 Web-UI: Default Firewall Rules 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:

17 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 groupmembership 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

18 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

19 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

20 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 administratorinput. 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

21 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:

22 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:

23 Web UI: AAA Policy WiNG 5 Role-Based Firewall How-To Guide

24 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.

25 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:

26 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:

27 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 B8-5C Wireless Clients not matching any Role: 1C-4B-D6-55-D0-2C 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:

28 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:

29 1) CLI Role Policy Verification ap650-85cd9c#show wireless client MAC IP VENDOR RADIO-ID WLAN VLAN STATE B8-5C Intel Corp 64 Data-Ready CD-9C:R1 vlan64-wlan Total number of wireless clients displayed: 1 ap650-85cd9c#show wireless client detail B8-5C ADDRESS USERNAME WLAN ACCESS-POINT RADIO-ID RADIO-NAME STATE CLIENT-INFO SECURITY DATA-RATES MAX-PHY_RATE : B8-5C B8-5C (vlan:64) : user2 : vlan64-wlan (ssid:vlan64) : Name:ap650-85CD9C Location:Gilbert, AZ : CD-9C:R1, alias ap650-85cd9c:r1 : radio1 Bss: BA-11 : Data-Ready : bgn, vendor: Intel Corp : Authentication: eap Encryption: ccmp : mcs0-15 : 300 M MAX-USER_RATE : 225 M n : Short guard interval: Y Channel width (capability: 40Mhz Current: 40Mhz) usec QoS POWER-MGMT ACTIVITY : AMSDU Max-Size: 7935 AMPDU Max-Size: AMPDU Min-Spacing: 0 : WMM: Y Type: Non Voice : PS-Mode: N Spatial-Multiplexing-PS: off WMM-PS/U-APSD: Disabled : Last Active: 00:00.00 ago SESSION INFO : Session Timeout: 0 days 06:08.00 Idle Timeout: 00.:30.00 RF-DOMAIN MCAST STREAMS : ROLE : default : fw-role/firewalled-users ap650-85cd9c#

30 5. Reference Documentation: Description WiNG 4 Wired / Wireless Firewall Role Based Firewall Location _Wired_Wireless_Firewall.pdf WiNG 5 Functional Spec