What are people's opinion about using Telnet in the light of all the recent exploits and malicious hacks going on?

You should never use telnet unless

1. You're on a physically secure wired network,
2. You trust everyone (cf. openroot project), or
3. Your security is so completely lacking that one more huge security hole isn't going to change anything.

But what does that have to do with the recent exploits and malicious hacks going on?

Originally posted by Nicholas Brown
What are people's opinion about using Telnet in the light of all the recent exploits and malicious hacks going on?

In general, telnet/shell access isn't the issue at hand. This is not an exploit issue that has to do with the recent BIND (and always Sendmail) type of exploits. This is an entirely different issue/question. Although, it's not like there's never been such a thing as telnet exploits or FTP exploits, etc. However, if someone compromises a server, they'll give themselves direct root shell access anyway. It's best to not give shell access to anymore people than you can help. It's not as if a properly configured system is going to be *that* much more open to attacks, simply by allowing shell access. However, as far as telnet specifically, I'd try and enforce SSH access in place of it so people can't grab clear text passwords.

Also, configure your system to deny user's from really being able to do or view or snoop for anything they ought not to be. Implement a chroot type jail for the users, enforce good passwords and make them understand to keep this information from places that people can easily access or gain access to. I.e., web based emails, public terminals, written down anywhere that's accessed by many people, etc. Set proper permissions, set rules, deny user's from access to anything that could be exploited or helps them gain information to accomplish such a task that you can possibly get away with. Then, allow specific user's access to certain tools and programs one by one that are anything that can be used for a means of obtaining sensitive information (although you'll not want that to be an issue either).

There's many things you can do, that those things in themselves would make a potential system cracker think twice before attempting to exploit something on your server. If they can't easily tell what the server's running, who's logged in, etc... as well as what tools or services are running -- and you may be making use of port monitoring tools, they don't know how many user's are logged in, logging tools, wrappers, firewalls, etc. then they might think twice. This isn't all there is to it, but it's one of the basic, helpful things that do prevent some crackers. It adds risk to them, and that's just one, very minor layer. I.e., you can have a very secure system with no realistic means for someone to actually root your server, but if they see a simple, otherwise harmless service running that shows them there's no users logged on, they are likely to have time to try things that might eventually work or give them the confidence to continue to try exploits and various attacks. If they can't see this information without risking it, you've lessened the chances of people trying by 30%.

So, doing things like only allowing specific user's to run certain rarely used or needed or relatively unused programs for legitimate reasons, can be accomplished with ease. Deny things like su, ps, netstat, tcpdump, who, w, etc. to only user's that will need such tools accessed. Most people do not, even with telnet access. Some might need some tools, but not others.

Furthermore, you can effectively "filter" these tools and allow the user's to access and run them, but only output the information that is relevant to them. Let them be able to run the ps command, but it only shows them the server's uptime, load averages, resources, etc. and their own account's processes. No other processes will be shown by any other users, they can't see how many other user's there are on the system or who they are. Of course you'll shut off all the stupid or useless services that might give too much information or verify an account exists too. So, disable, deny or filter the output of certain programs and log the calls to them and by who and what was passed.

This is all very basic information, and there's a lot to this, but I'm just trying to give you a very basic, general idea. So many things come into play, that it's not just telnet access that's the issue and it's not just telnet passing clear text passwords that's the danger, (but it's part of it), it's more so what information people can obtain, how and what they can do with it. Make it difficult, keep updated on security issues, make it so you don't *have* to worry if someone does gain access to a user's account. Simply put, so many users practice such poor security prevention, the biggest concern (or one of them) that people seem to overlook, is what user's can do once they are in the system, because an innocent user was careless with their password or login information.

Make it so if someone does access the system, they are very limited and next to, if not impossible to do anything once they do get in. There's many ways to accomplish this, but the general rule of disallowing everything and then specifically allowing certain *controlled* programs one by one, to certain user's and enforcing certain policies is usually 90% of the tasks.. not that that's easy for most people or quick to do, but certainly possible and not so far fetched as many people would like to make it seem. Granted, 99.999% of all servers I've ever had an account with, worked on or for, or.. uh.. "tested" for fun, have had minor to major security issues, these usually turn out to be obvious things that people seem to think is the least priority.

Take most servers about wanting to create control panels and billing systems and promotion and general hosting issues and the very last thing on their list says something like "after all these other tasks are done, we'll have to take a look around, turn off some services and secure the system a little" People over look the time that needs to be spent on these issues, depending on the size, complexity and features of the network and servers thereof, this can be a 2 hour or 8 per day job... not to sound over-kill, of course. Most of the planning and strategy issues, investigations, discussions and implementation can be solved or accomplished within a few days that will take care of a high prercentage of the issues involved and not require someone to spend that 2 to 4 or 8 hours a day every day (don't get me wrong).. But only if they are inclined to do so and care -- that is, if it's well planned out and structured, but a constant task of maybe even if a few minutes a day only -- but it's that most server's do not agree with or acknowledge that fact -- which explains the 99.999% of them being slack in security.

So, in conclusion to my novel, telnet in itself is not the issue at hand, anymore than is most other means of accessing. If you have the server configured decently, it only is an issue of allowing people to gain access to that user's account easier, if they happened to be gathering that information at that time. What people can do from there and the security issues, completely lie in how the server is set up and secured. So, is it an issue? Yes and no... But it's not so much an issue that no one should run it ever.

[Edited by Tim_Greer on 03-05-2001 at 03:30 AM]

~ wow ~

:D

to the people who deny telnet access and force users to use ssh (of which I am one): do you also deny ftp/pop3/imap4/http with basic authentication (the last for control panel type things, that is)? If you don't, what's the point?

How do people normally upload their sites without ftp access anyway? It's unlikely that windows users will be able or willing to upload their sites using rsync or edit them on-site using a text editor...

pyng: yes.

For FTP, allow FTP from localhost, and allow SCP/SFTP. That way people can either use an SCP client (there are graphical ones available) or run FTP over an SSH tunnel.

For POP3, disallow password authentication except from localhost. Eudora et al can use APOP authentication; LookOut users can run POP3 over SSH tunnel.

As for control panels... bah, who needs them anyway ;)

there are gui scp clients available? hmm. where?

the problem i was really envisioning is that most web authoring software have ftp access integrated, so taking ftp away makes it rather inconvenient.

FWIW, i used pop3s/imaps (over ssl) instead of going apop.

I personally use http://i-tree.org/ixplorer.htm... it is basically a GUI for pscp. If people must use FTP, let them tunnel it over SSH, that way it works with their integrated applications. POP3 over SSL works well except that 1. you need an SSL certificate which can be a PITA, and 2. POP3 over SSL encrypts the data traffic as well which is pointless since it arrived at the server in plaintext.

Originally posted by pyng
to the people who deny telnet access and force users to use ssh (of which I am one): do you also deny ftp/pop3/imap4/http with basic authentication (the last for control panel type things, that is)? If you don't, what's the point?

How do people normally upload their sites without ftp access anyway? It's unlikely that windows users will be able or willing to upload their sites using rsync or edit them on-site using a text editor...


This is certainly a point to take into consideration. There are ways and programs to do these things via SSH/SSL though. However, it's not a good idea to put in so many restrictions that it makes user's not want to host with your server. Don't misunderstand my post, if you did get that impression. There is such a thing as going too far. However, there's also ways to better secure some things that will not add a hassle to the client. I would try and enforce SSH, but also as you said yourself, most people use FTP, which has the same clear text password issue and getting them to use another FTP client without putting them through a hassle, is unlikely.

It's certainly worth informing people and encouraging them to use SSH if they need shell access (which not too many people have a problem doing in place of telnet anyway) and asking them to use a secure FTP client and email protocol. This basically goes back to my long post about this not being an issue of trying to use secure connections for all these things, but it ensure the system is less vulnerable in the first place. Let's be realistic about it, most user's gain unauthorized access via exploits that have nothing to do with telnet or FTP (which once they do, they'll grant themselves access to connect directly as root anyway), or because some user choose a poor password or didn't protect their login information and someone got into their account. Both these common means of gaining access can't be prevented by the means of enforcing secure connections anyway.

This reminds me of servers that have SSL for CC orders, but store the CC information on their server that allows all the users on the server to view that file with the CC order history/information. As someone said it best; it's like having money in a park bench shoe box, putting it in an armored truck and driving across town and putting the money into another park bench shoe box. This outlines some of the poor security measures practiced by many hosts and it's a result of ignorance, arrogance or false hope. This is one of so many countless but important factors when choosing a web host that many people, including the host overlook.

So, no, secure connections are hardly the answer, but it's definitely helpful in a lot of circumstances and does diminish the attacker ratio enough to make it worth the effort -- if you can get away with certain things without putting your client's through a hassle or stressful hosting experience -- but that is usually easy enough to do. And, the less connections made using telnet, even if FTP is still being used, the better. Better securing one service, isn't a bad idea, ever. The more the better, but even though it might seem a moot point if that's true, less chances are always less chances -- but my opinion is to always better secure the system, not just secure the cosmetics of it.

However, everything done, is a step to being more secure and depending on the server, if shell access is limited to the few user's that do likely care to use secure connections and protect their login information, then the accounts that might be broken into are usually owned by the unknowledgeable regular user with much less privileged and much more limited accounts (which this regular user likely wouldn't know about or care), which does help make it more difficult for the attacker to do much, as well as be less fun and productive for their task.

