Aruba Networks Integration ========================== Joshua Wright <jwright@arubanetworks.com> 05-SEP-2006 -- Overview -- As a centralized-processing wireless transport system, an Aruba Networks Mobility Controller (MC) has visibility into all wireless traffic including dynamic encryption keys. This architecture allows users to easily integrate with Snort for centralized monitoring of all wireless network traffic. In addition to traffic reporting capabilities, an Aruba Networks MC can enforce dynamic role-based access controls to restrict or limit accessibility into the network. When integrated with Snort's powerful rules language functionality, users can dynamically modify access permissions to the wireless network based on any matching rules. This allows an administrator to blacklist a user if their workstation appears to be infected with a worm, or limit access to network resources if spyware is detected, or any of several configuration possibilities. The ability to modify a user's role (and by association, access permissions) or to blacklist a user is provided in the alert_aruba_action output plugin. This document describes the features, implementation and configuration of this output plugin. -- Features -- The alert_aruba_action output plugin allows a Snort administrator to create custom rule types that modify the access permissions for wireless users when triggered. By configuring an Aruba MC to mirror all wireless traffic to a designated Snort box, Snort can assess all wireless traffic and interact with the Aruba MC to quarantine problematic sources within the network. Using the alert_aruba_action output plugin, an administrator can specify the action to take when a specified alert is triggered: blacklist: When a Snort alert is triggered, the source IP address becomes blacklisted on the Aruba MC, stopping all wireless access for the station. setrole: When a Snort alert is triggered, the source IP address has their role changed from the currently derived role to one of the administrator's choosing. This is often deployed as a "quarantine role", where restricted access is granted to the network for the station. -- Implementation -- In order to use this plugin effectively, the Aruba MC must be able to mirror a copy of wireless traffic to a Snort sensor as a directly connected (SPAN port) station, or the termination endpoint of a GRE tunnel (see Configuration for details). Also, the Snort sensor must be able to reach the Aruba MC on TCP/80 to blacklist or modify the role assignments for users. -- Configuration -- Configuration requires modification to the snort.conf file for the alert_aruba_action plugin, as well as configuration statements on the Aruba MC to authenticate Snort when changing client access permissions. The Snort sensor and the Aruba MC share a secret passphrase for authentication, and the Aruba MC must specify the source IP address of the Snort sensor. --- alert_aruba_action --- The configuration options are described below: * <controller address> * Specifies the IP address or hostname of the Aruba MC that will be responsible for modifying user role assignments, or blacklisting users. Mandatory. * secrettype * Specifies the type of secret used for the Snort sensor to authenticate to the Aruba MC, one of: sha1 - The shared secret, represented as a SHA1 hash. You can generate this string with the openssl tool as "echo password | openssl dgst -sha1", changing the string "password" to the shared secret string. md5 - The shared secret, represented as a MD5 hash. You can generate this string with the openssl tool as "echo password | openssl dgst -md5", changing the string "password" to the shared secret string. cleartext - The shared secret in plaintext. * secret * Specified the secret shared between the Snort sensor and the Aruba MC. Must be represented to match the secret type setting (SHA1, MD5 or cleartext). * action * Specifies the action that the Aruba MC will take against the source MAC address of the station reported by the Snort sensor, one of: blacklist - Terminate all network access for the wireless user, placing them on the blacklist. Station will be unable to access the wireless network until the blacklist duration expires. setrole:<rolename> - Modify the user's role assignment to the specified role name. The new role can be configured to restrict or grant access to the network as needed by the administrator. Example: In this example snort.conf file, we create a new rule type that has two output mechanisms; a local syslog entry and an Aruba action command: ruletype aruba_quarantine { type alert output alert_aruba_action: 172.16.0.252 cleartext foo setrole:snort_quarantine output alert_syslog: LOG_AUTH LOG_ALERT } Once the new rule type is created, the Snort administrator can specify the Snort rules that will take this action. For example, if the organization wants to prohibit the use of the ICQ chat protocol, we can use the following snort.conf entry to complete the output actions in the aruba_quarantine rule specified above: aruba_quarantine tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CHAT ICQ access"; flow:to_server,established; content:"User-Agent|3A|ICQ"; classtype:policy-violation; sid:541; rev:9;) --- Aruba MC --- In order to accept role change commands and blacklist events from the Snort sensor, the Aruba MC must be configured to recognize the Snort sensor by IP address and through the shared secret. The Aruba MC must also be configured with the appropriate roles if the alert_aruba_action plugin is configured with the "settype" action; the blacklist action is always available and does not require additional configuration. The following example configures the Aruba MC to accept role changes or blacklist events from the Snort sensor at 10.10.10.10 using the shared secret "pedantic": (Aruba200) >en Password:******** (Aruba200) #configure terminal Enter Configuration commands, one per line. End with CNTL/Z (Aruba200) (config) #aaa xml-api client 10.10.10.10 (Aruba200) (ecp-client) #key pedantic (Aruba200) (ecp-client) #end (Aruba200) #copy running-config startup-config You can verify the configuration using the "show aaa xml-api" commands: (Aruba200) #show aaa xml-api clients XML-API Client Configuration ---------------------------- IP Key ----------- --- 10.10.10.10 ***** 172.16.0.106 ***** (Aruba200) #show aaa xml-api statistics XML-API Statistics ------------------ Statistics 10.10.10.10 ---------- ----------- user_authenticate 0 (0) user_add 0 (0) user_delete 0 (0) user_blacklist 0 (0) user_query 0 (0) unknown user 0 (0) unknown role 0 (0) unknown external agent 0 (0) authentication failed 0 (0) invalid command 0 (0) invalid message authentication method 0 (0) invalid message digest 0 (0) missing message authentication 0 (0) missing or invalid version number 0 (0) Cant use VLAN IP 0 (0) Invalid IP 0 (0) Packets received from unknown clients : 0 (0) Packets received with unknown request : 0 (0) Requests Received/Success/Failed : 0/0/0 (0/0/0) Also ensure that any roles specified with the "setrole:rolename" action exist on the Aruba MC: (Aruba200) #show configuration | include snort_quarantine user-role snort_quarantine For additional information on configuring the Aruba MC, please see the ArubaOS Reference Guide or contact Aruba Customer Support.