12-06-2004 09:01 AM - edited 03-02-2019 08:25 PM
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.
12-06-2004 09:33 AM
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
12-06-2004 10:06 AM
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.
12-06-2004 10:51 AM
TACACS+ does encrypt the packet with MD5. Even Radius encrypts passwords...just not usernames.
12-06-2004 10:57 AM
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.
12-06-2004 11:35 AM
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
12-06-2004 11:41 AM
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.
12-06-2004 01:04 PM
reapeated message, disregard...
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: