Roque AP in the same backhaul and in-net

  • 6
  • Question
  • Updated 4 years ago
  • Answered
I have a WIPS question; for the last 3 months now the WIPS is reporting daily a few AP's of neighboring buildings as rogue AP's detected in the same backhaul and in-net.
The AP's are indeed rogue (because of not an AH MAC OUI), but definitely not in the same backhaul/in-net.
Is anybody experiencing the same?
thx,
M
Photo of Marcel

Marcel

  • 14 Posts
  • 1 Reply Like

Posted 5 years ago

  • 6
Photo of Brian Ambler

Brian Ambler

  • 245 Posts
  • 126 Reply Likes
Hello Marcel,

If WIPS is detecting that a Rogue AP is In-net, it means that the reporting Aerohive device has detected the MAC address of the rogue AP in its MAC learning table. In order for a MAC address of the rogue AP to be in the reporting device's MAC learning table it would need to be seen on the same L2 broadcast domain as the Aerohive device. So if you are seeing rogue, In-net, APs that you don't believe to be In-net, I would recommend running a network discovery tool such as Nmap to attempt to locate it on your network. I would recommend running nmap with a -sP or -sn switch (depending on the version of Nmap installed) to locate hosts on your network, details below:

Example:
If the Rogue AP is being detected as In-net on VLAN 30 (10.30.1.0/24), then I would recommend the following nmap switch be run from a device on VLAN 30:

nmap -sn 10.30.1.0/24

