Best Practices for securing VTY lines?

[cluovpemb]

Hi all,

The thread title makes this sound like a big post but it's not. 

If my router has say., 193 VTY lines as a maximum, but by default running-config has only a portion of those mentioned, should I set any configs I do on all lines, or just on the lines sh run shows?  Example: 

sh run on a router I have with default config has: :

line vty 0 4

access-class 23 in

privilege level 15

login local

transport input telnet ssh

line vty 5 15

access-class 23 in

privilege level 15

login local

transport input telnet ssh

Yet, I have the option of configuring up to 193 VTY lines:

Router(config)#line vty ?

  <0-193>  First Line number

It seems lines 16-193 still exist in memory, so my concern is that they are potentially exposed somehow to exploits or what not.  So my practice is to do any configs I do using VTY 0 193 to ensure universal configuration.  But, my "enabling" the extra lines, am I using more memory, and, how secure is this against somebody trying to say, connect 193 times to my router simtaneously?  Does it increase the likelihood of success on DoS attack for example. 

[Julio Carvajal · Accepted solution]

Hello Colin,

Actualy they are still   there ( they are a software interface)but you cannot use them unless properly configured , so that being said they cannot exploit that as you only have allowed 0 4 and 5 15 as an example, Son only 16 connections can happen ( no more than that, no matter what)

Now the best practices for me would be:

*Configure access-class

*Use AAA with them ( Authentication, authorization and accounting if possible)

* And last but not least if you are using a ZBFW restrict traffic to the self-zone

Note: If you use the entire amount of Virtual interfaces for inbound connection you are leaving the opportunity for 194 users to connect at the same time via SSH or telnet witch from a security point of view is a huge problem.

Regards,

[Marvin Rhoads · Accepted solution]

In addition to Julio's answer, please please turn off the telnet transport. "transport input ssh" is the method I endorse (and Cisco recommends).

Also consider where the device sits. If the interface is publicly exposed, you may want to consider an out of band (e.g. console server) solution that connects to the physical console port and disabling the vty alotgether.

Also have a look at the Cisco guides:

Guide to Harden IOS

NX-OS Securing

If it's a router, you can run the CCP security audit. See the CCP User Guide here. (Chapter 46). You can also run the "auto secure" function directly from the cli on your routers if you prefer.

Finally, you should be watching your configurations and syslogs and be alert for ANY unexplained configuration change and  sudden increase or change in the type and number of events logged. Often I see folks think that they can lock the door and walk away feeling 100% safe.

The cost of security is not only diligence but vigilance.

[cluovpemb]

Hi guys, thanks for the replies and excellent information.  I'm excited to look at the IOS Hardending doc and the other stuff too. 

Just to clarify, I don't actually use the default config, I only pasted it from a new router just to illustrate the default VTY line count. 

I never use telnet from inside or outside, anyting snooping a line will pick up the cleartext as ou both know of course.  SSH is always version 2 etc. 

I was considering doing a console server from the insidde as the only access method - which I do have set up but I have to remote to it It's just that with power outages at times, the console PC won't come back up (no BIOS setting to return to previous state, no WOL solution in place) so now I have both that plus the SSH access.  I have an ACL on both the VTY lines themselves as well as a ZBFW ACL governing SSH - perhaps a bit redundant in some ways but oh well if there's a zero-day ou thtere for turning off the zbfw I might still be protected  

Regretfully I havne't learned about AAA yet - that I believe is in my CCNA Security book but first I need to get other things learned. 

And with regard to logging in general, both enabling the right kind and monitoring it properly, that's a subject I need to work on big time.  I still get prot 25 outbound sometimes from a spam bot, but by the time I manually do my sh logging | i :25 I have missed it (due to cyclic logging with a buffer at 102400).  Probably this woud be part of that CCNA Security book as well. 

So back to the # of VTY lines.  I will see what I can do to reduce the line count.  I suppose something like "no line vty 16 193" might work, if not it'll take some research. 

But if an attacker wants to jam up my vty lines so I can't connect in, once they've fingerprinted the unit a bit to find out that I don't have an IPS running for example, wouldn't it be better that they have to jam up 193 lines simultaneously (with I presume 193 source IPs) instaed of 16?  Or am I just theorizing too much here.  I'ts not that this matters much, anybody who cares enough to hack this router will get a surprise when they find out there's nothing worth the effort on the other side But this is more so I can be better armed for future deployments.  Anyway, I will bookmark the info from this thread and am looking forward to reading it.