Aruba Networks Integration==========================Joshua Wright <jwright@arubanetworks.com>05-SEP-2006-- Overview --As a centralized-processing wireless transport system, an Aruba NetworksMobility Controller (MC) has visibility into all wireless traffic includingdynamic encryption keys.  This architecture allows users to easily integratewith Snort for centralized monitoring of all wireless network traffic.In addition to traffic reporting capabilities, an Aruba Networks MC can enforcedynamic role-based access controls to restrict or limit accessibility into thenetwork.  When integrated with Snort's powerful rules language functionality,users can dynamically modify access permissions to the wireless network basedon any matching rules.  This allows an administrator to blacklist a user iftheir workstation appears to be infected with a worm, or limit access tonetwork resources if spyware is detected, or any of several configurationpossibilities.The ability to modify a user's role (and by association, access permissions) orto blacklist a user is provided in the alert_aruba_action output plugin.  Thisdocument describes the features, implementation and configuration of thisoutput plugin.-- Features --The alert_aruba_action output plugin allows a Snort administrator to createcustom rule types that modify the access permissions for wireless users whentriggered.  By configuring an Aruba MC to mirror all wireless traffic to adesignated Snort box, Snort can assess all wireless traffic and interact withthe Aruba MC to quarantine problematic sources within the network.Using the alert_aruba_action output plugin, an administrator can specify theaction 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 acopy of wireless traffic to a Snort sensor as a directly connected (SPAN port)station, or the termination endpoint of a GRE tunnel (see Configuration fordetails).  Also, the Snort sensor must be able to reach the Aruba MC on TCP/80to blacklist or modify the role assignments for users.-- Configuration --Configuration requires modification to the snort.conf file for thealert_aruba_action plugin, as well as configuration statements on the Aruba MCto authenticate Snort when changing client access permissions.  The Snortsensor and the Aruba MC share a secret passphrase for authentication, and theAruba 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 responsiblefor modifying user role assignments, or blacklisting users.  Mandatory.* secrettype *Specifies the type of secret used for the Snort sensor to authenticate to theAruba 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.  Mustbe represented to match the secret type setting (SHA1, MD5 or cleartext).* action *Specifies the action that the Aruba MC will take against the source MACaddress 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 outputmechanisms; 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 theSnort rules that will take this action.  For example, if the organization wantsto prohibit the use of the ICQ chat protocol, we can use the followingsnort.conf entry to complete the output actions in the aruba_quarantine rulespecified 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 Snortsensor, the Aruba MC must be configured to recognize the Snort sensor by IPaddress and through the shared secret.  The Aruba MC must also be configuredwith the appropriate roles if the alert_aruba_action plugin is configured withthe "settype" action; the blacklist action is always available and does notrequire additional configuration.The following example configures the Aruba MC to accept role changes orblacklist events from the Snort sensor at 10.10.10.10 using the shared secret"pedantic":(Aruba200) >enPassword:********(Aruba200) #configure terminalEnter 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-configYou can verify the configuration using the "show aaa xml-api" commands:(Aruba200) #show aaa xml-api clientsXML-API Client Configuration----------------------------     IP       Key     -----------   ---     10.10.10.10   *****     172.16.0.106  *****(Aruba200) #show aaa xml-api statisticsXML-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 existon the Aruba MC:(Aruba200) #show configuration | include snort_quarantineuser-role snort_quarantineFor additional information on configuring the Aruba MC, please see the ArubaOSReference Guide or contact Aruba Customer Support.