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

Reply via email to