From owner-svn-doc-projects@FreeBSD.ORG Mon Apr 29 12:44:23 2013 Return-Path: Delivered-To: svn-doc-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D4920923; Mon, 29 Apr 2013 12:44:23 +0000 (UTC) (envelope-from dru@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id C65661266; Mon, 29 Apr 2013 12:44:23 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.6/8.14.6) with ESMTP id r3TCiNE7004917; Mon, 29 Apr 2013 12:44:23 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.6/8.14.5/Submit) id r3TCiN1H004916; Mon, 29 Apr 2013 12:44:23 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201304291244.r3TCiN1H004916@svn.freebsd.org> From: Dru Lavigne Date: Mon, 29 Apr 2013 12:44:23 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-projects@freebsd.org Subject: svn commit: r41513 - projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security X-SVN-Group: doc-projects MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for doc projects trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 12:44:23 -0000 Author: dru Date: Mon Apr 29 12:44:22 2013 New Revision: 41513 URL: http://svnweb.freebsd.org/changeset/doc/41513 Log: First pass through this chapter. Due to its size, patch only addresses first 1/2 of chapter, fixing the following: - &os; - etc and you - some acronym tags - general tightening and grammo fixing - removed note in 15.3 as this belongs in preface, not in a chapter - fixed filesystems (which bled over into other part of chapter) Approved by: gjb (mentor) Modified: projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml Modified: projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml ============================================================================== --- projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml Sat Apr 27 14:18:12 2013 (r41512) +++ projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml Mon Apr 29 12:44:22 2013 (r41513) @@ -24,31 +24,27 @@ Synopsis - This chapter will provide a basic introduction to system + This chapter provides a basic introduction to system security concepts, some general good rules of thumb, and some - advanced topics under &os;. A lot of the topics covered here - can be applied to system and Internet security in general as - well. The Internet is no longer a friendly place - in which everyone wants to be your kind neighbor. Securing your - system is imperative to protect your data, intellectual - property, time, and much more from the hands of hackers and the - like. - - &os; provides an array of utilities and mechanisms to ensure - the integrity and security of your system and network. + advanced topics under &os;. Many of the topics covered here + can be applied to system and Internet security in general. + Securing a system is imperative to protect data, + intellectual property, time, and much more from the hands of + hackers and the like. + + &os; provides an array of utilities and mechanisms to + protect the integrity and security of the system and + network. After reading this chapter, you will know: - Basic system security concepts, in respect to - &os;. + Basic &os; system security concepts. - About the various crypt mechanisms available in &os;, - such as DES and - MD5. + The various crypt mechanisms available in &os;. @@ -61,41 +57,37 @@ - How to set up Kerberos5 on + How to set up Kerberos on &os;. How to configure IPsec and create a - VPN between &os;/&windows; - machines. + VPN. How to configure and use - OpenSSH, &os;'s - SSH implementation. + OpenSSH on &os;. - What file system ACLs are and how to - use them. + How to use filesystem ACLs. - How to use the Portaudit - utility to audit third party software packages installed - from the Ports Collection. + How to use portaudit to + audit third party software packages installed from the + Ports Collection. - How to utilize the &os; security advisories - publications. + How to utilize &os; security advisories. - Have an idea of what Process Accounting is and how to - enable it on &os;. + What Process Accounting is and how to enable it on + &os;. @@ -107,36 +99,26 @@ - Additional security topics are covered throughout this book. - For example, Mandatory Access Control is discussed in and Internet Firewalls are discussed in . + Additional security topics are covered elsewhere in this + Handbook. For example, Mandatory Access Control is discussed in + and Internet firewalls are discussed in + . Introduction Security is a function that begins and ends with the system - administrator. While all BSD &unix; multi-user systems have - some inherent security, the job of building and maintaining - additional security mechanisms to keep those users - honest is probably one of the single largest - undertakings of the sysadmin. Machines are only as secure as - you make them, and security concerns are ever competing with the - human necessity for convenience. &unix; systems, in general, - are capable of running a huge number of simultaneous processes - and many of these processes operate as servers — meaning - that external entities can connect and talk to them. As - yesterday's mini-computers and mainframes become today's - desktops, and as computers become networked and inter-networked, - security becomes an even bigger issue. + administrator. While &os; provides some inherent security, the + job of configuring and maintaining additional security + mechanisms is probably one of the single largest undertakings of + the sysadmin. System security also pertains to dealing with various forms of attack, including attacks that attempt to crash, or otherwise make a system unusable, but do not attempt to compromise the - root account (break root). - Security concerns can be split up into several - categories: + root account. Security concerns can be + split up into several categories: @@ -148,7 +130,7 @@ - Root compromise through accessible servers. + Root compromise through accessible services. @@ -171,50 +153,36 @@ Denial of Service (DoS) - A denial of service attack is an action that deprives the - machine of needed resources. Typically, DoS attacks are - brute-force mechanisms that attempt to crash or otherwise make a - machine unusable by overwhelming its servers or network stack. - Some DoS attacks try to take advantage of bugs in the networking - stack to crash a machine with a single packet. The latter can - only be fixed by applying a bug fix to the kernel. Attacks on - servers can often be fixed by properly specifying options to + A Denial of Service DoS attack is an + action that deprives the machine of needed resources. + Typically, DoS attacks are brute-force + mechanisms that attempt to crash or otherwise make a machine + unusable by overwhelming its services or network stack. Attacks + on servers can often be fixed by properly specifying options to limit the load the servers incur on the system under adverse conditions. Brute-force network attacks are harder to deal - with. A spoofed-packet attack, for example, is nearly - impossible to stop, short of cutting your system off from the - Internet. It may not be able to take your machine down, but it - can saturate your Internet connection. + with. This type of attack may not be able to take the machine + down, but it can saturate the Internet connection. security account compromises - A user account compromise is even more common than a DoS - attack. Many sysadmins still run standard - telnetd, - rlogind, - rshd, and - ftpd servers on their machines. - These servers, by default, do not operate over encrypted - connections. The result is that if you have any moderate-sized - user base, one or more of your users logging into your system - from a remote location (which is the most common and convenient - way to login to a system) will have his or her password sniffed. - The attentive system admin will analyze his remote access logs - looking for suspicious source addresses even for successful - logins. - - One must always assume that once an attacker has access to a - user account, the attacker can break root. - However, the reality is that in a well secured and maintained - system, access to a user account does not necessarily give the - attacker access to root. The distinction - is important because without access to root - the attacker cannot generally hide his tracks and may, at best, - be able to do nothing more than mess with the user's files, or - crash the machine. User account compromises are very common + A user account compromise is more common than a + DoS attack. Many sysadmins still run + unencrypted services, meaning that users logging into the + system from a remote location are vulnerable to having their + password sniffed. The attentive sysadmin analyzes the + remote access logs looking for suspicious source addresses and + suspicious logins. + + In a well secured and maintained system, access to a user + account does not necessarily give the attacker access to + root. Without root + access, the attacker cannot generally hide his tracks and may, + at best, be able to do nothing more than mess with the user's + files or crash the machine. User account compromises are common because users tend not to take the precautions that sysadmins take. @@ -223,27 +191,14 @@ backdoors - System administrators must keep in mind that there are - potentially many ways to break root on a - machine. The attacker may know the root - password, the attacker may find a bug in a root-run server and - be able to break root over a network - connection to that server, or the attacker may know of a bug in - a suid-root program that allows the attacker to break - root once he has broken into a user's - account. If an attacker has found a way to break - root on a machine, the attacker may not - have a need to install a backdoor. Many of the - root holes found and closed to date involve - a considerable amount of work by the attacker to cleanup after - himself, so most attackers install backdoors. A backdoor - provides the attacker with a way to easily regain - root access to the system, but it also - gives the smart system administrator a convenient way to detect - the intrusion. Making it impossible for an attacker to install - a backdoor may actually be detrimental to your security, because - it will not close off the hole the attacker found to break in - the first place. + There are potentially many ways to break + root: the attacker may know the + root password, the attacker may exploit a + bug in a service which runs as root, or the + attacker may know of a bug in a SUID-root program. An attacker + may utilize a program known as a backdoor to search for + vulnerable systems, take advantage of unpatched exploits to + access a system, and hide traces of illegal activity. Security remedies should always be implemented with a multi-layered onion peel approach and can be @@ -251,26 +206,26 @@ - Securing root and staff + Secure root and staff accounts. - Securing root–run servers - and suid/sgid binaries. + Secure root–run servers + and SUID/SGID binaries. - Securing user accounts. + Secure user accounts. - Securing the password file. + Secure the password file. - Securing the kernel core, raw devices, and - file systems. + Secure the kernel core, raw devices, and + filesystems. @@ -283,8 +238,7 @@ - The next section of this chapter will cover the above bullet - items in greater depth. + The next section covers these items in greater depth. @@ -295,254 +249,141 @@ securing &os; - - Command Versus Protocol - - Throughout this document, we will use - bold text to refer to an - application, and a monospaced font to refer - to specific commands. Protocols will use a normal font. This - typographical distinction is useful for instances such as ssh, - since it is a protocol as well as command. - - - The sections that follow will cover the methods of securing - your &os; system that were mentioned in the last section of this - chapter. + This section describes methods for securing a &os; system + against the attacks that were mentioned in the previous section. - Securing the <username>root</username> Account and - Staff Accounts + Securing the <username>root</username> Account su - First off, do not bother securing staff accounts if you - have not secured the root account. Most + Most systems have a password assigned to the - root account. The first thing you do is - assume that the password is always - compromised. This does not mean that you should remove the - password. The password is almost always necessary for console - access to the machine. What it does mean is that you should - not make it possible to use the password outside of the - console or possibly even with the &man.su.1; command. For - example, make sure that your ptys are specified as being - insecure in the /etc/ttys file so that - direct root logins via - telnet or rlogin are - disallowed. If using other login services such as - sshd, make sure that direct - root logins are disabled there as well. - You can do this by editing your - /etc/ssh/sshd_config file, and making - sure that PermitRootLogin is set to - no. Consider every access method — - services such as FTP often fall through the cracks. Direct - root logins should only be allowed via - the system console. + root account. Assume that this password + is always at risk of being compromised. + This does not mean that the password should be disabled as the + password is almost always necessary for console access to the + machine. However, it should not be possible to use this + password outside of the console or possibly even with + &man.su.1;. For example, setting the entries in + /etc/ttys to insecure + prevents root logins to the specified + terminals. In &os;, root logins using + &man.ssh.1; are disabled by default as + PermitRootLogin is set to + no in + /etc/ssh/sshd_config. Consider every + access method as services such as FTP often fall through the + cracks. Direct root logins should only + be allowed via the system console. wheel - Of course, as a sysadmin you have to be able to get to - root, so we open up a few holes. But we - make sure these holes require additional password verification - to operate. One way to make root - accessible is to add appropriate staff accounts to the - wheel group (in - /etc/group). The staff members placed in - the wheel group are allowed to - su to root. You - should never give staff members native - wheel access by putting them in the - wheel group in their password entry. - Staff accounts should be placed in a - staff group, and then added to the - wheel group via the - /etc/group file. Only those staff - members who actually need to have root - access should be placed in the wheel - group. It is also possible, when using an authentication - method such as Kerberos, to use Kerberos' - .k5login file in the - root account to allow a &man.ksu.1; to - root without having to place anyone at - all in the wheel group. This may be - the better solution since the wheel - mechanism still allows an intruder to break - root if the intruder has gotten hold of - your password file and can break into a staff account. While - having the wheel mechanism is better - than having nothing at all, it is not necessarily the safest - option. + Since a sysadmin needs access to + root, additional password verification + should be configured. One method is to add appropriate user + accounts to wheel in + /etc/group. Members of + wheel are allowed to + &man.su.1; to root. Only + those users who actually need to have + root access should be placed in + wheel. When using Kerberos for + authentication, create a .k5login in + the home directory of root to allow + &man.ksu.1; to be used without having to place anyone in + wheel. - To lock an account completely, the &man.pw.8; command - should be used: + To lock an account completely, use &man.pw.8;: &prompt.root; pw lock staff - This will prevent the user from logging in using any - mechanism, including &man.ssh.1;. + This will prevent the specified user from logging in using + any mechanism, including &man.ssh.1;. Another method of blocking access to accounts would be to replace the encrypted password with a single * character. This character - would never match the encrypted password and thus block user - access. For example, the following staff account: + would never match the encrypted password and thus blocks user + access. For example, the entry for the following + account: foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - Should be changed to this: + could be changed to this using &man.vipw.8;: foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - This will prevent the foobar user - from logging in using conventional methods. This method for - access restriction is flawed on sites using + This prevents foobar from logging in + using conventional methods. This method for access + restriction is flawed on sites using Kerberos or in situations where the user has set up keys with &man.ssh.1;. - These security mechanisms also assume that you are logging + These security mechanisms assume that users are logging in from a more restrictive server to a less restrictive - server. For example, if your main box is running all sorts of - servers, your workstation should not be running any. In order - for your workstation to be reasonably secure you should run as - few servers as possible, up to and including no servers at - all, and you should run a password-protected screen blanker. - Of course, given physical access to a workstation an attacker - can break any sort of security you put on it. This is - definitely a problem that you should consider, but you should - also consider the fact that the vast majority of break-ins - occur remotely, over a network, from people who do not have - physical access to your workstation or servers. - - Using something like Kerberos also gives you the ability - to disable or change the password for a staff account in one - place, and have it immediately affect all the machines on - which the staff member may have an account. If a staff - member's account gets compromised, the ability to instantly - change his password on all machines should not be underrated. - With discrete passwords, changing a password on N machines can - be a mess. You can also impose re-passwording restrictions - with Kerberos: not only can a Kerberos ticket be made to - timeout after a while, but the Kerberos system can require - that the user choose a new password after a certain period of - time (say, once a month). + server. For example, if the server is running network + services, the workstation should not be running any. In + order for a workstation to be reasonably secure, run zero or + as few services as possible and run a password-protected + screensaver. Of course, given physical access to any system, + an attacker can break any sort of security. Fortunately, + many break-ins occur remotely, over a network, + from people who do not have physical access to the + system. + + Using Kerberos provides the ability to disable or change + the password for a user in one place, and have it immediately + affect all the machines on which the user has an account. If + an account is compromised, the ability to instantly change the + associated password on all machines should not be underrated. + Additional restrictions can be imposed with Kerberos: a + Kerberos ticket can be configured to timeout and the Kerberos + system can require that the user choose a new password after a + configurable period of time. Securing Root-run Servers and SUID/SGID Binaries - ntalk - - - comsat - - - finger - - sandboxes sshd - - telnetd - - - rshd - - - rlogind - - The prudent sysadmin only runs the servers he needs to, no - more, no less. Be aware that third party servers are often - the most bug-prone. For example, running an old version of - imapd or - popper is like giving a universal - root ticket out to the entire world. - Never run a server that you have not checked out carefully. - Many servers do not need to be run as - root. For example, the - ntalk, - comsat, and - finger daemons can be run in - special user sandboxes. A sandbox is - not perfect, unless you go through a large amount of trouble, - but the onion approach to security still stands: If someone is - able to break in through a server running in a sandbox, they - still have to break out of the sandbox. The more layers the - attacker must break through, the lower the likelihood of his - success. Root holes have historically been found in virtually - every server ever run as root, including - basic system servers. If you are running a machine through - which people only login via sshd - and never login via telnetd or - rshd or - rlogind, then turn off those - services! - - &os; now defaults to running - ntalkd, - comsat, and - finger in a sandbox. Another - program which may be a candidate for running in a sandbox is - &man.named.8;. /etc/defaults/rc.conf - includes the arguments necessary to run - named in a sandbox in a - commented-out form. Depending on whether you are installing a - new system or upgrading an existing system, the special user - accounts used by these sandboxes may not be installed. The - prudent sysadmin would research and implement sandboxes for - servers whenever possible. + The prudent sysadmin only enables required services + and is aware that third party servers are often the most + bug-prone. Never run a server that has not been checked + out carefully. Think twice before running any service as + root as many daemons can be run as a + separate service account or can be started in a + sandbox. Do not activate insecure + services such as telnetd or + rlogind. - - sendmail - - - There are a number of other servers that typically do not - run in sandboxes: sendmail, - popper, - imapd, - ftpd, and others. There are - alternatives to some of these, but installing them may require - more work than you are willing to perform (the convenience - factor strikes again). You may have to run these servers as - root and rely on other mechanisms to - detect break-ins that might occur through them. - - The other big potential root holes in - a system are the suid-root and sgid binaries installed on the - system. Most of these binaries, such as + Another potential security hole is SUID-root and SGID + binaries. Most of these binaries, such as rlogin, reside in /bin, /sbin, /usr/bin, or /usr/sbin. While nothing is - 100% safe, the system-default suid and sgid binaries can be - considered reasonably safe. Still, root - holes are occasionally found in these binaries. A - root hole was found in - Xlib in 1998 that made - xterm (which is typically suid) - vulnerable. It is better to be safe than sorry and the - prudent sysadmin will restrict suid binaries, that only staff - should run, to a special group that only staff can access, and - get rid of (chmod 000) any suid binaries - that nobody uses. A server with no display generally does not - need an xterm binary. Sgid - binaries can be almost as dangerous. If an intruder can break - an sgid-kmem binary, the intruder might be able to read + 100% safe, the system-default SUID and SGID binaries can be + considered reasonably safe. It is recommended to restrict + SUID binaries to a special group that only staff can access, + and to delete any unused SUID binaries. SGID binaries can be + almost as dangerous. If an intruder can break an SGID-kmem + binary, the intruder might be able to read /dev/kmem and thus read the encrypted - password file, potentially compromising any passworded - account. Alternatively an intruder who breaks group + password file, potentially compromising user accounts. + Alternatively, an intruder who breaks group kmem can monitor keystrokes sent through ptys, including ptys used by users who login through secure methods. An intruder that breaks the @@ -558,226 +399,203 @@ Securing User Accounts User accounts are usually the most difficult to secure. - While you can impose draconian access restrictions on your - staff and star out their passwords, you may not - be able to do so with any general user accounts you might - have. If you do have sufficient control, then you may win out - and be able to secure the user accounts properly. If not, you - simply have to be more vigilant in your monitoring of those - accounts. Use of ssh and Kerberos for user accounts is more - problematic, due to the extra administration and technical - support required, but still a very good solution compared to a - encrypted password file. + Be vigilant in the monitoring of user accounts. Use of + &man.ssh.1; and Kerberos for user accounts + requires extra administration and technical support, but + provides a good solution compared to an encrypted password + file. Securing the Password File The only sure fire way is to star out as many passwords as - you can and use ssh or Kerberos for access to those accounts. - Even though the encrypted password file - (/etc/spwd.db) can only be read by - root, it may be possible for an intruder - to obtain read access to that file even if the attacker cannot - obtain root-write access. + possible and use &man.ssh.1; or Kerberos + for access to those accounts. Even though the encrypted + password file (/etc/spwd.db) can only be + read by root, it may be possible for an + intruder to obtain read access to that file even if the + attacker cannot obtain root-write access. - Your security scripts should always check for and report - changes to the password file (see the Security scripts should be used to check for and report + changes to the password file as described in the Checking file integrity - section below). + section. Securing the Kernel Core, Raw Devices, and - File Systems + Filesystems - If an attacker breaks root he can do - just about anything, but there are certain conveniences. For - example, most modern kernels have a packet sniffing device - driver built in. Under &os; it is called the - bpf device. An intruder will - commonly attempt to run a packet sniffer on a compromised - machine. You do not need to give the intruder the capability - and most systems do not have the need for the - bpf device compiled in. + Most modern kernels have a packet sniffing device driver + built in. Under &os; it is called + bpf. This device is needed for DHCP, + but can be removed in the custom kernel configuration file of + systems that do not provide or use DHCP. sysctl - But even if you turn off the bpf - device, you still have /dev/mem and - /dev/kmem to worry about. For that - matter, the intruder can still write to raw disk devices. - Also, there is another kernel feature called the module - loader, &man.kldload.8;. An enterprising intruder can use a - KLD module to install his own bpf - device, or other sniffing device, on a running kernel. To - avoid these problems you have to run the kernel at a higher - secure level, at least securelevel 1. - - The secure level of the kernel can be set in a variety of - ways. The simplest way of raising the secure level of a - running kernel is through a sysctl on the - kern.securelevel kernel variable: + Even if bpf is disabled, + /dev/mem and + /dev/kmem are still problematic. An + intruder can still write to raw disk devices. An enterprising + intruder can use &man.kldload.8; to install his own + bpf, or another sniffing device, on a + running kernel. To avoid these problems, run the kernel at a + higher security level, at least security level 1. + + The security level of the kernel can be set in a variety + of ways. The simplest way of raising the security level of a + running kernel is to set + kern.securelevel: &prompt.root; sysctl kern.securelevel=1 - By default, the &os; kernel boots with a secure level of - -1. The secure level will remain at -1 unless it is altered, - either by the administrator or by &man.init.8; because of a - setting in the start up scripts. The secure level may be - raised during system startup by setting the - kern_securelevel_enable variable to - YES in the - /etc/rc.conf file, and the value of the - kern_securelevel variable to the desired - secure level. - - The default secure level of a &os; system right after the - startup scripts are done is -1. This is called - insecure mode because immutable file flags may - be turned off, all devices may be read from or written to, and - so on. + By default, the &os; kernel boots with a security level of + -1. This is called insecure mode because + immutable file flags may be turned off and all devices may be + read from or written to. The security level will remain at -1 + unless it is altered, either by the administrator or by + &man.init.8;, because of a setting in the startup scripts. + The security level may be raised during system startup by + setting + kern_securelevel_enable to + YES in /etc/rc.conf, + and the value of kern_securelevel to the + desired security level. - Once the secure level is set to 1 or a higher value, the + Once the security level is set to 1 or a higher value, the append-only and immutable files are honored, they cannot be - turned off, and access to raw devices will be denied. Higher + turned off, and access to raw devices is denied. Higher levels restrict even more operations. For a full description - of the effect of various secure levels, please read the - &man.security.7; manual page. + of the effect of various security levels, refer to + &man.security.7; and &man.init.8;. - Bumping the secure level to 1 or higher may cause a few - problems to X11 (access to /dev/io will - be blocked), or to the installation of &os; built from - source (the installworld part of - the process needs to temporarily reset the append-only and - immutable flags of some files), and in a few other cases. - Sometimes, as in the case of X11, it may be possible to work - around this by starting &man.xdm.1; pretty early in the boot - process, when the securelevel is still low enough. - Workarounds like this may not be possible for all secure + Bumping the security level to 1 or higher may cause a + few + problems to &xorg;, as access to + /dev/io will be blocked, or to the + installation of &os; built from source as + installworld needs to temporarily + reset the append-only and immutable flags of some files. + In the case of &xorg;, it may be + possible to work around this by starting &man.xdm.1; early + in the boot process, when the security level is still low + enough. Workarounds may not be possible for all secure levels or for all the potential restrictions they enforce. A bit of forward planning is a good idea. Understanding the - restrictions imposed by each secure level is important as + restrictions imposed by each security level is important as they severely diminish the ease of system use. It will also make choosing a default setting much simpler and prevent any surprises. - If the kernel's secure level is raised to 1 or a higher + If the kernel's security level is raised to 1 or a higher value, it may be useful to set the schg - flag on critical startup binaries, directories, and script - files (i.e., everything that gets run up to the point where - the securelevel is set). This might be overdoing it, and - upgrading the system is much more difficult when it operates - at a high secure level. A less strict compromise is to run - the system at a higher secure level but skip setting the - schg flag for every system file and - directory under the sun. Another possibility is to simply + flag on critical startup binaries, directories, script + files, and everything that gets run up to the point where + the security level is set. A less strict compromise is to run + the system at a higher security level but skip setting the + schg flag. Another possibility is to mount / and /usr read-only. It should be noted that being too draconian about what is permitted may - prevent the all-important detection of an intrusion. + prevent detection of an intrusion. - Checking File Integrity: Binaries, Configuration Files, - Etc. + Checking File Integrity - When it comes right down to it, you can only protect your - core system configuration and control files so much before the - convenience factor rears its ugly head. For example, using - chflags to set the schg - bit on most of the files in / and One can only protect the core system configuration and + control files so much before the convenience factor rears its + ugly head. For example, using &man.chflags.1; to + set the schg bit on most of the files in + / and /usr is probably counterproductive, because while it may protect the files, it - also closes a detection window. The last layer of your - security onion is perhaps the most important — - detection. The rest of your security is pretty much useless - (or, worse, presents you with a false sense of security) if - you cannot detect potential intrusions. Half the job of the - onion is to slow down the attacker, rather than stop him, in - order to be able to catch him in the act. + also closes an intrusion detection window. Security measures + are useless or, worse, present a false sense of security, if + potential intrusions cannot be detected. Half the job of + security is to slow down, not stop, an attacker, in order to + catch him in the act. The best way to detect an intrusion is to look for modified, missing, or unexpected files. The best way to look - for modified files is from another (often centralized) + for modified files is from another, often centralized, limited-access system. Writing your security scripts on the - extra-secure limited-access system makes them mostly invisible - to potential attackers, and this is important. In order to - take maximum advantage you generally have to give the - limited-access box significant access to the other machines in - the business, usually either by doing a read-only NFS export - of the other machines to the limited-access box, or by setting - up ssh key-pairs to allow the limited-access box to ssh to the - other machines. Except for its network traffic, NFS is the - least visible method — allowing you to monitor the file - systems on each client box virtually undetected. If your - limited-access server is connected to the client boxes through - a switch, the NFS method is often the better choice. If your - limited-access server is connected to the client boxes through - a hub, or through several layers of routing, the NFS method - may be too insecure (network-wise) and using ssh may be the - better choice even with the audit-trail tracks that ssh - lays. - - Once you have given a limited-access box at least read - access to the client systems it is supposed to monitor, you - must write scripts to do the actual monitoring. Given an NFS - mount, you can write scripts out of simple system utilities - such as &man.find.1; and &man.md5.1;. It is best to - physically md5 the client-box files at least once a day, and + extra-security limited-access system makes them mostly + invisible + to potential attackers. In order to take maximum advantage, + the limited-access box needs significant access to the other + machines, usually either through a read-only + NFS export or by setting up + &man.ssh.1; key-pairs. Except for its + network traffic, NFS is the least visible + method, allowing the administrator to monitor the filesystems + on each client box virtually undetected. If a limited-access + server is connected to the client boxes through + a switch, the NFS method is often the + better choice. If a limited-access server is connected to the + client boxes through several layers of routing, the + NFS method may be too insecure and + &man.ssh.1; may be the better + choice. + + Once a limited-access box has been given at least read + access to the client systems it is supposed to monitor, create + the monitoring scripts. Given an NFS + mount, write scripts out of simple system utilities such as + &man.find.1; and &man.md5.1;. It is best to physically + &man.md5.1; the client system's files at least once a day, and to test control files such as those found in /etc and /usr/local/etc even more often. When mismatches are found, relative to the base md5 information the limited-access machine knows is valid, it - should scream at a sysadmin to go check it out. A good - security script will also check for inappropriate suid - binaries and for new or deleted files on system partitions - such as / and / and /usr. - When using ssh rather than NFS, writing the security - script is much more difficult. You essentially have to - scp the scripts to the client box in order - to run them, making them visible, and for safety you also need - to scp the binaries (such as find) that - those scripts use. The ssh client - on the client box may already be compromised. All in all, - using ssh may be necessary when running over insecure links, - but it is also a lot harder to deal with. - - A good security script will also check for changes to user - and staff members access configuration files: - .rhosts, .shosts, - .ssh/authorized_keys and so forth, files - that might fall outside the purview of the + When using &man.ssh.1; rather than + NFS, writing the security script is more + difficult. For example, &man.scp.1; is needed to + send the scripts to the client box in order to run them. The + &man.ssh.1; client + on the client box may already be compromised. Using + &man.ssh.1; may be necessary when running + over insecure links, but it is harder to deal with. + + A good security script will also check for changes to + hidden configuration files, such as + .rhosts and + .ssh/authorized_keys, as these files + might fall outside the purview of the MD5 check. - If you have a huge amount of user disk space, it may take - too long to run through every file on those partitions. In - this case, setting mount flags to disallow suid binaries is a - good idea. The nosuid option (see - &man.mount.8;) is what you want to look into. You should - probably scan them anyway, at least once a week, since the - object of this layer is to detect a break-in attempt, whether - or not the attempt succeeds. + For a large amount of user disk space, it may take too + long to run through every file on those partitions. In this + case, consider setting mount flags to disallow SUID binaries + by using nosuid with &man.mount.8;. Scan + these partitions at least once a week, since the objective is + to detect a break-in attempt, whether or not the attempt + succeeds. Process accounting (see &man.accton.8;) is a relatively - low-overhead feature of the operating system which might help - as a post-break-in evaluation mechanism. It is especially - useful in tracking down how an intruder has actually broken - into a system, assuming the file is still intact after the - break-in has occurred. + low-overhead feature of &os; which might help as a + post-break-in evaluation mechanism. It is especially useful + in tracking down how an intruder broke into a system, assuming + the file is still intact after the break-in has + occurred. *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***