Wireless Access

Environment: 2 7210s in a master/local config, running 6.5.4.4-FIPS.

We've never really had a handle on WIPS, and I've been tasked with getting this set up. I've run through the GUI wizard a few times; created some match rules:

ids ap-classification-rule "High_db_1_AP"
   ssid "WqegFtMR22"
   ssid "testMachAuth"
   ssid "tfooJmtwSo"
   no match-ssids
   snr-min 60
   snr-max 100
   discovered-ap-cnt 1
   no check-min-discovered-aps
   conf-level-incr 25
!
ids ap-classification-rule "High_db_AtLeast2_APs"
   ssid "WqegFtMR22"
   ssid "testMachAuth"
   ssid "tfooJmtwSo"
   no match-ssids
   snr-min 60
   snr-max 100
   discovered-ap-cnt 2
   conf-level-incr 30
!
ids ap-classification-rule "High_db_AtLeast5_APs"
   ssid "WqegFtMR22"
   ssid "testMachAuth"
   ssid "tfooJmtwSo"
   no match-ssids
   snr-min 60
   snr-max 100
   discovered-ap-cnt 5
   conf-level-incr 40
!
ids ap-classification-rule "Low_Signal"
   ssid "WqegFtMR22"
   ssid "testMachAuth"
   ssid "tfooJmtwSo"
   no match-ssids
   snr-max 30
!
ids ap-classification-rule "Mid_dB_Multiple_APs"
   ssid "WqegFtMR22"
   ssid "testMachAuth"
   ssid "tfooJmtwSo"
   no match-ssids
   snr-min 30
   snr-max 60
   discovered-ap-cnt 2
   conf-level-incr 20                             
!
ids ap-classification-rule "Mid_Signal"
   ssid "WqegFtMR22"
   ssid "testMachAuth"
   ssid "tfooJmtwSo"
   no match-ssids
   snr-min 30
   snr-max 60
   discovered-ap-cnt 1
   conf-level-incr 10
!

The three SSIDs listed are valid in our enterprise. So these should match any SSIDs outside of these three, and add more confidence as the SNR increases.

But when I look in the security dashboard in the GUI, I'm seeing some of our valid enterprise APs being marked as Suspected Rogue, and others as Interfering. 

Meanwhile, I created a test WIPS policy that enables wireless containment with deauth-only (our main WIPS policy has containment disabled until we get this sorted out), and I've applied this test policy to a single AP near my testing area. 

I'm seeing containment events on this AP by valid clients:

Details show an AP Deauth Containment event with SSID:tfooJmtwSo; Channel 5; MAC:cc:3d:82:f5:f6:18

This is a valid SSID, and a valid client. The target of this event is listed as 9c:1c:12:f0:6a:51. If I look at this MAC in the WMS database, it's a valid AP:

# show wms ap 9c:1c:12:f0:6a:51

AP Info
-------
BSSID              SSID        Channel  Type     RAP_Type  Status  Ageout  HT-Type   HT-Sec-Chan
-----              ----        -------  ----     --------  ------  ------  -------   -----------
9c:1c:12:f0:6a:51  tfooJmtwSo  161      soft-ap  valid     up      -1      HT-40mhz  157
Probe Info
----------
MAC                IP           Name                   Type         Status  AP Type
---                --           ----                   ----         ------  -------
9c:1c:12:d3:87:b0  10.100.6.68  B1-F0-A028_FrontRm     soft-ap      up      135
9c:1c:12:f0:6a:50  10.100.6.26  B1-F0-A028_Datacenter  soft-ap      up      135
9c:1c:12:ac:cc:50  10.100.6.13  B1-F0-Hall_A028        air-monitor  up      135

So if this is a valid AP and a valid client, why is WIPS trying to contain it?

Unless I am mistaken, I think you are misinterpreting that.  It says there that it is a valid AP.

Whats the output of

show wms rogue-ap 9c:1c:12:f0:6a:51

#show wms rogue-ap 9c:1c:12:f0:6a:51

AP is not a rogue

That's why this is bizarre. The WMS sees this AP as valid, but it looks like it's doing deauth to it...

It does, however, appear to be seeing clients attempting to connect to this 'valid' AP as interfering:

#show wms client b8:8a:60:ed:13:72

STA Info
--------
MAC                Type         Status  Ageout  HT-Type
---                ----         ------  ------  -------
b8:8a:60:ed:13:72  interfering  up      -1      HT-40mhz
AP Info
-------
BSSID              SSID        Channel  Type     RAP_Type  Status  Ageout  HT-Type   HT-Sec-Chan
-----              ----        -------  ----     --------  ------  ------  -------   -----------
9c:1c:12:f0:6a:50  WqegFtMR22  161      soft-ap  valid     up      -1      HT-40mhz  157
STA Info
--------
MAC                Type         Status  Ageout  HT-Type
---                ----         ------  ------  -------
b8:8a:60:ed:13:72  interfering  up      -1      HT-40mhz
AP Info
-------
BSSID              SSID        Channel  Type     RAP_Type  Status  Ageout  HT-Type   HT-Sec-Chan
-----              ----        -------  ----     --------  ------  ------  -------   -----------
9c:1c:12:f0:6a:40  WqegFtMR22  5        soft-ap  valid     up      -1      HT-40mhz  1
Probe Info
----------
MAC                IP            Name                   Type         Status  AP Type
---                --            ----                   ----         ------  -------
9c:1c:12:d3:87:a0  10.100.6.68   B1-F0-A028_FrontRm     soft-ap      up      135
9c:1c:12:d3:87:b0  10.100.6.68   B1-F0-A028_FrontRm     soft-ap      up      135
9c:1c:12:d3:db:a0  10.100.6.19   B1-F0-A02E             soft-ap      up      135
9c:1c:12:d3:a2:a0  10.100.6.151  B1-F1-NEC_CONF         soft-ap      up      135
9c:1c:12:ac:e2:60  10.100.6.31   B1-F1-A112E            soft-ap      up      135
9c:1c:12:f0:6a:50  10.100.6.26   B1-F0-A028_Datacenter  soft-ap      up      135
9c:1c:12:f0:6a:40  10.100.6.26   B1-F0-A028_Datacenter  soft-ap      up      135
9c:1c:12:ac:c9:a0  10.100.6.152  B1-F1-A114             soft-ap      up      135
9c:1c:12:ac:cc:50  10.100.6.13   B1-F0-Hall_A028        air-monitor  up      135

