This repository has been archived by the owner on Jan 18, 2024. It is now read-only.
/
README.aruba
196 lines (149 loc) · 7.88 KB
/
README.aruba
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
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.