#; #; Hardening the Sun Solaris Operating Environment #; ----------------------------------------------- #; #; This guide is a basic understanding of the internal of the #; Solaris operating environment by Sun Microsystems. This guide #; has been tested to work for Solaris 2.6 and 2.7. #; #; Modification to this environment, and additional applications, #; are not covered in this document and should be tested prior #; to deploying on a production system. #; #; If you have any questions regarding this template, please feel free #; to contact the DePaul University Information Security Team via #; email at . #; #; The Information Security Team #; #; Copyright Notice Copyright (c) 2002. DePaul University. All Rights Reserved. Table of Contents 1.0 Summary 2.0 Installation Notes 3.0 Patches and Backups 4.0 Initialization Scripts 4.1 Sendmail 4.2 Inetinit 4.3 RPC 4.4 Internet Services 5.0 Base Hardening 5.1 Kernel Modifications 5.2 Core File Limits 5.3 Eliminating STOP-A System Halts 5.4 Eliminating Floppy Drive Access 5.5 Securing Against R* Service Authentication 5.6 Console Security 5.7 Controlling and Auditing Login 5.8 Cron Logging 5.9 Password Requirements 5.10 SU Logging and Path Control 5.11 System Account Configuration 5.12 Denying FTP Access 5.12 Subsystem Users 5.13 Shadow File 5.14 Valid Login Shells 5.15 Cron Access 6.0 Network Services 7.0 File and File System Permissions 7.1 SUID Files 7.2 File and Directory Permissions 7.3 Backup Tapes 7.4 Removing Unecessary Files 7.5 Miscellaneous Checks 7.6 Mount Point Permissions 8.0 System Logging 9.0 Additional Security Measures 9.1 Sudo 9.2 Integrity Checking 9.3 IP Filter 9.4 Auditing Logs 9.5 Hardening Tools 9.6 Restricted Shells 10.0 Post Hardening 1.0 Summary The purpose of this document is to assist in improving the security of the Solaris operating system. This document is intended for securely deploying a resource onto a hostile network such as the Internet, a shared extranet between two competing entities, etc. The internals of the Solaris 2.6 operating system will be covered herein using the SPARC distribution as examples. NIS, NIS+, Kerberos and other remote authentication mechanisms will not be discussed in this document. Securing applications such as CacheFS, NFS, Printing, Sendmail and other applications will not be covered in this document. These applications require further audits that should be performed before their use in a production environment. When possible, replacements for "higher level" applications that are notoriously insecure will be suggested. The details in this document may vary according to your vendors' modifications and should be referenced in the case of a discrepancy. This document does not cover physical security that should be considered in addition to the contents of this document. A Denial-of-Service (DoS) attack will be considered a security problem in this document. 2.0 Installation Notes To secure Solaris, a clean installation is recommended if the time and resources allow this to happen. If not possible, care should be given to ensure that all critical system binaries have retained their validity. A tool such as MD5 can be used to checksum binaries from a system previously installed against those from a cleanly installed system, or distribution media such as CD-ROM. To ensure that your checksum tool has not been compromised, recompile it statically if possible. To install the system for the first time it is suggested that you use the terminal based installation program available by connecting a serial cable to the RS-232 port and accessing this by using a dumb terminal or terminal emulation software on the attached device. The machine should not be attached to a network until the Hardening process has been completed. A quick summary of this type of installation follows. After attaching the serial cable to the serial port, insert the installation media and power the machine on. You may notice that the machine begins to boot. It is necessary that you send a "break" signal to halt the boot process and drop down to the OpenBoot PROM prompt. To boot from CDROM and install, perform the following. {ok} boot cdrom install The installation process is self-explanatory and the front-end provides several choices of which type of system you plan to install. The choices are a quick method by which to install a system for a particular task. We suggest that you install only the "Core" Solaris architecture and install any non-essential packages after the machine has been built. When planning disk partitions, the "more is more" approach is recommended. At minimum, create the following system partitions. / 60MB /usr 400MB /var 500MB Partitioning your disk as above allows you to prevent local Denial-of-Service (DoS) attacks from happening on a partition. This could happen if the attacker launched an extensive dictionary attack against a running daemon. With each failed authentication attempt the attacker would cause failure messages, generated by syslog, to be written to a file in /var (that is if you have syslog properly configured and are indeed logging events). This in turn would cause the root filesystem "/" to subsequently fill up /var has not been partitioned separately. The above partition layout also calls for /usr, and if necessary /opt, to be separately partitioned. The hardening process will mount /usr read-only to make system binaries more tamper resistant. Allocating an /opt partition will allow user accessible binaries to be installed without having to dirty up /usr. Obviously /opt would be best mounted in read-only mode also, though your site application requirements may not allow this. Finally it is necessary to secure the machines boot prompt. This can be done through an OpenBoot PROM password and limiting what commands can be performed without a password from the boot prompt. To limit the OpenBoot PROM commands to 'boot' and 'continue' the following should be done. Note that the password that we are setting is "hard2guess" as an example. {ok} setenv security-mode command security-mode = command {ok} setenv security-password hard2guess security-password = Setting the OpenBoot PROM password can also be accomplished via the UNIX command line interface as follows: {host}# eeprom security-mode=command Changing PROM password: New password: hard2guess Retype new password: hard2guess It is imperative to remember that if the OpenBoot PROM password is lost, there is no possibility of recovering this password. If the OpenBoot PROM password is lost replacing the EEPROM, a hardware chip in the machine, is required. Many applications rely on a valid HostID which is a unique string taken from the EEPROM. Changing EEPROMs may cause applications to fail. It may also wise to require a password to boot the machine each time. This can be useful when requiring an extremely high level of security that would be required if an attacker attempted to reboot a host with an infected kernel, or in a school environment where a server shutdown should remain shutdown. Set this by performing the following from the UNIX command line interface. {host}# eeprom security-mode=full Situations may arise where an attacker may physically break open a machine and replace the EEPROM chip to bypass the OpenBoot PROM password. Changing the EEPROM chip will change the HostID, a string that is unique to each individual EEPROM. The the HostID of the machine should be recorded and verified regularly as follows. {host}# hostid 80b14a3a 3.0 Patches and Backups A system should be maintained by applying the latest current patches at least once a month. During this time, system downtime may be required to successfully apply a patch, change shared libraries, etc.. Before patching the system, make a log of what patch level you are currently at. {host}# showrev -p > /patches.before Provisions should be made to perform a full system backup after an initial installation. This can be achieved by executing a level 0 dump of the system to tape, or by using other archive utilities such as tar or cpio. Another full system dump should be performed after the host has been hardened. 4.0 Initialization Scripts The next step to hardening the system is to remove any unnecessary services that may start at boot time. The following is a list of services that may be uneeded in your environment; rename the files to "off." or remove them completely. These files are located in the /etc/rc?.d directories. Name Function ------------------------------------------------- S10initpcmcia PCMCIA initialization S35cacheos.sh CacheFS initialization S65pcmcia PCMCIA initialization S20sysid.net Reconfigure networking S47asppp Point to Point Protocol S71sysid.sys Reconfigure system S72autoinstall Jumpstart S73nfs.client NFS client S74automounter Automounter S76nscd Name service caching S80lp Print server management S80PRESERVE Preserve ex/vi files after crash S89bdconfig Buttons and Dials Support S91leoconfig Configure Leo graphics S92rtvc-config Configure SunVideo S92volmgt Floppy/CDROM Volume Management S93cacheos.finish CacheFS configuration S15nfs.server Start NFS services Sun has setup the links in /etc/rc?.d as hard links as they provide better security. Several of the files in /etc/init.d should be modified slightly for enhancement. These enhancements are: 4.1 Sendmail If your site requires the use of a local mailer to delivery mail, replace the '-bd' arguments with '-q' on the line that invokes sendmail. This stops stops sendmail from listening to port 25/tcp and will still process any mail that is unable to be delivered from your system. The default timer is one hour. Other mailer-daemons such as Qmail or Postfix should be deployed if possible; these MTAs have been proven more secure for public use. 4.2 Inetinit Comment out the NIS domainname setting and comment out the router discovery configuration section. The next section of this document explains how to setup a default router. 4.3 RPC Comment out all lines. However, if you need to run RPC services for NFS or other services that require it, do not comment out the line that starts rpcbind. 4.4 Internet Services If this machine will not run named, have /etc/defaultrouter statically assigned, and not need a dynamically assigned IP address, use the following replacement for inetsvc. #!/bin/sh #; Sample /etc/init.d/inetsvc file for Solaris 2.6. echo "Bringing up network interfaces" /usr/sbin/ifconfig -auD netmask + broadcast + # Start inetd with stack tracing enabled echo "Starting inetd" /usr/sbin/inetd -s -t Only run inetd if it is critical to your environment. Install TCP_WRAPPERS as a means of mediating network connections. TCP_WRAPPERS will be addressed in the section entitled "Additional Security Measures" contained later in this document. The following services should be commented out of /etc/inetd.conf Service Replacement ------------------------------- ftp Secure FTP (SFTP) telnet Secure Shell (SSH) name - shell SSH login slogin exec - uucp - tftp - finger - systat - netstat SNMPv3 time NTP [8] echo - discard - daytime - chargen - 100232/10 - rquotad/1 - rusersd/2-3 - sprayd/1 - walld/1 - rexd/1 - 100068/2-4 - 100083/1 - ufsd/1 - 100221/1 - fs - 100235/1 - kerbd/4 - printer - Reboot your system to ensure that all services have stopped. Once this has been verified, remove the unneeded files in /etc/init.d, or move them to a directory only accessible by root. 5.0 Base Hardening The modifications made throughout this section will require rebooting the machine. Perform all modifications in a step-by-step manner and halt the machine by executing the following. {host}# /usr/sbin/shutdown -g0 -i0 -y Once the system has halted to the "{ok}" prompt, reboot with the following flag give to execute a global system reconfiguration. {ok} boot -r Note that reconfiguring a system at boot time will take a substantially longer amount of time to complete, thereby incurring more downtime. 5.1 Kernel Modifications The Solaris kernel allows modifications to be made dynamically that only require reboot. Slight kernel modifications can strengthen the kernel and require processes to remain within their allocated sandboxes. To limit exploit attacks against Solaris' kernel executable system stack, append the following changes at the end of /etc/system: * Make the system stack non-executable * and track exploit attempts set noexec_user_stack = 1 set noexec_user_stack_log = 1 This will not protect Solaris running on older versions of SPARC hardware or Solaris running on Intel x86 hardware. This will only protect sun4d, sun4m and sun4u SPARC hardware. 5.2 Core File Limits When a system binary encounters an error that causes it to panic and exit, valuable debugging information is sometimes left within a file called a "core" file. Core files are dangerous for two reasons: the first is that core files can dump into any directory and rampantly fill up a filesystem if the error is a recurring error. The second, and more critical, problem is that the core file may contain a chunk of RAM that was not privileged to the program/user running the failed binary. This often can occur in SUID binaries dumping cores on exit. It is wise to eliminate cores from being dumped, and in Solaris defining the core size in /etc/system is the preferable way to do so. Append the following edits to /etc/system. * Set the global core dump size to 0 set sys:coredumpsize = 0 5.3 Eliminating STOP-A System Halts One of the questionable functions built into Solaris is the ability to send a break to the system and bring it down to the OpenBoot PROM "{ok}" prompt. Having this functionality can cause a system halt of a production system, whether it be intended or not (it is quite easy to innocently send a break signal to the host if attempting to access the console with buggy terminal emulation software or a flaky cable). Eliminate the machines reaction to the break signal and you will eliminate this risk. In /etc/system append the following lines. * Disable STOP-A (breaks) from suspending the system set abort_enable = 0 Modify /etc/default/kbd and replace the appropriate line as shown. #; Sample /etc/default/kbd for Solaris 2.6. #; KEYBOARD_ABORT=disable 5.4 Eliminating Floppy Drive Access If the machine that you are hardening has a floppy drive, either remove it or place the following in /etc/system * Exclude the floppy device exclude fd Remove the floppy devices from /dev {host}# rm -rf /dev/fd 5.5 Securing Against R* Service Authentication The Berkley "r" services (rlogin, rsh, rcp, rwho, ruptime) have been notorious for intrusions since their conception. These services work as "trusted" computing services and are easy to spoof into false authentication. At this time we will remove all rsh/rlogin authentication methods from the Pluggable Authentication Module (PAM) configuration file. Edit /etc/pam.conf and remove the following lines. rlogin auth sufficient /usr/lib/security/pam_rhosts_auth.so.1 rsh auth required /usr/lib/security/pam_rhosts_auth.so.1 Later in this document we will suggest the removal of the "r" binaries. 5.6 Console Security To ensure that the console device is securely configured, /etc/logindevperms should be checked to ensure that /dev/console has permissions that only allow the owner of that device (i.e. the user that has logged into the device) to access it. All of the entries beginning with /dev/console should retain permissions of only the owner being able to read and/or write to the device; "group" and "other" should not have any access to the device. 5.7 Controlling and Auditing Login Root should not be allowed to login from any device other than the console, and passwords should be required for all users. These policies can be enforced by modifying /etc/default/login as outlined below: #; Sample /etc/default/login for Solaris 2.6 #; #; Root can only login here CONSOLE=/dev/console #; Passwords are required for login PASSREQ=YES #; Set the $SHELL variable on login ALTSHELL=YES #; * initial $PATH PATH=/usr/bin:/bin #; * root's $PATH on su SUPATH=/usr/sbin:/sbin #; * default umask UMASK=077 #; * logins are logged SYSLOG=YES For a truly paranoid, modify CONSOLE=/dev/console to be set to CONSOLE=/dev/null. This will disallow root logins from anywhere, requiring the administrative staff to facilitate "su" for root privileges. Note that this step should not be done until the hardening process is complete. 5.8 Cron Logging By default, Solaris 2.6 does not log cron job execution. Modify /etc/default/cron to change this behavior. CRONLOG=YES 5.9 Password Requirements Weak passwords are one of the largest compromises in a security policy. Most users insist on using passwords that are dictionary based and/or limited in their length. While Solaris does not have exceptional facilities built-in to accommodate for this problem, the password settings that can be applied will enhance password security. Configure /etc/default/passwd in the following manner: #; Sample /etc/default/passwd for Solaris 2.6 #; Minimum amount of weeks before password can be changed MINWEEKS=1 #; Maximum amount of weeks until password must be changed MAXWEEKS=8 #; Minimum password length PASSLENGTH=8 5.10 SU Logging and Path Control All attempts at running "su" should be logged for auditing. /etc/default/su should be configured to do so. #; Sample /etc/default/su for Solaris 2.6 #; Sulog - where su's are logged SULOG=/var/adm/sulog #; Supath set for initial $PATH when su'ing to root SUPATH=/usr/sbin:/usr/bin:/sbin:/bin #; Log attempts to syslog SYSLOG=YES Access to "su" can be controlled by utilizing UNIX file permissions to control binary execution. The following will only allow users within the wheel group to execute "su". Remember to add the group and users to the group before performing this change. {host}# chgrp wheel /bin/su /bin/su.static {host}# chmod 4550 /bin/su /bin/su.static This type of access control policy should be examined for other binaries as well. 5.11 System Account Configuration At install time all system users, or those users that are installed as part of a subsystem, need to be properly denied access. Enhancing your system in this manner will aid in preventing a system account from being accessed by an intruder. 5.12 Denying FTP Access Even if you do not intend to run an FTP service, it is generally wise to add all system accounts to a file called /etc/ftpusers. Most FTP servers honor this file; however, it may be necessary to check the documentation if you are building and installing a new version of the service. To add all system users (where UID < 100 or > 60000) to the account, assuming that you have not added any other user accounts at this point, perform the following. {host}# awk -F":" '($3 < 100) || ($3 > 60000) {print $1}' \ /etc/passwd > /etc/ftpusers 5.12 Subsystem Users It may be necessary to have subsystem accounts on the machine to ensure that those daemons function correctly. All subsystem accounts should be given a home directory of /tmp and a default login shell of /bin/false. If possible, obtain and statically build "noshell.c" as a substitute for /bin/false. The following is a sample /etc/passwd file with the secured default accounts. #; Sample /etc/passwd file for Solaris 2.6. root:x:0:1:Charlie Root:/root:/sbin/sh daemon:x:1:1:the devil himself:/tmp:/bin/false bin:x:2:2:bin:/tmp:/bin/false sys:x:3:3:sys:/tmp:/bin/false adm:x:4:4:Adm:/tmp:/bin/false sample:x:30000:30000:sample daemon user:/tmp:/bin/false nobody:x:65534:65534:nobody:/tmp:/bin/false 5.13 Shadow File All system accounts except for root should have their passwords locked. This can be achieved by editing /etc/shadow and adding "*LK*" to the encrypted password field. This is shown below. We have already removed users such as "lp" and other subsystem users since they are unneeded. Your mileage may vary. #; Sample /etc/shadow file for Solaris 2.6. #; root:f0ofo0f0ofe0feof::::::: daemon:*LK*:6445:::::: bin:*LK*:6445:::::: sys:*LK*:6445:::::: adm:*LK*:6445:::::: sample:*LK*::::::: nobody:*LK*:6445:::::: 5.14 Valid Login Shells Add all valid shells to /etc/shells. Note that any shells subsequently added to the system will need to be contained within this file as well. #; Sample /etc/shells for Solaris 2.6. #; /usr/bin/ksh /usr/bin/rksh /usr/bin/csh /sbin/sh /usr/bin/sh 5.15 Cron Access Edit /etc/cron.d/cron.allow to permit root and other administratively allowed users, to use cron functionality. This file should have one username per line. Edit /etc/cron.d/cron.deny to deny all other users access to cron functionality. This is overkill if /etc/cron.d/cron.allow exists. 6.0 Network Services The following settings should be appended to the end of /etc/init.d/inetinit. These settings are used to improve the kernel level handling of packets. Adjusting the following parameters may affect system performance and Sun does not encourage making these changes. #; Sample NDD settings for Solaris 2.6. #; * Modify ARP cache timeouts - these are changed from 5'/20' to 1'/1' #; * Do not perform ARP modifications if you are on congested segment ndd -set /dev/arp arp_cleanup_interval 60000 ndd -set /dev/ip ip_ire_flush_interval 60000 #; * Turn off all IP forwarding (not optimal for firewall host) ndd -set /dev/ip ip_forwarding 0 ndd -set /dev/ip ip_forward_src_routed 0 ndd -set /dev/ip ip_forward_directed_broadcasts 0 ndd -set /dev/ip ip_ignore_redirect 1 ndd -set /dev/ip ip_respond_to_timestamp 0 ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0 #; * Protect against ping floods ndd -set /dev/ip ip_respond_to_echo_broadcast 0 #; * Protect against SYN floods ndd -set /dev/tcp tcp_ip_abort_cinterval 10000 echo "tcp_param_arr+14/W 0t10240" | adb -kw /dev/ksyms /dev/mem ndd -set /dev/tcp tcp_conn_req_max_q 1024 ndd -set /dev/tcp tcp_conn_req_max_q0 4096 #; * Increase I/O throughput in network stack ndd -set /dev/tcp tcp_xmit_hiwat 65536 ndd -set /dev/tcp tcp_recv_hiwat 65536 ndd -set /dev/udp udp_xmit_hiwat 65536 ndd -set /dev/udp udp_recv_hiwat 65536 ndd -set /dev/tcp tcp_cwnd_max 65535 Modify /etc/default/inetinit to reflect the following change and increase defense against sequence number attacks. #; Sample /etc/default/inetinit for Solaris 2.6. #; * TCP_STRONG_ISS sets the TCP initial sequence number generation #; * parameters. Set TCP_STRONG_ISS to be: #; * 0 = Old-fashioned sequential initial sequence number generation. #; * 1 = Improved sequential generation, with random variance in #; increment #; * 2 = RFC 1948 sequence number generation, unique-per-connection-ID. #; TCP_STRONG_ISS=2 Create /etc/notrouter and secure permissions on this file. This will turn off local routing. {host}# touch /etc/notrouter && chmod 400 /etc/notrouter Create /etc/defaultrouter and specify your local gateway. All packets destined for 0/0 will be directed at this IP address. In the below example, the default gateway of the network would be 10.219.172.254 {host}# echo '10.219.172.254' > /etc/defaultrouter {host}# chmod 400 /etc/defaultrouter Modify /etc/nsswitch.conf to resolve addresses via DNS lookups. #hosts: files hosts: files,dns Configure /etc/resolv.conf to point to local DNS servers, and add your search domains to this file. #; Sample /etc/resolv.conf file for Solaris 2.6. search internal.example.org branch01.example.org domain example.org nameserver 10.254.181.1 nameserver 172.19.211.5 nameserver 192.168.51.23 7.0 File and File System Permissions Most of the binaries distributed with Solaris come with more permissive settings than required. Hardening the system files in this section is a large part of the hardening the OS. By performing these steps, the possibility of allowing a malicious user to gain access to a system account or exploit bugs on a system will lessen. 7.1 SUID Files SUID binaries should be critically audited periodically to ensure that there is the least amount of these binaries available on a system. The "s" bit on a file allows the user to execute the application as the owner of the binary. Let's look at a simple example; we will copy a Korn Shell (ksh) binary to the local directory, then change it to SUID. Take note of the differences in UIDs before and after this experiment. Also notice that /etc/shadow, which should not be accessible by a normal user, is accessible when we obtain the EUID of root. {host}$ id uid=1002(bob) gid=(users) {host}$ ls -l /usr/bin/ksh -r-xr-xr-x 2 bin bin 186356 Jul 15 1997 /usr/bin/ksh {host}$ head -1 /etc/shadow /etc/shadow: Permission denied {host}$ cp /usr/bin/ksh . {host}# chmod u+s ksh {host}# exit {host}$ id uid=1002(bob) gid=(users) {host}$ id uid=1002(bob) gid=(users) euid=(root) {host}$ ls -l ./ksh -r-sr-xr-x 1 bin bin 186356 Aug 18 10:05 ./ksh {host}$ ./ksh {host}$ head -1 /etc/shadow root:f0ofe0ffo0fe2::::::: To protect against SUID exploits, the best action is to remove all unneeded SUID bits from those binaries that are unneeded. If a SUID binary is kept on a system, watch for exploit announcements on a forum such as BUGTRAQ. The following is a partial list of these binaries and depending on how the machine was installed, some may or may not be on your system. /usr/sbin/allocate /usr/sbin/whodo /usr/sbin/ffbconfig /usr/sbin/ping /usr/sbin/arp /usr/sbin/dmesg /usr/sbin/static/rcp /usr/sbin/lpmove /usr/sbin/pmconfig /usr/sbin/sacadm /usr/sbin/swap /usr/sbin/prtconf /usr/sbin/sysdef /usr/sbin/wall /usr/bin/at /usr/bin/atq /usr/bin/atrm /usr/bin/chkey /usr/bin/crontab /usr/bin/eject /usr/bin/fdformat /usr/bin/nfsstat /usr/bin/rcp /usr/bin/rdist /usr/bin/rlogin /usr/bin/rsh /usr/bin/tip /usr/bin/volcheck /usr/bin/volrmmount /usr/bin/uptime /usr/bin/newgrp /usr/bin/nispasswd /usr/bin/cancel /usr/bin/lp /usr/bin/lpset /usr/bin/lpstat /usr/bin/admintool /usr/bin/ct /usr/bin/uucp /usr/bin/uuglist /usr/bin/uuname /usr/bin/uustat /usr/bin/uux /usr/bin/write /usr/bin/xargs /usr/bin/ypppasswd /usr/lib/exrecover /usr/lib/lp/bin/netpr /usr/lib/fs/ufs/quota /usr/lib/fs/ufs/ufsdump /usr/lib/fs/ufs/ufsrestore /usr/lib/acct/accton /usr/lib/sendmail /usr/platform/`uname -i`/sbin/eeprom /usr/platform/`uname -i`/sbin/prtdiag /usr/lib/uucp/remote /usr/lib/uucp/unknown /usr/lib/uucp/uucico /usr/lib/uucp/uusched /usr/lib/uucp/uuxqt /etc/lp/alerts /usr/openwin/bin To audit SUID/SGID binaries, periodically run the following script to ensure that you are aware of which files have SUID permissions. #!/bin/sh #; Script to find all SUID/SGID files on a system. #; Report Status to root. PATH=/usr/sbin:/usr/bin:/sbin:/bin find / \(-perm -4000 -o -perm -2000 \) -type f -exec ls -l \{\} \; |\ cat < chmod 660 $TAPEDEVS > done Create a group called 'mt' in /etc/group, and perform the following. Add the users that require accessing the tape devices to the 'mt' group. {host}# chgrp mt /usr/bin/mt {host}# chgrp mt /usr/bin/tcopy {host}# chmod o-a /usr/bin/mt {host}# chmod o-a /usr/bin/tcopy 7.4 Removing Unecessary Files There will be files remaining on the system that will have no use to your environment. At this point, it should be safe to remove these files. Depending on your needs, you may be required to keep these files, in whole or part. /etc/nsswitch.files /etc/nsswitch.nis /etc/nsswitch.nisplus /var/yp /var/nis /etc/auto_* /etc/dfs /usr/openwin/bin/rpc.ttdbserver /usr/openwin/bin/rpc.ttdbserverd /usr/sbin/in.comsat /usr/sbin/in.fingerd /usr/sbin/in.ftpd /usr/sbin/in.named /usr/sbin/in.rarpd /usr/sbin/in.rdisc /usr/sbin/in.rexecd /usr/sbin/in.rlogind /usr/sbin/in.routed /usr/sbin/in.rshd /usr/sbin/in.rwhod /usr/sbin/in.talkd /usr/sbin/in.tftpd /usr/sbin/in.tnamed /usr/sbin/in.uucpd /usr/sbin/nis* /usr/sbin/rpc.* /usr/bin/adb /usr/bin/at /usr/bin/atq /usr/bin/atrm /usr/bin/audio* /usr/bin/batch /usr/bin/ct /usr/bin/cu /usr/bin/finger /usr/bin/ftp /usr/bin/nfsstat /usr/bin/nis* /usr/bin/on /usr/bin/rcp /usr/bin/rdate /usr/bin/rdist /usr/bin/rlogin /usr/bin/rsh /usr/bin/rup /usr/bin/ruptime /usr/bin/rusers /usr/bin/solstice /usr/bin/talk /usr/bin/telnet /usr/bin/tftp /usr/bin/tip /usr/bin/vedit /usr/bin/view /usr/bin/volcheck /usr/bin/write /usr/bin/yp* /usr/ccs/bin/make /usr/ucb/cc Remove all filesystem types that will not be needed in your environment. /usr/lib/autofs /usr/lib/nfs /usr/lib/fs/autofs /usr/lib/fs/cachefs /usr/lib/fs/nfs /usr/lib/fs/pcfs /kernel/fs/autofs /kernel/fs/cachefs /kernel/fs/nfs /usr/kernel/fs/pcfs /usr/platform/`uname -a | awk '{ print $7 }'`/lib/fs/nfs /export Check the existing packages available and audit through each one to determine if it is necessary. Most packages that will not be used are described as "applications". Check for these by performing: {host}# pkginfo | grep -i application The following takes an imaginary package called SUNWwoft and removes it from the system. {host}# pkginfo -l SUNWwoft PKGINST: SUNWwoft NAME: Imaginary Sun Package CATEGORY: system ARCH: sparc VERSION: 11.6.0,REV=1999.01.12.11.56 BASEDIR: / VENDOR: L-user Company DESC: utilities for making network managers cringe PSTAMP: on297m15214432 INSTDATE: Jul 12 2000 23:03 HOTLINE: Please contact your local service provider STATUS: completely installed FILES: 22 installed pathnames 10 shared pathnames 1 linked files 16 directories 2 executables 7 blocks used (approx) {host}# pkgrm SUNWwoft (Answer 'yes' to the prompts if you are sure the package is unneeded) 7.5 Miscellaneous Checks It is best to run a check for world writable files that are available on a system. This check can be achieved by executing: {host}# find / \(-type f -a -perm -0002 \) -exec ls -l \{\} \; Check to see if removing files on a system left any orphaned soft links. {host}# find / -type link -exec ls -lL \{\} \; >/dev/null 7.6 Mount Point Permissions At this point, enhance the security permissions on your mounted partitions. This can be done by editing /etc/vfstab and applying various options. The following is a sample vfstab file with the mount options given. This file should be tab delimited. #; Sample /etc/vfstab for Solaris 2.6 #; * device device mount FS fsck mount mount #; * to mount to fsck point type pass @boot options #; fd - /dev/fd fd - no - /proc - /proc proc - no - /dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1 no - /dev/dsk/c0t0d0s1 - - swap - no - /dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /usr ufs 1 no ro /dev/dsk/c0t0d0s5 /dev/rdsk/c0t0d0s5 /opt ufs 2 yes - /dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /var ufs 1 no nosuid,noexec swap - /tmp tmpfs - yes nosuid,noexec /dev/dsk/c0t0d0s4 /dev/rdsk/c0t0d0s4 /home ufs 3 nosuid 8.0 System Logging Solaris is distributed with the BSD syslog daemon. On a default installation, syslog is configured to log a fair amount of information to files such as /var/adm/messages for kernel messages and /var/log/syslog for daemon information. However this information is not extensive enough for successful security auditing of a host. A centrally located syslog server should be implemented that accepts forwards of critical log information that will aid in debugging system failures, intrusions, etc. While syslog is not a secure solution, replacements such as "syslog-ng" and "nsyslogd" exist that are more reliable and secure. The following sample syslog.conf file will log audit information to unique files in /var/log and push the critical information off to a loghost. This file must be tab delimited with at least two (2) tabs between the facility and logfile. #; Sample /etc/syslog.conf file for Solaris 2.6. #; #; facility.priority /path/to/logfile #; #; Local logging #; auth.debug /var/log/auth.log auth.notice /var/log/auth.notices daemon.debug /var/log/daemon.log kern.debug /var/log/messages mail.debug /var/log/mail.log user.debug /var/log/user.log *.notice /var/log/notices #; Define what goes to loghost kern.notice @loghost *.crit @loghost *.emerg @loghost #; In case of failure write root *.alert;kern.crit;daemon.crit root #; Wall everyone on a system if an emergency *.emerg * The logfiles defined in /etc/syslog.conf should be "touched" after this file has been configured. The @loghost parameter uses /etc/hosts for lookup of the loghost. A default Solaris install defines loghost as the local machine. This can be changed as follows. #; Sample /etc/hosts for Solaris 2.6 #; 127.0.0.1 localhost 10.219.172.15 server server.example.org 10.219.172.94 loghost loghost.admin.example.org To restart syslogd execute the following command. {host}# kill -1 `cat /etc/syslog.pid` Log rotation of syslog files is normally done by root's crontab calling /usr/lib/newsyslog to rotate the files. Edit this script accordingly in order to rotate the new log files. 9.0 Additional Security Measures There are a variety of additional security packages and tools available to assist in hardening the operating system. These tools range from improving the security of terminal access to checking file integrity, though should not be considered intergral part of this document, rather suggested tools for improving your security to a greater extent. Use these tools only after the hardening process above has been complete. 9.1 Sudo Sudo... "...allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while logging the commands and arguments." There are useful areas in which sudo can be used: from not requiring the system administrator to type a root password in front of "prying" eyes to allowing junior administrator limited command sets to do routine system maintenance. However, sudo should be configured only with a limited command set for all users (Note: A limitation to sudo is that it allows for shell escapes to occur if allowing a broad command set. In doing this, you successfully give away all system security). After compiling and installing it, add a "sudo" group to /etc/group and modify the file permissions to only allow users in that group to execute the command. 9.2 Integrity Checking After the base operating system hardening is complete, it is necessary to run a baseline check of the file permissions on a system. Both "Tripwire" and "AIDE" have the ability to checksum file sizes, file permissions, file signatures (using MD5, SHA, etc.) and other parameters that are unique to each file. Consult the documentation for further assistance. 9.3 IP Filter IPF is a kernel level packet filter mechanism that allows for filters to be configured and deny traffic destined for the host. IPF is strongly suggested for host level packet filtering to increase end-node security, and for it's logging capabilities of unknown and/or denied traffic. 9.4 Auditing Logs The log files of a busy host can increase tremendously to the point of requiring tools for audit. Both "Swatch" and "Logcheck" can aid in audits and with minimal effort perform actions if a parameter, or group thereof, are matched. Both of these tools can be powerful if used on a centralized log server. 9.5 Hardening Tools There are several hardening tools available to assist in the hardening process. These scripts can be run to automate some of the procedures necessary for hardening a host. These tools do not substitute the knowledge required to manage services securely, and should be reviewed and tested thoroughly before used. You may find "Titan", "YASSP" and "Fix-Modes" useful to automate your hardening processes. 9.6 Restricted Shells If it is necessary to allow shell sessions to a multi-user system (for example a university that offers a command line interface mail reader such as "Pine"), we suggest that you configure a restricted shell environment. 10.0 Post Hardening Systems should be continuously monitored with alerts triggered if a set of parameters has been met. Backups are extremely critical in order to expedite disaster recovery, and aid in performing forensics on a compromised host. Never go into production without a full system backup of the hardened host kept at an offsite location easily accessible via authorized management. Security Policies are necessary to disseminate the knowledge of the IT team throughout the rest of the organization. Documentation and user training sessions are a necessary means by which a large amount of information can be broken down and easily related to the organization. Hardening documents are only valid if the entire organization is aware of the policies and practices that they should adhere to. No security mechanisms are foolproof. With each bug that is exploited, a new task to secure the exploits incurred must be performed. Tackling a hardening procedure is a mere procedure in the overall security process. This process is one that will cycle and requires your involvement at all times. #; #; $Id: sol2.6-hardening.txt,v 1.1.1.1 2003/09/25 19:23:57 epancer Exp $ #;