cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7599
Views
20
Helpful
6
Replies

Unknown Root User Logged In

dkirks
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

Marvin Rhoads
Hall of Fame
Hall of Fame

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.

View solution in original post

6 Replies 6

a.alessandri
Level 1
Level 1

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

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

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".

Thank you Mr. Marvin.

Marvin Rhoads
Hall of Fame
Hall of Fame

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.

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!