Is enabling https on a Cisco router a considerable security risk?

Question

I would like to use Cisco's Network Assistant to manage my Cisco routers (I know there are other solutions for this, but for now I've decided to use CNA). It requires the HTTP or HTTPS service to be running on routers being managed. Where I work I have already been told I probably won't be allowed to implement this because enabling HTTP/HTTPS on the routers is a security risk.

But is it really a security hole as long as I enable HTTPS and change the default port number? I want to be able to say with confidence that doing it this way is completely secure. Of course nothing is "completely" secure and a port scanner could find any open ports, but the HTTP service running in the IOS isn't that hackable is it?

Lastly, should I have asked this question in the security forum?

Answer 1

As an Information Assurance (IA) principle, the less unnecessary services running on a device, the lower the attack surface. To mitigate issues, proper configuration and patching levels are key. Changing ports is one of many elements you can do to lower the potential security risk.

Cisco has an excellent guide for proper implementation of the HTTP/HTTPS service here (Selective Enabling of Applications Using an HTTP or HTTPS)

Answer 2

One potential problem with HTTPS is that lazy people (like me) may not set up a Kerberos certificate on the device to ensure that connections to it are secure. Your certificate would have to come from one of 3 sources: a commercial certificate authority like Verisign (expensive), setup your own CA using a Windows or Linux server (not that hard, but time consuming), 3rd option is to use a self-signed certificate, as described here:

https://security.stackexchange.com/questions/38589/can-https-server-configured-without-a-server-certificate

If your device has no certificate, connections should still be encrypted, making it more difficult for the casual wireshark user, but by no means "secure" in any meaningful sense. You will have no guarantee that connections are not affected by a man-in-the-middle attack. besides that, you (or the users depending on the resource) may have a false sense of security, analogous to having anti-virus, but not updating it.

I would argue that, though changing the listening port is a good basic precaution, once your device is found in a port scan, anyone interested could start trying the basic services e.g. HTTP, HTTPS, SSH or SMTP using the appropriate client for that service, and see if they get any valid responses. This can be scripted e.g. with cURL for HTTP/S, mutt for smtp, ssh...for SSH. The best defenses, if your listening ports must be Internet facing, are to keep the OS and services patched, and restrict access to only those IP addresses or ranges that you trust, using ACL's (Access Control Lists).

Answer 3

Enabling HTTPS and changing the port number is actually very common practice. Using a secure password for the login will also increase the security.

Of course, you should always use HTTPS over HTTP.

But ultimately to answer your question, no it's not insecure. The web management interface is just a user friendly way to configure the settings, but if someone wants in to your router (and knows what they're doing) they won't use the web interface. You should be fine.

Answer 4

Every open port on your device or server increase the attack surface, certainly. That said, enabling HTTPS would be more secure than enabling a non-encrypted protocol like Telnet or HTTP.

You mention changing the port number. Be careful with that, you may prevent the Cisco Network Assistant from finding/managing the device. (Does CNA let you specify a custom port number?)

Whatever management services you have, make sure the appropriate security lockdowns are in place. Implement as many of the following as is feasible:

1. Only use encrypted protocols for management (HTTPS and SSH).
2. No management ports should be exposed to the public internet or a guest network (e.g. visitor WiFi).
3. Idle session timeout for the management interfaces. Note these may be configured separately for HTTP vs SSH vs serial console, so make sure you have all your bases covered.
4. Implement rate limiting and temporary account lockout to mitigate brute force attacks.
5. Use long, complex, unique passwords
6. The admin account on the switch should not be something "well known" like admin, administrator, root. (Something an automated script would try to use to break in.)
7. Make sure that passwords/timeouts/lockouts are also applied to the serial console. (I have seen a lot of devices where the serial console was not passworded, or never timed out. You could plug in a serial cable and join an active session that was opened months ago.)
8. Watch out for SNMP leaving a back door into the system.
9. Consider AAA and RADIUS to allow central management of passwords and permissions.
10. Make sure logging is configured to track who logged into the device and when.
11. Use NTP to get the time/date correct in your logs (also important for certificate validity).
12. Have logs stored somewhere where they won't be cleared if the device crashes/reboots. Log to the filesystem, or ideally an independent syslog server.
13. Backup your configurations regularly.
14. Passwords stored in the device should be encrypted using the strongest encryption available. (Someone should not be able to get the password if they stumble across your config backups.)
15. Stay on top of security bulletins that affect your devices, update your IOS regularly.
16. Implement proper HTTPS certificates with your own internal cert authority.
17. Limit the IP range that can access the management ports (e.g. only the PC with CNA installed)
18. Limit the management interfaces to a specific VLAN or network port that is not accessible by regular users.
19. If multiple people will manage the device, consider multiple management accounts with different access levels.