## Seven Steps to a More Trusted System ## Mike Hoskins This paper addresses 'Adding Trust to a New System'. All examples are taken from a FreeBSD 3.0-RELEASE system. A somewhat 'generic' approach is taken to allow application across numerous UNIX platforms. Some FreeBSD-specific examples are included. Adding trust to an existing system is quite different then adding trust to a 'newly installed' system, and typically depends upon the administrator's ability to confirm the integrity of system data. Data integrity is beyond the scope of this paper, so we will assume we are starting with a newly installed system, or that some amount of integrity is present. This paper represents a walk-through of steps I typically take when preparing a newly installed FreeBSD system for commissioning. It is not all-inclusive. Many topics can add to system trust (such as network security), but are beyond the scope of this paper. It is suggested that CERT's Unix Security Checklist also be consulted as a bare minimum. It can be found at: ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist It is suggested that the described steps be taken on any newly-commissioned systems before going 'multi-user' (attaching to a network or allowing non-administrative access). The methods described below should follow the installation of any known, vendor, security patches/updates. Step 1 - SUID/SGID Audit SUID (Set User ID) and its weaker cousin, SGID (Set Group ID) have led to the majority of system compromises on UNIX platforms. Skill may be required to find potential SUID/SGID-related weaknesses, but many times compromises are driven by mere brute-force techniques (since attackers seem to always have more time on their hands than the already over-worked administrators) or existing exploits in 'script' form. The following excerpt from 'man chmod' gives us enough technical understanding of SUID/SGID: ...(the set-user-ID-on-execution bit) Executable files with this bit set will run with effective uid set to the uid of the file owner. Directories with the set-user-id bit set will force all files and sub-directories created in them to be owned by the directory owner and not by the uid of the creating process, if the underlying file system supports this feature: see chmod(2) and the suiddir option to mount(1). ...(the set-group-ID-on-execution bit) Executable files with this bit set will run with effective gid set to the gid of the file owner... Numerous SUID/SGID applications are available on most UNIX systems. Many of these are not needed, or are candidates for restricted access. Therefore, system trust can be increased by removing/restricting access to programs with the SUID/SGID bits set. Let's find all SUID/SGID programs on our system... # find / \( -perm -2000 -o -perm -4000 \) -print >> audit.0221& This will look at all files under '/' (everything) and match any which have the SGID (2000) or SUID (4000) bits set. It will then print the results (redirect) to the file 'audit.0221'. The '0221' is just a date stamp. Note that I appended an ampersand '&' to this command... Depending upon the system, this 'find' can take a few minutes. The ampersand instructs the shell to perform the current process in the background, allowing user interaction to continue while we wait. The file 'audit.0221' will now contain a complete list of files with the SUID and/or SGID bits set. You can now remove/restrict access according to local policy... For me, I simply remove world access to the majority of SUID/SGID programs. A 'chmod o-rx ' is quite simplistic, and takes care of the threat posed by most of the typically unused SUID/SGID programs. Some obvious selections will need to remain o+rx, such as passwd. Other 'common' utilities such as 'netstat' (SGID kmem) can be used to gain information about the system that is potentially useful to an attacker, and should be treated cautiously and/or according to site policy. Step 2 - Disable Unnecessary Services On UNIX systems, /etc/inetd.conf contains a list of supported services and the associated programs inetd should spawn to answer incoming service requests. By default, many unnecessary services may be running. Some systems, for example, leave TCP/IP 'small servers' enabled (chargen, echo, etc.). These are almost always 'unnecessary' and may be disabled. Any service that is not needed should be removed. To remove a service, simply comment out it's associated line in inetd.conf by placing a hash '#' in front of it. I typically only leave telnet open (for compatibility only; I use and recommend ssh). After making edits, save inetd.conf and HUP inetd: # ps ax | grep inetd 135 ?? Is 0:00.11 inetd # kill -1 135 One service that is often debated is 'finger'. If you choose to run fingerd, be sure to invoke the secure operation ('-s' argument under FreeBSD). If your vendor does not support secure operation by default, you should look to alternative finger implementations such as secure_finger. Personally, I disable finger. To provide some level of user feedback and avoid frustration, I replace the existing fingerd line in inetd.conf with the following: finger stream tcp nowait nobody /bin/cat cat /etc/finger.msg This causes the file '/etc/finger.msg' to be displayed to users requesting network (requests including '@') finger information. Ideally, this file should include something useful... An example: Domain Networks, Inc. Phone: +1 123 456 7890 Email: noc@domain.com We do not provide finger information to external hosts... For more information, or to report system problems, please send email or call. Finally, chmod 600 inetd.conf - there is no need for non-administrative users to access inetd's configuration file. Step 3 - Install TCP Wrappers You should closely monitor and control access to the few essential services you do provide. TCP Wrappers provides an easy way to secure many system services. Under FreeBSD, TCP Wrappers can be installed from the ports collection (/usr/ports/security/tcp_wrapper). TCP Wrappers controls access via 'hosts.allow' and 'hosts.deny' files in /usr/local/etc. You can specifically allow/deny hosts or networks access to services. Step 4 - Audit System Accounts System accounts should be closely audited. Whenever possible, administrative accounts should be configured with no login shell or home directory. They should have their password field set to '*' to disallow logins. An example is the 'pop' account: pop:*:68:6:Post Office Owner:/nonexistent:/sbin/nologin Any unnecessary accounts should be removed from the system. Traditional accounts such as 'uucp' should be disabled, and any programs associated with them should be 'chmod 0' unless needed for system operation. Once the system is commissioned, account auditing should become a routine... 'Joe accounts' (accounts with the same username and password), blank passwords, etc. should be watched for. Step 5 - Secure the Console To avoid the possibility of 'root compromise by reboot', cd /etc and edit 'ttys'. Look for the 'console' line and change 'secure' to 'insecure' as follows: console none unknown off insecure This will cause the system to prompt for the root password when being rebooted in single-user mode. Step 6 - Minimize Root Processes: Many popular processes such as 'named' and 'sendmail' run as root. It is possible to increase system trust by decentralizing the control of as many system daemons as possible. Named can be ran in a chroot() environment and configured with its own user/group... Sendmail can be tweaked - or sendmail alternatives such as 'qmail' and 'Postfix' can be installed - to maximize security. Information on running chroot() named can be found at http://www.psionic.com/papers/dns.html (original, full text, OpenBSD version) as well as http://www.antisocial.net/~modred/papers/named.html (FreeBSD command summary and comments). Sendmail 8.9 is quite useable... and http://www.sendmail.org/ provides a wealth of related information. For those preferring a tool more in tune with UNIX philosophy, however, I would suggest Postfix. Postfix minimizes the use of root-owned processes and is quite simplistic to setup. My installation details for FreeBSD may be found at http://www.antisocial.net/~modred/papers/postfix.html. Step 7 - Monitoring There is no 'final' step. While the tasks described here and in other papers provide a good starting place, administrators must remain proactive. Utilities such as COPS, Tiger and Tripwire should be configured and closely monitored. Systems (especially those that are Internetworked) are subjected to ever-increasing risks by crackers with lots of time, patience and resources. Administrators must take advantage of available countermeasures and techniques to better ensure system integrity and increase trust. Summary This paper is, in no way, a single point of reference. Security-conscious administrators will read other well-known resources such as CERT's checklist, browse security mailing lists and archives for known weaknesses, implement security measures such as those detailed at http://www.psionic.org, and engage in countless other activities to increase the trust of the systems they are responsible for. Administration is an ever evolving art form... There is no time to loose in the battle against computer crime. I hope that some of the techniques and resources provided within this paper are beneficial to those reading it. I welcome related comments, or systems and network security discussion in general. Good luck, and secure computing... Mike $Id: security.txt,v 1.1 2000/02/16 08:07:49 jim Exp $