Cybersecurity

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 http://www.jmcresearch.com/projects/jail/ 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:

Code:

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.