Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I administer a number of linux servers that require telnet access for users. Currently the user's credentials are stored locally on each server and the passwords tend to be very weak and there is no requirement for them to be changed. The logons will soon be integrated with Active Directory and this is a more closely guarded identity.

Is it really a concern that user's password could be sniffed from the LAN given that we have a fully switched network so any hacker would need to insert themselves physically between the user's computer and the server?

share|improve this question
Since you are on linux, try ettercap. Here's a tutorial: – Joseph Kern Aug 10 '09 at 15:22
-"linux servers that require telnet access"??? I have not seen a linux server that was missing ssh the last 5-10 years or so... Feels like I'm missing something here... – Johan Aug 11 '09 at 20:21
@Johan - The applications running on these servers have been accessed by telnet for some years, since before ssh existed. The company buys a telnet client for the users who access these apps. Telnet is also used to access apps on a HP-UX server and from mobile handsets. Hence telnet is very much entrenched and isn't going anywhere no matter what I think about it. FTP likewise. – mmcg Aug 12 '09 at 10:23

9 Answers 9

up vote 42 down vote accepted

It is a reasonable concern as there are tools that accomplish arp poisoning (spoofing) that allow you convince computers that you are the gateway. An example and relatively easy to use tool would be ettercap that automates the whole process. It will convince their computer that you are the gateway and sniff the traffic, it will also forward packets so unless there is an IDS running the whole process might be transparent and undetected.

Since these tools are available to the kiddies it is a fairly large threat. Even if the systems themselves are not that important, people reuse passwords and might expose passwords to more important things.

Switched networks only makes sniffing more inconvenient, not hard or difficult.

share|improve this answer
I answered your specific question, but I recommend reading Ernie's answer as well about a broader approach to thinking about security. – Kyle Brandt Aug 10 '09 at 16:40
s/posing/poisoning/ – grawity Aug 10 '09 at 18:03
grawity: I spend about as much time correcting my hideous spelling with firefox spell check as I do writing each post:-) – Kyle Brandt Aug 10 '09 at 18:35
+1 You can all fill a switch's mac tables and turn it into a hub. Obviously bigger switches have bigger tables and therefore harder to fill. – David Pashley Aug 10 '09 at 19:00
Filling the switch's mac tables leads to unicast packets destined for unknown (because of the flooding attack) addresses getting broadcast. VLANs still restrict the broadcast domain, so it's more like a hub per VLAN. – sh-beta Aug 11 '09 at 21:49

Yes, but it's not just because of your use of Telnet and your weak passwords, it's because of your attitude towards security.

Good security comes in layers. You should not assume that because you have a good firewall, your internal security can be weak. You should assume that at some point in time, your firewall will be compromised, the workstations will have viruses, and your switch will be hijacked. Possibly all at the same time. You should make sure that important things have good passwords, and less important things do too. You should also make use of strong encryption when possible for network traffic. It's simple to set up, and in the case of OpenSSH, makes your life easier with the use of public keys.

And then, you also have to watch out for the employees. Make sure everyone's not using the same account for any given function. This makes it a pain for everyone else when someone gets fired and you need to change all the passwords. You also have to make sure that they don't fall victim to phishing attacks through education (tell them that if you ever asked them for their password, it would be because you've just gotten fired and you don't have access anymore! Anyone else has even less reason to ask.), as well as segmenting access on a per-account basis.

Since this seems to be a new concept to you, it's probably a good idea for you to pick up a book on network/systems security. Chapter 7 of "The Practice of System and Network Administration" covers this topic a bit, as does "Essential Systems Administration", both of which I recommend reading anyway. There are also entire books dedicated to the subject.

share|improve this answer
"Good security comes in layers." Very well said I think, thought about editing my post to have something like this, but it wouldn't have expressed so well. – Kyle Brandt Aug 10 '09 at 16:33

Yes it is a big concern as with some simple ARP poisoning you can normally sniff the LAN without being physically at the right switch port, just as in the good old hub days - and it's very easy to do too.

