Re: how to make Unix box secure

From: Sam N (sam_at_unix.ms*nospam*)
Date: 07/29/03 

Date: Tue, 29 Jul 2003 09:09:53 +0100

"Bridge" <bridge_xue@yahoo.com> wrote in message
news:3e949365.0307281855.56440fa4@posting.google.com...
> Is there any way to find out who actully login to the Solaris box?
> Suppose the person knows the root passwd and su to root. If the person
> removed utmp and wtmp file, is there still any way to find out what
> the person did?
>
> How to make the Solais box secure, I mean how to find out what other
> persons did on the box?
>
> Many thanks!!

There are myriad things you can do to make your Solaris boxes secure, and to
describe a comprehensive list would be far outside the remit of a NG post. A
few *simple* things you can do however (and I'd recommend as any baseline),
are:

0: Who actually needs access to the box? Do you want to be able to log in
from public interfaces? Use a management net and access from a -secure
jump-off box or similar.

1: Harden the box: turn off all the crap in /etc/inet/inetd.conf that you
don't need. Remove any accounts that you don't need. Tidy up permissions on
files. This can be time consuming and it's easy to miss things, so get a
hardening script. I recommend Sun's JASS
http://wwws.sun.com/software/security/jass/index.html - once set up, this is
great. There's a demo output of what it can do at
http://www.unix.ms/secure.txt - If you're really concerned, why not consider
Trusted Solaris?
http://wwws.sun.com/software/solaris/trustedsolaris/index.html

2: He who logs longest laughs last. Turn up your logging! man syslog. (Also,
set your syslog server up to be a dot matrix printer with the line-feed
reverse disabled - any jeffk's trying to root you won't be able to delete
these logs unless they have physical access. )

3: Consider Access Control Lists - this way you can assign users to specific
jobs and vice versa - much safer than having numerous people knowing your
root password. Remember, if you have root, you are effectively God. man
setfacl, facl, getfacl.

4: Consider the physical security of the box. Where is it located? Is it
locked away, or can anyone access it?. You'd be surprised how many sysadmins
fail to consider the consequences of a physical breach of security. Social
engineering attacks are all too common - are you sure that guy fixing the
aircon in the lab isn't working for your competitor?

It's not only the machine itself you need to think about securing, it's your
whole environment. Think of security not as something you paste over the top
of an existing installation, but build it in at the design stage. Security
In Depth, I think it's called (apologies Alec :) )

I'm sure this thread will have many more replies - the concept of what
constitutes "secure" is of course entirely subjective. For me a box is
secure if it only does *exactly* what I want it to do, and nothing else.
Surprises are bad, mmkay.

Sun's Professional Services people come highly recommended if you want some
top advice :)

cheers

Sam N

Relevant Pages

  • Re: Encrypted file system without initial password:
    ... > This was not a question about potential root exploits. ... These settings can then be password-protected in the BIOS ... >> software-based security measure would be useless. ... the system should be fairly secure. ...
    (comp.os.linux.security)
  • Re: Renaming root account
    ... administrative user's username to enhance security that little bit more. ... > chflags and kernel secure levels. ... > root access they wouldn't be able to change files... ... > rc.conf in single user mode and then reboot change the flags back from ...
    (FreeBSD-Security)
  • Re: Compile problem
    ... It turned out after looking at the man pages for ld.so.1 the security ... Secure processes have some restrictions applied to the ... The default trusted directory known to the runtime linker is ... root, it has no problem finding the gcc library. ...
    (comp.mail.sendmail)
  • Re: Is there any encrypted or secure NFS?
    ... But that is certainly an order of magnitude more secure than basic NFS, ... which says that if you can root _ANY_ box on the network, ... Make sure you're familiar with Kerberos. ... forms of security. ...
    (Debian-User)
  • Re: how to restrict who can su to root
    ... >>It's strange that most free Unices have this option and Solaris has done ... >>minimum of security. ... > in as long as they possessed the root password. ...
    (comp.unix.solaris)