A Practical Guide to Solaris Security pdf

Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 1 A Practical Guide to Solaris Security A White Paper March 1994 Synopsis This white paper aims to provide practical security guidelines for the Solaris operating system (supplied by SunSoft). It focuses on the Solaris 2.3 version, however, references are made to Solaris 1 in-order to illustrate the improvements. Who should read it? This paper assumes some knowledge of Solaris and is suitable for anyone who has completed the ‘Solaris2.x System Administration’ course and would like to know more about Solaris2 security features. Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 2 Contents 1 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 Physical Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5 EEPROM Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6 Login Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1 Compromised Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 6.2 Good Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3 Missing Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.4 Password Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 6.5 Direct root login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.6 Password Cracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.7 Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.8 Shell Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 6.9 The Swap User Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.10 Modem Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7 Application Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1 Basic file permissions revisited . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2 UMASK Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3 Automatic Start-up Wrappers. . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.4 Setuid programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.5 Setuid Shell Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 7.6 Shared Library Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.7 Hidden directories and files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.8 X11 Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.9 Loading files from Media. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.10 Device Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8 Network Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1 Machine cloning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 8.2 Network Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 9 Network Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1 Secure RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.2 DES Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.3 Kerberos Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 3 10 Network Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1 NFS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.2 inetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.3 in.routed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.4 sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.5 Remote Access Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11 Public Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1 Automatic Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.2 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.3 Ftp & Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12 Network Information Services . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.1 Solaris1 & Solaris 2 NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.2 Moving NIS Map Source files . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.3 Solaris 2 & NIS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13 Logs & auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 13.1 Console Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13.2 BSM auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 13.3 The system logger “Syslog” . . . . . . . . . . . . . . . . . . . . . . . . . . .36 13.4 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 14 Unbundled products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 14.1 History of Solaris Security Products . . . . . . . . . . . . . . . . . . . . . 38 14.2 Automatic Security Enhancement Tool (ASET) . . . . . . . . . . . . 38 14.3 Account Resource Management (ARM) . . . . . . . . . . . . . . . . . . 39 14.4 Compartmented Mode Workstation (CMW) . . . . . . . . . . . . . . . 39 15 Hackers toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 15.1 Trojan Horse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 15.2 Trojan Mule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 15.3 Viruses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 15.4 Worms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 15.5 Back Doors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix A: Crack programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix B: Net Groups and NetIDs . . . . . . . . . . . . . . . . . . . . . . . . 43 Appendix C: Third Party Products Mentioned . . . . . . . . . . . . . . . . . 44 Appendix D: References and Further Reading . . . . . . . . . . . . . . . . . 44 Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 4 1. Executive Summary The UNIX* operating system is generally perceived to lack adequate security. This is partly due to its academic origins and partly due to its design goal to be inviting and flexible. As UNIX has matured more security features have evolved and today UNIX can provide similar levels of security to those found in proprietary systems. One of the main objectives of Solaris 2.3 is to take UNIX further into the commercial market- place where good security is a major concern. Many new security features have been included in Solaris 2.3 to achieve this goal. As an example, Solaris 2.3 has a “Basic Security Module” which has “audit trail” functionality mandated by government groups. For some organisations security is important but not paramount. They wish to have a reasona- bly secure system without losing the flexibility that attracted them to UNIX. The Solaris2 ‘aset’ command has been included for this type of user. 2. Overview This document guides the system administrator thought the issues of system security. Each sec- tion provides examples of the command used to setup the security feature. Information on the important system files and commonly made mistakes have been highlighted. At the end of each section a reference to the relevant Solaris manual set is provided for further information. This document details several methods of attack and tools that are used to gain unlawful access to computer systems (“hacking”). This information will prove useful to enable the system ad- ministrators to guard against hacking. Getting Help Following the guidance of this document will result in a much tighter security for your system. however no system can be considered totally secure. Sun have setup a Security Awareness Pro- gram. As part of this an email alias “security-alert@sun.com” is available for customers to track/report new security issues. It is important to know that Sun will provide security patches to anyone who requests them, even if they do not have a maintenance contract. 3. Introduction The dictionary defines secure as: to make safe from risk or damage; to guarantee against loss. The word security is defined as: freedom from danger, fear, or anxiety; protection: measures taken to protect against espionage or sabotage. All these definitions of security apply to computer systems. We need to physically protect our computers from damage.We need to guard against loss of data as well as illegal access. UNIX* - Is a trademark of X/open Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 5 An organisation’s primary concern is the protection of its data rather than it’s computers sys- tems. Preventing unauthorised access is just a means of protecting data. The loss of CPU time and disk space is not the main concern, data integrity is. Figure1 illustrates that the majority of data damage is caused by error rather than malicious intent. It is clearly a security prerequisite that a thorough backup strategy and comprehensive disaster recovery procedures exist. The task of protecting data involves more than making secure backups and preventing outsiders from logging in. Figure2 illustrates that computer crime is predominately committed by em- ployees. Account security is just the perimeter fence. It is important to protect users from each other with good file system security. As with all crimes, increasing the likelihood of being apprehended is the best prevention. Au- diting provides the weapon to make users accountable for their actions. Fig1: Causes Of Data Damage 52% 15% 10% 10% 10% 3% Human Error Fire Water Sabotage Crime Terrorism Disaster Recovery 77% Security 23% source: Data Processing Management Assoc 1992 Fig 2: Perpetrators Of Computer Crime Employee Former Employee Outsider 81% 13% 6% Login Security 19%Audit Security 81% source: Data Processing Management Assoc 1992 ! Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 6 4. Physical Security “A computer is only as secure as the room it’s locked in?” The problem is that anyone with physical access to a machine can bring along their own disk and connect it. Then it’s a simple matter of crashing the machine and booting from this disk. Once the system is up and running on their disk, the file systems on the original disks can be mounted and tampered with. This would be even easier if, like most SPARCservers, the machine had a CD-Rom player at- tached. In this case all that is required is a copy of the Solaris CD. The system is booted from the CD into single user mode where access to resident disks can be obtained. The machine’s operating system could even be reinstalled! The solution to this scenario is found in section 5 ‘EEPROM security’. However even if the EEPROM will not let them boot an external disk, cables and SCSI switches can be changed to make the new disk appear to be the old disk. So to prevent this tampering with cables, the machines cabinet needs to be locked. Larger Sun Servers have keys which need to be turned for the boot sequence to start but most are left in for convenience. Sun’s Data-centre cabinets also have connections for an electronic key on the back of the power supply, but few people utilise this. Servers can be locked in computer rooms. However desktop systems often cannot. For example a teaching laboratory environment. It is possible to secure the CPU box to a desk as all desktop Suns have a bolting point integral to the system. This not only safe guards against theft of the box but also prevents the lid from being opened and memory or disks removed. It may just be the intention of the assailant to crash the system. It’s difficult to prevent someone pulling out the power cable. However other ways of crashing the machine such as the “stop-a” sequence and unplugging the keyboard cable can be prevented by modifying the kernel. A similar problem is faced with the serial cable to console terminals. Switching the console ter- minal on/off will cause a server to crash. It may even be worth buying a graphics head for your server to side step this potential hazard. In conclusion machines with important data should be locked in a computer room - even if they don’t need air-conditioning. ! Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 7 5. EEPROM Security All Sun system CPU boards have an EEPROM. This EEPROM contains the ‘monitor’ program which controls the system during startup. When a machine is powered on, the monitor firmware will automatically run system diagnostics then boot the system. If this boot sequence is inter- rupted with “stop-a” (the break key if the console device is a dumb terminal), then the machine will be left with the monitor’s interactive prompt: “ok” From this prompt you can instruct the monitor to boot the system from any device: CD-Rom, external disk or even another machine on the network. To limit this, the monitor has three se- curity modes none-secure (the default), command-secure and fully-secure. In fully-secure mode a password, known as the “EEPROM-password” has to be given before the monitor will boot anything. This is a little inconvenient on desktop machines which are prone to being accidentally halted or crashed. The automatic reboot feature would be interrupt- ed with a prompt for the EEPROM password. To alleviate this the command-secure mode can be used which allows only the boot command ‘b’ to be executed without entering the EEPROM password. A suitable policy would be to set server systems to fully-secure and client worksta- tions to command-secure. For example: ok# setenv security-mode=command passwd = <type your password> ok# printenv A nice feature of the “monitor” is the ability to change the power on logo which normally dis- plays the machine’s serial number. You can set this to identify the machine as belonging to your organisation. This would reduce the likelihood of a thief finding a buyer. As long as the EEP- ROM password was set he could not change this banner message. Note however if the EEP- ROM password is not set a thief could disguise the serial number. An Example: ok# setenv oem-banner?=true ok# setenv oem-banner=”THIS IS MY MACHINE” ok# printenv It is possible to reset the EEPROM password without knowing the old password. As long as the machine is up and running the root user can change EEPROM password with the “eeprom” command: # eeprom security-password= Changing PROM password: New password: If you forget the EEPROM password with the security-mode set to full and the machine is halt- ed you will not be able to reboot the machine. The only way then, to reset the EEPROM pass- word would be to change the EEPROM chip itself, which on some machines means changing the CPU board. ! Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 8 There is also a way to see if anyone has attempted to break into the EEPROM. A variable called “security-#badlogins” keeps a count of the failed attempts. It can be set to zero by typing: # eeprom security-#badlogins security-#badlogins=0 Early versions of the ‘Open Boot Prom’ (Version 1.x) had a security problem with specific break sequence. This has been fixed in Version 2.x. If you have one of these older EEPROM it should be replaced. Sun’s customer services should be contacted for advice on your particular machine. To display EEPROM revision type “banner” at the “ok” prompt. Accidental Interrupts No matter which security mode you have set, it is always possible to use the continue command “go”. This assumes the machine has not been turned off. As long as the memory and CPU reg- isters have not been altered the machine will resume execution at the point that it was interrupt- ed. this is the first thing to try if the break sequence has been used accidentally. Users should be informed of this to prevent the system administrator having to attend every accidentally halt- ed machine. NOTE: If the EEPROM is in ‘old-mode’, the user will be prompted by the ‘>’ character instead of ‘ok’. In this case the ‘c’ command is used instead of ‘go’. Alternatively to obtain an ‘ok’ prompt the command ‘new-mode’ is used. Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 9 6 Login Security For the moment we will forget the complications of network authentication systems like NIS and NIS+ (see section 12) and concentrate on accounts and their associated passwords. 6.1 Compromised Passwords The simplest way to gain illegal access to a machine is by obtaining a valid user’s password. A password might be guessed though personal knowledge of the account holder, or discovered written on paper or even written in a file on another system. A common hacking technique is to search email folders for account names and passwords. It’s bad practice, but often users are giv- en their account details to a new system by email. If the new account is little used, rather than remember this additional password, some users save the email or commit it to a file. It may be a low privilege account but it could often be the door for a hacker to greater things. There are many other factors that drive users to committing their password to paper/disk: 1. They have a too many different passwords for too many different machines. 2. For the password to be any good it has to be unintelligible and thus difficult to remember. 3. The administrator makes the users change their password too often. 4. The administrator allocates computer generated passwords impossible to remember. We can do much to prevent a password being discovered, not least by choosing better pass- words, but there is little we can do if users feel they have to write them down in order to re- member them. With this respect you are left at the mercy of the users. 6.2 Good Passwords A good password is meaningful to the user but nonsensical to anyone else. No word found in a dictionary is good enough thanks to programs like “Crack” (See appendix A). Solaris 2.3 has some new features which help users create good passwords. Users run the command “passwd” to change their passwords. Under Solaris 2.3 new passwords are vetted by “passwd” before be- ing accepted. It checks that: 1. The password is greater than six characters. (Configurable in the /etc/default/passwd file). 2. The password has at least two alphabetical and one non-alphabetical characters 3. The new password is not the same as the old password. 4. The password is not the same as the user name. Unlike Solaris1, insisting on a rejected password will not result on the password being accept- ed. Note: “passwd” will not object to any password set by root as it is assumed that the root user knows best. 6.3 Missing Passwords Its a bad idea to allow accounts to have no password. By default, Solaris2 forces all accounts to have a password. To confirm this check that the PASSREQ (PASSword REQuired) parameter in the /etc/default/login file, is set to YES. ! Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 10 6.4 Password Administration Solaris 2 has a number of new features for setting password policies. These are set as fields in the /etc/shadow file. On a per user basis the following can be defined: username:passwd:lastchg:min:max:warn:inactive:expire Username: must match a line in /etc/passwd passwd: encrypted password lastchg: number of days between 1/1/70 and last change of password min: minimum number of days between password changes max: maximum number of days between password changes warn: number of days before password expires a warning is given inactive: number of days of inactivity allowed before account is locked. expire: date when account will expire All the above fields can be changed with the /usr/bin/passwd command. Its always best to use commands like passwd or use admintool to set these properties as hand editing the shadow password file can result in catastrophe if typing mistakes are made. Solaris1.1 did have a pass- word aging facility but it was not compatible with NIS and was little used. Note: Default poli- cies for password aging are defined in “/etc/default/passwd”. (See man page for passwd (1)). Locking Accounts and Passwords Solaris 2 gives us the facility to lock an account.There is even a way to prevent users from changing their passwords. By setting ‘min’ greater than ‘max’ the user can still login but not change his password. Useful for allocating password rather than allowing users choose their own. Here are some examples: # passwd -l <user> Lock an account # passwd -n 10 -x 7 Lock a password # passwd -f <user> Change password on next login # passwd -n 30 <user> Change password every 30 days Remember: don’t enforce too strict a regime, as it will force users to write down their pass- words. Passwords are your first and most important line of defence and any one user can be the weak link in the chain. Education of users rather than enforcement of rules is the key to good password security. 6.5 Direct root login Any user with the UID of 0 (often called the Superuser or root) is granted full access to all files on the system despite any access permissions set-up by the file’s owner. The superuser’s name may not necessarily be called “root” and in fact several user names could have a UID of 0. This is an important thing to remember when looking for evidence of hacking. Given it’s awesome power it’s a good idea to restrict the activities done as root. Most system administrators login directly as root as a matter of course, because they believe that root privi- leges are needed to perform their tasks. Not so, in Solaris 2 group 14, often named “Sysadmin”, ! [...]... application/database In some implementations all users login with the same UNIX username and rely on the database’s user registration for security This is never a good idea but often done Smarter implementations will match the UNIX username to the database user name and have tools for the database administrator (DBA) to create/remove accounts Adding a user with such a tool will create a UNIX account and DBMS account... these maps by communicating with the NIS server This has the advantage that modifications can be made in one central machine (the master NIS server) and their effects propagated to all machines in the NIS domain For instance a new user can be added to the /etc/passwd map and instantly be able to login to any machine in that NIS domain Initially Solaris 2 supported only Client side NIS functionality,... commands is a complicated task A GUI interface is definitely needed before NIS+ is widely accepted 13 Logs & auditing Page 34 Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK An important security requirement is the ability to monitor what is happening and what has happened on a system It may be easy to commit a crime but not so easy to get away with it! By running auditing you make your... This machine can then be setup a Firewall machine A Firewall machine has IP routing turned off and does not run in.routed Extra physical and login security is applied Since any external assailant has to gain access to this machine first before he can attack any of your other machines, security efforts can be focused on it Authentication and file access permission can be vigorously tightened The ASET utility... detected There have been many request that SunSoft make the number of allowed failure configurable Page 11 Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Encrypted Passwords Because of password cracking programs (See Appendix A) , its a bad idea to let the world see even your encrypted passwords If hackers can take a copy of the encrypted passwords then they can attempt to crack them... your machine less attractive to hackers However auditing itself is not infallible A clever hacker will either turn-off auditing or alter logs to cover his tracks If he has gained access to the root account there is nothing to stop him editing the audit log files One approach is to printout audit logs as they are created No hacker can erase what has been printed Similarly a printer can be connected to the... (See Appendix C-Third Party Products) If full bidirectional functionality is required then Solaris 2 has an additional “port passwords” feature that can help Port Passwords The Solaris 2 login program can be setup to prompt for an additional password when users connecting over dialup lines Although this feature may have been intended for additional security to dialup lines, you can enable this for any... their own machine at leisure and in secret To prevent this Solaris 2 has a shadow password file UNIX requires the account information to be globally accessible This means that the /etc/passwd file must be readable by everyone In Solaris 1 encrypted passwords were stored in this file too In Solaris 2 the /etc/passwd file still contains the account information but passwords and associated information is kept... utility can be used to turn a gateway machine into a firewall (See section 14.2 on ASET) Of course it may be excessively prohibitive to turn off all IP routing So it is possible to allow the firewall machine to effectively route packets from specific applications Some utilities like “ftp” can still be used across the gateway by making it a “proxy” ftp server Page 31 Solaris Security : A Practical Guide :... terminating all calls after the user has identified himself The system will then dial him back on a number stored by the system administrator In this way only registered phone numbers can establish connections The disadvantage being that the call is now outgoing for telephone charging purposes Solaris 2 has no dial-back facility as standard However a third part product called “TermServ” can be purchased and . Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 1 A Practical Guide to Solaris Security A White Paper March 1994 Synopsis This white paper aims to provide practical. damage.We need to guard against loss of data as well as illegal access. UNIX* - Is a trademark of X/open Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 5 An organisation’s. some machines means changing the CPU board. ! Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK Page 8 There is also a way to see if anyone has attempted to break into the