Controller Based WLANs

Product and Software: This article applies to all Aruba controllers and ArubaOS versions.

A rogue AP is an unknown AP that has been connected (most likely using Ethernet) to your company's network. This AP might not have the best security settings configured, so it is important to detect it and inhibit it quickly to prevent unwanted access to your corporate network. Aruba systems perform all these tasks without the administrator having to manually mark a specific AP as a rogue or not.

Behind the Scenes  When the system detects a rogue, events similar to the following are generated (format may differ slightly depending on the ArubaOS version):

This means that the rogue AP with the SSID Maison and BSSID 00:0f:66:a3:32:a7 was detected by the AM 1.1.125 and that the MAC address that triggered this detection (see below for details) is 00:50:8d:f9:05:a6 with an IP 192.168.0.109. 

The question is how can the Aruba system determine that an AP is a rogue AP and not an interfering AP? 
Starting with ArubaOS 2.5.2.0, when the system has found a rogue AP, more information can be displayed from the CLI by issuing the following command:

Match Type: A picture of how the AP was classified as rogue. Possible values are "Eth-Wired-MAC", "AP-Wired-MAC", "Config-Wired-MAC", "External-Wired-MAC", "Base-BSSID-Override", "Manual", and "EMS". 

Match Method: How was the match made. Possible values are "Exact-Match" and "+1/-1 Match". 

Match Location: The location of the AM/AP that learned this rogue. 

Match Time: Time when the match was made. 

Helper AP BSSID:AP/AM that helped in classification. 

AM locations: All the AMs where the MAC was learned.

Rogue Detection Details

The Aruba AP constantly builds and updates an internal table of MAC addresses by collecting all MAC addresses on its Ethernet interface. This table is called the Ethernet wired MAC table. You can view this table by issuing the 'show am wired-mac <IP of Aruba AP> <Ethernet Mac address of Aruba AP>' command.

While the Aruba AP is up, it also constantly monitors wireless frames outgoing from other APs. As soon as a new AP is detected (regardless whether this AP is classified as Rogue / Valid / Interfering / KnownInterfering), the Aruba AP internally creates a separate table. To view this table, issue the 'show am wired-mac <IP of AM> <BSSID of detectedAP>' command. When an interfering AP is acting as L2 (that is, it does not route), it sends frames in the air with a src-mac that is the MAC address that originally sent the frame. The src-mac is in this case is different from the BSSID. This src-mac is used to populate this table.

One of the following conditions triggers the system to mark an AP as rogue: 

·    Eth-Wired-Mac       

Two scenarios would trigger a rogue detection based on Eth-Wired-Mac:         -     

An Aruba AP/AM detects that the same MAC is contained in both its Ethernet wired MAC table and in one of its non valid AP wired MAC table.         -     

When a nonvalid AP is acting as Layer 3 (with potentially NAT service enabled), it sends frames that have src-mac=BSSID, but more importantly that have BSSID=Ethernet MAC of the AP +/- 1. In this case, the Aruba AP checks whether a src mac either equals the BSSID +/-1 that can also be found in its Ethernet wired MAC table. If there is a match, rogue detection is triggered.

In our case, on the wired side, we have:

On the wireless side we have:

Notice that the MAC 00:50:8d:f9:05:a6 appears in both tables, which is what triggered the rogue detection.

It is very important to understand that this rogue classification method led us to have a nearly 100% confidence level in the assessment.

Starting with ArubaOS 2.5.3.4, to retain 100% confidence in the assessment, this behavior was changed slightly. From this release, the MAC that is used for doing the matches between the two tables also has to be the gateway MAC address. This change was made to avoid misclassifying APs as rogues. For example, a wired device that was connected to the customer network and then moved and connected to a disjoint network on the wired side would cause an AP in the disconnected network to be classified as a rogue. By using the gateway MAC address during matching, mobile wired devices are not misclassified as rogues.

•   AP-Wired-Mac

This method was primarily designed to support rogue detection in an environment where wireless connectivity was achieved by a third-party vendor. In these cases, these third-party vendors AP can no longer be used to gather wired MAC addresses on the Ethernet as an Aruba AP/AM would do. 

In this case, an Aruba AP/AM fills its AP wired MAC table by collecting MAC addresses of wired devices by monitoring the 802.11 traffic outgoing from valid APs (the third-party APs are marked as valid either through learning "wms ap-policy learn-ap enable" or by customer setting) under the condition that frame src-mac is not equal to frame BSSID. 

