I have a document/tutorial, that I wrote on hardening solaris, just wondering if anyone would be interested in it, if they are then I`ll post it on AO.
Printable View
I have a document/tutorial, that I wrote on hardening solaris, just wondering if anyone would be interested in it, if they are then I`ll post it on AO.
R0n1n, I would be very interested in reading it.
Solaris is rare near me, i dont think theres a copy in this town at all, iv never used it but i guess it would be kinda neat. and as for the tut if you put effort into writing it and you think its good then by all means post it=)
R0n1ns guide to Hardening Solaris
-----------------------------------
Contents
1 Introduction
1.1 Document Purpose
1.2 Assumptions
2 Sun Solaris Operating System Baseline Installation
2.1 Pre-Installation
2.2 Boot Time Configuration
2.3 ‘Core’ OS Installation
2.4 Additional Packages
2.4.1 Required Packages
2.4.2 Install the System Accounting Packages
2.5 Sun Recommended and Security Patch Cluster
2.5.1 Obtain the latest Patches
2.5.2 Apply Patches
2.6 Set Up the Second Network Interface.
2.7 Configure the Gateway Address
2.8 Set root Password
3 Post Installation Configuration Changes
3.1 OpenBoot Considerations
3.1.1 Setting the OpenBoot password
3.1.2 Change the OpenBoot banner
3.2 Unnecessary Package Removal
3.3 Secure Root to Complete Network Setup
3.4 Root search path
3.5 Include System Name in Root Shell Prompt
3.6 Directory /etc/default/
3.6.1 login
3.6.2 passwd
3.6.3 cron
3.7 Inappropriate entries in /etc/aliases (or /usr/lib/aliases)
3.8 Securing the Network
3.8.1 /etc/inetd.conf
3.8.2 Log all inetd services
3.8.3 IP Routing, Forwarding, Source-Routing and Multicasting
3.8.4 TCP Packet Sequence Numbering
3.8.5 IP Security Settings
3.8.6 Remove /etc/hosts.equiv, /.rhosts.
3.9 System File Protection
3.10 Configuring Accounts
3.10.1 Accounts that Come with the OS
3.10.2 Restricting Use of su
3.11 Scripts to Remove
3.12 Force System daemons to start with a more secure umask
3.13 Improved Logging
3.13.1 Repeated Login Failures: /etc/syslog.conf
3.13.2 loginlog
3.13.3 /etc/cron.d/logchecker
3.14 Change syslog to Start Without Opening Port
3.15 Enable System Accounting (SAR)
3.16 Crontab Review
3.17 Cron.deny and at.deny
3.18 Permit ftp users (if appropriate)
3.19 Kernel Adjustments (More Protection Against Stack Smashing)
3.20 Logon Banner
3.21 Auditing Important Files
3.21.1 SETUID and SETGID Programs
3.21.2 Find files with no or inappropriate permissions
3.21.3 Create an alias for ‘ls –a –b’ for hidden files
3.21.4 Lsof
3.22 Ensure proper utmp and utmpx permissions
3.23 Disable Stop-A Abort Sequence
3.24 Volume Management
3.25 Mount Options
3.26 Core Files
3.27 PAM.conf.
4 Additional Software
4.1 SSH Installation
4.2 Profiles
4.3 SUDO Installation
4.3.1 The /etc/sudoers configuration
4.4 ACE Client Installation
5 Finalizing the Installation
1.1 Document Purpose
This document describes the manual method to harden a Solaris box.
1.2 Assumptions
The following assumptions were made about server configurations:
* Terminal consoles (character based) are used for console access.
* No X Window server software will be required on the server.
* Peripheral devices. No provision has been made for environments where other devices like modems have been connected to the Solaris box.
* Mitigating Controls. Hardening of Solaris can’t be done in a vacuum without considering database and application controls. For example if an application calls the Solaris server using the root id. This would seem to be a significant security issue. However, the logical access controls for the application may be so granular that this risk is mitigated and thus this is not a significant issue. This is a mitigating control.
* No NFS
* No NIS
2 Sun Solaris Operating System Baseline Installation
This section describes the baseline installation of the Sun Solaris operating system. Note that the installation can be done with either a console or serial terminal server (9600 bps, 8 data bits, no parity, and 1 stop bit).
Important: At no time during the OS installation should the new system be connected to an active network or the Internet. Failure to observe this step could expose the system to a possible compromise.
2.1 Pre-Installation
The following information should be known before proceeding with the installation:
* IP addresses and hostnames for all network interfaces.
* Netmask for the IP subnets
* Disk carving information
* Root password
2.2 Boot Time Configuration
* The Solaris 8 Software 1of 2 CD should be inserted into the CD ROM drive and used to boot the machine. To activate the initiate process, press <stop> <a> when the system boots to bring up the boot EEPROM and type “boot cdrom” at the “ok” prompt.
* Follow the on-screen prompts and select “English” and choose char set “USA (ASCII)”. This will be the 49th choice in the list
* Enter the host name
* Select “Networked” (even if machine is currently disconnected)
* Choose hme0 as the primary interface and enter the IP address
* Choose “None” for name service
* Enter the appropriate sub network mask information
* Select the time zone and set the time. The selected time zone is GMT set at ‘0’
* Verify that the date and time presented by the system is correct
2.3 ‘Core’ OS Installation
Using anything but the “Core” and additional essential installation packages may result in the addition of unnecessary packages and increase the host’s exposure to possible compromise.
* Choose “Initial” install to start with a clean system image.
* Configure the machine as a standalone server – i.e. the machine should not be dependent upon resources from other machines that could be compromised or shutdown.
* Choose “continue” to bypass the allocation of client services and additional language selection.
* Select “Core” system.
* Choose “continue” to select disks and “continue” to not preserve the preinstalled OS image that came with the machine.
* Choose “auto layout” and select /, /opt, /usr, /var and swap and then “continue”. Note required partitions may vary from one installation to another depending on the host’s purpose.
* Choose “customize” to choose the appropriate size for the selected disk partitions. The disk space available for the present installation is 36 GB. Example:
/ = 5000 MB.
swap = 2000 MB
/var = 10000 MB
/opt = 7000 MB
/usr = 7000 MB
/export/home = 1000 MB
Note: Just a little more than 2500 MB of free space was left over for future considerations.
* Do not to mount any remote file systems.
* Choose “auto reboot”. The system installation will continue and the machine will reboot afterwards.
2.4 Additional Packages
2.4.1 Required Packages
Add only necessary packages.
2.4.2 Install the System Accounting Packages
Install the SUNWaccu and SUNWaccr packages. The SAR utility analyses and reports on I/O and CPU utilization and allocation, by providing a simultaneous interval by interval profile of disk and CPU usage. This utility can provide indications of which system resource may be limiting overall system performance if used during heavy workloads or periods of inadequate system performance.
Copy the SUNWaccu and SUNWaccr packages from the Solaris 8 Software 2 of 2 CD to /var/tmp. The packages are located at /cdrom/Solaris_8/Product. Copy the packages over by using ‘cp –r <package> /var/tmp’. Run ‘pkgadd –d ./<pkg name>’ or ‘pkgadd –d . <pkg name>’ to add the packages.
2.5 Sun Recommended and Security Patch Cluster
The latest Solaris CD contains only the latest patches tested as a full set. There will undoubtedly be security and recommended patches for individual packages that have since been released. From a separate machine (this one is not networked and not yet secure enough to add to the network) download the cluster.
2.5.1 Obtain the latest Patches
* Download ftp://sunsolve.sun.com/pub/patches/8_Recommended.zip or http://sunsolve.sun.com .
* Download ftp://sunsolve.sun.com/pub/patches/8_Recommended.README
* Read 8_Recommended.README for special instructions
2.5.2 Apply Patches
* Patches can be applied using the following steps:
* Copy the patches to a /var/tmp file
* Decompress and extract the patches via zcat <filename of patch> | tar –xvf, or unzip <filename of patch> | tar -xvf
* Change to the patch directory
* Install the patch cluster via ./install_cluster. Because of the many modules stripped from the OS, it can be expected that some patches will not be applicable and will fail with an error message. (e.g., Installation of 102971-01 failed. Return code 8).
* Reboot so that the changes take effect.
* Remove the patch cluster from /var/tmp using: ‘rm -rf /var/tmp/8_Recommended’.
Note that patch installation can enable services that have been disabled or overwrite configuration files. This is not critical at this point in this document. However, once hardening (package removal and system configuration) has been done, patch installation should only be done after the index of the package has been reviewed for possible conflicts.
The “showrev –p” command can be used to list all patches installed on the system
Always check the /var/sadm/install_data/install_log file for any errors after a patch install. This file holds all of the patch installation output. So newer patch output is appended to the file.
2.6 Set Up the Second Network Interface.
After the root account has been secured, the network setup should be completed for any additional NICs. This can be done as follows:
* Create a /etc/hostname.xxx file with an entry for the second NIC’s host name, where xxx refers to the relevant interface (i.e. hme1, qfe, etc). Use the chown command to change the /etc/hostname.xxx file to root ownership.
* Edit the /etc/hosts file to add the appropriate IP address(es) and name.
* Edit the /etc/netmasks file to add the network address and mask.
2.7 Configure the Gateway Address
Add the appropriate default gateway IP address: ‘vi /etc/defaultrouter’.
2.8 Set root Password
* Passwords must be a least 8 characters long.
* Passwords should contain a mixture of upper and lower case letters.
* Passwords should contain a numeric character and/ or special character.
* Passwords should not contain any form of your name or userid.
* Root passwords should be changed on a regular basis.
3 Post Installation Configuration Changes
3.1 OpenBoot Considerations
OpenBoot is the firmware that is part of all Sun SPARC boot PROMs. It contains the information about how a SPARC system is booted, plus built-in commands for testing the hardware on the SPARC system. OpenBoot is activated as soon as a SPARC system is turned on.
In addition to boot time, OpenBoot can also be accessed while the system is running by pressing Stop-A. Pressing Stop-A stops the system and the integrity of the system’s data is at risk.
3.1.1 Setting the OpenBoot password
There are two reasons why an end user should ever have access to OpenBoot:
1. A clever user with access to OpenBoot can boot the system from almost any SCSI device. This gives the user complete control.
2. A user who can Stop-A a system can change any OpenBoot environment variables.
Recommendation: Sun OpenBoot should be set to ‘command’. This means that all commands except ‘boot’ and ‘go’ will require a password. The system may be booted from the default boot device.
Set the OpenBoot password from Solaris: # ‘setenv security-password’.
3.1.2 Change the OpenBoot banner
The OpenBoot banner should be changed from the default to a XXXX specific text. (This needs to be added)
Example:
ok setenv oem-banner? true
ok setenv oem-banner “This system is the property of XXXX”
3.2 Unnecessary Package Removal
Even with the minimal core installation, some packages may be installed which are not required. Clearly this will depend on the purpose that the host is being built for.
The list of current packages installed can be displayed with the “pkginfo” command. Any unnecessary packages can then be removed with the “pkgrm” command.
Note: This section can be time consuming and trial-by-error can play a factor (especially if you have to start all over after removing a package, rebooting and the box doesn’t come up). It is therefore advisable to complete this section and test the application before further hardening the box.
Although functionality testing must always be done, the following packages can be removed for Apache, Sendmail and Bind servers:
* SUNWadmr System & Network Administration Root
* SUNWatfsr AutoFS, (Root)
* SUNWatfsu AutoFS, (Usr)
* SUNWauda Audio Applications
* SUNWaudd Audio Drivers
* SUNWauddx Audio Drivers (64-bit)
* SUNWced Sun GigaSwift Ethernet Adapter (32-bit Driver)
* SUNWcedx Sun GigaSwift Ethernet Adapter (64-bit Driver)
* SUNWcg6 Device Driver
* SUNWctpls Portable Layout Services for Complex Text Layout support
* SUNWdmfex Sun Davison 10/100Mb Ethernet Driver (64-bit)
* SUNWensqr Ensoniq ES1370/1371/1373 Audio Device Driver (Root) (32-bit)
* SUNWensqx Ensoniq ES1370/1371/1373 Audio Device Driver (Root) (64-bit)
* SUNWdtcor Solaris Desktop /usr/dt filesystem anchor
* SUNWfcip Sun FCIP IP/ARP over FibreChannel Device Driver
* SUNWfcipx Sun FCIP IP/ARP over FibreChannel Device Driver (64 bit)
* SUNWfcp Sun FCP SCSI Device Driver
* SUNWfcpx Sun FCP SCSI Device Driver (64-bit)
* SUNWfctl Sun Fibre Channel Transport layer
* SUNWfctlx Sun Fibre Channel Transport layer (64-bit)
* SUNWftpr File Transfer Protocol, (Root)
* SUNWftpu File Transfer Protocol, (Usr)
* SUNWged Sun Gigabit Ethernet Adapter Driver
* SUNWhmd SunSwift Sbus Adapter Drivers (64-bit)
* SUNWkey Keyboard configuration tables
* SUNWloc System Localization
* SUNWnisr Network Information System, (Root)
* SUNWnisu Network Information System, (Usr)
* SUNWpcelx 3COM EtherLink III PCMCIA Ethernet Driver
* SUNWpcmci PCMCIA Card Services, (Root)
* SUNWpcmcu PCMCIA Card Services, (Usr)
* SUNWpcmem PCMCIA memory card driver
* SUNWpcser PCMCIA serial card driver
* SUNWpl5u Perl 5.005_03
* SUNWpsdpr PCMCIA ATA card driver
* SUNWsiox SuperIO 307 (plug-n-play) device drivers, (Root) (64-bit)
* SUNWsndmr Sendmail, (Root)
* SUNWsndmu Sendmail, (Usr)
* SUNWsolnm Solaris Naming Enabler
* SUNWqfed Sun Quad FastEthernet Adapter (32 bit)
* SUNWuaud USB Audio Drivers
* SUNWuaudx USB Audio Drivers (64-bit)
* SUNWusb USB Device Drivers
* SUNWusbx USB Device Drivers (64-bit)
* SUNWwsr2 Solaris Product Registry & Web Start runtime support
* SUNWxwdv X Windows System Window Drivers
* SUNWxwdvx X Windows System Window Drivers (64-bit)
* SUNWxwkey X Windows software, PC keytables
* SUNWxwmod OpenWindows kernel modules
* SUNWxwmox X Window System kernel modules (64-bit)
3.3 Secure Root to Complete Network Setup
After installation ensure that the root account is secured by taking the following steps:
* Log on as root.
* Use the “passwd root” command to set a root password.
* Use the “mkdir /root” command to establish a root directory.
* Use “chmod 700 /root” to secure the directory permissions.
* Use “chown root:root /root” to establish ownership.
* Change the home directory of root to the “/root” directory. Do this with the “vi /etc/passwd” command. The best way to do it is to use the “passwd –h” command.
# passwd -h
Default values are printed inside of '[]'.
To accept the default, type <return>.
To have a blank entry, type the word 'none'.
Home Directory [/]: /root
* Always test from another session with the su command to make sure that all is fine. It is possible to loose the system.
3.4 Root search path
It is often convenient to define a "search path" in a user's profile. Doing so can eliminate the need to type absolute paths when accessing files or programs. This is useful because absolute paths to even common programs can be long and cumbersome.
However, it is inadvisable to specify the working directory (".") near the beginning of the search path for any user. The primary reason for this is to prevent the passwords from being captured by a trojan horse program. In this context, a "trojan horse" refers to a program that is placed within a user's search path to gather passwords typed by the unsuspecting user.
Be sure root has a safe search path, as in /usr/bin:/sbin:/usr/sbin.
Root's path should never include the current directory specified as '.'. Check files:
-> /.login
-> /.cshrc
-> /.profile
Also check the PATH variable (via ‘set’)
3.5 Include System Name in Root Shell Prompt
The system name should be a part of root’s shell prompt so that the UNIX administrator will never need to expend extra effort to see which system he/she is on. This will deter operations being done on the wrong system.
To put the system name in root’s shell in Bourne shell (/bin/sh) or Korn shell (/bin/ksh), add the following to /root/.profile:
PS1=” `uname –n` # “
export PS1
CSH:
To put the system name in root's shell prompt in C shell (/bin/csh), add
the following to /root/.login: set prompt=" `uname –n` # "
3.6 Directory /etc/default/
3.6.1 login
The following changes should be made
* The “CONSOLE=” line should be uncommented. This will force telnet and rlogin root logins to only work from the console.
* Make sure “PASSREQ=YES” line should be uncommented. This forces one to choose a password.
* Make sure “SYSLOG=YES” line should be uncommented. Repeated login failures will be logged to syslog.
* Make sure “ALTSHELL=YES”. Determines if login should set the SHELL environment variable.
* Uncomment and set TIMEOUT=300
* Uncomment and set UMASK=027
3.6.2 passwd
The line “PASSLENGTH=X” where X is the minimum password length should be used to enforce the minimum length for user passwords. The “MAXWEEKS” line should be used to enforce password aging.
MAXWEEKS=8
MINWEEKS=6
PASSLENGTH=8
3.6.3 cron
Uncomment the line “CRONLOG=YES.” This will establish a log of cron processes that are run, the ID used, and when the processes started and finished. The log can be used as a diagnostic tool to see what processes have been started in a given time frame.
3.7 Inappropriate entries in /etc/aliases (or /usr/lib/aliases)
Examine the /etc/aliases (or /usr/lib/aliases) mail alias file for inappropriate entries. Some alias files include an alias-named 'uudecode' or just 'decode.' If this alias exists on your system and you are not explicitly using it, then you should remove it.
3.8 Securing the Network
Implementation of the following features will enhance protection against attacks from external sources
3.8.1 /etc/inetd.conf
Use the “chmod” command to change the permissions on this file to 400. Note that this step is only really effective if the “netstat” and “lsof” commands are not installed and if the telnet daemon is disabled.
Disable all the services by placing a "#" at the beginning of each line. Afterwards, confirm that all services have been disabled with the command: ‘grep –v “^#” /etc/inetd.conf’
3.8.2 Log all inetd services
Modify the /etc/rc2.d/S72inetsvc file so that it reflects ONLY the following entries:
/usr/sbin/ifconfig -auD4 netmask + broadcast +
/usr/sbin/inetd –s –t (This can also be deleted when inetd is not needed)
Note: If you are running the SUN OS named, DHCP, or multicast, you will have to modify this.
3.8.3 IP Routing, Forwarding, Source-Routing and Multicasting
* Disable IP routing and forwarding. To do this, create and harden a /etc/notrouter file as illustrated below. Background: If a Solaris machine has more than one network interface, Solaris will route packets between the multiple interfaces. This can be turned off with ‘touch /etc/notrouter’. Be aware that there is a small window of vulnerability during startup when the machine may route, before the routing is turned off.
touch /etc/notrouter
chown root:sys /etc/notrouter
chmod 444 /etc/notrouter
Note: It is still possible for applications to forward packets.
* Disable IP multicast. To do this, edit the file /etc/rc2.d/S72inetsvc and comment out (set first character in each line to #) all of the script after the lines #ADD a static route for multicast packets out our default interface through the last line in the file (/usr/sbin/inetd –s)
3.8.4 TCP Packet Sequence Numbering
Decrease the predictability of the TCP sequence numbers that the host uses by editing the /etc/default/inetinit file and setting the variable TCP_STRONG_ISS=2 rather than 1. This truly randomizes the initial sequence number of all TCP connections and protects the system against session hijacking and IP spoofing. Note, by default, the system installs with a setting of 1, which is not as secure.
3.8.5 IP Security Settings
Modifications can be made to the IP module to improve security. Commands can be added to a startup script ‘/etc/rc2.d/S70nddconfig’ to prevent the system from responding to broadcast ICMP Echo and Timestamp requests. This will also disable ICMP redirects.
These steps should protect the system from certain types of attack such as SYN floods, ARP spoofs, smurf attacks and from being unwitting allies to DDoS attackers. Explanations for each configuration can be read in the S70nddconfig file.
Embedded is the complete compressed S70nddconfig file:
3.8.6 Remove /etc/hosts.equiv, /.rhosts.
Remote users can gain unauthorized root access to the system. If you are not running "r" commands, you should have no use for these files and they should be removed.
* /etc/hosts.equiv - This file allows other hosts to be trusted by your system. It can be used to log on to your machine without a password.
* /.rhosts - Make sure that no user has a .rhosts file in their home directory. They pose a greater security risk than /etc/hosts.equiv since they can be created by each user. You can use a cron to check for and delete .rhosts files periodically.
3.9 System File Protection
No file in the directory /etc/ needs to be group writable. The file permissions should be changed as follows:
chmod –R g-w /etc/
The /etc/ utmp file should also not be world writabe. This can be changed using:
chmod 644 /etc/utmp
3.10 Configuring Accounts
3.10.1 Accounts that Come with the OS
Solaris comes with several IDs that are not normally used for login, but are used to set ownership of various files. These IDs include daemon, bin, uucp, sys, etc.
* Remove the uucp and nuuccp default accounts using the userdel <account> command. Any other unnecessary accounts should also be removed.
* Assign the non functional shell /bin/false to the system accounts daemon (daemon, bin, sys, adm, listen, lp, nobody, noaccess, nobody4, mailnull, etc) by appending /bin/false to their /etc/passwd entries. The operating system will prevent log in for an account that is assigned an invalid shell. This is a good "defense in depth" strategy to prevent crackers from using default accounts to gain access to your host. Example: ‘daemon:x:1:1::1/:/bin/false’. Here is the false file (copy/paste):
#!/bin/sh
#:
#
# This script was leveraged from Titan toolkit. For
# more information, refer to the following URL:
# http://www.fish.com/~brad/titan/Titan-Docs/index.html
#
trap "" 1 2 3 4 5 6 7 8 9 10 12 15 19
HOSTNAME="`/bin/uname -n`"
USER="`/bin/id | /bin/awk '{ print $1 }'`"
/bin/logger -i -p auth.err "Attempted access by ${USER} on host ${HOSTNAME}"
wait
exit
* Place the false file supplied on the run book CD in /bin. Make sure of the permissions.
* Lock these same accounts (daemon, bin, sys, adm, listen, lp, nobody, noaccess, nobody4, mailnull, etc) by setting the password field to “LK” in /etc/shadow. This can also be accomplished using the ‘passwd -l <account>’ command.
3.10.2 Restricting Use of su
It is possible to restrict use of su to a group of users, such as UNIX administrators. This is accomplished with the following commands.
# chgrp admins /usr/bin/su
# chmod o –rwx /usr/bin/su
Two binaries.
In this example, it is assumed that UNIX administrators are already members of the admins group.
Or install sudo. The sudo run book explains how to disable su after a successful install of sudo.
3.11 Scripts to Remove
Create a FCS directory under /etc/rc2.d and /etc/rc3.d respectively. Move the following scripts to the FCS directory.
Example:
mv /etc/rc2.d/ S80lp /etc/rc2.d/FCS/ S80lp
From the /etc/rc2.d directory remove the following scripts:
S71rpc
S72slpd
S73cachefs.daemon
S73nfs.client
S74autofs
S76nscd
S80lp
S85power
S88sendmail
S92volmgt
S93cacheos.finish
S96vmsa-server
From /etc/rc3.d close the following services:
Set auto boot to run level 2. Ensure no executable scripts are therefore present in /etc/rc3.d.
S15nfs.server – to disable the NFS server daemon
S76snmpdx
S77dmi
Reminder: The K scripts must remain in /etc/rc0.d else it will not be executed with init 6 reboot.
3.12 Force System daemons to start with a more secure umask
Create a script that forces system daemons to start with a more secure umask:
Create a script, S00set-tmp-permissions linked to ../init.d/set-tmp-permissions, that will fix the permissions of /tmp and /var/tmp (ln –s ../init.d/set-tmp-permissions S00set-tmp-permissions).
* Create file in /etc/init.d:
/bin/touch /etc/init.d/set-tmp-permissions
/bin/chmod 744 /etc/init.d/set-tmp-permissions
* Create soft links in each rc directory to the /etc/init.d/ set-tmp-permissions file:
/bin/ln -s /etc/init.d/set-tmp-permissions /etc/rc0.d/S00set-tmp-permissions
/bin/ln –s /etc/init.d/set-tmp-permissions /etc/rc1.d/S00set-tmp-permissions
/bin/ln –s /etc/init.d/set-tmp-permissions /etc/rc2.d/S00set-tmp-permissions
/bin/ln –s /etc/init.d/set-tmp-permissions /etc/rc3.d/S00set-tmp-permissions
/bin/ln –s /etc/init.d/set-tmp-permissions /etc/rcS.d/S00set-tmp-permissions
* Here is the set-tmp-permissions file (copy/paste):
#!/bin/sh
#
# Copyright (c) 2001 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident "@(#)set-tmp-permissions 1.2 01/06/10 SMI"
#
# INTRODUCTION
#
# The purpose of this script is to set the correct
# permissions on the /tmp and /var/tmp directories
# when the system is rebooted. If an inconsistency
# is found, it will be displayed to standard output
# and logged via SYSLOG.
#
# INSTALLATION
#
# To install this script, the following commands should
# be performed as 'root'.
#
# # cp <script> /etc/init.d/set-tmp-permissions
# # chmod 744 /etc/init.d/set-tmp-permissions
# # chown root:sys /etc/init.d/set-tmp-permissions
# # ln /etc/init.d/set-tmp-permissions /etc/rc2.d/S01set-tmp-permissions
# # ln /etc/init.d/set-tmp-permissions /etc/rc2.d/S07set-tmp-permissions
#
# The reason that this script is installed into /etc/rc2.d
# twice is to permit this check to be performed both before
# and after the "mountall" command is run (from S01MOUNTFSYS).
# That way, both the mount point and the mounted filesystem
# will be sure to have the correct permissions and ownership.
#
# Glenn M. Brunette <glenn.brunette@sun.com>
#
TMP_OWNER="root"
TMP_GROUP="sys"
# If you change TMP_PERMS for any reason, be sure to update
# TMP_PERMS_SET accordingly. These values are reasonable,
# however, and should not need to be changed.
TMP_PERMS="drwxrwxrwt"
TMP_PERMS_SET="1777"
# Verify both /tmp and /var/tmp.
for tmppath in /tmp /var/tmp; do
if [ -d "${tmppath}" ]; then
oldVal="`ls -ld ${tmppath}`"
# Obtain and verify the permissions on ${tmppath}.
perms="`echo ${oldVal} | awk '{ print $1 }'`"
if [ "${TMP_PERMS}" != "${perms}" ]; then
echo "WARNING: ${tmppath} had incorrect permissions (${perms})."
fi
# Obtain and verify the ownership of ${tmppath}.
owner="`echo ${oldVal} | awk '{ print $3 }'`"
if [ "${TMP_OWNER}" != "${owner}" ]; then
echo "WARNING: ${tmppath} had incorrect ownership (${owner})."
fi
# Obtain and verify the group of ${tmppath}.
group="`echo ${oldVal} | awk '{ print $4 }'`"
if [ "${TMP_GROUP}" != "${group}" ]; then
echo "WARNING: ${tmppath} had an incorrect group setting (${group})."
fi
# Make all of the changes to ${tmppath} to bring it into
# compliance with the settings as defined above.
/bin/chown ${TMP_OWNER} ${tmppath}
/bin/chgrp ${TMP_GROUP} ${tmppath}
/bin/chmod ${TMP_PERMS_SET} ${tmppath}
fi
done
3.13 Improved Logging
3.13.1 Repeated Login Failures: /etc/syslog.conf
The section below has two lines. The first line is included in a normal /etc/syslog.conf file. Add the second line to activate logging of repeated login failures. It does not log single login failure and disconnect.
vi /etc/syslog.conf and add:
auth.none /var/adm/messages (Must be TAB separated or it won’t work)
auth.info /var/log/authlog
auth.notice /var/log/authlog
Check the attributes:
[goalpsrv19]# ls -al /var/log/authlog
-rw------- 1 root sys 0 Feb 26 18:00 /var/log/authlog
Otherwise:
chown root:sys /var/log/authlog
chmod 600 /var/log/authlog
Restart the syslog process with the ‘kill –HUP <process id>’ and check for error messages.
3.13.2 loginlog
You should ensure that security-related events are logged by syslog. This includes reboots, failed login attempts and all su attempts.
touch /var/log/loginlog
chown root:sys /var/log/loginlog
chmod 600 /var/log/loginlog
3.13.3 /etc/cron.d/logchecker
Set the limit of crom logfiles to 2 MB before it is rotated.
LIMIT=2048
3.14 Change syslog to Start Without Opening Port
Note: Only do this when the server in question is not a loghost.
Put –t in the /etc/rc2.d/S75syslog:
#!/sbin/sh
#
# Copyright (c) 1991-1999 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident "@(#)syslog 1.13 99/09/06 SMI"
case "$1" in
'start')
if [ -f /etc/syslog.conf -a -f /usr/sbin/syslogd ]; then
echo 'syslog service starting.'
#
# Before syslogd starts, save any messages from previous
# crash dumps so that messages appear in chronological order.
#
/usr/bin/savecore -m
if [ -r /etc/dumpadm.conf ]; then
. /etc/dumpadm.conf
[ "x$DUMPADM_DEVICE" != xswap ] && \
/usr/bin/savecore -m -f $DUMPADM_DEVICE
fi
if [ ! -f /var/adm/messages ]; then
/usr/bin/cp /dev/null /var/adm/messages
/usr/bin/chmod 0644 /var/adm/messages
fi
/usr/sbin/syslogd -t >/dev/msglog 2>&1 &
fi
;;
'stop')
if [ -f /etc/syslog.pid ]; then
syspid=`/usr/bin/cat /etc/syslog.pid`
[ "$syspid" -gt 0 ] && kill -15 $syspid
fi
;;
*)
echo "Usage: $0 { start | stop }"
exit 1
;;
esac
3.15 Enable System Accounting (SAR)
System accounting is one of the mechanisms by which investigations and diagnostics are done.
Note: Do a “EDITOR=vi; export EDITOR” or you may have problems below.
Do a “crontab –e sys” and uncomment the various entries. This will turn on system accounting. When finished, the file should look similar to the following example:
ident "@(#)sys 1.5 92/07/14 SMI" /* SVr4.0 1.2 */
#
# The sys crontab should be used to do performance collection. See cron
# and performance manual pages for details on startup.
#
0 * * * 0-6 /usr/lib/sa/sa1
20,40 8-17 * * 1-5 /usr/lib/sa/sa1
5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 –A
3.16 Crontab Review
All entries in /var/spool/cron/crontabs/ and /var/spool/cron/atjobs/ should be reviewed to check for activity not accounted for. Also, all programs that are run by root should NOT be other writable, and should be owned by root. Also in file /etc/default/cron, set “CRONLOG=yes.” This will enable logging of all cron processes.
Important: Remove crontab entries in /var/spool/cron/crontabs for all users except root and sys.
3.17 Cron.deny and at.deny
Set the explicit restrictions to cron.deny and at.deny:
/usr/lib/cron/at.deny – deny all accounts
/usr/lib/cron/cron.deny – deny all accounts except root and sys
Example:
echo "root" > /etc/cron.d/cron.allow
echo "sys" >> /etc/cron.d/cron.allow
chown root /etc/cron.d/cron.allow
chmod 600 /etc/cron.d/cron.allow
cat /etc/passwd | cut -f1 -d: | grep -v root > /etc/cron.d/cron.deny
chown root /etc/cron.d/cron.deny
chmod 600 /etc/cron.d/cron.deny
cat /etc/passwd | cut -f1 -d: > /etc/cron.d/at.deny
chown root /etc/cron.d/at.deny
chmod 600 /etc/cron.d/at.deny
3.18 Permit ftp users (if appropriate)
FTP access should be replaced with scp and sftp. Due to the clear text passwords FTP should never be used.
cat /etc/passwd | cut -f1 -d: > /etc/ftpusers
chown root /etc/ftpusers
chmod 600 /etc/ftpusers
3.19 Kernel Adjustments (More Protection Against Stack Smashing)
The following entries should be added into /etc/system to help make buffer exploits harder to generate:
# set system not to make the user stack executable
set noexec_user_stack = 1
set noexec_user_stack_log = 1
Warning: Take care making changes to this file. Mistakes may prevent the system from booting properly.
These lines in the /etc/system file make the user stack not executable. A common exploit that cracks a system is to overflow a buffer on the user stack with a modified return address and some code to run, which is also on the stack. When the program returns from the current routine that is running, the jump instruction jumps to a place on the stack that has the cracking executable code. By making the stack not runable, the exploit then causes the program to crash instead. There is a possible denial of service attack, but at least the root privileges will not have been gained.
Note: A reboot is needed for these changes to take effect. This step should help protect against stack smashing but can never afford 100% protection.
3.20 Logon Banner
The /etc/motd and /etc/issue file should contain the following message:
Restricted Access, For Use By Authorized XXXX Personnel Only.
Violators may be subject to criminal prosecution and/or civil litigation
under state and/or federal law. All connections are monitored.
3.21 Auditing Important Files
This section is particularly important for hardening boxes that are already in production.
3.21.1 SETUID and SETGID Programs
Setuid and Setgid programs are used to change the effective UID or GID of the invoking process to the UID or GID of the program. This allows the user executing the program to exercise the permission of the program’s owner or group, but only within the capabilities of the program.
Programs that are suid root are often targets of the hacker because they can be replaced with programs that provide the same functionality, and yet hide the hacker in addition to providing an open back door into the system.
To minimize the risks associated with these programs:
1. apply the principle of least privilege wherever possible
2. Use Setuid or Setgid only when no alternative is available
3. Avoid using Setuid if Setgid will suffice.
4. avoid using Setuid to root when you can move to an account with fewer privileges
In addition the following guidelines should be observed:
1. Setuid programs must not be located in group- or world-writable directories including the system temporary directories;
2. Root-owned Setuid programs should be located in root-owned directories;
3. Write access to an Setuid program should be restricted to the program’s owner;
4. Setuid programs should be located in the / and /usr filesystems.
Important: Create a master list of the remaining setuid/ setgid programs of your system and check the list remains static over time. Any unnecessary files should be removed. Make sure to copy this to a floppy to insure its integrity. An inventory of all Setuid and Setgid programs can be obtained by running the following commands:
For Setuid programs use: ‘find / -perm –4000 –print’
For Setgid use: ‘find / -perm –2000 –print’
Similarly (and pipe output to a file): ‘find / \ (-perm –004000 –o –perm –002000 \) –type f \ > -fls suidfiles.dat. The ‘-fls’ writes the sizes along with names so one can check for alterations.
3.21.2 Find files with no or inappropriate permissions
Files and directories that are writable by "group" or "other" are a security risk both for the user owning the files and for the system as a whole. Therefore, with the exception of departmental library accounts, users should not be permitted to maintain group or world writable files or directories on a system.
* Search for files without user or group
find / -nouser –o –nogroup ! –type f –exec ls –ld {} \;
* Search filesystem for world writable files
find / -perm -2 –a –typ f! –fstype f –exec ls –ld {} \;
* Search filesystem for world writable directories
find / -perm -2 –a –typ d! –type d –exec ls –ld {} \;
More Simple:
* Printing files matching a user's permission mode
Recursively print all file names whose permission mode exactly matches read, write, and execute access for user, and read and execute access for group and other:
find / -perm u=rwx,g=rx,o=rx
The above could alternatively be specified as follows:
find / -perm a=rwx,g-w,o-w
* Printing files with write access for other
Recursively print all file names whose permission includes, but is not limited to, write access for other:
find / -perm -o+w
* Printing local files without descending non-local directories
find / ! -local -prune -o -print
3.21.3 Create an alias for ‘ls –a –b’ for hidden files
A UNIX administrator should always use the –a (show hidden files) and –b (print nonprintable character) options when using ls.
A hidden file or directory is one whose name begins with the dot (.) character.
Nonprintable characters in filename? Yes. They can be created by accident or even purposely by a mischievous user.
For Bourne shell and Korn shell users, include the following entry in the .profile file:
ls ( ) { /usr/bin/ls –a –b $* ; }
3.21.4 Lsof
Once intruders compromise a system, hackers often set up base camp. These base camps are invisible to the ls command even though they may consume a significant amount of disk space.
The technique of hiding files is actually quite simple. The hacker starts a process that opens a file and then unlinks the file. Even though the file has been unlinked, the process can continue to write to it. Since unlinking a file results in its directory entries being removed, it becomes invisible. However, disk resources remain in use until the file is actually closed.
These covert files are fantastic places to hide scan results and similar data. To find these types of files, a tool is needed that can determine the number of links that a file has. A program called lsof does this quite well.
Lsof is available free from Purdue: ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/. It should be configured and compiled for the architecture in question and then installed setuserid root. The executable should be placed in directory /usr/local/bin/.
Hidden files that result from unlinking have a link count of zero. So we can use the lsof command with a +L1 argument to find any open files that have been masked in this manner. The +L1 tells lsof to display all of the open files that have a link count less than 1.
3.22 Ensure proper utmp and utmpx permissions
The utmp and utmpx databases contain user access and accounting information for the system. If these files are group- or world-writable, then the record of system accesses can be altered or erased easily.
The file permissions for /var/adm/ utmp and /var/adm/utmpx should be 644
3.23 Disable Stop-A Abort Sequence
For Solaris 2.6 and later, the stop-A abort sequence can be disabled by editing /etc/default/kbd and setting “KEYBOARD_ABORT=disabled”
Warning: If the system becomes unstable and hangs, the use of the above setting will force a hard power down to be performed in order to interrupt the system.
Also note: this setting may need to be relaxed in order to perform crash dump diagnostics
3.24 Volume Management
Solaris provides users with an easy way to mount removable media without requiring root access. The daemon that manages this system is called “vold”. If the system does not require the automatic mounting of removable media, this system should be disabled. One way of doing this is to remove the Volume Management packages (SUNWvolr, SUNWvolu, and SUNWvolg). Note that these names might vary from one version to another.
In cases where Volume Management is necessary, the mount options for some file systems need to be modified for security. By default the Volume Management system allows suid file systems for all removable media that it supports, thus a UFS formatted floppy disk could be inserted by anyone and a setuid executable could be used to gain control of the system. To prevent this, the following lines can be added to the bottom of the /etc/rmmount.conf file:
mount hsfs –o nosuid
mount ufs –o nosuid
3.25 Mount Options
File system partitions can be mounted with options that enhance security. It has already been recommended to minimize the use of Setuid files, because of the potential security exposure associated with them. If a file does have the Setuid bit set, it will not be effective on file systems mounted with the “nosuid” option. In general user file systems should be mounted with the “nosuid” option in /etc/vfstab.
Wherever possible file systems should be mounted in read only mode and be set to ignore the Setuid bit on files. Note that it is not possible to mount the root file system (/) with the “nosuid” option. By mounting file systems in read only mode, an intruder is prevented from storing backdoor files or overwriting and replacing files on the file system.
For Example: consider mounting the /usr file system read only in /etc/vfstab. Warning: to mount it writable, the machine will need to be rebooted in order for changes to take effect (for example: to install patches).
Note: Mounting file systems in read only mode and set to ignore the Setuid bit on files is considered extreme. It may be that this risk is mitigated and thus not a significant issue.
3.26 Core Files
Sometimes programs terminate unexpectedly and dump the process core into a core file. The core file can then be used to debug program errors. This can cause two problems. Firstly, core files can take up large amounts of disk space and could cause a system crash if the root partition (/) were to become full. Secondly, the core file may contain privileged information that users should not be able to access. The creation of core files can be prevented by adding the following line to the /etc/system file:
set sys:coredumpsize = 0
3.27 PAM.conf.
The pam.conf file is the configuration file for the Pluggable Authentication Module architecture, or PAM. A PAM module provides functionality for one or more of four possible services: authentication, account management, session management, and password management. An authentication service module provides functionality to authenticate a user and set up user credentials. A account management module provides functionality to determine if the current user's account is valid. This includes checking for password and account expiration, as well as verifying access hour restrictions. A session management module provides functionality to set up and terminate login sessions. A password management module provides functionality to change a user's authentication token or password.
All the lines that starts with a “”r” must be deleted from the /etc/pam.conf file. This ensures that none of the ‘r’ commands can be carried out. This is a sample of the minimal that is required:
login auth required /usr/lib/security/$ISA/pam_unix.so.1
#
#
other auth required /usr/lib/security/$ISA/pam_unix.so.1
#
# Account management
#
login account requisite /usr/lib/security/$ISA/pam_roles.so.1
login account required /usr/lib/security/$ISA/pam_projects.so.1
login account required /usr/lib/security/$ISA/pam_unix.so.1
#
other account requisite /usr/lib/security/$ISA/pam_roles.so.1
other account required /usr/lib/security/$ISA/pam_projects.so.1
other account required /usr/lib/security/$ISA/pam_unix.so.1
#
# Session management
#
other session required /usr/lib/security/$ISA/pam_unix.so.1
#
# Password management
#
other password required /usr/lib/security/$ISA/pam_unix.so.1
4
Additional Software
4.1 SSH Installation
The compilation:
The following compile options were used to make the SSH binaries:
--with-tcp-wrappers=/root/tcp_wrappers_7.6 --with-pam --without-none --disable-server-port-forwardings --disable-client-port-forwardings --disable-server-port-forwardings --disable-client-x11-forwarding --disable-server-x11-forwarding --without-x --disable-suid-ssh--signer --disable-suid-ssh --without-rsh
This SSH package is for a Unix server with no x, x-forwarding or RSH support.
Installation:
Proceed as follows:
* Copy the SSH package to the Unix client that requires SSH. Do disable TELNET or FTP access at this point.
* Logon to the Unix server and use the “su –“ command to get root access. Change to the directory where the ssh package resides; this is the home directory of the user that was used to ftp the package originally.
* Install the package using the command pkgadd -d ssh. Look at Appendix A for a sample installation.
* Add “SSH 22/tcp” to /etc/services. This enables commands like “netstat” to identify the port, and allows one to use “SSH” instead of remembering the port number (22).
* Start the SSH daemon from the /etc/init.d directory with the command sshd start, and use the command netstat –an | grep 22 to check if it is running.
* Configure the SSH daemon to use a specific interface when the server is running multiple interfaces. This is done by changing the ListenAddress in the /etc/sshd_config file. Remember to restart SSH after the change. Before the change:
# netstat -an | grep 22
*.22 *.* 0 0 0 0 LISTEN
After the change:
# netstat -an | grep 22
10.197.8.3.22 *.* 0 0 0 0 LISTEN
In the first sample the *.22 implies that the server will answer requests from any SSH client. The 10.197.8.3.22 entry in the second example will only start SSH negotiation when the client connects to IP address 10.197.8.3
TCP Wrappers:
Next you need to install files which determine who can and who cannot access the system via SSH.. This is accomplished by two files: hosts.allow and hosts.deny, which you install in /etc.
The general format for lines in /etc/hosts.allow is
<service> : <host> ... <network> ...
where <service> is the name of the daemon that you want to allow access to, e.g., in.telnetd, in.ftpd, portmap, sshd, sendmail, etc., and <host> is the hostname or IP address of a host and <network> is a subnet either in the form ..com or 10.196..
Only install this once SSH is up and running and working. Current SSH sessions will stil stay active.
Simple configuration:
* First deny all users access in the /etc/hosts.deny file with the entry:
ALL:ALL EXCEPT localhost:DENY
* Then allow access to the SSH daemon only from network 10.170.33.0/24
sshd : 10.170.33. : allow
Sample installation:
# pkgadd -d sshd.pkg
The following packages are available:
1 sshd sshd
(sparc) 3.0p1
Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: 1
Processing package instance <sshd> from </root/sshd.pkg>
sshd
(sparc) 3.0p1
SSH build from OPENSSH
The selected base directory </usr/local> must exist before
installation is attempted.
Do you want this directory created now [y,n,?,q] y
Using </usr/local> as the package base directory.
## Processing package information.
## Processing system information.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.
This package contains scripts which will be executed with super-user
permission during the process of installing this package.
Do you want to continue with the installation of <sshd> [y,n,?] y
Installing sshd as <sshd>
## Installing part 1 of 1.
/etc/init.d/sshd
/usr/local/bin/s2p
/usr/local/bin/scp
/usr/local/bin/sftp
/usr/local/bin/slogin <symbolic link>
/usr/local/bin/ssh
/usr/local/bin/ssh-add
/usr/local/bin/ssh-agent
/usr/local/bin/ssh-keygen
/usr/local/bin/ssh-keyscan
/usr/local/etc/ssh_config
/usr/local/etc/ssh_prng_cmds
/usr/local/etc/sshd.pid
/usr/local/etc/sshd_config
/usr/local/libexec/sftp-server
/usr/local/sbin/sshd
[ verifying class <none> ]
/etc/rc2.d/S99sshd <linked pathname>
## Executing postinstall script.
Generating public/private dsa key pair.
Your identification has been saved in /usr/local/etc/ssh_host_dsa_key.
Your public key has been saved in /usr/local/etc/ssh_host_dsa_key.pub.
The key fingerprint is:
b8:c6:4f:1c:61:9a:77:c2:56:66:67:9c:e8:9b:66:84 root@goalpsrv19
Generating public/private rsa key pair.
Your identification has been saved in /usr/local/etc/ssh_host_rsa_key.
Your public key has been saved in /usr/local/etc/ssh_host_rsa_key.pub.
The key fingerprint is:
26:9b:bd:57:a2:db:9f:d1:47:74:d2:8c:0e:37:1e:3a root@goalpsrv19
Installation of <sshd> was successful.
# /etc/rc2.d/S99sshd start
# exit
Sample:
In this sample we have two systems…
[goalpsrv19]# cat /etc/hosts.allow
sshd : 10.170.33. : allow
sshd : 10.196.2. : allow
sshd : 10.197.0. : allow
sshd : 10.250.12. : allow
sshd : 10.250.4. : allow
[goalpsrv19]# cat /etc/hosts.deny
ALL:ALL EXCEPT localhost:DENY
[yyalpsrv56]# cat /etc/hosts.allow
sshd : 10.196.2.189 : allow
[yyalpsrv56]# more hosts.deny.old
ALL:ALL EXCEPT localhost:DENY
4.2 Profiles
Ensure the following is represented in the files below.
/etc/profile
PATH=/usr/local/bin:$PATH
PS1="[`hostname`]$ "
export LOGNAME PS1 PATH
/root/.profile
umask 022
PS1="[`hostname`]# "
export PATH PS1
4.3 SUDO Installation
This is the SUDO installation instructions
# pkgadd -d sudo
The following packages are available:
1 sudo sudo
(sparc) sudo-1.6.3p5
Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: 1
Processing package instance <sudo> from </root/sudo>
sudo
(sparc) sudo-1.6.3p5
Sudo
Using </usr/local> as the package base directory.
## Processing package information.
## Processing system information.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.
The following files are being installed with setuid and/or setgid
permissions:
/usr/local/bin/sudo <setuid root>
Do you want to install these as setuid/setgid files [y,n,?,q] y
Installing sudo as <sudo>
## Installing part 1 of 1.
/etc/sudoers
/usr/local/bin/sudo
/usr/local/sbin/visudo
[ verifying class <none> ]
Installation of <sudo> was successful.
4.3.1 The /etc/sudoers configuration
From the $ prompt: ‘sudo /usr/local/sbin/visudo’.
Configure dzwamborn and jbron:
# User privilege specification
jbron ALL=(ALL) ALL
dzwamborn ALL=(ALL) ALL
4.4 ACE Client Installation
This is the SSH installation instruction
# pkgadd -d ace
The following packages are available:
1 ace ACE Client
(sparc) ace-4.1.097
Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: 1
Processing package instance <ace> from </root/ace>
ACE Client
(sparc) ace-4.1.097
RSA
Using </opt> as the package base directory.
## Processing package information.
## Processing system information.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.
The following files are being installed with setuid and/or setgid
permissions:
/opt/ace/prog/sdshell <setuid root>
Do you want to install these as setuid/setgid files [y,n,?,q] y
Installing ACE Client as <ace>
## Installing part 1 of 1.
/etc/sdace.txt
/opt/ace/data/sdace.txt
/opt/ace/data/sdconf.rec
/opt/ace/data/version.txt
/opt/ace/prog/_sdinfo
/opt/ace/prog/copyright.txt
/opt/ace/prog/license.txt
/opt/ace/prog/sdinfo
/opt/ace/prog/sdshell
/opt/ace/prog/version.txt
[ verifying class <none> ]
Installation of <ace> was successful.
SHELLS:
jbron:x:1002:10:Jacques Bron:/export/home/jbron:/opt/ace/prog/sdshell
5 Finalizing the Installation
NOW Connect the System to the Network
Contents