Community Tribal Knowledge Base

Leveraging Centralized Encryption with Snort

Back to the future with this Airheads Online article from July 2007. 


One of the technical advantages of centralized encryption is that we have a mechanism to inspect all decrypted traffic as it traverses to or from the wireless network.  Of course, this is a key differentiator for Aruba, and it's something I always keep in mind when prototyping software as something we can do that our competitors cannot.  Recently, I had the opportunity to leverage this advantage in a project that continues to show how our architecture provides unparalleled security benefits by integrating the popular open-source Snort intrusion detection system (IDS) with the mobility controller.


Why Snort?
Snort is a powerful open-source IDS tool that is positioned as the "de facto standard for intrusion detection/prevention".  Deployed in many of our customer's networks, Snort is well-known for its powerful rules language and analysis features.  Using Snort, organizations can take advantage of community-developed IDS rules to identify attacks or compromised workstations through passive network monitoring. 


Users can also develop their own rules to identify attacks or even policy violations on the network.  For example, if an organization has a policy against the use of the BitTorrent peer-to-peer file sharing protocol, they can monitor their network with the following Snort rule:


alert tcp $HOME_NET any -> $EXTERNAL_NET 6881:6889 \
  (msg:"P2P BitTorrent transfer"; flow:to_server,established; \
  content:"|13|BitTorrent protocol"; depth:20;\
  classtype:policy-violation; sid:2181; rev:2;)



This rule can be described as follows:


 Token Description
