Wireless Access

Hi,

I have a controller with IDS enabled to fairly high.  I have enabled rogue containment, rogue classification and protect ssid enabled and added the ssids to the valid list.

So I have an IAP configured with some of the valid ssids and another random ssid which I plugged directly into the controller.

When I do a 'show wms ap list' it is showing the IAP as only being suspected-rogue, and only 20%.

'protect ssid' does work and I can see the client being tar-pitted though.

Any suggestions?

Thanks

Are u using Controller or an IAP? or an IAP connected as normal ap the controller?

Just clearify this issue in order for me to advise you with good tips

using controller with campus APs.

The instant is plugged into the controller and is my 'rogue' for testing.

you can configure the controllers to actively disable rogue AP's though I prefer to be alerted about it and then decide if I want to do anything to the rogue AP.  If setup properly you could send a deauth/auth flood to the rogue AP as well an ARP attack on the wired side.

Interferring are AP's that are not configured on your controller, but your AP's see them in the wireless spectrum but doesn't see them on the wired network. Suspected Rogue may be plugged into the network and are worth investigating. Rogue are plugged into your wired network and also providing wireless access. They should deifnately be looked into.

Assuming you have the WIPS licenses installed, you can use the wip wizard to configure what attacks to look for and how to deal with them.

Reference the Wireless Intrusion Detection section of the User Guide for detailed instructions and lots of good content on this.

yeah, I know and have done all that, but the problem is that it is only classified as suspected rogue, even though it is plugged directly into controller.

I can, and have manually reclassified, and the tar-pitting works fine.

This should happen automatically though.

Be sure your ARM profile configured to monitor.

(be sure that your controller - can see the segment of your rouge)

can u print out/screen shot your configurion of Rouge detetcion.IDS profile..please

---

@kdisc98 wrote:

Be sure your ARM profile configured to monitor.

(be sure that your controller - can see the segment of your rouge)

 

can u print out/screen shot your configurion of Rouge detetcion.IDS profile..please

---

yeah, the rogue is plugged into the controller, so can see :smileywink:

I think this is the profile you mean.

try this:

The easiest way to configure that is to run the WIP Wizard.

 The Wizard will give you the options to influence how rogues are classified.  How the controller automatically classifies rogues is here:  https://arubanetworkskb.secure.force.com/pkb/articles/FAQ/Rogue-Classification-on-AOS-6-0

You can configure something called a "Valid SSID" which means that the controller will allow devices to connect to that SSID.  You can then block traffic from connecting to anything but Valid SSIDs.

The controller normally looks at client associations to contain devices, so even if you can see powerful access points from far away, if the controller cannot see the client associating to it, it will not do anything.  If it can see your users attempting to associate to it, and you have protection on, it can stop those users, however.

You can define a specific SSID as a Valid SSID to keep it from being blocked.

Again, IDS/IPS is a very involved topic and you need to (1) Read the entire chapter on IDS/IPS to fully understand it and (2) Test any scenario before putting it into production so that you do not create any performance issues.

more info:

http://www.arubanetworks.com/techdocs/ArubaOS_61/ArubaOS_61_UG/New_WIP.php

Just to clarify, this is a lab setup and all APs/clients are in close proximity.  We are putting together a design for use in high security government environments.  At some stage they will be sending some penetration testers around to try to crack it and see the rogue containment in action.  I need to make sure it is working as it should, and the rogue containment must happen automatically without manual classification.

The protect-ssid thing is working and clients cannot attach to that valid ssid coming from the rogue.  I'm happy with that.

The rogue ssid in the instant is set to controller-assigned dhcp and traffic will be natted.  According to that kb link which says,

A device will only be automatically marked as a rogue if a gateway MAC has been seen in the wireless traffic coming from the device.

Is this the reason why it is not automatically classified as rogue?  So what about an ordinary home wireless router where the traffic is nat'd behind the wan ip, does that mean it is not classified as rogue?

Thanks

Is possible that is seeing that aruba BSSID as valid ?

Your IAP is almost certainly not marked as a full rogue, because there has been no wired side confirmation of the MAC. So yes, I think you're right.

BEWARE of course, if you change your test rig, if the IAP discovers the controller it will convert!!!

In the past, I always used something more dirty for these test processes. Cisco autonomous AP, Netgear or something like that.

Here's the main rule on the wire. Yes, one of the APs or AMs controlled by the detecting controller must "hear" the MAC of the rogue AP on the wired port. And further, what the system REALLY wants to see, is a MAC of a wireless client in the air on the rogue, and on the wire (on a "internal" VLAN) searching (ARPing) for a desitnation of an IP default gateway the same as the controlled AP knows about (by listening). The controller can't do this. In general deployments to achieve this, I put 1 or 2 dedicated AMs onto VLAN trunk/tagged links at core or distribution customer switches. This way, those AMs are able to classify the rogue properly for the solution.

Oh, by the way, look out for VRRP and HSRP considerations for this. There are options you can configure to tell the system to assume VRRPs and HSRPs are "interesting" (i.e are to be considered local VLAN gateway macs). Something like this might be needed (for hsrp)...

ids unauthorized-device-profile "default"
  allow-well-known-mac hsrp

It would be dangerous for the system to do this by default, as it may trigger false positives where your legitimate "neighbour" was also using hsrp on their LAN.

Hope this helps?

Thanks for the tips.  More testing is needed.

I'm kind of almost there, but will have a look again when in the office next.

:smileyhappy:

I have to agree with The.Rack.Monkey

Strong possibility the IAP MAC is not being seen on the wire and there is a chance that if it is, it is seen as a valid Aruba MAC OUI.

I've recently been 'playing' with RFProtect and had no issues replicating an automatic rogue containment and rogue client tarpit(attached).

release 6.2.1.2,

Aruba AP105 as AP and AM

netgear as rogue

Why would it matter if a rogue is seen with a 'valid' Aruba MAC OUI? If it's a rogue no matter what brand it should be detected and/or blocked. Surely you don't exclude all Aruba AP's/IAP/... from being rogues right?

---

@KoenV wrote:

Why would it matter if a rogue is seen with a 'valid' Aruba MAC OUI? If it's a rogue no matter what brand it should be detected and/or blocked. Surely you don't exclude all Aruba AP's/IAP/... from being rogues right?

 

---

Yes, I agree.  It's perfectly reasonable that an Aruba AP can be a rogue.

So I've tested some more and yes racking.monkey is correct.  The mac of the client needs to be on the wire.  Basically, when I changed the ssid on the IAP to be static or default, and connected a client, it was automatically contained and the IAP classified as rogue.

So unfortunately, for the vast majority of rogues that are just soho type wireless devices innocently plugged in, they won't get contained automatically cause the user traffic is nat'd behind that device.

Thanks everyone for the input.  Much appreciated.

:smileyhappy:

oops, double