UNIX Security Checklist

UNIX SECURITY CHECKLIST SUBMITTED BY: Michael Parkinson email: par282@audit.csiro.au This model was used to assess the relative security of a large number of independently managed SUNOS machines. This was in the context of a distributed Financial Management system. Preliminary Obtain the following file listings (or equivalents) .profile, .cshrc and .login files for: -root -systems administrator (with the highest level of privilege) -privileged users or special group users -a typical non-privileged user -the default (as supplied to new users) Special Files: /etc/config/login.options /etc/ftpusers /etc/group /etc/hosts.equiv /etc/hosts.lpd /etc/inittab /etc/inetd.conf /etc/passwd /etc/rc /etc/rc.local /etc/security /etc/security/audit/audit_control /etc/shadow, /etc/security/password.adjunct, /etc/security/group.adjunct /etc/ttytab /.rhosts Directory Entries (ls -al) for: all .rhosts files on system / (root) directory entry /bin (include also directory entries for all files in this directory) /dev /etc /etc/config/login.options /etc/ftpusers /etc/group /etc/hosts.equiv /etc/hosts.lpd /etc/inetd.conf /etc/inittab /etc/passwd /etc/rc /etc/rc.local /etc/security /etc/security/audit/audit_control /etc/shadow, /etc/security/password.adjunct, /etc/security/group.adjunct /etc/ttytab /unix /usr /usr/adm /usr/bin (include also directory entries for all files in this directory) /usr/lbin (include also directory entries for all files in this directory) /usr/lib/crontab /usr/spool Copy of these files in login directory: /usr/adm/sulog /etc/adm/messages*.* Run the following commands 1. Run the COPS package 2. Please run the CRACK package. 3. ls -lARg / > unix.directories There is a script file called initialcheck.foreign which is available from the audit unit. This can be modified using sed as follows: sed s/foreign/host/ initialcheck.foreign > initialcheck.host Running this script will collect many of the required files into a local directory - giving them file names of the form host.* ----------------------------------------------------------------Additional Investigations Search for Powerful Utilities This is a hard task, for we do not know what file names we are looking for. It will be necessary to identify the purpose of all executables with the same owner/group as the data files in key applications. There are a couple of other things we can do: Seek 'zap' files Issue command: grep -i "zap" unix.directories > zap.files : Seek executables with setuid or setgid to root This is done with the grep command from the directories or as output from COPS. Check umask Issue commmand: umask 077 would be ideal, but this might be impracticable; 027. Machine Access Examination of Files Obtained /etc/ttytab should have no terminals marked as "secure". If this is the case, noone can logon directly as root; they are required to use the su command to get superuser access. - It is probably advisable to globally replace 'secure' with 'unsecure' in this file. It is reasonable to retain 'console' as secure. /etc/hosts.equiv should not exist. /etc/hosts.lpd should contain no entries of '+'. In /etc/inetd.conf there are a number of default entries which should be removed or commented out: shell stream tcp nowait root /usr/etc/in.rshd in.rshd login stream tcp nowait root /usr/etc/in.rlogind in.rlogind exec stream tcp nowait root /usr/etc/in.rexecd in.rexec.d comsat dgram udp wait root /usr/etc/in.comsat in.comsat uucp stream tcp nowait root /usr/etc/in.uucpd in.uucpd tftp dgram udp wait root /usr/etc/in.tftpd in.tftpd -s /tftpboot finger stream tcp nowait nobody /usr/etc/in.fingerd in.fingerd rusersd/1-2 dgram rpc/udp wait root /usr/etc/rpc.rusersd rpc.rusersd Examine /etc/rc.local and check whether code to run NIS has been removed or commented out. Confirm that status is correct. suggest at least Check for world-writeable files Use grep find or COPS. Be particularly wary of world-writable files which are referenced in /etc/rc or /etc/rc.local. Other Version of Unix uname -a .rhosts files in user directories Issue command: grep 'host' unix.directories > hosts.files (see footnote 1) Issue command: grep -v ':/home/' /etc/passwd > rhosts.files.2 (see footnote 2) - This lists files without their home directory on the /home tree. This helps to locate rhosts files in strange places. It also assists in identifying users without a valid home directory. Issue command: ls -lAR /home | egrep '(\.rhos|\.cs|/hom)' > rhosts.files.3 (see footnote 3) - This identifies rhosts files on the /home tree. User Identification & Priveleges Examination of Files Obtained Ensure that there are no '+' entries in: /etc/passwd /etc/security/passwd.adjunct /etc/group /etc/security/group.adjunct These allow the use of a Name Information Server (yellow pages) for remote authentication and lessen control over the system. In /etc/group the group wheel should be defined. If it is not, than any one may use the su command to become root (that is assuming that they have the password). The entry will list all those people who are permitted to have superuser access. All accounts must have passwords (that is, field 2 in both /etc/passwd and /etc/security/passwd.adjunct [C2 security] must be non-blank). For C2 security, an entry of '##' in this field is required in /etc/passwd and if '*' occurs in /etc/security/passwd.adjunct it effectively disables use of the account. File /etc/ftpusers (see footnote 4) must exist and contain the entry "root". This prevents the use of ftp to the machine as root user. - There might be an exception to this - I am looking. Superuser password is changed regularly Question the systems administrator. password expiry? npasswd Is it used? Unique Userids Issue commands: copy /etc/passwd local.passwd sort -n -t: +2 -osorted.password local.password Examine the resulting file and ensure that all userids (field 3 of each entry) is unique. Last Login time/Unused Accounts Issue commands: cut -d: -f1 /etc/passwd > usersout sed s/^/"finger "/ usersout >usersf sh usersf > last.login or: cut -d: -f1 /etc/passwd | xargs finger -m > last.login Unused accounts: Maximum idle time? Idle accounts (not logged on for three months) Idle accounts should be disabled. Check accounts against PEDLIST - Only those with legitimate access (officers of the site/Division) to the machine should have active accounts. Be wary of large numbers of ITSB/CFB accounts (especially if they are listed in group wheel). Procedures Formal procedures for obtaining login accounts or for authorisation of access levels? Messages Files Examine messages file for ROOT and su activity. Copy files: cp /etc/adm/messages*.* Concatenate into a single file dahsun.log: cat messages.4 ... messages.1 messages > dahsun.log Issue command: grep -v 'vmunix:' dahsun.log > edited.log Password storage. Automated This should remove the more tedious messages from the file Issue command: who /var/adm/wtmp | egrep '(Jun|Jul)' > who.is.on This lists all logins for June and July. This log might assist in the analysis of the prior log. Test repeated logins with wrong password Examination of the Audit Logging Examine the version of the audit daemon auditd which is running. This should be 24 July 92 or later. The audit log contains messages from authpwd deamon. These indicate all login attempts (whether successful or unsuccessful), the success of the attempt and the userid. Earlier versions of auditd also included the unencrypted password. The result was to compromise the password of every user on the system: anyoune who has access to the audit files can access anything on the system. If the later version of auditd is not running, then the audit account should be disabled (put a '*' in the password field) so that noone can log in. This means that access to audit privileges must be obtained by use of su from the root account. Mail for audit should be redirected to root. - Version of auditd: Particular Applications This will depend upon the system being investigated. The principle is to ensure that changes to program code is controlled: * programmers (that is people who have programming facilities available) should not have write access to applications * system update proceudres should be documented * configuration/version control procedures should be in place Unibis Files - /home/finance/ - is assumed to be the Unibis directory Issue commands: ls -lAR /home/finance/ > unibis.dir grep -i '/' unibis.dir > unibis.tree.structure grep -v ' unibis ' | grep -v ' root ' > unibis.files.owned.by.users Examine these files to determine structure and access permissions for the system. Files in the /DATA directory in this structure should be protected from the ordinary user. Unibis users should, in general, not have access to native Unix. Thus the .login & .profile scripts for these users should take them directly into Unibis and log them out of the system when they leave the application. Unibis data files should be accessible only through the Unibis application. That is, Unibis and its files should have a single owner; Unibis should have the setuid flag set (mode 2110 or permissions ---s--x--) and data files should be mode 600 (that is read/write only by owner [permissions -rw-------]). Examine the file unibis.dir created above. Contents of directories /usr/util, /usr/ubprog4, /var/adm should be protected. The Progress executables (directory /usr/dlc/_* should be owned by root and have permission -rwxr-x---. Network and System Administration Administrator?? Time? Other responsibilities? Training/Background?? USO?? UNIBIS setup and update?? Backup Log/Instructions? According to Systems Administration Manual (Ch 9) backup process is started by cron. Check cron commands. Review the backup script. Have restoration procedures been documented and tested? Where are backup tapes stored? How many set of tapes/cartridges are there? How often are the heads of the drive cleaned? Logging of significant events Examine console log. Are system problems documented, investigated, reported further and followed up as necessary. How is upgrading of software handled? - who initiates, who authorises, who is notified? Security Administration/Audit COPS CRACK ------------------------------------------------------------------------Deputy? UNIX SYSTEM Our standard is that all systems should be secured to (at least) level C2 unless there are very good reasons for not doing so. The access levels a system has should not be determined solely by the data held on the system, but also by the data on the network that can be accessed via the machine. Conversely, every machine should assume that the network is hostile. Security Compliance Checklist (see footnote 5) Security Criterion Management of log-on IDs - all users should have to identify themselves to the computer by unique individual logon IDs * procedure for obtaining account * procedure for determining access levels * restriction of user's access to various facilities (procedure for authorising access) * written records of registration / relationship with /etc/passwd file there should be no group accounts. All users should be responsible for their own logon IDs * /etc/passwd has no generic accounts * userids (the number) should be unique unused logon IDs should be suspended/ removed. Locking a logon ID is generally to be preferred to deleting a logon ID from the system, as the management and audit trails are easier to follow * procedures exist for monitoring account usage and regularly removing or suspending unused accounts * procedure when staff leave * obtain details of staff who have left in past 12 months and check against /etc/passwd file. lockouts - logon IDs should be disabled after three unsuccessful logon attempts * test the effect of multiple logon attempts time outs - inactive sessions should be disconnected after fifteen minutes. * question system administrator Yes No Action - - - * observe result of leaving terminal idle * use finger to test system (see testing notes) login script warns against unauthorised use and consequencess od security breaches * message should not give too much help to would-be intruders Password management A password policy should be developed and distributed to all users - passwords should be mandatory - password minimum length should be six characters - passwords should be regularly checked against obvious choices * Consider regular use of CRACK to highlight poor passwords * Install npasswd - C2 security features such as a "shadow" passsword file should be implemented - passwords should be stored in an encrypted format - password change should be enforced at least every 30 days - only the system administrator should be able to change a password more frequently than once a day, and - previous passwords should be stored by the system, and the re-use of the last ten passwords disallowed. Privileges - the passwords for logon IDs with high-level privileges such as System Administrator, Super-User and 'root' should be held securely and changed frequently - number of people who have (or can obtain) superuser priveleges should be minimised * examine number in SUNOS group wheel or any group with gid=0 - computer consoles should be locked eg. by a password, when unattended. * consider use of locking programs (voluntary) such as Xlock Access to data - access to data (READ, WRITE, MODIFY, DELETE etc.) should be controlled eg. by access control lists (ACLs) * consider the default umask (The minimum umask for users should be 022 and - for root should be 027. umask of 077 gives maximum protection) system protection The following files (directories) should have only root as their owner and groups: /. /etc /user /dev /bin Establish the existence of worldwriteable files and examine to determine if appropriate * list all such files using COPS (if available) Consider access to powerful utility programs (eg ZAP programs) * examine program access permissions & ownership * examine extent of logging of use Establish the existence of files with setuid (see footnote 6) and setgid and determine whether reasonable * COPS should identify these - user protection: (see footnote 7) - home directory not writeable by others - login shell not writeable by others - current directory last in path list (if present at all) - .profile and .login not accessible (read, write, execute) by others. * examine file permissions for a sample of user home directories * examine file permissions for a sample of user loin shells * review .profile for a sample of users and examine the position of the entry "." in the PATH statements * review permissions for .login and .profile for a sample of users programmers should not have WRITE access to production code or data. - Network Access - The machine should be protected against attack via another machine * consider .rhosts files & hosts.equiv * consider the security of any Name Information Server. * consider use of network encryption * consider fire-walls & packet filtering mechanisms (eg routers) * consider use of traffic monitors such as tcp_wrapper or tripwire. Logs The following should be logged: - all failed login attempts - all attempted logins from a remote source - all sus to root Physical security - computer rooms should be locked when unattended - access to computer rooms should only be granted after written application has been made specifying the level of access required (eg. to an outer office where the printer is located, or to the inner area holding the computer itself) and the reason that access is needed. An authorising signature should be part of the document * consider control of keys & revoking of access * access control the responsibility of a single person (independent of the programming function) * consider level of supervision of this function - card-key access to the computer room should be recorded continuously in another secure area, and - the construction of the computer room should make forced access sufficiently difficult to deter potential intruders. - Protection against environmental hazards such as humidity and electrical surges. (The decision about which computers should be in specially designed computer rooms and those which can be housed in a secure office environment should be made by management according to the sensitivity of the data held.) hardware outside the computer room (eg switching gear, modems & communication lines) should be protected from unauthorised intererence. Backup - there should be regular backups of - - system software, applications, and data; a minimum of a weekly backup of a full image copy backup procedures should be documented, including an appropriate backup schedule, and up-to-date backups should be stored off-site. * review transport doumentation * consider accompanying documentation list of files backed up, chnges made to system since last backup. The heads of the tape drive are cleaned regularly Backup storage rotated, retensioned and replaced regularly Backup media well labelled and controlled. Capacity and Reliability - there should be a mechanism for monitoring the system capacity and user service on a regular basis - target service levels should be set and reported against Disaster Recovery - there should be a documented disaster recovery plan which includes: - where backups of software and data are stored off-site - who has authority to access the stored backups - where appropriate hardware will be available, and - the procedures to be followed to load system software, applications and data, - the version (release dates) of software to be recovered, - system testing to be conducted after recovery - the disaster recovery plan should be endorsed by management - a hard copy of the plan should be stored off-site - the plan should be tested annually, with restoration from off-site backup. System Administration - Systems administrators should be appropriately trained and supported. - background - training support services deputy backup System software change control - system software change control requirements include: - consultation with areas affected, before a change is approved - authorisation - backup - testing - contingency planning - segregation of duties - scheduling changes - notification of users before the change is made, and - the formal recording of changes made. - a standard change control form that lists the steps to be gone through, the positions or officers responsible, and the signatures to be obtained can simplify the recording process and provide evidence of the procedures followed, and - procedures to be followed should be documented. - version control * determine that Unix version is the one approved * examine version logs for key applications compare with latest release and update approvals * examine fault reports for key applications and subsequent action Software ownership - purchased software must be covered by licences . - contractor-developed software must have all intellectual rights owned by the Commonwealth. Delegates should be made aware of this requirement, and - licences and contracts should be stored safely so that they can be produced upon request. FOOTNOTES 1 Two .rhosts files were found. 2 Identify users whose home directory is not on tree /home/ 3 A group entry beginning with a `+' (plus sign), means to incorporate an entry or entries from the Network Information Service (NIS) A `+' on a line by itself means to insert the entire contents of the NIS group file at that point in the file. An entry of the form: `+groupname' means to insert the entry (if any) for groupname. If a `+' entry has a non-empty password or user-list field, the contents of that field override the corresponding field from the NIS service. The gid field cannot be overridden in this way. An entry of the form: -groupname indicates that the group is disallowed. All subsequent entries for the indicated group- name, whether originating from the NIS service, or the local group file, are ignored. Malformed entries cause routines that read this file to halt, in which case group assignments specified further along are never made. To prevent this from happening, use grpck(8) to check the /etc/group database from time to time. 4 /etc/ftpusers contains a list of users who cannot access this system using the File Transfer Protocol (FTP). ftpusers contains one user name per line. If this file is missing, the list of users is considered to be empty, so that any user may use FTP to access the system if the other criteria for access are met. 5 Adapted from ANAO checklist used in IT Audits of Dept of Primary Industry and CSIRO sites. This is suplemented by the Unix Security Checklist produced within Corporate Audit. 6 Setuid is a under the owner's privileges of the privileges of the powerful privilege which allows a user to run a program userid. This effectively gives the user all the owner. Setgid is similar except that the owner group are provided. 7 These steps are mostly designed to protect users from trojan horses.