alert  Whenever this rule is matched, following the reporting rocedures specified for alerts.
tcp $HOME_NET any -> $EXTERNAL_NET 6881:6889 This rule monitors TCP traffic originating in the list of networks defined as $HOME_NET (internal networks) with any source port, destined to traffic in the  EXTERNAL_NET (usually the inverse of $HOME_NET) on TCP ports 6881-6889.
(msg:"P2P BitTorrent transfer"; When an alert is raised, identify the alert with the string "P2P BitTorrent transfer".
flow:to_server,established; The rule will only alert when the flow of traffic is from the client to the server, and the TCP connection is in the established state (e.g. Snort has observed that the client and server have completed the TCP three-way handshake).


Once you get the hang of Snort rules, many find it to be a very powerful analysis mechanism that is effective at describing many different traffic patterns that characterize undesired event on the network.  More information on writing Snort rules is available in the "How to Write Snort Rules and Keep Your Sanity" guide available in the additional information section of this article.


Since Snort is widely recognized as a leader in wired IDS technology, and because it is an open-source project that anyone can contribute to, it was selected as the candidate for integration with the mobility controller.


Project Requirements
Before embarking on this task, I identified several project requirements or goals that would direct the project:

  1. The solution must mirror a copy of unencrypted wireless traffic to the wired IDS for analysis;
  2. The solution must facilitate monitoring of all wireless networks with a single wired IDS sensor, up to the bandwidth and capacity constraints of the networks being monitored;
  3. The solution must provide protective measures to enforce policy requirements for network usage by modifying the offending user's wireless privileges, or by stopping all network access;
  4. The solution should highlight strengths in our architecture that are not easily copied by competitors;
  5. The solution should have practical, tangible benefit for customers;
  6. The solution should be easy to deploy, monitor and troubleshoot;
  7. The solution should not cause an unreasonable performance burden on a mobility controller based on recommended deployment scenarios;
  8. If, at all possible, the solution should not require any code changes in ArubaOS to make it accessible to all customers with relatively current ArubaOS distributions.

In my lab, I established a network environment that was relatively simple, yet comparable to what I thought a production deployment of Snort and the mobility controller would look like, as shown below.


The area to be monitored by the Snort sensor is defined in the dashed box, essentially providing IDS monitoring for all wireless clients.  This highlights the strengths of centralized encryption, allowing organizations to monitor all wireless traffic with a single Snort sensor.  This is as opposed to the distributed encryption model, where the customer's network is exposed to a variety of attacks, as shown below.


In a distributed encryption model, the organization can deploy an IDS like Snort in a network distribution point like a wired switch, but they are unable to monitor any traffic that does not transition from the wired network to the distribution system and then to an upstream host.  This leaves organizations vulnerable to insider attacks, or any attacker within range of the wireless network when weak or no encryption is deployed on the WLAN.  Even vendors that manufacture wireless-specific IDS devices (WIDS) cannot meet this same level of monitoring, since their sensors are not an integral part of the data path which prevents them from having the knowledge of dynamic encryption keys, limiting their analysis to layer 1 and layer 2 only.


Monitoring Traffic
My next task was to identify a mechanism where the mobility controller could delivery a stream of unencrypted data frames to the Snort sensor for analysis.  Coming to my aid here was long-time Aruba champion Chris Geaghan who worked out a solution for me in about 15 minutes.  Much to my delight, ArubaOS includes a feature in the Firewall to mirror a copy of all decrypted frames processed by the mobility controller to a specified destination address, encapsulated in a GRE tunnel.  This was a great find, since it meant customers could use their existing deployments of ArubaOS to forward a copy of the traffic to a Snort sensor.


Leveraging Role Based Access Controls
The ability to monitor traffic from the wireless network with the Snort sensor is great, but we also wanted the ability to leverage our role-based access controls on the mobility controller based on Snort's analysis mechanisms.  This is effectively similar to a network admission control mechanism except that it uses passive analysis (provide by Snort) to grant or revoke access to network resources based on role privileges.

Again, the ability to integrate with an external system to modify the privileges granted to users on the network was already available in ArubaOS as part of the XML API.  Here, Aruba hero Greig Bannister came to my rescue with sample code and documentation on how to blacklist users or modify role assignments based on source IP or MAC address through HTTP/HTTPS POST verbs.  This mechanism provides the foundation to manipulate network access from a remote entry over a flexible and secure channel.


The Snort Piece
At this point, I have everything that is needed to meet all the goals of the project from an ArubaOS perspective; both the architecture and the software support the functionality needed for monitoring and protective measures.  The only remaining integration piece was to modify Snort to receive data from the mobility controller, and leverage the ArubaOS XML API to manipulate user permissions.


Snort Input
Using the ArubaOS feature to copy all decrypted traffic to a specified IP address gives Snort the ability to inspect a GRE-encapsulated packet stream.  Unfortunately, one of the missing features from Snort was the ability to inspect the contents of a GRE tunnel.  While Snort is capable of inspecting the outer IP header of the GRE traffic, and can examine any traffic inside the GRE tunnel based on specified byte patterns, it was unable to examine the inner IP header and payload contents using the standard Snort rule language.

Fortunately, the power of open-source software came to the rescue.  Because Snort is distributed under the GNU Public License, I was able to modify the source to add GRE tunnel analysis features, allowing Snort to inspect inner-IP frames as if it were just another frame.  I contributed this patch to the Snort team who gracefully accepted this feature and has since improved and integrated it into the mainline Snort distribution.  As of version 2.6.1 Beta 2, a Snort sensor can inspect and process the contents of GRE-encapsulated traffic using standard Snort rules, allowing Snort to inspect the traffic from the mobility controller.


Snort Output
With the ability to examine the unencrypted wireless traffic, the next piece was to allow Snort to manipulate user permissions on the mobility controller.  Snort includes extensive support for output plugins to satisfy the varied reporting requirements for Snort deployments.  Currently, Snort includes output plugins for the following reporting options:

 Output Option Description
Syslog Log using specified syslog facilities to a local or remote syslog service.
 Fast Writes a quick one-line format alert to a specified ASCII output file. 
Full Writes an ASCII file based on the source IP address and port combination with full packet headers.
Unix socket Writes alert information to a Unix socket that can be read and processed by other local processes.
TCPdump Copies the packet content that matches a rule to a libpcap file that can be processed with tools like TCPdump or Wireshark/Ethereal.
Database Sends snort data to a remote database using SQL.  Supports MS SQL Server, MySQL, PostgreSQL, Oracle, and ODBC databases.
CSV Logs data to a CSV-formatted file.
Unified Logs data to a binary data file for maximum reporting speed, compatible with the Barnyard processing tools bundled with Snort.
NULL Generates no logging for matching rule entries


Snort also allows users to specify multiple logging options, allowing a Snort deployment to capture TCPDump files locally, while reporting alerts over Syslog or any combination of supported output plugins.

The obvious solution to allow Snort to communicate with the mobility controller is to create a new output plugin that allows the administrator to specify an action to take on the mobility controller for a matching Snort rule. 


Fortunately, the API for writing Snort output plugins is well documented, and only took a few days to produce a new Snort plugin I named the "aruba_action" plugin.  Using this plugin, the Snort administrator specifies the IP address and secret key information for the mobility controller, and an action to take on the mobility controller for the Snort rule's matching source address. Currently, the available actions are:

  • Blacklist: Blacklist the user based on their source IP address
  • Set Role: Change the granted role permissions to a specified role name

After a few days of development, testing, debugging and documentation, I had a working deployment of Snort and an ArubaOS 2.5.2 mobility controller.  I submitted this new output plugin to the Snort team, who have made it available starting in Snort 2.6.1 Beta 2.


Deployment - Mobility Controller Configuration
Next, let's take a look at the deployment mechanics to integrate Snort and the mobility controller.

In order to send a stream of unencrypted frames to a Snort sensor, we need to configure the firewall session-mirror-destination feature with an access list that identifies the traffic to be mirrored, and a derivation rule that specifies the role for traffic mirroring.


An example is shown below that will mirror all traffic matching the SSID "foo" to the Snort sensor at

firewall session-mirror-destination ip-address
user-role testmirror
    user-role mirror-pol
ip access-list session mirror-pol
    any any any permit mirror
aaa derivation-rules user
    set role condition ssid equals "foo" set-value testmirror


Note that the Snort sensor does not need to exist at; rather, the routing of traffic to the host at (if it exists, or not) must be monitored by the Snort sensor.


Next, we need to configure the XML API with a shared secret that will be used to identify the Snort sensor.  An example is shown below that will allow the Snort sensor at to communicate with the mobility controller when it successfully identifies itself with the passphrase "pedantic":

aaa xml-api client
    key pedantic


Finally, configure the roles you want to use on the mobility controller for granting or revoking access permissions to end-users based on Snort alerts.  In our example, we'll use the "quarantine_role" to revoke access to all network resources except a single helpdesk server where users could presumably download patches or open a ticket to get assistance with restoring their network access privileges:

fdfuser-role quarantine_role
    session-acl quarantine_acl
ip access-list session quarantine_acl
    any host tcp 80 permit


That's it for the mobility controller configuration, next we'll look at the configuration of the Snort sensor.


Deployment - Snort Configuration

In order to take advantage of the GRE analysis capability and Aruba Action plugin you need to run Snort 2.6.1 Beta 2 or later.  Instructions on how to get this version of Snort and how to build it for Linux/Unix systems is available in the additional resource section of this article.  Note that the Aruba Action plugin is not built by default; you must pass the "--enable-aruba" argument to the "configure" script when compiling Snort.  Also specify the "--enable-gre" argument to enable the GRE analysis features recently added to Snort.  A Windows version of Snort with these features is planned when Snort 2.6.1 is released from Beta testing.


The configuration of Snort is based primarily on the snort.conf file.  For this example, we'll configure Snort to monitor the network for clients using BitTorrent, and modify their role assignment to the quarantine_role whenever the rule is triggered.
First, we'll create a new Snort rule type to use the Aruba Action plugin, and generate a syslog entry, as shown:



ruletype aruba_quarantine {
    type alert
    output alert_aruba_action: cleartext pedantic \
    output alert_syslog: LOG_AUTH LOG_ALERT



This entry will create a new Snort verb known as "aruba_quarantine".  Each rule configured with the aruba_quarantine verb will generate a syslog message and trigger the Aruba Action plugin, when the rule is triggered.


The configuration of the Aruba Action plugin takes several parameters:


 Configuration Token Description
 <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.
<secret type> 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).


Next, we specify a rule we want to use with the new Snort verb.  We can use any Snort rule, simply changing the default "alert" verb to "aruba_quarantine".  We'll also define the HOME_NET and EXTERNAL_NET variables here:



var HOME_NET []

aruba_quarantine tcp $HOME_NET any -> $EXTERNAL_NET 6881:6889 \
  (msg:"P2P BitTorrent transfer"; flow:to_server,established; \
  content:"|13|BitTorrent protocol"; depth:20; \
  classtype:policy-violation; sid:2181; rev:2;)




The sample snort.conf is shown in full below with an include directive to pull in the classification configuration file needed for the policy-violation identifier:



include classification.config
var HOME_NET []

ruletype aruba_quarantine {
    type alert
    output alert_arubaaction: cleartext pedantic \
    output alert_syslog: LOG_AUTH LOG_ALERT

aruba_quarantine tcp $HOME_NET any -> $EXTERNAL_NET 6881:6889 \
  (msg:"P2P BitTorrent transfer"; flow:to_server,established; \
  content:"|13|BitTorrent protocol"; depth:20; \
  classtype:policy-violation; sid:2181; rev:2;)


Using this configuration file, it's simply a matter of running Snort on the interface that will monitor the GRE-encapsulated traffic.  Portions of the output have been omitted for space:

# snort -c /etc/snort/snort.conf -i eth0
Running in IDS mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file /etc/snort/snort.conf

Rule application order: ->activation->dynamic->pass->drop->alert->log->aruba_quarantine
Log directory = /var/log/snort
Verifying Preprocessor Configurations!

+--[Pattern Matcher:Aho-Corasick Summary]----------------------
| Alphabet Size    : 256 Chars
| Sizeof State     : 2 bytes
| Storage Format   : Full
| Num States       : 21
| Num Transitions  : 40
| State Density    : 0.7%
| Finite Automatum : DFA
| Memory           : 11.79Kbytes

        --== Initialization Complete ==--

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.6.1.beta2 (Build 13)
   ''''    By Martin Roesch & The Snort Team:
           (C) Copyright 1998-2006 Sourcefire Inc., et al.




With this configuration in place, the Snort IDS will monitor all activity on the wireless network for BitTorrent traffic.  When found, Snort will tell the mobility controller to change the role of the wireless user, based on source address, to the quarantine_role.  The Snort administrator needs to only simply modify their Snort rules file to change the "alert" directive to "aruba_quarantine" for any Snort rules they want to enforce access control for.


Unfortunately, there isn't a tremendous amount of troubleshooting that can be done with Snort.  Running Snort in verbose mode displays the contents of each frame on the screen but does not indicate when the Aruba Action plugin is executed, or the status of the action unless the mobility controller returns an error status.  However, you know the author of the Aruba Action plugin, so feel free to contact me with any questions (be sure to send me your snort.conf file as well).


On the mobility controller, we have lots of troubleshooting options available to us.  Verify the configuration of the XML clients (the Snort sensor) with "show aaa xml-api" and "show aaa xml-api statitics".  In ArubaOS 2.5.2, the authmgr log is also helpful in identifying when Snort contacts the mobility controller, and the status of the response:

(Aruba200) #show log authmgr 2

Oct 3 16:34:35 :INFO:  Received XML-API command 'user_add' from
Oct 3 16:34:35 :INFO:  XML-API command 'user_add' (2) result=Ok, error=''

Attacks on wireless networks aren't limited to layer 1 or layer 2; insider attacks, preferred network list (PNL) attacks and open networks all expose clients to attacks that happen at the upper-layers of the OSI model.  Monitoring the network for these attacks on lightweight AM's isn't possible due to resource constraints and the nature of encrypted traffic; centralized encryption proves to offer another compelling advantage to organizations concerned about security.


If anyone has customers who would be interested in integrating a mobility controller with Snort, please let me know.


Additional Resources
"How to Write Snort Rules and Keep Your Sanity"

Getting Snort 2.6.1 Beta 2,

Various guides on setting up Snort and accompanying tools for multiple operating systems are available at

Version History
Revision #:
3 of 3
Last update:
‎02-03-2012 04:17 PM
Updated by:
Labels (2)
Search Airheads
Showing results for 
Search instead for 
Did you mean: 
Is this a frequent problem?

Request an official Aruba knowledge base article to be written by our experts.