01-10-2013 11:03 AM - edited 03-09-2019 11:58 PM
Hi all,
I came across a strange phenomenon today when configuring a switch. We put a WS-C3750G-12S online with a routable, public IP on interface vlan1. When I logged in later, I noticed a session on vty 0:
Line User Host(s) Idle Location
1 vty 0 root idle 00:00:03 190.120.237.150
2 vty 1 ME ... ... ...
How could this happen? There was no 'root' user account set up on the switch, and the IP address, according to whois, is registered in Latin America.
Is there some kind of hack being excecuted here? The switch was purchased as "equal to new" from our vendor. The code on the switch is:
c3750-ipbasek9-mz.122-55.SE6.bin
Any ideas would be appreciated!
Dan
Solved! Go to Solution.
02-09-2016 09:38 AM
When a user (or a scanning script) attempts a login, even without authenticating successfully, a vty line will be opened up while the switch waits for authentication and it will show the username presented during the login attempt. Once authentication fails (or times out waiting), the line will be released.
I just verified this on my lab switch (with no Internet connection) as follows:
SW-HO>ssh -l root 10.0.128.1
Password:
% Password: timeout expired!
[Connection to 10.0.128.1 aborted: error status 0]
SW-HO>
While watching via another session:
SW-HO#sh users
Line User Host(s) Idle Location
* 1 vty 0 marvin idle 00:00:00 192.168.104.135
2 vty 1 marvin 10.0.128.1 00:00:05 192.168.104.135
3 vty 2 root idle 00:00:14 10.0.128.1
Interface User Mode Idle Peer Address
SW-HO#
SW-HO#sh users
Line User Host(s) Idle Location
* 1 vty 0 marvin idle 00:00:00 192.168.104.135
2 vty 1 marvin idle 00:01:04 192.168.104.135
Interface User Mode Idle Peer Address
SW-HO#
That's why it's a best practice to put ACLs on your vty lines (as noted in the earlier reply) - especially on ones that are on the public Internet. With an ACL, the initial tcp 3-way handshake won't even complete.
02-09-2016 05:33 AM
Hi all,
I have the same issue (with another Public IP) on my 2911!
The only way to stop the VTY connection is to use an ACL for the input telnet session.
Alessandro
04-23-2016 09:40 PM
Hello All,
I have the same issue.I am using telnet for administering my remote switches. Today when I saw all the vty lines were busy. I am advised to use ACL but I can not do this because these devices are being accessed through INTERNET by some of our employees from other areas as well. And also my switches do not support SSH. Could someone please advice me what to do to block all these unknown connections to my remote switch?
Thanks and Regards
Riaz Ulhaq
04-24-2016 08:37 AM
Do your employees from other areas need to access the switches' management interfaces? That would be odd. If so, you should still be able to narrow down what addresses you allow in an ACL.
A given remote office normally has a single or small number of source IP addresses. You could use those in your ACL.
Another alternative is that you could require the remote staff needing to access the switches to use a proxy server or jump box to do so. With that approach you can narrow down the allowed addresses to a single IP.
You should really update your switches or their image to support ssh and/or change your design to not use public addresses on the switch itself. Running telnet on an unprotected publicly addressed switch is like putting up a sign that says "hack me".
08-13-2016 10:12 PM
Thank you Mr. Marvin.
02-09-2016 09:38 AM
When a user (or a scanning script) attempts a login, even without authenticating successfully, a vty line will be opened up while the switch waits for authentication and it will show the username presented during the login attempt. Once authentication fails (or times out waiting), the line will be released.
I just verified this on my lab switch (with no Internet connection) as follows:
SW-HO>ssh -l root 10.0.128.1
Password:
% Password: timeout expired!
[Connection to 10.0.128.1 aborted: error status 0]
SW-HO>
While watching via another session:
SW-HO#sh users
Line User Host(s) Idle Location
* 1 vty 0 marvin idle 00:00:00 192.168.104.135
2 vty 1 marvin 10.0.128.1 00:00:05 192.168.104.135
3 vty 2 root idle 00:00:14 10.0.128.1
Interface User Mode Idle Peer Address
SW-HO#
SW-HO#sh users
Line User Host(s) Idle Location
* 1 vty 0 marvin idle 00:00:00 192.168.104.135
2 vty 1 marvin idle 00:01:04 192.168.104.135
Interface User Mode Idle Peer Address
SW-HO#
That's why it's a best practice to put ACLs on your vty lines (as noted in the earlier reply) - especially on ones that are on the public Internet. With an ACL, the initial tcp 3-way handshake won't even complete.
02-11-2016 06:03 AM
Absolutely agree with what Marvin said about placing an ACL that restricts access to that public facing interface. For instance, if you are not doing any management via that interface then that access should be completely blocked. If you look at your logs I bet you will that this device gets hits thousands of time per day with users trying to gain access to it.
I hope this helps!
Thank you for rating helpful posts!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide