Re: Hardening a Solaris system.

From: Dave (d-a-v-e-5-7_at_wi.rr.com)
Date: 11/16/03

  • Next message: Casper H.S. ***: "Re: Hardening a Solaris system." 
    Date: Sun, 16 Nov 2003 13:35:35 -0600

    "Dr. David Kirkby" <see_my_signature_for_my_real_address@hotmail.com> wrote
    in message news:c99d2c79.0311140749.2e91890e@posting.google.com...
    > I know files that execute with root permissions by normal users (e.g.
    > su) can be a security risk. Is it necessary to have any such files, if
    > only the root user logs in ?? In other words, making the sytem
    > unusable to anyone but root.
    >
    > I'm particulary thinking about Solaris 9 on a Sun SPARCstation 20.
    >
    > I've set up a web server, running Apache, so are thinking about what I
    > can do to reduce the chances of it being hacked. I've done several
    > things.
    >
    > 1) Installing the bare minimum Solaris.
    > 2) Have a firewall hardware only open on port 80
    > 3) Turning off what services I don't need
    > 4) Not installed any man pages, so someone not knowing a Solaris
    > command would be stuck.
    <snip...snip>

     Good as a start but you have more to do... some of which is a repeat of
    other messages but some of which is not. If I were to build a secure server
    that ran apache I would do the following high level steps in addition to
    above:

     1) Use "pkginfo" and remove all un-needed services such as SNMP, sendmail,
    java (what's not used), unused drivers, remote admin, CDE, telnetd etc.
    Strip the machine right down to just what is needed. This is time consuming
    but worth it.
     2) Visit a file called /etc/inetd.conf and empty it. The only possible
    thing to leave enabled in here might be a backup port. But if that is not
    needed, consider disbling inetd all together. Even rename the executable to
    inetd.old. Don't use ftp or telnet, use secure shell (sshd).
     3) Remove unused accounts like lp, uucp, nuucp that are not used.
     4) Run a host based firewall, and worry about what goes out as much about
    what comes in. Restrict any ports left open for ssh and backups to where
    they are supposed to come from. IPFilter or SunScreen would be good. For
    example, if it is a web server all outgoing traffic should originate from
    port 80 or whatever your using. Rules to block anything else would be good.
    A simplified example:.
         pass in quick on dmfe0 proto tcp from any to <host ip> port 80 keep
    state
         pass in quick on dmfe0 proto tcp from <friendlynet> to any port 22 keep
    state
         pass out quick on dmfe0 proto udp from <host ip> to <loghost>
         block out log on dmfe0 from any to any
         block in log on dmfe0 from any to any
     This creates a situation where even if your host became compomized, the
    perp might not even know it. If they could start a process on port 9999 and
    it tried to go it would be blocked. And better yet, the firewall rules
    would log the event and tip you off to it.
     5) Read the apache documentation, there are security steps here. Do NOT
    run apache as root at run time. Consider a few things, "chroot" jail
    apache. And if your firewall permits port mapping, run it on say a port
    like 1080. The two objectives are not to run as root and jail the running
    app so it can't get to the rest of the OS. When setting up the chrooted
    path, only put in what is needed to make it run.
     6) Patch the system to current levels. Get the patch cluster with security
    patches.
     7) Once you have done all this, "ps -ef" and understand every ruuning
    process on the system, remove it if not needed.
     8) Whatever you serve in apache, test it. Test all work.
     9) Load "tripwire" and monitor it for all changes including web content.
     10) Assume your host is going to be compromised, and rig the log files to
    tell you if something funny is going on. If for example some process hits a
    firewall rule and gets logged - it could be signs of trouble.

    This just secures the OS, the application then needs a similar regiment. In
    fact, it is often the applications security holes that let hackers in in the
    first place.

    Also notice the trend of not running much on the system. This is for a few
    reasons. You need to understand what all is running and it's correct
    configuration. It is easier to remember 38 running processes than 238. It
    also gives a hacker fewer avenues for attack. It also gives the hacker
    fewer tools to work with if they do get the host.

    What I spelled out above is not perfect in the real world. You might have
    to compromise. For example, if you use Omniback it needs inetd on port 5555
    (?) to run. You would then enable it and run inetd but also firewall it off
    so only the backup host could see that port.

  • Next message: Casper H.S. ***: "Re: Hardening a Solaris system."