CCIE or Null!

My journey to CCIE!

Posts Tagged ‘Cisco Management

Cisco WLC Interfaces.

with 5 comments

If you have ever worked with a Cisco WLC or have looked through any configurations for a WLC, then you have no doubt seen the interfaces that make it work. You’ve probably also seen that diagram concerning how these interfaces relate to the physical interfaces on a Cisco WLC.

Now their are only five different types of interfaces (Management, AP-Manager, Virtual, Service-Port, and Dynamic Interfaces), I figured I would just take some time to quickly touch on them.

  1. Management Interface – As you can suspect this interface is for in-band management and handles any communication with AAA servers. This interface will also handle the layer 2 communication between the controller and any APs. Needless to say the configuration of this interface is mandatory and can not be skipped.
  2. AP-Manager – If you want to have APs on different subnets other then the subnet the WLC is on then this interface must be configured, it’s a requirement for Layer 3 LWAPP transport mode. So as you would suspect this interface handles all layer 3 traffic between the WLC and the APs. Since higher end WLCs can have multiple AP-Managers only 1 AP-Manager interface can be configured per physical port.
  3. Virtual Interface – Another mandatory interface that must be configured (once again like the management interface you don’t get the option to skip the configuration of this interface). This interface handles any mobility management, VPN Termination, Web authentication, and is also a DHCP relay for WLAN clients. You really want to give this interface a bogus type address (Like 1.1.1.1 or something) since it’s only accessed and used by the WLC, the APs and WLAN clients will not interact with this interface. (Other then it’s purpose as the DHCP relay, but it’s all in done within the controller unknown to the AP’s or clients)
  4. Service-Port – This is also a physical port for out of band management, so it’s configuration is optional. The port doesn’t even support 802.1Q, so you can’t use it for anything other then accessing the controller. (Note: This is only physical port that is active while the controller is booting)
  5. Dynamic Interface – Now these are the interfaces you can create and use to link specific SSID’s to specific VLAN’s on the wire. So this is where and how you can separate your wireless client traffic, this interface will also double as the DHCP relay for it’s subnet/VLAN (Note: A WLC can have up to 512 dynamic interfaces)

Written by Stephen J. Occhiogrosso

March 28, 2011 at 11:51 AM

Secure Cisco Device Management.

leave a comment »

One thing that should be standard in your setup, is secure management. Being a network engineer requires you to secure your management interfaces, whether the management interface is a web page or remote CLI session, it should be encrypted and authenticated. After all configuring port security and firewalls are useless if your administrative credentials are sniffed off the network in clear text, or worst case your entire configuration.

First thing you want to do is activate the secure protocols and disable the weak protocols. So we would issue the following commands:

As you can see we first disabled the HTTP protocol, and then enabled HTTPS (Note: the first time you enable HTTPS a certificate may be generated), then configured the vty lines to accept only SSH, and not telnet connections.

Note: Prior to disabling telnet and enabling SSH, you want to configure the aaa new-model parameters along with any local users DB entries. See this Cisco guide for configuring SSH in more detail. Last thing you want to do is lose remote access to your device.

Now this device can only be managed via HTTPS or SSH, telnet and HTTP access have been disabled. This will prevent the administrative credentials of your network devices from being sniffed off the network in clear text, only encrypted cipher text will be found.

Just to push the point home some more, here is a TCP stream where I telnetted into a lab switch and issued the sh run command. First off you see the password I entered to access the switch and secondly the entire output of the sh run command is right there in clear text!

Now, I did a second capture where I accessed the switch via SSH and issued the same commands.

Very different output, as you can see, in the beginning you see I used Putty after that the encryption algorithm exchange and the rest is cipher text.

You can also verify this by using NMAP to perform a port scan on the device to see what ports the device is listening on.

Here is a NMAP Scan with all four protocols enabled (Telnet, SSH, HTTP, and HTTPS)

Here you can see, the lab switch is listening on all four ports, so individuals can connect to this device in an insecure manner. (The option should not even be out there)

Now a second NMAP scan after the commands shown above were entered.

Now the device is only listening on 22 and 443. This device can only be managed in a secure way.

I’ll end this on a final note… The tools I used here are all free to download NMAP, WireShark, and Putty. So it doesn’t take much for some barely knowledgeable (and bored) user on your network to start sniffing packets on your network.

%d bloggers like this: