cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
287
Views
0
Helpful
7
Replies
Steve Graham
Beginner

Securing mgmt access to 3500XLs

Throughout our Cisco environment there are roughly 30 or more 3500XL (makes up about 70% of my layer 2 environment). The dilemna I'm faced with is securing port 23 access to these from an administrative standpoint. We use TACACS+ for authentication, however, it is my understanding that the authentication from the switch to the tacacs server is sent in clear text. This is a problem in our environment, and unfortunately the 3500XLs do not support SSH. Anyone have any creative suggestions of securing up mgmt access to these devices? ACLs are an answer, but I'd like to see if there are any other suggestions prior to ACL implementation.

7 REPLIES 7
7rbowenii
Participant

Have you considered using only console access and not configuring layer-3 interfaces on the swithces. There are some terminal servers (Lantronix) that can support SSH, but direct access to the 3500s would be via the console port. Logistics of a large (30+) switch rollout may be another matter, but it is an idea and the problem is solved.

Another option is using Cisco's authentication proxy feature. This would require implementing ACLs, but would require authentication to gain access to the network via port 23 and then you would still ahve to authenticate to the local device...

-Bo

Thanks for your input, console port access is definately a good answer, I will research this and see if it is a feasible alternative across the campus.

duncanm
Beginner

TACACS+ does encrypt the packet with MD5. Even Radius encrypts passwords...just not usernames.

Correct, however, when accessing these devices from a PC, it is sent in clear text to the aaa client, and since the 3500xl switches do not support SSH, my delimna occurs.

Why not put access-classes on the vty lines to restrict what source IP addresses can connect. I agree if the Telnet session was 'sniffed' the passwords could still be seen, but your attacker couldn't telnet to the switches unless he was from an authorised IP address:

access-list 10 permit 10.1.1.0 0.0.0.255

!

line vty 0 4

access-class 10 in

Andy

Thought about this, however, with the size of our campus and the locations and segmentation in our environment, support to switches needs to be accessed throughout the environment. My techs need the capability to manage a switch from a user's PC, however, if worse comes to worse, I could leverage the data centers in each building and restict telnet access from an IP segment in each of the data centers. Thank you for your response, I will take this approach into consideration for further investigation to work within our environment.

reapeated message, disregard...