Hi there,
Due to limited resource available in my network, I had to allow users comming from internet to telnet my SCO UNIXWARE box directly, like:
telnet 23.1.1.2, anyone can access. I can't make it secure based on IP addresses or hostnames since IP address is dynamic. I have made all the passwords secure but still there is a risk of system hack thru telnet port. Any one can suggest me the way to improve my security with the resources available.
Regards,
Tayyab
You can't. As long as you use telnet, passwds are flying back and forth in ASCII.
At the very least, install SSH and use keys.
Thanks for your reply. Can you give me some more detail how can I integrate my existing application with ssh.
Regards,
Tayyab
I have been supporting a dialup BBS -- yes they still exist -- for five years now. Telnet itself is not an inherently insecure protocol nor are most daemon implementations any more buggy than, say, FTP. Stay current with patches and you'll be fine on that point. There are two issues that you must consider:
1 ) Transmission of account and password information in plain text
Since the server is Internet facing, it is quite possible that someone could intercept a valid user's account/password information and use it for nefarious activities. Depending on your server configuration, that account may also grant the intruder access to through other services such as FTP or mail.
2 ) Shell access to the server.
Unlike HTTP which can more readily be limited to specific areas of the system, shell access throws open the floodgates to your system and any weaknesses in configuration. Using restricted shells does little as there are numerous ways to bypass that limited security.
Here are some ideas:
As System Shock suggested, Secure Shell can completely address Issue #1 by encrypting not only the data stream once logged in but also the account information as the user logs in. It is freely available from http://www.openssh.org/. It is moderately complex to compile and configure but it will integerate seamlessly with your existing application; it is simply a replacement for Telnet not the application already running on the system.
The down-side is that it requires your users to use an SSH client to connect to your server. Telnet and Hyperterminal will no longer work. This can be a deal-breaker.
The second issue can be addressed with a "change root" jail in which the user is locked into a subdirectory structure of the entire file system. I have no direct experience myself but the JMC Research - Juan M. Casillas Web Site reference has been suggested. There may be issues integrating with your application but I can not say what they would be.
So, what to do?
The most important thing is to harden your server to the point of paranoia. There are many documents on how this can be achieved but here are a few general suggestions.
Hi,
Thanks a lot for your detailed reply. It was more than I expected.
Following is the only entry which I have in my hosts.allow file:
in.telnetd: ALL
This means no other service but telnet only.
Yeah, I restricted root access to the console only. And same is the case with password policy.
I'll check if I can acheive it.
About ssh, I can't stop my telnet daemon, users they don't use telnet directly. They are using a client software wiz KCML Client. So, if they are diretly doing telnet to system, I can simply replace telnet with ssh. But for above case, I'll check with my software provider, if they could help me.
Thanks a lot for your help.
Best Regards,
Tayyab
... none of this will do a lick of difference if you are still using telnet to connect into the network; I can snoop your su - root as good as your login. You have to either encrypt or tunnel -if not both- the original connection. Otherwise, your single point of failure (in this case, single point of risk ) still remains, i.e., the original connection into your network using telnet.
With SSH, the connection into the network is encrypted; not that it can't be hacked, but it'll take governent-type resources to do so. Add the use of keys, where the public key in your server has to match the private key in your user's computer, it makes it that much harder to hack. You add a "security verification" after login, and change the SSH port, it adds to the protection.
Also, even if your users have dynamic IP's, you can still use wrappers to deny connections from outside your users' networks. For example, if you have a user that has 32.1.1.10 right now, chances are, next time his IP refreshes, he's not going to go to say 222.123.321.4, since ISP's have a limited number of IP's - and therefore networks - to work with, so you could accept connections from say 32.1.xx.xx only and reject everything else.
All quite true, System Shock, but there is one important point: the KCML client accesses the server application through Telnet. I am not personally familiar with the client but if it does not support SSH2/SSH3 encryption, installing SSH is of no value. If it does, then there is the herculean task of coordinating the protocol change with all of the users.
Therefore, securing the server must take precedence.
I agree that TCP Wrappers can limit the server's exposure. It stands to reason that restricting access to a series of address ranges is preferable to the entire Internet. Only shereenmotor can identify his requirements. Reviewing access logs can help with that.
Honestly, I have found that blind trust in SSH to solve "all" security vulnerabilities misplaced. It encrypts a data stream. It does not protect against easily guessed or missing passwords. Analysis, configuration, and process secure a system. Securing a system from unwanted access is, of course, important but of equal importance is minimizing the impact should (some would argue when) an intrusion occur. Also a system administrator must be constantly vigil to identify the intrusion through review of logs and placement of trip wires.
SSH is not a magic bullet, however it is most certainly in the arsenal.
What????
..yeah, that's what I said... go install SSH in your server but let everyone else telnet.. sure...
What I said in my first post, is that if you are using telnet, you can't secure the connection into your network. That was the original point.
I then suggested to at least try SSH. OBVIOUSLY BOTH SERVER AND CLIENT. What's this, amateur hour? And again, you can "harden" anything you want, but if you do not "harden" the most important part, i.e., the connection into your network, it doesn't matter what you do, because if you are using telnet - regardless what client software uses the protocol - anything that leaves the client's computer leaves it in ASCII. Even if you connect into a server then have to jump to another, whatever leaves the client's computer ot hits the first server's NIC can be easily seen with a snoop, so a snoop will see what you are typing to jump into the other server anyway.
There's no "blind faith" in SSH. Who's saying is a "magic bullet"? It is simply more faith in an encrypted data stream rather than an ASCII data stream. Yes people can guess passwd's, but sure as hell are not going to just guess the private key that matches the public key on the server. I did add that even the encrypted transmission can be decrypted, but it'll take much, much more than your average passwd cracking software to do so. There's more to implementing SSH than just installing it and using it, you know?
No matter how much you analyze and configure and "process" a system: Absolute Truth #1 of network security: if it's on the network, it can be hacked.
First thing that you protect is the connection into the network. Without it, anything else you do is pretty much a waste of time.
You may lock all of your valuables in your house, but if you leave your front door wide open...
Yeah, I can still su-->root on any terminal, how to stop that.?
About ssh, I'm still checking with my application provider. From above discussion:
So I have concluded that I should not continue with telnet anymore and if ssh is not possible then I'll obviously go for VPN but not for an open telnet method.....
I'm planning to use ssh for remote access only and continue with telnet from local computers, that should be fine?
One stupid question here: Is it possible that my KCML client which uses telnet might be using its own encryption method with the telnet tunnel and decrypt the data at KCML server end which is located at UNIX box? Why I'm asking this question here not to my software provider because I just want to confirm if this is possible and I don't want to give those guys a chance of thinking me as a stupid 
Pls confirm the possibility.
Thanks for all your replies.
Best Regards,
Tayyab
Telnet is a protocol. No matter which application you use to telnet, it'll still function the same way. So telnetting with KCML will basically be the same as telnetting with the telnet command.
Let me stress that no method is 100% safe. Like I said in my previous post, if it's on a network, it can be hacked. The difference is in how difficult you make it for hackers to break in. And that is the key concept. I can give you a dozen analogies about not protecting the front doors, but think about this:
Hacker tries and tries and tries and tries to break in. Depending on the skill level of the hacker, after so many tries, if he/she can't get in, he/she will eventually give up and go to the next target: A script kiddie that has but a tool he/she downloaded from the net will not get anywhere, while an elite hacker may take more time depending on what he sees.
However, whatever level the hacker is, IF HE GETS IN, then he's bound to put forth a higher effort in going further in his hacking activity.
So it is all about putting enough barriers up front to discourage further hacking events.
And that's what you as an admin can do to protect your servers.
Now, user stupidity, well, that's another battle.