Quote:
Originally Posted by hegemaro
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...