share|improve this answer
In addition, think about how many network ports there are in insecure or questionably secure areas. One of my past employers had half a dozen in an unmonitored, insecure elevator lobby. Even if the port's secure, think about who else is in the building -- janitors, service techs, etc. -- and remember that social engineering is one of the easiest vectors to bypass physical security. – Karl Katzke Aug 10 '09 at 15:20
"Hi receptionist! I'm here to see John but I'm a bit early, could I borrow a free conference room to handle some e-mail on my laptop? Really? Great!" – Oskar Duveborn Feb 10 '10 at 14:11

You're more likely to be hacked from the inside than the outside.

ARP spoofing is trivial with the various prebuilt scripts/tools widely available on the Internet (ettercap was mentioned in another answer), and requires only that you're on the same broadcast domain. Unless each of your users is on their own VLAN, you're vulnerable to this.

Given how wide-spread SSH is there's really no reason to be using telnet. OpenSSH is free and available for virtually every *nix-style OS out there. It's built-in on all the distros I've ever used, and administration has reached turnkey status.

share|improve this answer
+1 For mentionning Vlans and broadcasting domains. – Maxwell Aug 10 '09 at 15:23
Getting a bit out of my network security depth here... But I'm not sure VLANs will protect you either as a general rule:… – Kyle Brandt Aug 10 '09 at 15:31
+1 for mentioning OpenSSH when noone else had. – Ernie Aug 10 '09 at 16:00
Kyle - the vulnerabilities there are mostly irrelevant. The MAC flooding attack is still restricted by broadcast domain, so no VLAN hopping. Same with the ARP attacks. The double-encapsulation VLAN-hopping attack that everyone quotes as why VLANs are insecure requires the attacker be attached to a trunk port with a native VLAN. Trunks should never have a native VLAN in the first place... – sh-beta Aug 10 '09 at 17:21

Using plain text for any portion of the login and authentication process is asking for trouble. You don't need a great deal of ability to gather user passwords. As you're planning to moving to AD in future, I assume you're doing some sort of central authentication for other systems too. Do you really want all your systems wide open to an employee with a grudge?

Can the AD move for now and spend your time setting up ssh. Then re-visit AD and please use ldaps when you do.

share|improve this answer

Sure, you've got a switched network now... But things change. And soon someone will want WiFi. Then what are you going to do?

And what happens if one of your trusted employees wants to snoop on another employee? Or their boss?

share|improve this answer

I agree with all the existing comments. I wanted to add though that if you HAD to run this way, and there really was no other acceptable solution, you could secure it as much as you can. Using modern Cisco switches with features like port security and IP Source Guard, you can mitigate the threat of arp spoofing / poisoning attacks. This creates more complexity in the network as well as more overhead for the switches, so it's not an ideal solution. Obviously the best thing to do is encrypt anything sensitive so that any sniffed packets are useless to an attacker.

That said, it's often nice to be able to find an arp poisoner even if simply because they degrade the performance of your network. Tools like Arpwatch can help you with this.

share|improve this answer
+1 for suggesting possible mitigation – mmcg Aug 12 '09 at 10:31

Switched networks only defend against en-route attacks, and if the network is vulnerable to ARP spoofing it does so only minimally. Unencrypted passwords in packets are also vulnerable to sniffing at the end-points.

For example, take a telnet-enabled linux shell-server. Somehow, it gets compromised and the bad people have root. That server is now 0wn3d, but if they want to bootstrap to other servers on your network they'll need to do a bit more work. Rather than deep-crack the passwd file, they turn on tcpdump for fifteen minutes and grab the passwords for any initiated telnet session during that time. Due to password reuse, this will likely allow the attackers to emulate legitimate users on other systems. Or if the linux server is using an external authenticator like LDAP, NIS++, or WinBind/AD, even deep cracking the passwd file wouldn't get them much so this is a far better way to get passwords cheaply.

Change 'telnet' to 'ftp' and you have the same issue. Even on switched networks that effectively defend against ARP spoofing/poisoning, the above scenario is still possible with unencrypted passwords.

share|improve this answer

Even beyond the topic of ARP Poisoning, Which any reasonably good IDS can and will detect and hopefully prevent. (As well as a plethora of tools intended to prevent it). STP root role hijacking, Breaking into the router, Source-Routing information spoofing, VTP/ISL panning, The list goes on, In any case - There are NUMEROUS techniques to MITM a network without physically intercepting traffic.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.