Telnet? Really?

apr911

DevilWAH wrote: »

ITs all about knowing what the weaknesses of telent are any how you are mitigating against them. Now of course the most obvious and simplest way is to turn off telnet and running SSH. But as is always the case in IT there is no singe right or wrong way to do things. its all good and bad ways. and that is determined by having a real understanding of how the systems works and doing thorough risk analyses before putting solutions in to production.

This right here is spot on. Its easy to teach in a class, where everything is black and white, that telnet is bad and we dont use telnet. In the real world where things get more grey, its about knowing why you shouldnt use telenet... What are the risks, how can we mitigate them and/or protect ourselves from being found negligent.

Geek1969 wrote: »

I have encountered multiple network devices Cisco and HP with both Telnet and SSH enabled as well as other configuration items neglected.

Unfortunately, this is often the way of things. I recently had a client who wanted to "get the network working and worry about security in the 2nd iteration." I steadfastly refused, insisting that we need to worry about security in the 1st iteration.

I pointed out the difficulty of slapping security on top of something and used the oft overused expression of slapping lipstick on a pig... At the end of the day, its still a pig... Trying to secure an insecure network that wasnt designed to be secure or with security in mind requires many more man-hours and has a much higher cost than a network implemented with security from the ground up.

Plus, as is often the case, placing security second at the start usually puts security second in the end too and "securing" the network will consistently get pushed off to make room for other "higher" priority tasks to the point your "secure" network is a hodge-podge of configurations that have been implemented at various times with no real consistency and plenty of overlooked/neglected configurations and inherited technical debt.

Finally, if an attacker finds their way in, getting them out again without performing a full outage and en masse audit/wipe of devices attached to the network and starting from scratch is really just a matter of luck. There is a lot of skill involved in trying to eject a hacker from a network but the success or failure of the security analyst or the hacker all boils down to luck. Its a cat-and-mouse game and all it takes is for one missed compromise for the attacker to get back in.