Re: Putting together a server/network...

["Dr. Evil" <drevil@sidereal.kz>]

> 	No, it is YOU who don't understand.  Security is based on knowledge and
> understanding, period.  If Steve needs to know what makes telnet
> unsecure in a certain environment, it is best to inform him so that he
> then can figure out what ELSE is insecure in that environment. 

He seemed to have a pretty good handle on it.  He knew what a switched
LAN is and why it is relevant to unencrypted protocols (ie, it may
provide some protection against LAN sniffing).  That's why I answered
the way I did.  If he had asked, "what's the diff between telnet and
ssh" or some lower-level question I would have answered differently.

> Furthermore, using ANY security system without knowing why it works will
> rarely help - you can make the people lock their doors, but if you don't
> explain about the thief in town, they'll still throw open the windows
> when it gets hot.

Right, that's very true.  Even more generally, you shouldn't use
systems you don't understand to do stuff which is important.  This
especially applies to security, explosives and firearms...

> 	At work, I use rlogin and telnet a lot - for communicating between
> machines which (1) are behind a firewall and (2) don't contain anything
> worth stealing (it's a test network).  This saves me a lot of time
> installing ssh & co., which would provide no net gain.

Yup, exactly.  In my post, I said there may be some cases where plain
old telnet is the right thing to do, and use on non-important test
networks might be a case where telnet is fine.  I would _never_ say
that everything should always be encrypted.  There are absolutely no
universally-correct security policies.

> 	In any case, an argument of "I say so, so you have to do what I say
> unless you can PROVE to me that you shouldn't" doesn't wash after second
> grade!

It does wash with security stuff; you have a choice between having a
vulnerability and not having it.  You need to prove why you should
have the vulnerability, not why you shouldn't have it.  The proof
could be really simple, as in the case you gave: "There aren't any
valuable resources on this network, the threat is small and I don't
want to waste time (money) installing ssh."  But the decision should
be made consciously and with some understanding.

> > Cryptography everywhere is a very good idea.  OpenBSD is almost
> > there...  It has only one huge gaping hole of plaintext.
> 
> 	Which would be what?

File system encryption.  It's got network encryption (SSH, ipSEC, and
SSL, I think) and it's got swap encryption, and it has two broken ways
of doing FS encryption (tcfs and encrypted vnd) but it doesn't have
any way of doing FS encryption that is "release quality".  This is a
real shame because it seems like it would not be that hard to fix
tcfs, perhaps.  The place where I used to work had all the laptops
stolen from the executive offices one night.  Disk encryption is a
good option to have for cases where the machine may not have good
physical security, like a laptop, or a server being kept in a location
with poor physical security, or a desktop machine.

Let me put it another way: Windows XP has a basic encryption/security
feature which OpenBSD doesn't have.  That seems WRONG!  I can just
imagine the conversation: "Well, we'd love to install OpenBSD on these
laptops, but I guess we need to use Windows XP instead... maybe when
OpenBSD 3.1 comes out..."