[Edited by Tim_Greer on 03-05-2001 at 01:26 PM]

Since FTP passwords are usually sent in the clear, would making users use different passwords for FTP and Telnet/SSH make things more secure?

yes, but not by much. People have a tendancy to type in the wrong passwords, so someone could likely pick up the SSH password by sniffing the FTP connection; further, given ftp access, (provided that cgi scripts are allowed) you can easily extend that to shell access.

well said Tim :)

:beer:

whoa Tim.. don't you ever get tired of typing? Did you know if you seperated your posts into many little posts, you would have posted more posts them the adminstrator? j/k... good job man

Originally posted by Dim8
whoa Tim.. don't you ever get tired of typing? Did you know if you seperated your posts into many little posts, you would have posted more posts them the adminstrator? j/k... good job man

Tim,
You can also put all this security related and any thing you have an expertise on your website so that many people will benefit from it. If you have already done so, please post the URL, and if the forum rules prohibit it, include it in your sig.

BTW, I've fallen down laughing at reading Dim8's reply and am still rolling on the floor. So can't...............................

I am not a man of few words. If it's not at least a chapter long, I feel inadequate. As sad as it is, I fell and "went boom" as a small child, and had to live off of regurgitated resources. That, and the mandatory requirement I was to wear a protective helmet and full body pads at all times. I slipped into a deep depression when I was told I could not longer play with the toys rated for my age -- and I tell you! Those soft, sponge toys are just not fun after a while! All my cool Skeletor wall paper had to be covered up with padded walls, padded bars caging me in like a small drooling animal with a bad rash! SOMEONE scratch me, I beg of you!? Still, silence in the long cold halls, my cry's echoed into a void. *uncontrollable sobbing!*

As soon as I move my site's to a dedicated server (if I ever get one), I'll hopefully have time to post some well defined tips and articles about a variety of things. Also, I just noticed there's a web security forum, which I must have passed up, so it's good to see that on the forums list. As I have time, I'll be stopping by there. Perhaps give some general or specific descriptions, tips, whatever. Something better put together, surely. :-)

..*...voices... voices.... voices...*...