On Thu, 8 Nov 2001, Keith Morse wrote: > On Thu, 8 Nov 2001, Rodolfo J. Paiz wrote: > > > At 11/8/2001 05:13 AM -0800, you wrote: > > >While I agree that useing SSH over an open network is the way to go, on a > > >closed network, > > >telnet is just fine.
I tend to agree. > > > > By some sources, over 80% of attacks, thefts, sabotages, etc. are internal. > > I'm a statistician by training and my education says that most such statistics are BULL! Actually they are quite meaningless as a generalization. While it is right to point out that one must consider all the potential sources of security problems, the risk of such occurrences is not uniformly distributed! I.E. YMMV. I may assign a much different risk to internal sources than you might, depending on the environment. E.g. if the local environment is such that everyone has read access to each others' files anyway, then password stealing locally is probably not going to be attributed a high probability, but even in that environment, external threats will be regarded as being much more likely and the effects much more damaging. It's up to the practitioner to assign the relative risks. > > By my own consulting practices, a *huge* percentage of problems are > > internally-caused. > > Maybe so, in the type of environments you consult in! And in those environments, where the company's secrets are all online and industrial espionage might have enormous consequences, it might pay to be careful, even approaching paranoia. However, in the majority of environments that I install, local problems are of almost no consequence. As I said, YMMV. Of course, in a perfect world, we would all use ssh, at least until machines and software catches up with ssh-encryption of today to the point of being practical enough that someone might try to crack it without a roomful of Crays. In my opinion, we should try to use ssh whenever possible. We can take to carrying a floppy with putty on it, for example, so that if we get caught at a PC without an ssh client, we can still use ssh. However, if it is not possible at that moment, then, instead of letting it keep work from being done, we might be able to proceed with the telnet or ftp and then we should be responsible for changing the password as soon as possible (using a secure connection of course). Or, like I said, in some local environments, you might not have to care. If you anticipate having to use ftp on an open wire, why not first set your password to something you might not mind being captured! :-) Then, change it as soon as possible after using it. Then, you have minimized the exposure. Well, if you are in an environment that requires paranoia, then this would not work, but I know of environments in which that would be very appropriate, and things wouldn't be delayed while you try to get putty of some such onto the PC. > > In kidnapping cases, 95% of attackers had inside information. > > > > In divorce cases where money is an issue, in over 85% of cases one spouse > > is spying or stealing information from the other. > > > > Yes, you can do it. But really, if SSH works just as well out-of-the-box > > and is just as simple, why would you? Because it is NOT THERE OUT OF THE BOX on most of the desktop boxen out there (from Mr. Bill and Co.). > > > > Heck, on my internal network SSH is much *easier*. I set up the right keys, > > and now I type one password when logging in then get access to everything, > > properly authenticated, transparently. Yes, you're lucky. But do you have a mixture of Win95, Win98, NT, Macintosh, and Linux boxes on your LAN? I often do. I have not found it easier in that case. > > > > Just because a thing *can* be done is often no reason to do it. Yes, but why stand on your head if you don't have to? If telnet is there out of the box, but ssh is not, then it might amount to standing on your head to get ssh there if all you needed was to quickly check on something that was time crucial. Way the risks against the rewards. > > Well spoken, Rodolfo. My standard is to only permit telnet to devices > that cannot do ssh, yet. And where I work, this is policy and practice. > And it might be appropriate where you work. However, my observation of 25 years in the IT support business leaves me with the feeling that policies are often crafted by system managers and their (non-technical) managers because of: 1) a "Fascist mentality" - it's MY system and I've got to control everything 2) An untrusting soul - Don't ever trust users with being responsible for their own password or even more, you just don't trust users 3) laziness - lets make things easier for the system manager, who cares about the users. Now, maybe there are environments where a high degree of paranoia is appropriate and maybe from experience in that environment, users can NOT be trusted for some things, and maybe there really are 10 million machines to support and just one person, but that is not always the case, nor is it even frequently the case, just as with my obviously gross-over-generalizations about how policies are made. YMMV. I really think that it's important to educate users and help them to use the systems responsibly in light of the particular environment. I also think it's important to help users be as productive as possible, and delaying work until putty or something is installed is not always the most productive approach. If I were in a corporate environment, where the company store has to be protected, even from the company, would I feel differently? Of course, because if I didn't I wouldn't be able to stay there long! :-) -- *************************************************************************** Jerry Winegarden OIT/Technical Support Duke University [EMAIL PROTECTED] http://www-jerry.oit.duke.edu *************************************************************************** _______________________________________________ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list