That output doesn't show any containment happening.

Generally speaking, all clients are interferring, but I agree with you in that a client connected to a valid AP should be classified as valid rather than interferring.

So it would seem that something is definitely performing containment. Here is the security log from when I try to connect with my valid client (f0:d5:bf:5b:19:c2).

The one AP I'm using to test containment is in a separate AP group than the rest of the APs near me. The two AP groups are configured, for the most part, the same. The test group has an extra SSID on which I'm testing machine authentication. Also, the test group has containment turned on with 'deauth-only' as the containment method, while the regular enterprise AP group does not.

#show log security all | include 19:c2
Oct 9 08:57:37 :126035:  <22286> <WARN> |wms| |ids| AP(9c:1c:12:ac:cc:50@B1-F0-Hall_A028): Disconnect Station Attack: An AP detected a disconnect attack of client f0:d5:bf:5b:19:c2 and access point (BSSID 9c:1c:12:f0:6a:51 and SSID tfooJmtwSo on CHANNEL 161). SNR of client is 16. Additional Info: @^T▒{@^T▒\177Avg-Deauth-Disassoc-PktRate(pps):2.0; Interval(sec):10. Associated WVE ID(s): WVE-2005-0045, WVE-2005-0046, WVE-2005-0048.
Oct 9 08:57:38 :126102:  <22286> <WARN> |wms| |ids| AP(9c:1c:12:f0:6a:40@B1-F0-A028_Datacenter): AP Deauth Containment: An AP attempted to contain an access point (BSSID 9c:1c:12:f0:6a:42) by disconnecting its client (MAC f0:d5:bf:5b:19:c2) on channel 5.
Oct 9 08:57:39 :126102:  <22286> <WARN> |wms| |ids| AP(9c:1c:12:f0:6a:50@B1-F0-A028_Datacenter): AP Deauth Containment: An AP attempted to contain an access point (BSSID 9c:1c:12:f0:6a:52) by disconnecting its client (MAC f0:d5:bf:5b:19:c2) on channel 161.
Oct 9 09:12:00 :126102:  <22286> <WARN> |wms| |ids| AP(9c:1c:12:f0:6a:50@B1-F0-A028_Datacenter): AP Deauth Containment: An AP attempted to contain an access point (BSSID 9c:1c:12:f0:6a:51) by disconnecting its client (MAC f0:d5:bf:5b:19:c2) on channel 161.
Oct 9 09:12:00 :126102:  <22286> <WARN> |wms| |ids| AP(9c:1c:12:f0:6a:40@B1-F0-A028_Datacenter): AP Deauth Containment: An AP attempted to contain an access point (BSSID 9c:1c:12:f0:6a:41) by disconnecting its client (MAC f0:d5:bf:5b:19:c2) on channel 5.
Oct 9 09:12:42 :126035:  <22286> <WARN> |wms| |ids| AP(9c:1c:12:ac:cc:50@B1-F0-Hall_A028): Disconnect Station Attack: An AP detected a disconnect attack of client f0:d5:bf:5b:19:c2 and access point (BSSID 9c:1c:12:f0:6a:51 and SSID tfooJmtwSo on CHANNEL 161). SNR of client is 19. Additional Info: @^T▒{@^T▒\177Avg-Deauth-Disassoc-PktRate(pps):1.0; Interval(sec):10. Associated WVE ID(s): WVE-2005-0045, WVE-2005-0046, WVE-2005-0048.

As a test, I've reprovisioned the test AP back into the fold, and of course, all is working just fine. I need to get IDS and especially WIPS working for my job requirement, but I'm not making any progress while the system is containing valid SSIDs and clients!

I suggest you remove all those rules, or at least take out the ssids you have listed there.

If you want to contain unknown APs that are broadcasting your ssids, the correct place to do this is using the valid-ssid list in the unauthorised device profile.

ids unauthorized-device-profile <name>
    valid-and-protected-ssid <ssid>
     -
     -
     valid-and-protected-ssid <ssid>

So I guess the goal I had, was to categorize neighbor/interfering signals, increasing confidence levels based on signal strength, number of dectecting APs, etc. I thought I needed to tell it to not match on my enterprise SSIDs, but I suppose it makes sense that the system should be able to know which SSIDs are valid.

I will try making the changes you suggest, and re-test.

Thanks!

So I removed the SSID definitions from my ids-ap-classification-rules, and re-provisioned my test AP to the AP group that has that WIPS policy. I'm still seeing my valid AP and SSIDs being flagged for AP Deauth Containment...do I need to re-init the WMS database for the change to take effect?

 I've re-initialized the wms db, and it's still flagging the SSIDs in my AP group as flagging containment. 

Perhaps I need to start from scratch. What is the best method of configuring WIPS? Use defaults? I eventually want to use containment, but I want to roll it out slowly; in a separate AP group, while the main AP groups are configured with no containment.