From the Nmap manual (http://nmap.org/book/man-host-discove...)
sn (No port scan)
This option tells Nmap not to do a port scan after host discovery, and only print out the available hosts that responded to the scan. This is often known as a “ping scan”, but you can also request that traceroute and NSE host scripts be run. This is by default one step more intrusive than the list scan, and can often be used for the same purposes. It allows light reconnaissance of a target network without attracting much attention. Knowing how many hosts are up is more valuable to attackers than the list provided by list scan of every single IP and host name.

Systems administrators often find this option valuable as well. It can easily be used to count available machines on a network or monitor server availability. This is often called a ping sweep, and is more reliable than pinging the broadcast address because many hosts do not reply to broadcast queries.

The default host discovery done with -sn consists of an ICMP echo request, TCP SYN to port 443, TCP ACK to port 80, and an ICMP timestamp request by default. When executed by an unprivileged user, only SYN packets are sent (using a connect call) to ports 80 and 443 on the target. When a privileged user tries to scan targets on a local ethernet network, ARP requests are used unless --send-ip was specified. The -sn option can be combined with any of the discovery probe types (the -P* options, excluding -Pn) for greater flexibility. If any of those probe type and port number options are used, the default probes are overridden. When strict firewalls are in place between the source host running Nmap and the target network, using those advanced techniques is recommended. Otherwise hosts could be missed when the firewall drops probes or their responses.

In previous releases of Nmap, -sn was known as -sP.


This will output something like the following:

Hyperion:~ bambler$ sudo nmap -sn 10.30.1.0/24

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-21 01:35 PDT
Nmap scan report for 10.30.1.1
Host is up (0.035s latency).
MAC Address: 08:EA:44:XX:XX:XX (Aerohive Networks)
Nmap scan report for 10.30.1.5
Host is up (0.045s latency).
MAC Address: 08:EA:44:XX:XX:XX (Aerohive Networks)
Nmap scan report for 10.30.1.10
Host is up (0.038s latency).
MAC Address: XX:XX:XX:XX:XX:XX (Unknown)
Nmap scan report for 10.30.1.20
Host is up (0.0018s latency).
MAC Address: XX:XX:XX:XX:XX:XX (VMware)
Nmap scan report for 10.30.1.21
Host is up (0.0045s latency).
MAC Address: XX:XX:XX:XX:XX:XX (Unknown)
Nmap scan report for 10.30.1.50
Host is up (0.0048s latency).
MAC Address: XX:XX:XX:XX:XX:XX (Hewlett-Packard Company)
Nmap scan report for 10.30.1.60
Host is up (0.022s latency).
MAC Address: XX:XX:XX:XX:XX:XX (VMware)
Nmap scan report for 10.30.1.100
Host is up (0.0017s latency).
MAC Address: XX:XX:XX:XX:XX:XX (LG Electronics)
Nmap scan report for 10.30.1.253
Host is up (0.0062s latency).
MAC Address: E0:1C:41:XX:XX:XX (Aerohive Networks)
Nmap scan report for 10.30.1.254
Host is up (0.0062s latency).
MAC Address: 08:EA:44:XX:XX:XX (Aerohive Networks)
Nmap done: 256 IP addresses (10 hosts up) scanned in 6.68 seconds


More information on WIPS can be found in the Aerohive Help System here, with the section detailing detecting In-net Rogue APs excerpted below:

Determine if detected rogue APs are in the backhaul network

You can use this option in combination with other WIPS techniques to determine if a detected rogue AP is in the same network as compliant APs. Knowing whether a rogue AP is in the same network can help you decide the urgency of your response.

An Aerohive AP builds a MAC learning table from source MAC addresses in the broadcast traffic it receives from devices in its Layer 2 broadcast domain. When an Aerohive AP running HiveOS 5.0r2 or later detects a rogue AP through any of the rogue detection mechanisms in the WIPS policy, it checks its MAC learning table for an entry within a 64-address range above or 64-address range below the BSSID of the invalid SSID. If there is a match, it is assumed that both MAC addresses belong to the same device. Because one of its addresses is in the MAC learning table, the rogue is considered to be in the same backhaul network as the detecting AP and "In Net" appears in the In Network column for that rogue in the list of rogue APs. You can then take the appropriate steps to mitigate the rogue. If there is no match, then nothing appears in the In Network column for that entry.

To enable the mechanism for determining if rogue APs are in the same network as an AP, select the check box. To disable it, clear the check box.
Photo of Marcel

Marcel

  • 14 Posts
  • 1 Reply Like
Hello Brian,
Thanks for your reply.
I am having the nmap scanner standby when I receive another (email)warning about it. The network concerned is small enough to know for sure that the reported in-net roque AP is not connected.
I will let you know the results, thx!
Photo of Brian Ambler

Brian Ambler

  • 245 Posts
  • 126 Reply Likes
Hi Marcel,

Thanks for the update, I will await your reply.
Photo of Marcel

Marcel

  • 14 Posts
  • 1 Reply Like
Hi Brian,
I did a scan on 2 occasions when I received an email alert;
Attached is 1 screenshot.
nmap doesn't show any mac addresses from the rogue AP range.
Photo of Joel

Joel

  • 9 Posts
  • 0 Reply Likes
I've been having this same problem also. I can't see how my APs would have the MAC address of this rogue in their tables, as it's a BelAir Networks metro AP. I doubt the AP would ever join my network as a client. Is there a bug somewhere that needs to be addressed?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I suspect the feature is buggy as I see erroneous entries frequently.
Photo of JimmyBoJingle

JimmyBoJingle

  • 9 Posts
  • 3 Reply Likes
The idea is, if there is a MAC address very close in range to the BSSID of a reported rogue, this indicates that AP has a physical connection into your back-haul (wired) network. Indicating someone has connected a rogue AP into your network, offering their own WiFi off your network.
Photo of JimmyBoJingle

JimmyBoJingle

  • 9 Posts
  • 3 Reply Likes
I am also seeing incorrect results for Rogue APs being reported as In-Net when they do not appear to be. The documentation states it will check it's MAC learning table for addresses that match 64 addresses above or below as the trigger for a rogue AP. I think this is where the bug lies, that its checking for MAC addresses outside of that 64 range.

For instance I see a reported in-net rogue AP as having a BSSID of:

001E1302A890

I don't see how to just look at the MAC table on an AP, only the ARP table. If i look at that the closest results I get are:

001e:c955:4a91
001e:c600:1904
001e:c600:184b

Which are obviously way outside the range of 64 addresses. They don't even match the full OUI, just the first 4 hex numbers. Looking at the MAC table on my switches, I see the same thing. No where near a close match.
Photo of JimmyBoJingle

JimmyBoJingle

  • 9 Posts
  • 3 Reply Likes
I spoke with tier2 at AeroHive and mentioned there a few ways a rogue AP will get classified as in-net. If the AP is on the same channel, using the same IP range, or has clients connected it will also flag it as in-net.

Appears that's what was happening in my case, that BSSID did have active clients.