In Part 1 of my Cisco wIDS/wIPS adventure, found here, I covered trying to scale and scope what it is you need before trying to purchase a Cisco wIDS/wIPS. If you haven’t read that one, you should go do that now and then move on to Part 2, the link is at the end of Part 1.
In Part 2, I covered how the information flows within the Holy Trinity and lessons learned that I think better explain what’s going on so when you tackle this mess you don’t waste as much time as me. Assuming you got to Part 3 by reading Part 1 and skipping Part 2 somehow, it’s located here and I suggest you give that a glance before continuing.
OK – on to Part 3! By this point you should have a WLAN that is up and running and passing traffic (admit it, videos of cats and people doing dumb stuff is much more fun than this so I hope got that working already) as well as a somewhat functioning Cisco Prime Infrastructure (here on out referred to as CPI, or “Sub-Prime” by a certain individual that will remain anonymous) and now a nice shiny new MSE with some expensive licenses and and not much else going on. Feeling a little angry and cheated? Good, that’s how I felt as well. Now that your MSE is up and running, go ahead and forget about it for a while, it’s job is done.
We now get to work on CPI and the myriad of things it does. I’m going to dangle the carrot here a second and show you what you are hoping happens if all goes well. On CPI navigate to the menu and go to “Dashboard –> Wireless –> Security.” What you want to see is something that looks like this:
Now, what shows up on your page will either be nothing (because you haven’t finished configuring it) or hopefully something similar to the image on the right, because you haven’t tuned your system to match what I did. Different environments should have different alert profiles. Ideally, what you will see here is a whole host of alerts that then allow you to fine tune the alerts down based on the fine security policy that you created in Part 1. If not, I will get to that in a minute. If you don’t see any alerts, let’s get to work on CPI to get you something pretty to show management, and more importantly the project manager so they will leave you alone!
Navigate to the menu on CPI and go to “Services –> Mobility Services –> Mobility Services Engines.” On this screen you should see your new shiny MSE listed with a name, device type, IP address, version, reachability and then the services running on it. If no servers are listed, look in the upper right corner and using the drop down select “Add Mobility Services Engine” and select go. After walking through the steps, and assuming you wrote down the information from the installation correctly, it should add the MSE to this page and give you a reachability status of “Reachable.” If it’s not reachable check your firewall configurations (remember from Part 2?) or MSE configuration. Remember, these 2 servers were designed to talk to each other and want to communicate so it’s not like you are linking an Apple product to your Windows laptop. Also, from this screen, you can click on the device name (highlighted with blue letters) and it will take you to the MSE GUI log-in screen. This helps when others want to access the MSE GUI later. Don’t ask me why, my boss is nosy and yours might be as well.
Next step is to synchronize the MSE with the WLC’s. Not sure why you do it from CPI, but it’s where you do it. In Part 2 I showed you what it looks like when the synchronization is working, this is how you do it as well as what to do when it doesn’t work. Top tip, it won’t show as working the first time so don’t panic.
On CPI navigate to “Services –> Mobility Services –> Synchronize Services.” The first page that will appear will be the maps and buildings that you may or may not have built in CPI. These are used for your other MSE (or CMX) and aren’t applicable here. Don’t panic just look in the grey box on the left hand side and pick the second entry down, “Controllers.” This will pull up a list of all network devices that CPI has identified on your wired network that report themselves as controllers. I personally have some WLC’s that I think of as controllers(3504, 8510) and then some 3850 and 4507 catalyst switches listed as well. If you have some weird issues with your WLAN infrastructure, looking here might give you some places to start figuring out why you have a Catalyst 3850 that still thinks it’s a WLC. Luckily I have a couple of wired networking guys that help me with this, you might not be as lucky.
Anyways, select the controller(s) that you want to actually use by checking the box on the left side of it’s name and at the bottom of the list, select “Change MSE Assignment.” This process might need to be repeated in the future and is handy when troubleshooting so it’s a good page to remember how to get to. Once you select that button it will give you a list of functioning MSE’s and the service you want to assign. Find your new shiny wIPS MSE in the name list and check the box to the right of it under “wIPS” and then select “Synchronize.” It will take you back to the list of controllers and on the right hand side will show you the service, which MSE that service is running on and if it is synchronized. In my experience, it won’t show you a good status at this point. My suggestion is to go to lunch at this point, let it sit and come back in a little bit to check things. It’s painful, but eating a good lunch is much better than banging your head on a table.
After lunch come back to the screen from before, refresh it and see if the status has changed. If it’s working, great! If not, select the blue entry next to the WLC and MSE that isn’t working named “NMSP Status.” This is the only way I know to get to this screen, and it’s probably the best and most helpful place to look at your new MSE. There is even a place to troubleshoot why the MSE and WLC aren’t synced. For that look at the NMSP Status in the summary and click on the status (it looks like a doctors stethoscope.)
Keep in mind, this is what tells the WLC where to send the wIPS NMSP traffic in the first place, so it’s a critical step. No data in, no data out. In this scenario; no NMSP in, no SNMP traps out. I will also point out that it might take a couple of attempts to get the sync to work. Go back and select your WLC’s and change the MSE assignment to nothing (un-select the boxes) and sync again. Go back and try synchronizing them again. Another tip, NTP can be an issue here so verify you have a good time source. In my experience, everything can be correct and it will take a couple of attempts to get them to talk. Keep with it, it will happen. After it’s synced up, move onto the profiles
This is a big enough step I wanted to highlight it as it’s own section. It’s where you make alerts show up, and maybe don’t show up. It takes some time, focus, and a good written policy before beginning. It’s also going to take longer than you think, so be prepared. While the steps are pretty straight forward, it’s just a bear to do.
On CPI, navigate to “Services –> Mobility Services –> wIPS profiles.” You can use the default profile to play around with, but my suggestion is to build a profile based on the deployment, how many locations and WLC’s it will be deployed to. It’s OK, you can base the new profile on a couple of different pre-built profiles, the default being one of them. Using the drop down on the right hand side select “Add Profile” and select go. Name your profile and select a profile to copy from. If your type of environment is listed, or is close to one that is listed, I suggest choosing that here; it could save you a lot of time in the following steps. Select “Save and Edit” and it gets you going.
On this next step it’s best to understand what this really is. I went through it a couple of times before I read the note in the guide that says this really only applies to an overlay system. If you selected an integrated system way back when, this section really doesn’t apply so you can skip it. The AP’s reporting the wIPS stuff already know about what SSID’s them and their neighbors have so you don’t need to define it here. This really only comes into play if you are managing an overlay system or multiple systems. If you are doing a true overlay, take the time to read the manual on this step and build in the SSID’s you are really concerned about. If this is for an integrated system, simply ignore everything and click next.
Now for the fun, and time consuming part. You are looking at a 2 “window” screen at this point. The window on the left is all of the available alerts (roughly 260) and the window on the right will change based on which alert is selected. The box next to the alert name indicates if that particular alert/alarm is included in the profile. This is the step that tells the MSE what to care about and what should trigger an SNMP Trap to be sent to the trap receiver(s). My only suggestion is bring a snack and a drink and expect to spend some time here. Click on each alert name and read the corresponding window on the right. The upper section will allow you to adjust certain parameters of the alert while the bottom section will explain the alert. It’s fun to read through all of that only to get to a statement that says something like “Cisco WLAN knows about this and can deal with it so this alert isn’t needed.” Make sure those alerts are un-selected on the left hand side and move to the next one.
Going to the way back machine, remember when I stated that having a written policy is crucial before doing this? If you don’t have a written policy before this step, you will fully understand what I meant. While technically some alerts make sense (like a dictionary attack,) most fall into the category of technically it doesn’t matter one way or the other, but what do others expect to see out of this system. Not having a policy makes selecting alerts difficult, if not impossible. Don’t worry, it’s been my experience that you will visit this list many times before everyone is happy and then sporadically in the future as alerts are found to be false positives or new alerts emerge. Either way, expect to spend some time here and be patient, it’s at the heart of the system.
Once at the bottom of the list, click the “Save” button at the top. It’s a no brainer, but it has bitten me in the past. Click save before hitting next, don’t count on or expect the system to prompt you, though it might. After clicking “Next” we are almost home! Select the WLC’s that you want your new policy to apply to by checking the box to the left of the WLC name you want included in this and then hit “Apply” at the bottom of that window. You’ll see an alert/warning that’s it’s applying the profile, and you are done! Pat yourself on the back, get up and stretch your legs and go get a drink!
Also, it will be at this point you realize that you can configure, and apply, different policies to different WLC’s based on what they do. Going back and creating a new policy, defining the alerts and then applying the new policy to the different WLC is all it takes to care about Mi-Fi’s in one environment but not in a different one. Unfortunately, I don’t know how to apply different policies to the same WLC but different AP’s. I don’t think you can but I am open to being corrected.
Now, when you get back, navigate to “Dashboard –> Wireless –> Security” and you will now see your own list of crazy things happening in your environment. Selecting the count to the right of the alert will give you a detailing listing of that alert. It’s about this time you will realize that while this will suffice for just about any auditor, functionally it’s lacking. This is where adding a second SNMP trap receiver, like Splunk, comes in handy. You can either do that from the MSE GUI itself or from CPI on the page where the NMSP status link got you. Adding it is simple and straight forward. Realizing later that there isn’t a published MIB for the SNMP traps sent by the MSE makes you want to pull your hair out.
Side note here – if anyone figures that part out I would appreciate a link to a blog post. I wasted too much time on figuring that out and had to move on without great results.
That’s it! Your Cisco wIPS/wIDS is now functioning, and it’s just a matter of setting either more or less AP’s into wIPS mode and/or changing the alerts you are seeing.
My last input is this. If you don’t have a written policy by this point, all of this was for naught. These systems need to be cared for and updated. There needs to be constant babysitting of the alerts generated and guidance on what to do about the alerts. A lack of written, enforceable policy means the system you just built will exist only for the auditors, and that’s just depressing.
If you want to go back and read Part 1, click here.
If you want to go back and read Part 2, click here.
A link to official guide can be found here.
If you have any input or additional tricks, tips, or steps I forgot, please leave me a comment and I will make changes as needed. Remember, this isn’t meant to replace the official Cisco guide (found here), just to tell my story and tips and tricks I learned along the way. Thanks for hanging with me and getting to the end!
Until next time!