IINS 210-260

IINS 210-260

Recommended Practices for Management Plane Security

There are a number of things we can do and best practices that we can perform to protect the management plane. We could obviously enforce a strong password policy using Cisco IOS login features, as well as strong passwords and password lengths, things like that. We can implement role-based access control in the form of CLI views. We can deploy AAA services for centralized device management to, let's say, a RADIUS or a TACACS+ server, maybe Cisco ACS for Windows. We can use Network Time Protocol as opposed to manual setting of clocks on our devices. This is going to help with consistent timestamps in logs like Syslog messages as well as making sure that our digital certificates have the proper validation of the date and timestamp. If we're using SNMP, we want to use the newer version – version 3 – that has strong authentication and integrity mechanisms. We might also want to restrict access to management protocols. We can use access control lists to reduce the attack surface by only allowing certain host or subnetworks to manage our routers. We can also use the Management Plane Protection feature which uses the same thing as CoPP, basically the same type of policy-based approach. We can also use CoPP as well.

Secure management and reporting

Okay, let's take some time here to really kind of peruse this topology. What we're looking at here is two different methods for delivering secure management and reporting.

Secure Management and Reporting

Now these two methods here are not mutually exclusive, let me just tell you that, okay. But let's start at the kind of the top-right where we see OOB Configuration Management. Notice that we have a what's called a Terminal Server there, that can be a terminal server, it can be an access server, it could just be a Cisco router. For example, in my rack, I've got a old 2500 router that has two asynchronous ports on the back that take octal cables. So I've got 16 cables that go to the console ports on 16 devices, and so I can do out-of-band management. I can connect myself from my management station down at the bottom-left, for example, the system admin host. I can connect to the console on that terminal server at the top. And then I can use something like TeraTerm, or Putty, or Secure Shell, which is highly recommended, and I can use that, and I can connect to all the console ports on all of those devices. That is out-of-band management, because it's not in the same channel or the same band as production traffic. Now if you can do that, that's a good way to do it; however, you may want to do web-based management of things. You may want to use third-party management and reporting tools that are already in place that you're using in your organization. So your management and reporting is actually in-band. In other words, it's in the same channel as your production networks, that's kind of at the bottom-right, okay, there is our corporate LAN – our production network. So if we're going to be doing management and reporting on the same band within the same virtual LAN – we can call it as the rest of our production traffic, then we need to put in some mechanisms. We need to have stateful packet filtering to reduce our attack service so that only certain hosts and subnetworks can manage our devices. We might want to do some time-based rules where we can only access during work hours. We might want to use IPsec to secure that traffic at the very least to provide authenticity and integrity. We want to make sure that we're behind our management VLAN, which is on the left-hand side. It is behind some device that has a firewall on it – either a router Cisco IOS firewall with a VPN or an Adaptive Security Appliance. And then, over on the left-hand side, we see all these different servers. At the bottom we have our admin host or hosts, and of course, we have management servers – SNMP server, our Cisco Security Manager, access control server (maybe ACS for Windows), Syslog Servers and others. And, so instead of putting all of those servers on their own VLAN, we can create VLANs within a VLAN and create private VLANs so that we can separate those services. Even though they're still in one IP address subnetwork, they're all in their own protected private VLAN, and that is going to enforce our trust model so that, for example, if the SNMP server is compromised with some type of malware, or distributed DOS attack, or some other Trojan, it's not going to affect the other Syslog server, for example, or the ACS server, because there is no Layer 2 connectivity or communication between those servers. That's what private VLANs do for us. And of course, those who want to use NTP down there to make sure we have synchronized and accurate clocks on all of our management clients and servers.

So, that is really kind of a look at secure management and reporting. And technically in a large organization, in a large enterprise, you wouldn't have just one giant management VLAN, you would typically have pockets of management VLANs, which is another good way to create security zones and to prevent the spread of malware outbreaks from affecting your entire management infrastructure.

Role-based access control

Something else you might want to do is move away from user-based access control – where users have these individual user accounts that have different types of permissions and security levels assigned to them – to more of a role-based access control – where different users assume the Admin role, different users assume the Auditor role or the Monitor role, and then they have rights, and privileges, and access based on that role.

Role-Based Access Control

The Cisco IOS software has role-based CLI access which allowed you to set up an RBAC architecture for your router management access. You create different views for different groups of users, and the views define what commands they can run also what's visible to them when they do show commands, what configuration information can they see as well. With role-based CLI, you can have better control of your network devices. Now for scalability, users, permissions and roles the best way to do this is to have users, permissions, and roles generated and maintained in a central repository, for example, an ACS for Windows server, so that these can be made available to multiple devices.

Deploying AAA

Remember, AAA is authentication, authorization, and accounting. Authentication is who are you, authorization is what can you do, and accounting is when did you start, when did you stop and how long did you do it, okay. Here's an example of a simple AAA architecture.

Deploying AAA

The remote client establishes a connection with our perimeter router, let's say an integrated services router generation 2. The router prompts the user for credentials – a username and password. The router passes those credentials back to the AAA server, which in our case would be an ACS for Windows server – access control server from Cisco. That server will authenticate the user, they'll be authorized to access the router administrative access. So this is not accessing through the router. This is basically what we call character mode admin access to the router. And it's based on the information or the data found in the AAA server authorization database.