Setting Up Cisco wIDS/wIPS, Part 2

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 design and purchase a Cisco wIDS/wIPS solution.  If you haven’t read that one, you should go do that now and then come back here.

In Part 2, we are going to cover deploying your new and shiny Cisco wIPS solution, and then watch the magic start to pour in in Part 3!  I’m not going to get into how to install Cisco Prime Infrastructure or the MSE 8.0 with the wIPS licenses, the guides are pretty straight forward and self explanatory, that’s not what this is about.  The one lesson learned for this section, and I think it’s a lesson most of us have learned at one point in our career, is understanding where the enterprise firewall’s live, logically, in the intended architecture.  This will come in handy later when certain things just aren’t happening, or when it’s time to submit those request to get the firewall changed.

Before going much further, I want to highlight a drawing from the guide that I want to explain in detail, since no one really did this for me and it cost me some time trying to figure it out.  I know the quality is poor but I suspect it’s been copied and pasted more than once!

With this layout I think you can see where the term “Holy Trinity” came from, and in a little bit you will really understand it.  As you can see, the WLAN hardware in the lower left centers on the WLC as this is a converged deployment.  I think you could do this in a different mode but at scale it might prove tough to manage.  Anyways, as you can see by the arrows, there are different communications protocols that happen within this trinity, and they all come into play when setting up and running a Cisco wIPS/wIDS system.

If there is one thing I need to impress at this point is while the MSE plays a significant role in the functionality of the system, other than the basic setup and configuration to get it to “talk” on your network, you actually don’t DO anything on the MSE server.  There is a couple of set up tasks that you can go back and add later (licensing and SNMP traps) but in a functioning solution, there isn’t any to see or do here.  Let me show you my live system to show you what I mean.  The main screen looks like this:

Not much to see, but it shows that something is happening.  The other screen to check is called the NMSP status page, and this gives you just that.  By referring to the trinity picture above, you can see that NMSP is the communication between the WLC and MSE, and it shows that information is indeed flowing INTO the MSE, which is step 1.  To give you an idea, this is what that looks like:

As far as the MSE server goes, that’s about it.  There are a couple of other screens, but they are self explanatory (licensing and SNMP trap destinations) so I won’t cover them.  That and SNMP trap destinations can be done on Prime Infrastructure.  Biggest thing I learned over time, that no one pointed out to me and the one thing I want you to take away from this, almost ALL of the work is done on Cisco Prime Infrastructure (here on out referred to as CPI.)  Let’s break that down.

I know the picture above shows all three devices playing a part, and they do, but do you notice which server is at the top of the pyramid?  It’s CPI.  Assuming the WLC and Wi-Fi infrastructure is already up and running and you added CPI to give you some historical visibility into the system (and then they tried to tell you to do all the management of the system with CPI and you said no, just like me) the MSE is the last piece of this trinity.  It probably does the most work in a wIPS solution with the least amount of credit.

Using either a configuration template from CPI or manually selecting the option on the AP via the WLC, you are going to have wIPS information being sent from an AP configured in WIPS mode to the WLC via the CAPWAP tunnel and then from the WLC to the MSE server using the NMSP protocol.  The MSE is going to see that information as having come from the WLC (hence the NMSP status pages I just pointed out) but what it does with that information is controlled by CPI.  CPI is where the profile being used (basically what alarms you want to see) is configured and then pushed to the MSE via the SOAP/XML link link between the two.

Now when the NMSP traffic from the environment hits the MSE, it analyzes that traffic looking for different patterns that indicate known events happening.  When it sees a pattern that matches a known event, it triggers an SNMP trap from the MSE server to CPI.  During the configuration that is done for this solution on CPI, the IP address for CPI is inserted as the primary, and only SNMP trap destination in the wIPS MSE.  This is important since there isn’t anywhere on the MSE that you can actually tell that an alert has been triggered.  I spent a lot of time searching and there is no other way I can find that will show you this information.  It’s not in the syslog of MSE nor can you find anything great in the trap logs on the WLC.

Now, if you have turned on the mitigation part of wIPS there will be a coordinated effort from CPI to the WLC to deal with the offender, but only in certain circumstances have I ever heard of that functionality being enabled.  This is where the policy from Part 1 comes into play.  Accidentally doing a DDOS attack against a legitimate, neighbor AP can get you in trouble with the FCC so you better be sure your management has a written, approved policy that makes sense before turning that on.

To sum all this up, after initial configuration, it works like this:

1. WIPS traffic from the WLAN is sent to the wIPS MSE using NMSP.
2. WIPS MSE analyzes the data looking for specific patterns that match known “issues.”
3. WIPS MSE identifies a known pattern and checks to see if it’s an issue that has been configred to alert on.
4. If it is an alert-able pattern, MSE will send a SNMP trap to the destinations listed in it’s configuration (should be CPI by default, others can be added.)
5. SNMP trap is logged on CPI, and others if configured, and depending on configuration can attempt to mitigate the offending device.

Like I said, the MSE does almost all of the work, but for all of that there isn’t much to actually see or do on the MSE.  If NMSP traffic is flowing and alerts are showing up on CPI and other trap receivers, then it’s working.

Coming up in Part 3 – Configuring and looking at these mythical wIPS/wIDS alerts.

If you missed it, Part 1 is here