YASSP

Post installation steps (for beta#15)

www.boran.com/security/sp/solaris/yassp/after.html 

Overview

After completing the SECclean installation, there are further configuration steps that may be necessary. Your choices will depend upon the applications installed, the type of usage, the hostility of the network environment, and other site specific criteria. These steps are outlined below.

• Yassp configuration
• Mounting file systems restrictively in /etc/vfstab
• RPC
• General configuration
• Patches
• Logging
• Limiting SUID files
• File Integrity Checking
• Minimising GUI daemons/services
• Final Note

References and further reading
Changes to this document

Yassp configuration

Workaround for limitations in Yassp beta #15:

1. Secure Shell (SSH):
   • SSH is a good thing, it should be considered essential for any UNIX system. There are several SSH variants. Yassp bundles OpenSSH, but there are a few issues:
     • SecurID authentication is not yet supported (use SSH1 for that).
     • The Solaris SUNWzlib package must be installed first.
     • Binaries are only available for Solaris 8 and they are not backwards compatible.
     • See also www.OpenSSH.com
   • Create empty /etc/primes, which is missing:
     > touch /etc/primes
   • The server side of scp will not work as expected without either including /opt/local/bin in the PATH visible to the SSH daemon (e.g. in .bash_rc) or adding the following link: (Note from Jean: corrected in Beta#16)
     > ln -s /usr/local/bin/scp /usr/bin/scp
     
2. Solaris 8 10/00 includes a new daemon 'picld', not covered by Yassp. The man page says: "Platform Information and Control Library (PICL) provides a mechanism to publish platform-specific information for clients to access in a platform-independent way. picld maintains and controls access to the PICL information from clients and plug-in modules. "
   Consider disabling it:
   mv /etc/rcS.d/S95picld /etc/rcS.d/.S95picld
   mv /etc/init.d/picld /etc/init.d/.picld
3. Tocsin (from Doug Hughes) is a 'featherweight' Intrusion Detection System. A binary package is included in the Yassp tarball, but not automatically installed. Read the Tocsin notes below and install it if needed:
   > pkgadd -d aubtocsin

Having installed Yassp, the first thing to do is browse the man pages yassp.conf(4) and yassp(1) and have a look at the configuration /etc/yassp.conf. Typically nothing needs to be enabled for bastion hosts, except ssh access. /etc/yassp.conf is well commented and should be easy to understand.

1. Accounts
   • The default umask for daemons and users (DEF_UMASK) are both set to 077 (no group or world access). In many environments, it makes sense to change the user umask to 027, allowing group read access by default.
   • cleanup_passwd disables, but does not remove user accounts from /etc/passwd (by default). The USERDENIED variable in yassp.conf contains the default list. Add any non-standard application accounts (that you likewise want to be disabled).
   • If you prefer that certain accounts are actually deleted, set the USERDELETED list in yassp.conf and rerun cleanup_passwd.
     Note: This may result in orphaned files and a corrupt package database if it mentions files where the owner is removed. Patch scripts need the user nobody - don't delete it.
   • The ROOTALLOWED variables lists accounts that are allowed to have a UID of 0 and cleanup_password will disable any UID 0 accounts not listed. If you need to have other accounts with UID 0 you will need to list those accounts as well. However, we do not recommend that practice.
2. Cron:
   • If any user other than root needs to use at/cron, then the allow/deny files in /etc/cron.d/ will need adapting.
   • The root cron was replaced rather than edited, if you already had added entries, they will have to be re-added. The old cron is backed up under /yassp.bk.
   • If you don't want to run the Yassp example daily script for log pruning, comment it out in the root cron.
3. SSH: Yassp has installed an SSH client and server, with a pretty tight configuration.
   • This version of SSH is "tcp wrapper" enabled, so access must also be granted in /etc/hosts.allow, by default no access is possible.
     • To enable any host to access this ssh server, add the following to /etc/hosts.allow:
       sshd : ALL
     • To allow X11 forwarding to work with SSH, add the line:
       sshdfwd-X11: LOCAL
   • Tip: Do not use reverse fingers in the SSH rules in hosts.allow/deny (TBD: explain why.. finger storms?)
   • 'scp' is normally used to transfer files in SSH. However, there is also the option to allow file transfer with the new SSH2 option, 'sftp'. If needed, enable it in /etc/sshd_config. Since this is quite a new feature, don't use it unless really necessary.
     Subsystem sftp /opt/local/libexec/sftp-server
   • To forbid RSA user authentication and require passwords:
     RSAAuthentication no
   • TBD: description on how to disable or restrict root login.(SSH ignores /etc/default/login unless "uselogin" is true?)
   • Check other settings in the default server configuration /etc/sshd_config and client configuration /etc/ssh_config. For example, consider only allowing specific users to access SSH and deny daemon accounts access.
4. Syslog: On Solaris 8, Yassp will start syslog with the "-t" option, so it will not accept syslog connections from other hosts. So, if you want to run a central syslog server, set
   SYSLOGFLAGS=""
5. If INETD services are needed, set RUNINETD to YES and uncomment the appropriate line in /etc/inetd.conf. By default, all inetd.conf services have been disabled by Yassp -- reopen specific services, only if absolutely needed. Use tcp wrappers if possible (examples for finger and tftp are listed in inetd.conf), and edit the tcp wrapper access control files /etc/hosts.allow and /etc/hosts.deny.
6. "The Name Server Cache Daemon (nscd) daemon:
   • Some applications such as Netscape's http proxy will not work if nscd does not run, hence there is a NETSCAPE or NSCD variable which can be set to activate nscd.
   • If nscd is turned off, the load on the nameserver will increase, so consider varying the order of nameservers in resolv.conf files to balance the load. Worse nameserver performance has been noted on some webservers after turning off nscd.
   • Nscd is involved in name services other that host lookups. On large many-user systems it can be improve performance significantly for even silly things like user lookups for an "ls -l" command.
7. Edit login banners to warn users about unauthorised access, you may need this if you want to prosecute intruders. For Telnet and SSH, use /etc/issue (for pre-login) and /etc/motd (for post-login). Default banners are installed by yassp.
8. Yassp tunes Solaris by adjusting /etc/system, these may need further modification.
   • It increases file descriptor limits rlim_fd_max=1024 and rlim_fd_cur=256. Some applications may need a higher value (or had already set a higher value before Yassp was installed), in which case this value will have to be adjusted.
     Increasing the soft limit for Solaris < 8 to 256 does not hurt, and might help some applications. The hard limit should be left at 1024 (not entered, or entered as comment) in a very generic installation. The final values depends on how the server is to be used. Any application needing more (e.g. Squid, innd, ...) knows how to increase their own soft limit to the given hard limit, the sys-admin will have to know which apps will need a higher hard-limit and set /etc/system accordingly.
   • Corefiles are disabled sys:coredumpsize = 0, some admins may prefer to have access to cores for debugging. Be aware that core files can contain sensitive information, since it is a memory dump.
   • Yassp increases number of concurrent login sessions (SVR4 style ptys) to 128 (set pt_cnt=128). On Solaris 8, this means that more that 128 sessions are not allowed, since the devfsadm daemon is also stopped by Yassp (devfsadm would dynamically increases ptys as required). Therefore you may need to disable or increase this setting on large multi-user servers. (Note to Jean: the pt_cnt entry should be removed for Solaris8 in beta#16).
   • Other settings:

     * Attempt to prevent and log stack-smashing attacks
     set noexec_user_stack=1
     set noexec_user_stack_log=1

     * enable advanced memory paging technique
     * NOT NEEDED ON Solaris 8: set priority_paging=1

     set tcp:tcp_conn_hash_size=16384
     * If the NFS_PORTMON variable is set, then clients are required to use
     * privileged ports (ports < IPPORT_RESERVED )in order to get NFS services.
     set nfssrv:nfs_portmon=1
     * max users processes in here too
     set maxuprc=150

   • See the following for a more complete discussion:
     http://www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html#rfc
     http://www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html#solfuture

In the next sections we run through additional configuration, not directly covered by Yassp.

Back to top

Mounting file systems restrictively in /etc/vfstab

Several options can be set to improve the security and robustness of filesystems when they are mounted. Run the mount command to check that filesystems options are effective.

Be very careful when editing vfstab, e.g. an error on the / or /usr lines can render the system unbootable! If this happens, boot from cdrom in single user mode, mount the problem disk, correct vfstab and reboot. Some examples of vfstab entries are:

A simple server with only a root and /var partition, running Solaris 2.8:

fd                -                  /dev/fd fd - no -
/proc             -                  /proc proc - no -
/dev/dsk/c0t3d0s1 -                  -    swap  - no  logging
/dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0 /    ufs   1 no  logging
/dev/dsk/c0t3d0s7 /dev/rdsk/c0t3d0s7 /var ufs   1 no  logging,nosuid,noatime
swap              -                  /tmp tmpfs - yes size=100m

and on a larger server:

fd                -                  /dev/fd fd - no -
/proc             -                  /proc proc - no -
swap              -                  /tmp tmpfs - yes size=200m 
/dev/dsk/c0t8d0s0 /dev/rdsk/c0t8d0s0 /    ufs   1 no  logging
/dev/dsk/c0t8d0s1 -                  -    swap  - no  -
/dev/dsk/c0t8d0s4 /dev/rdsk/c0t8d0s4 /usr ufs   1 no  logging
/dev/dsk/c0t8d0s6 /dev/rdsk/c0t8d0s6 /var ufs   1 no  nosuid,noatime,logging
/dev/dsk/c0t8d0s5 /dev/rdsk/c0t8d0s5 /opt ufs   2 yes logging

Reboot to allow the vfstab values to have effect.

Back to top

RPC

RPC services should be avoided on sensitive servers, such as those on the Internet or in a DMZ. RPC uses dynamic ports and provides no standard access control methods. However, some programs insist on having RPC e.g. CDE, OpenWindows, Disksuite and Legato Networker. If possible avoid RPC, otherwise....

Improving Disksuite Security:

OK, lets' get back to general measures for RPC security:

• If you are using Solaris 8, the bundled (free) Sunscreen EFS lite Firewall can be used [2] to filter who can access the rpc services (since the Sunscreen includes an RPC state filter engine), or...
• IPfilter [6] can also be used as local firewall to prevent access to RPC services.
  • It's free and works on older Solaris, not just 2.8.
  • It doesn't have an RPC state based engine though (so it can't filter on RPC program names or allow RPC to specific destinations),
  • but it can be used to allow all localhost RPC traffic (enough for some RPC applications such as Disksuite or CDE) and deny all remote traffic except, say, HTTP or whatever service is provided to remote hosts.
• Use Wietse Venema's rpcbind (included in the Yassp tarball), which provides tcp wrapper-like access control and logging. Rpcbind is a "directory" service that's used to locate a service (by RPC name or by RPC number). Since it is not used to mediate the connection to the service, it cannot provide access control to the actual RPC programs. A port scanner can detect active RPC services and unless the kernel is adapted to filter such connections it's impossible to prevent others from accessing them.
  Summary of features (extract from the README):

  - host access control on IP addresses. The local host is considered authorized. Host access control requires the libwrap.a library that comes with recent tcp wrapper implementations.
  - requests that are forwarded by the rpcbind process will be forwarded through an unprivileged port.
  - the rpcbind process refuses to forward requests to rpc daemons that do (or should) verify the origin of the request: at present, the list includes most of the calls to the NFS mountd/nfsd daemons and the NIS daemons.
  - the rpcbind process refuses REMOTE requests sent to high-numbered UDP ports (instead of TCP or UDP ports 111). High-numbered ports are opened by the rpcbind server as a side effect of other activity. These ports could be abused to bypass packet filtering restrictions. See the advisory (and addendum) on http://www.secnet.com/

  • It is based on the Solaris 2.3 sources for rpcbind, which were made publicly available by Sun in 1994. A code review was also conducted (by Jean Chouanard) on the differences with Solaris 2.7's RPCBIND, the differences were minimal.
  • The additional logging is useful. If RPC is restricted to localhost, and 'rpcinfo -p' is attempted from another host, the following is logged:
    Aug 4 14:55:15 myserver rpcbind: refused connect from 160.97.24.221 to dump()
  • By default, logging is to syslog MAIL.INFO, in Yassp it is changed to AUTH.INFO. [Note: Yassp beta#16 should fix this]
  • Switch on this RPCBIND by setting RPC=YES and WVRPCBIND=YES in /etc/yassp.conf (the actual binary is /usr/sbin/WVrpcbind).
  • By default, access is only allowed to localhost, otherwise 'rpcbind' entries will have to be added to /etc/host.allow|deny for IP level access control. As an example, to allow communications between rpcbind and localhost or 176.17.17.5 add the following line to /etc/hosts.allow:
    rpcbind: 176.17.17.5

Back to top

General configuration

• Routing:
  • Avoid DHCP for sensitive or Internet systems and do not rely on dynamic router discovery.
  • For default routes, add the IP address of the router to /etc/defaultrouter
  • or for static routes, create a startup file in /etc/init.d/static_routes and a symbolic link under /etc/rc2.d/S99static_routes using the 'route' command.
  • Empty the routing table and add a route for a specific network, e.g.:
    > route -f add net 129.97 `cat /etc/defaultrouter`
  • If you must run the routing daemon (we don't advise this - use a dedicated router instead), make sure you understand how it works. The paper [7] is a good resource. Misconfigured routers can subvert default routes and impair network service. Consider running in quiet mode, or tell the interface not to publish routes with the 'private' option to ifconfig. To run the routing daemon in quiet mode, set SUNSTARTUP=YES in /etc/yassp.conf and make sure no default router is specified.
    
• Configure /etc/hosts with a list of critical machines which you don't want resolved via DNS. Configure /etc/nsswitch.conf to use files first and dns second for host lookups. If a DNS client resolution is necessary - add the domain name and DNS servers to /etc/resolv.conf and a DNS entry for "hosts" in /etc/nsswitch.conf.
• Environment: /.cshrc /.profile: set aliases, variables (such as VISUAL, EDITOR and PATH - don't include ".").
• The useradd tool is a typical way of adding new accounts to the system. The first time it is run and defaults are set, it creates /usr/sadm/defadduser for new user accounts. This might be a good time to edit this file and set the defaults you expect to use for new user accounts (e.g. shell, groups, expiration).
• Email client: If hosts are not supposed to send email outside the subnet, don't configure the mailhost alias (in /etc/hosts). Delete /usr/lib/sendmail if you don't need any kind of email. Otherwise,
  • edit /etc/mail/aliases, at least point mailer-daemon, root and other system accounts to real addresses.
  • add an entry with the IP address of the mail-server in /etc/hosts with the mailhost alias
  • add an entry with the fully qualified domain name (FQDN) of your machine to /etc/hosts -- i.e. add a hostname.YOURDOMAIN.COM alias for your machine. Otherwise sendmail may constantly log errors about not knowing the FQDN.
  • in /etc/mail/sendmail.cf set the following to ensure all outgoing email is relayed to mailhost (the grayed-out bits are normally not needed on Solaris 8):
    Dj$w.YOURDOMAIN.COM.
    DSmailhost
    DRmailhost
    DHmailhost
    O FallbackMXhost=mailhost
  • Add a root cron entry to flush spooled email every hour:
    /usr/lib/sendmail -q
  • send a test email to check the config:
    > mailx -v -s test_email root </dev/null
    
• Email server: If you really need to receive Email (i.e. run an SMTP server), it's not a trivial task. Refer to [4].
  
• Protecting the console with EEPROM options:
  • On high availability servers where the console is exposed to unauthorised users switch on security, which requires a password to be entered each time the EEPROM prompt is accessed.
    a) This should be used with care, as forgetting the password can render a machine useless.
    b) This password is needed for each reboot (so console access is needed for rebooting)
    c) This has the additional benefit of preventing a DoS attack: if an attacker does penetrate the machine at some stage later in it's life, he cannot set a random password and hence render the host useless until the NVRAM has been replaced.
    > eeprom security-mode=command
    
  • The Stop-A keyboard sequence can be disabled by setting KEYBOARD_ABORT to disable in /etc/default/kbd Of course "STOP-A; sync" won't work anymore which can be a major inconvenience, so it's suggested only for physically insecure environments.
  • If managing a console via serial cable, an alternate BREAK signal can be set to prevent terminal power cycles causing a stop of the console and to allow the break signal to be sent from terminal emulators that cannot send a BREAK signal properly (e.g. HyperTerminal). STOP-A behavior from a graphical console will not be affected by this setting.
    This feature is only available since Solaris 2.6 and requires patches:
    2.6 - requires patch 105924-10 or later
    7 - requires patch 107589-02 or later
    8 - functionality is already integrated.
    - To enable the new break signal which is <RETURN> <TILDE> <CONTROL-B>, edit /etc/default/kbd and set KEYBOARD_ABORT=alternate. (Make sure Tilde '~' works correctly on your keyboard first!).
    
• Time Synchronisation:
  • If you think you might have to produce evidence in court, use NTP to synchronise time, not rdate. Rdate sets the time, whereas ntp skews the clock to the right time. Prosecutions have failed because, on busy servers, a few seconds difference could be used to insist that there is a doubt about the identity of a session. This happened to a bank in Australia trying to prosecute an Internal Attacker.
  • If using NTP, either get a (cheap) radio clock (if you are near an appropriate transmitter - e.g. the Stuttgart transmitter in Germany), or setup a dedicated bastion host as a 2nd stratum NTP server, which uses three 1st stratum sources.
  • Setup the firewall filter to allow only NTP from the bastion NTP server to the three 1st stratums and allow Intranet hosts to query the bastion.
  • Other hosts can synchronise to the NTP servers via a simple cron command, they don't have to run the ntp daemon:
    > /usr/sbin/ntpdate -s ntp1 ntp2 ntp3
  • NTP can also be setup for higher security by configuring DES+MD5 authentication keys on server and client, see man xntpd.
  • Some sites rely on ntp broadcast time - everyone on the cable is a peer. Don't trust that.
    
• If you are using multiple network interfaces, you may want to use a different Media Access Control address (MAC or also called Ethernet address) for each of them. By default, Solaris will use the same MAC addresses for all the network interfaces. It will use the MAC address which is burnt in the EEPROM motherboard. If you want each network interface to use its own MAC address, type:
  > eeprom local-mac-address\?=true
  
• C2 auditing/BSM: Solaris contains an audit trail feature called Basic Security Module (BSM). This can be useful for tracking commands executed by users. See also www.boran.com/security/sp/Solaris_bsm.html .
  
• Headless x86: It is possible to get PCs to use the serial port A (COM1) as their consoles. On Solaris 8:
  > eeprom ttya-ignore-cd=true
  > eeprom input-device=ttya
  > eeprom output-device=ttya
  However the keyboard must be left attached on most PCs, for example on my test Compaq which did not have a BIOS option to disable the keyboard.
  See also Question 6.20 on http://www.sun.pmbc.com/faq/6.html and http://aa11.cjb.net/sun_managers/2000/01/msg00326.html

Back to top

Patches

Wait, don't skip to the next section just yet! Yes, patches make us all yawn... are they a waste of time? This sections presents some strategies for handling patches and tools to make life easier.

During installation, the Solaris recommend patch bundle was installed. However, not all security fixes are included in this bundle, and as time goes by you'll have to check regularly for new patches. Systems which have security patches installed are more secure than those which don't. For overview of the concepts of Solaris Patching, "A SunSolve Patch Primer"  [1].

Patch strategies

Weakness are continually discovered in Solaris and 3rd party applications. Not only do the weakness pose threats but the volume of weaknesses and patches can be a threat: if not managed carefully, they will consume too much time or they will be simple ignored.

The first problem is to be aware that weaknesses and/or patches actually exist. Possible strategies are:

1. Get on all the mailing lists of organisations such as CERT/First, vendors like Sun, and especially Bugtraq. This can consume quite a lot of time.
2. Get on the mailing list of an organisation which produces regular summaries of weakness/patches and security news, for example SecurityFocus (Sun section/ email list) or SANS. If a regular source of reliable information on Solaris and the applications that you use can be found, it may save much time.
3. Run a tool on important servers that checks the current patch level and compares it with the newest list of patches available from Sun: This is the ideal situation (it is discussed below in more detail).
4. Check Sun's recommended patch bundles for changes every month or two: This requires little effort, but security is not as tight and the recommended bundles do not cover all Security problems. The recommended bundles may cause problems with some applications though, if kernel patches are applied.
5. 3rd party application patches need to be checked and applied too. Don't forget them!

How do you decide whether a weakness is worth patching?

• If the weakness concerns a remotely exploitable weakness in an active network daemon, exposed to a hostile environment like the Internet, install it soon.
• If the weakness concerns a local exploit of a tool not normally used, not a daemon and on a host where only root or administrator accounts exist, it may be enough to install the patch together with a bundle at regular intervals (e.g. every six months).
• If the weakness concerns a local exploit of a tool on a host where non-administrative users have accounts, then it depends on how critical the system is and how much the users can be trusted. Regular patches to multi-user systems are advised.
• If the systems runs highly specialised software like databases, be very wary of installing Kernel, I/O and driver patches. It is advisable to test patches on a separate system first.
• Patches differ by Solaris version and architecture. So it makes sense to try and keep servers of the same OS/architecture on the same patch-level and define a master host, whose patch level is automatically checked at regular intervals.

Patching Gotchas:

• Beware of sendmail patches (even in the recommended bundle), they can overwrite configuration and startup files without asking. An example is 105395-06 on Solaris 2.6.

  			Warning: Sun patches may reverse some of Yassp's changes. Therefore, reboot after applying patches and check carefully that no unexpected daemons are running and all services operate as expected.

• The Solaris tool Patchadd is the script used to install patches, but it has also had bugs and may need patching! So ensure that your patchadd is up-to-date before installing other patches, otherwise patchadd may refuse to install some patches. On 15th Feb 2001, the relevant patches were:
  106125-10 SunOS 5.6: Patch for patchadd and patchrm
  106126-10 SunOS 5.6_x86: Patch for patchadd and patchrm
  106960-01 SunOS 5.7: Manual Pages for patchadd.1m and patchrm.1m
  106961-01 SunOS 5.7_x86: Manual Pages for patchadd.1m and patchrm.1m
  107171-08 SunOS 5.7: Fixes for patchadd and patchrm
  107172-08 SunOS 5.7_x86: Fixes for patchadd and patchrm
  108987-02 SunOS 5.8: Patch for patchadd and patchrm
  108988-02 SunOS 5.8_x86: Patch for patchadd and patchrm
  110763-01 Trusted_Solaris_8_x86: patchadd doesn't work correctly

Tools to help find and install patches relevant to your system [1]:

• GetApplyPatch and CheckPatches are Bourne shell scripts for Solaris patch management, that I use myself and can personally recommend. Below we provide some examples on how to use them, but they are distributed with lots of doc that will help you even more.
  1. CheckPatches: is a script that uses showrev to see what patches are installed, compare this against the Solaris patch report, and makes a list of recommended and security patches that need installation. It expects to find 'SolarisX.PatchReport' in the current directory (or you can use '-f' to download the latest Patch report via ftp)
     > ./CheckPatches -f
  2. GetApplyPatch: is a script to get and apply a patch. Arguments are a list of patch numbers.
     If run from an interactive session it will: ask you to confirm the download, show you the patch readme, ask if you want to install the patch and if you want to tidy up when done. It can also run without prompting in "batch mode" (-b).
     > ./GetApplyPatch 108875-07
     We can also download the patch via a proxy, if direct ftp access to the internet is not available:
     > ./GetApplyPatch -s proxy1 -u anonymous@sunsolve.sun.com 108875-07
     A cron script for automating this and emailing the results is included (CheckPatches.cron).
  3. Both scripts can be used together to get each patch that is needed and install it. By default this is interactive: it downloads the patch list and works out what patches are needed, then for each patch, you are asked if you want to download the patch, then view the readme, then install it, delete the patch files and move on to the next one. Cool.
     > ./CheckPatches | ./GetApplyPatch
     A cron script for automating this and emailing the results is included (GetApplyPatch.cron). I would not recommend automatically applying patches on important (high availability) servers.
  4. Other features:
     • Man pages are included as is a Makefile, that put the stuff in /usr/local by default.
     • Solaris Intel and SPARC is supported & tested. 
     • ftp proxies may be configured and you can download from your local mirror rather than Sunsolve.
     • CheckPatches can be configured to ignore certain patches. For example, we have a Solaris8 x86 server and CheckPatches reports that we need:
       109897-03 SunOS 5.8_x86: USB patch
       109952-01 SunOS 5.8_x86: jserver buffer overflow
       110417-02 SunOS 5.8_x86: ATOK12 patch
       But we don't use any of these products, hence we'd like to ignore patch information of these. So we create a file Solaris8_x86.PatchReport.Except in the same directory as Solaris8_x86.PatchReport, that contains the above 3 lines and CheckPatches will automatically ignore any patches with the same major number and description. Neat.
     • Alternatively we could suppress the output of CheckPatches with our own expression, e.g.:
       ./CheckPatches | egrep -v "109897|109952|110417"
     • The cron scripts are for automating the whole business. For a complex example, lets say we installed in /opt/patches ("make ROOT=/opt/patches") and we want to:
       - check the patch level on the 4th of each month
       - and automatically apply them on the 6th (we have two days to react if we don't want patches installed)
       - all reports and files are stored in /opt/patches
       - the results are mailed to 'sean@yassp.org'

       5 0 6 * * ROOT=/opt/patches VAR=/opt/patches ADMIN=sean@yassp.org /opt/patches/etc/CheckPatches.cron
       5 0 4 * * ROOT=/opt/patches VAR=/opt/patches ADMIN=sean@yassp.org /opt/patches/etc/GetApplyPatch.cron
       

  5. Problems: Many problems were fixed and improvements added in Dec'00/Jan'01. The version we tested here was from 26.Jan'01.
     - Sometimes it does not install a patch because some other patch is required. Hopefully a second run catches those.
     
• The Patchdiag tool from Sunsolve can be used along with the latest patchdiag.xref to see what recommended and security patches are missing, then download & install the missing ones. This tool is apparently free, but only available for download for contract customers.
• The Patch Check tool, released in April 2001, from Sun, which is apparently free. Not yet tested.
• Consider checking with the SecurityFocus vulnerability calculator. Execute the following:
  > showrev -p | cut -f2 -d' ' | xargs
  and then paste it into the window on SecurityFocus.com and select OS version, architecture and hit run. This will probably result in a long list of vulnerabilities, most of which are not relevant. Go through the list looking for applications or services that are active on your host, that then need fixing. A link is provided for each vulnerability, where more details and fixes can be found. This list of vulnerabilities includes not just Solaris, but all third party applications.
• FastPatch is a replacement for patchadd, the same but a lot faster. (TBD: is that all? Should we drop it from this documentation?)
• Patchreport is a script that does everything CheckPatches and GetApplyPatch do, plus checking integrity of patches via MD5, logging in to sunsolve to get the public patch reports or if you have a Sunsolve ID and getting the full patchdiag.xref file. It's written in Perl and does require quite a few Perl modules to be installed. Not yet tested in detail.

Back to top

Logging

Syslog logging: Yassp uses a modified syslog configuration /etc/syslog.conf which enables more logging than the default and saves logs in /var/adm/messages. An optional /etc/syslog.conf.server is also installed by Yassp, which is designed for loghosts and splits up services into separate logfiles.

Yassp has disabled the Solaris log pruning and other lines in the root cron. It added an entry to run the "daily" script, which you may wish to examine. This script prunes and compresses the logs listed in the LOGS variable (and moves them to /var/oldlogs), and uses rcs to backup configuration files in the BACKUPF variable to /var/backups. The default settings for these variables are:
BACKUPF="/etc/passwd /etc/shadow /etc/group /etc/yassp.conf /var/sadm/install/contents"
LOGS="/var/log/authlog /var/log/sshlog /var/adm/messages /var/adm/named /var/log/kernlog /var/log/userlog /var/log/maillog /var/log/daemonlog /var/log/lprlog /var/log/newslog /var/log/cronlog /var/log/local0log /var/log/local2log /var/log/loc al5log /var/log/alertlog"

Improvements to consider:

• Syslog client: Designate one machine as the loghost (in /etc/hosts).
  • Test that logging to the server works correctly:
    > /usr/ucb/logger -p auth.warn "test of syslog"
    and check that it appears in the server logs.
  • If you would like a copy of logs to be kept locally, as well as remotely, uncomment the line in /etc/syslog.conf:
    *.err;auth.info;kern.debug /var/adm/messages
  • If syslog does not work as expected, read the commented example and tips in syslog.conf.
    
• Syslog server or "loghost":
  • Give the loghost a whopping great disk for logs.
  • On Solaris 8, Yassp will start syslog with the "-t" option, so it will not accept syslog connections from other hosts. So, if you want to run a central syslog server, set SYSLOGFLAGS="" in /etc/yassp.conf.
  • An optional /etc/syslog.conf.server is also installed by Yassp, which is designed for loghosts and splits up services into separate logfiles in /var/log. So copy over the appropriate config file and restart syslogd:
    > mv /etc/syslog.conf /etc/syslog.conf.client
    > cp /etc/syslog.conf.server /etc/syslog.conf
    > kill -1 `cat /etc/syslog.pid`

Back to top

Limiting SUID files

Files which have the SUID bit set (an "s" where the execute bit for the owner/group is shown in 'ls' listings) allow the user executing the program to assume the identity/group of the owner of the program. This is typically used to allow normal users access to certain functions only allowed to root, for example binding to low ports, mounting a floppy disk, etc. The problem is that historically, many security weakness have been found in such programs allowing attackers with local accounts to become root by exploiting buffer over flows, race conditions etc.

• Solaris has many "SUID/SGID" binaries and each one presents a risk, so when hardening systems it is advisable to disable as many  as possible. Newer Solaris releases have less SUID programs, but still have far more than the newer Linux distributions for example.
• On Solaris 8, all SUID bits could be removed and RBAC (role based access control) used to provide selective access to those tool, with root id. See the man page rbac(5). This solution is not discussed here.
• The purpose of this section is to provide a brief overview of the subject, a list of documents and scripts for disabling SUID files are provided.

What SUID files are on the system?

How should we handle SUID files? Possible courses of action, in order of preference, are:

What SUID files need to be limited?

Further reading:

• Reg Quinton explains [8] each Solaris SUID file and recommends settings, together with an appropriate script that can be customised. The recommended settings are for "medium" security systems.
• See [8] for SUID references and further reading.

To Do:

Back to top

File Integrity checking

Regularly check the integrity of files on the system, to be assured that they have not been maliciously modified. Solaris provides "pkgchk -n" which checks the package databases against the size, permissions and checksums of actually installed files. This is useful and recommended, however checksums can be fooled and the package database can itself be manipulated, so it is no protection against the clever attacker (or the 'script kiddie' with clever tools). What is required, is a file integrity checker that uses secure (one-way) hashing algorithms.

Which is why the Yassp Tarball installs tripwire in /secure/tripwire. Tripwire uses several secure hashing algorithms (and in it's commercial form, provides cryptographic signing of it's database).

After the initial installation you should take a snapshot of the files on the newly configured system, i.e. initialise tripwire's database and then run regular checks to monitor for changes. If possible keep the master database on another machine, offline or on write-once media.

What options do we have for integrity checking?

• Tripwire [3]: There are both free and commercial versions (which costs ~$500.-/host).
  • The free version can be tricky to get working correctly and has a few bugs. Source code is provided. It may crash on very large disks. This is the version included with Yassp.
  • The commercial version is a bit pricey - except on Linux where it is free. Reports are verbose (you'll need filter scripts - V2.2.1 is better in this regard, then again 2.2.1 is buggier than 2.0.1) and more configuration examples should be provided. It is more stable than the free version, also runs on RH Linux and NT and offers enhanced security by cryptographic signing of policy and configuration files. Personally I've found that Support, even when paid for, is not great.
  • Neither version supports the use of regular expressions when defining policy rules. e.g. you can't specify a rule for "/home/*/www/cgi-bin" files, that would work even when new directories are added under /home.
  • The commercial Tripwire was released as OpenSource for Linux (but not Solaris) in October 2000. It's under the GPL, so presumably it could be ported to Solaris by volunteers.
  • A good mix is to use the commercial version on a secured central host, which then runs the free version remotely via SSH on all other hosts.
  • An added layer of protection can be provided by PGP signing the tripwire database.
    
• PGP can also be used by signing files to be protected (creating lots of signature files), then writing a script to check the validity of signatures. This will not catch permission, link, inode or modify date changes though.
• MD5 hashes (one way hashes that are more secure than non-unique CRC checksums) could be used in a similar way, but the list of MD5 hashes should not be stored on the system being monitored, unless it is PGP signed or encrypted.
• Aide is a new GPL tripwire replacement that looks interesting, I've not had a chance to test it so far. [3]
• Fcheck is also a GPL tripwire replacement.[3]

An example using the free Tripwire Version 1.2 (bundled with Yassp):

• Adapt /secure/tripwire/tw.config for your site, if needed.
• Next, the "initial state" of the system needs to be saved:
  > cd /secure/tripwire; ./tripwire -i 2 -initialise -c tw.config
  This will create a new file database (which may take 5-15 minutes). Lots of warnings like "No such file or directory" may appear, just ignore them.
  Note: we run tripwire with the "-i 2" option to increase speed (it disables one checking algorithm, snerfu, but SHA1 and MD5 are still used).
  Copy the newly created database (in /secure/tripwire/databases) to a floppy or another machine where it is safe (encrypt it if possible). This backup of the tripwire database will be useful for forensics, if the machine is ever attacked or suspected of being modified.
• The checking can be run each day from cron, or manually via:
  > ./tripwire -i 2 -c tw.config
• To tell Tripwire that (changes to) files or entire directory trees are OK:
  > tripwire -update [/file1 /file2 /patch3....]
• Improvements:
  • The tripwire database can be saved on the same machine, but protect the integrity by encrypting or signing it with a strong encryption tool like PGP.
  • For increased security and automated checking of several systems from one trusted host, copy tripwire and it's database and run it remotely at regular intervals using SSH. Delete the tripwire database on the target after checking.
  • This makes it difficult for an attacker to know that tripwire is being used to check the system. In addition, immediately update the tripwire database, so that only differences are reported by successive runs.
  • See the sample script trip_host.sh [3] for doing exactly this and filtering all those annoying "No such file or directory" warnings. It must be run from the 'master' host which has an SSH trust to the target and assumes it is installed in /secure/tripwire.

  To run the first time:
  > /secure/tripwire/trip_host.sh -init HOST
  Each time after that:
  > /secure/tripwire/trip_host.sh -check HOST
  To automate for many hosts, this script is then called from another script for each host that needs to be monitored. See the sample script trip_all [3]. This script also assumes that the commercial tripwire is used on the central trusted host (only). The commercial tripwire allows signing of the tripwire database, which makes it more secure.

Regularly copy the configuration and database to floppy disk or write-once media and sign it with pgp or MD5. In a crisis it will be very useful.

Back to top

Minimising GUI daemons/services

The focus of this paper has been on preparing hardened headless servers. However it would be useful to present suggestions for running a GUI console on Workstations or on servers where this really can't be avoided. Refer to the RPC section for more ideas (e.g. using Wietse's RPCBIND).

a) Chris Calabrese suggests the following to run CDE without RPC.

1. Disable rpc.ttdbserverd in inetd.conf
2. Replace /usr/dt/bin/Xsession with a script like the following, designed for HP-UX (In Solaris, it looks like one could use /usr/openwin/bin/twm instead of /usr/bin/X11/mwm, and also /usr/openwin/bin/xsetroot instead of /usr/bin/X11/xsetroot):

   #!/sbin/sh -
   /usr/bin/X11/xsetroot -default &
   /usr/bin/X11/mwm &
   sleep 4
   /usr/dt/bin/dtterm -ls

3. Then remove SUID access to CDE binaries:
   chmod ug-s /usr/dt/bin/dtaction /usr/dt/bin/dtappgather /usr/dt/bin/dtprintinfo /usr/dt/in/dtsession

b) Reg Quinton suggests a less drastic approach: leave RPC but reduce CDE daemons/services (e.g.on a desktop workstation).

1. /etc/inetd.conf can be stripped of every single service
2. /etc/rc2.d/S99dtlogin is required (for the CDE login panel)
3. /etc/rc2.d/S71rpc is required (ttsession uses rpc)
4. Restrict dtlogin to the console, for example by the 'sh' script:

   [ -d /etc/dt/config ] || mkdir -p /etc/dt/config
   [ -f /etc/dt/config/Xaccess ] ||
   cp /usr/dt/config/Xaccess /etc/dt/config/Xaccess

   ed - /etc/dt/config/Xaccess >/dev/null 2>&1 <<EOF
   g/^*/s//# HARDEN #*/
   w
   q
   EOF

Side effects: You will give up some minor CDE tools e.g. the calendar manager has been stripped by 1). The cmsd can be re-enabled in inetd.conf, although be aware that it has been a source of remote holes.

Back to top

Final Note

You now have a system that is quite resistant to attack. To maintain this security, caution is needed:

• be careful when adding services, application and users to the system.
• keep patches up to date on active services.
• be minimalist, only install what is necessary.
• monitor and regularly check the system for intrusions.
• check other Solaris hardening papers such as [2] for other ideas and tools.

Back to top

References and further reading

[1] Patches:

[2] Further reading on Hardening:

[3] Integrity /Tripwire Checking links:

[4] General Application Hardening:

[5] Email/sendmail links:

[6] IPfilter

[7] Routing

[8] Disabling SUID files:

[9]Tocsin

Back to top

Changes to this document

Back to top

Home

Seán Boran Last Update 19 avril, 2002