From: sunguy@cyrion.net
Date: Mon May 12 2003 - 19:54:41 EDT
Thank you all for your responses in this matter..
I would like to start by saying that most of the responses I've received
consisted mostly of rather negative comments about our cio, and
explinations of ssh etc. These are both things my team is already aware
of :-D lol...
However, what I was actually looking for was some sort of hard documented
"evidence" that I can use to try to sway him, or at the very least, to
have to cover my *ss. I have a number of books "Hack Proofing Solaris 8",
"Solaris 8 Security"(ISBN 1-57870-270-4) which i've found to be quite in
depth, however I was looking for something from SUN.
I managed to find a blueprints book: "Enterprise Seucrity" (ISBN
0-13-100092-6) with the words "The Official Sun Microsystems Resource
Series" on the cover. This states several times that all r* daemons
should be disabled and goes on to explain their inadequacies. I hope that
this might be used to persuade him.
I still have not found any official stance on the allowance of logins to
an account that has been locked (*LK*).
Also I've found that moving the original pam.conf back into place didn't
actually "fix" the system.. It allows rlogin / rcp, however when it is in
place root / users cannot set/change passwords. I will report back when I
figure this one out.
I would like to expand my security question to smartcards. I have
smartcard authentication setup locally on my sunblade workstation, however
I am curious if it is possible to use it for remote connections.. ie. I
am on box A, and i want to ssh to box B. Is it possible to have box B
search for presence of a smart card on box A and look for credentials
there instead of a password?
Also, would anyone know if it is possible to do card-auth with sunray's?
I know that sunray server will key your session id to a token on your
smart card, but there are no authentication credentials on that card.. Is
it possible to set that up similar to the sun blade?
Thank you all for the many responses.
-SunGuy
On Fri, 9 May 2003 sunguy@cyrion.net wrote:
> Hello,
>
> Every basic computer book or security book I've ever read always
> mentions the importance of having passwords, and not allowing accounts
> without passwords. Newer security books mention the importance of running
> (at least all system administration) remote connections through ssh.
>
> At my company (not disclosed, am emailing from alternate email),
> we are required to allow rlogin access to all by means of .rhosts files.
> In addition, everyone's account is locked *LK*, so they cannot login to a
> box without a .rhosts.
>
> This seems like a bug / security problem in soalris. A locked
> account should NOT be allowed to login. I have just recently upgraded to
> the latest patch level: 5.8 Generic_108528-20, which seemes to have fixed
> this bug by changing /etc/pam.conf. However this patch doesnt mention
> anything about rlogin. It's actually for ldap. [ 108993-18 SunOS 5.8:
> LDAP2 Patch ].
>
> Our CIO believes that it is better to NOT have passwords, because
> if a user has a password, it can be compromised. However in our setup, a
> potential intruder does not even need to attempt to compromise a password.
> Once he is in the network, he is granted free reign via existing rhosts on
> every account across multiple boxes..
>
> THE QUESTION:
>
> I would like to know if there is any hard documentation from SUN anywhere
> that effectively argues this fact (requiring passwords). Additionally, I
> 'd like to see something arguing in favor of ssh over rlogin, and finally
> the removal of .rhosts files.
>
> I would also like to know if the allowance of locked ( *LK* ) accounts to
> log into a system via .rhosts is an intentional "feature" or if it is a
> bug that nobody has noticed.
>
> I appreciate any assistance on this as I have been unable to find any
> "official" documentation on this, with the exception of o'reilly books,
> and what not. I think an official stance from sun is the only thing that
> may sway him.
>
> - SUNGuy
>
> PS.
>
> If anyone is in this situation and upgrades to 5.8 Generic_108528-20,
> patch 108993-18 is included in that patch cluster and moves your original
> /etc/pam.conf to pam.conf.pre108993-18. Simply moving it back will
> restore previous operations.
> _______________________________________________
> sunmanagers mailing list
> sunmanagers@sunmanagers.org
> http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:26:24 EDT