03-16-2020 02:51 PM
What is the best configuration for an environment where I have a ssid for visitors? They are employees who can access this network and anyone else who accesses the organization.
Do I consider sanctioned customers, through a rule, those who connect to this ssid?
I am doing it this way, but this way when a client connects to another network, for example, I receive alarms informing that a sanctioned client has connected to another non-sanctioned network.
But I don't want to have this level of control over clients who connect to the visitor network.
Solved! Go to Solution.
03-16-2020 03:45 PM
Casimiroir,
“What is the best configuration for an environment where I have a ssid for visitors? They are employees who can access this network and anyone else who accesses the organization.“
You have an SSID that is designated for employees but they are visitors? I need clarification on this statement.
“Do I consider sanctioned customers, through a rule, those who connect to this ssid?”
The only time you should sanction a client is if they are a trusted device - typically meaning they are an employee’s device or some other device that is under your management/control.
But yes, you can create a Device Action Manager rule that will automatically Sanction client devices, but you only want to do this for employee/company devices. You can also import a CSV file of the client MACs, or you can setup a rule that sanctions the clients based on polling of a wireless controller.
“I am doing it this way, but this way when a client connects to another network, for example, I receive alarms informing that a sanctioned client has connected to another non-sanctioned network.”
This would be expected behavior if you are sanctioning non-employee devices. What’s happening is that AirDefense is then seeing what is now a sanctioned client connecting to an SSID that doesn’t belong to you (because they aren’t employees and are connecting to non-corporate networks - which would be normal behavior for them.
“But I don't want to have this level of control over clients who connect to the visitor network.”
How you normally setup a true Guest network is you continue to sanction the guest BSS, but in the Security Profile that you create for the guest SSID and assign to the guest BSS’s, you check the box that says that non-sanctioned clients are allowed to connect. This will prevent AirDefense from thinking that these guest unsanctioned clients are Rogue clients when they connect to your Sanctioned Guest BSS.
Bottom line, sanction your APs and create the necessary Security Policies for them based on the SSIDs. If you have 5 SSIDs, you’ll have to create 5 Security Profiles. Then ensure that the appropriate security profile is assigned to the BSS’s.
For the client side, you then want to somehow sanction (there are multiple methods) only *your* client devices. You can either specify that a client device is okay to use any SSID in your security profiles (Sanction Inherit)...or just specific ones (Sanction Assign)
03-17-2020 01:49 PM
Yes, ssid "777" is still from the previous solution that is being disabled. I had created a profile security to avoid these alarms and I disabled it today because I imagined that the "777" network was no longer in use. I believe that in the next few days we will not have it anymore. Likewise, the two "siemens".
Thank you.
03-17-2020 01:35 PM
The CTS Flood and NAV Attack alarms are most certainly false positives (detection mechanisms will undergo tweaking very soon) so you can ignore those (I would actually disable those alarms for now).
The Rogue Client on Switch alarm is for a Zebra client device that is using SSID “777”. Does this SSID sound familiar? Do you have any Zebra client devices? This alarm still shows active. This one warrants attention.
Two Rogue AP on Switch alarms: These are APs that have been classified as neighboring….so I’m assuming that they are then not your APs. These APs have been detected via a switch port scan. Look in the alarm details to see what switch the AP was found on (I think the details also list the port as well) and then check the switch to see if it’s still there.
The Impersonation Attack you see in Forensics is due to a wireless seen operating as both an AP and a client. This isn’t expected behavior for 99% of devices out there….but there are *some* legitimate cases where this is expected. You have this classified as a Sanctioned device so I would try to understood who/what it is first...and that will likely tell you WHY it might be behaving this way.
03-17-2020 01:24 PM
Ops… I didn't remember the forensic analysis. There is good documentation there .…
03-17-2020 01:14 PM
Great. I configured my guest network as suggested and now the behavior of the alarms is according to plan.
I have only these alarms below. I remember that this wireless network infrastructure is in a factory environment.
Any help finding documentation of the cause and how to mitigate these alarms, even if they are false positives?