As previously, an interfering AP is marked as rogue when the Aruba AP finds the same MAC in the wired MAC table of one of its valid APs and in this interfering AP wired MAC table. 

Notes:

This mechanism has been extended to use rogue APs as learning agents. The premise is that if an AP is a rogue, then it is connected to the customer network. So if the MAC is present in a rogue AP wired-mac table and an interfering AP wired MAC table, then the interfering AP will be classified as a rogue.  ·    

This classification method can only work if the third-party vendor APs are working in Layer 2.  ·    

This classification method does not require that an Aruba AP be directly connected to all VLANs that are used by the third-party vendor AP.  ·    

This classification method might lead to a false positive in some very specific scenarios. That is why we have a new config option, 'wms ap-policy overlay-classification enable' to enable / disable the AP-wired-MAC matching method.

Here is an example of such a false-positive scenario:       -     

We have an interfering AP (AP-I) and a client (Client-A) associates to it.       -     

We have at least one other client associated to this same AP.       -     Client-A issues an ARP request. This ARP request is relayed by AP-I to other wireless clients. 

If the first packet the AM hears from Client-A is being transmitted by AP-I and not by Client-A (the AM could be too far away from Client-A for example), the AM classifies Client-A as a wired device and not as a wireless device. We would therefore add it to the wired MAC table of AP-I. We could potentially also add it to the Ethernet wired MAC table of the Aruba-AP, if it sees frames from it on the Ethernet side (we do not know that it is a wireless device and do not ignore them). 

If the same Client-A moves to another valid AP (call it AP-V) and we see a similar sequence of events, then we would classify this as a wired device and add it to the wired MAC table of AP-V. 

At this point, the same MAC address of Client-A would appear at the same time in the wired MAC table of AP-I and AP-V which would cause a false rogue classification of AP-I. 

Obviously, this false-positive scenario described here is much more likely to happen if SSIDs are configured in open mode. 

For example, if an AP-R is communicating to wired station with a MAC address of 33:33:33:33:33:33 and at the same time this MAC has been broadcasted in the air by a frame coming out of a valid AP (AP-V), then both the APs are on the same network and the system would classify AP-R as a rogue AP. 

Issuing the 'show wms rogue-ap <BSSID of the Rogue>' command reveals:  …  Helper-AP-BSSID = AP-V (This is the AP that actually helped finding out that AP-R was indeed a rogue) 

Match Type = AP-Wired-MAC  Match MAC available at:  show am wired-mac <am-ip> <AP-V>  show am wired-mac <am-ip> <AP-R>  ·    Base BSSID  This rather unlikely case happens when there are two neighboring networks with Aruba APs. If an Aruba AP is classified as a rogue, then all its virtual APs (that is, other SSIDs) will be classified as rogues as well. 

·    Config-Wired-MAC  This would happen when an Aruba AP/AM detects a match between a wired MAC table and a predefined MAC address that has been entered in the system manually by issuing the following command:

    MAC  This would happen when an Aruba AP/AM detects a match between a wired MAC table and a predefined MAC address that has been uploaded manually in the database by using the 'rap-wml' command. 

·    Manual  To manually designate an AP as a rogue, issue the following command: 

•    EMS  You can use the EMS to designate an AP as a rogue. 
•    Unknown  Previously classified entry in WMS database. 

Also, as soon as an AP has been classified as a rogue, any wireless station associating to it triggers the following syslog message.

Now, as you can see the Aruba AP is making the call as to whether a specific AP is a rogue or not based on the information it collects. However, in some circumstances, it is possible that Aruba AP 1 knows that MAC 1 is on the wired network and at the same time Aruba AP 2 knows that another non valid BSSID has relayed a frame on the air coming from this MAC 1. Since AP 1 and AP 2 do not share the same wired-tables database, neither of them will be able to determine that we have a rogue AP. To circumvent this issue, all Aruba APs detect MACs that are supposed to be gateways and send them to the Aruba switch. The Aruba switch pushes the information to all other Aruba APs. Gateway MACs are likely to be very few, so this communication does not create much traffic. Similarly, gateway MACs are used heavily, so rogue detection in this case should be very fast as well. 

For reference:  Wired MAC addresses that an AM/AP learns on the Ethernet interface are aged out after 15 minutes with a maximum of 2048 entries (for ArubaOS 2.5 and later).  Wired MAC addresses that are learned through other APs on the air are not aged out and each AP that ArubaOS monitors can store a maximum of 256 entries.