Date: Mon, 29 Apr 2013 12:44:23 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> 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 Message-ID: <201304291244.r3TCiN1H004916@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 @@ <sect1 id="security-synopsis"> <title>Synopsis</title> - <para>This chapter will provide a basic introduction to system + <para>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 <quote>friendly</quote> 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.</para> - - <para>&os; provides an array of utilities and mechanisms to ensure - the integrity and security of your system and network.</para> + 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.</para> + + <para>&os; provides an array of utilities and mechanisms to + protect the integrity and security of the system and + network.</para> <para>After reading this chapter, you will know:</para> <itemizedlist> <listitem> - <para>Basic system security concepts, in respect to - &os;.</para> + <para>Basic &os; system security concepts.</para> </listitem> <listitem> - <para>About the various crypt mechanisms available in &os;, - such as <acronym>DES</acronym> and - <acronym>MD5</acronym>.</para> + <para>The various crypt mechanisms available in &os;.</para> </listitem> <listitem> @@ -61,41 +57,37 @@ </listitem> <listitem> - <para>How to set up <application>Kerberos5</application> on + <para>How to set up <application>Kerberos</application> on &os;.</para> </listitem> <listitem> <para>How to configure IPsec and create a - <acronym>VPN</acronym> between &os;/&windows; - machines.</para> + <acronym>VPN</acronym>.</para> </listitem> <listitem> <para>How to configure and use - <application>OpenSSH</application>, &os;'s - <acronym>SSH</acronym> implementation.</para> + <application>OpenSSH</application> on &os;.</para> </listitem> <listitem> - <para>What file system <acronym>ACL</acronym>s are and how to - use them.</para> + <para>How to use filesystem <acronym>ACL</acronym>s.</para> </listitem> <listitem> - <para>How to use the <application>Portaudit</application> - utility to audit third party software packages installed - from the Ports Collection.</para> + <para>How to use <application>portaudit</application> to + audit third party software packages installed from the + Ports Collection.</para> </listitem> <listitem> - <para>How to utilize the &os; security advisories - publications.</para> + <para>How to utilize &os; security advisories.</para> </listitem> <listitem> - <para>Have an idea of what Process Accounting is and how to - enable it on &os;.</para> + <para>What Process Accounting is and how to enable it on + &os;.</para> </listitem> </itemizedlist> @@ -107,36 +99,26 @@ </listitem> </itemizedlist> - <para>Additional security topics are covered throughout this book. - For example, Mandatory Access Control is discussed in <xref - linkend="mac"/> and Internet Firewalls are discussed in <xref - linkend="firewalls"/>.</para> + <para>Additional security topics are covered elsewhere in this + Handbook. For example, Mandatory Access Control is discussed in + <xref linkend="mac"/> and Internet firewalls are discussed in + <xref linkend="firewalls"/>.</para> </sect1> <sect1 id="security-intro"> <title>Introduction</title> <para>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 - <quote>honest</quote> 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.</para> + 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.</para> <para>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 - <username>root</username> account (<quote>break root</quote>). - Security concerns can be split up into several - categories:</para> + <username>root</username> account. Security concerns can be + split up into several categories:</para> <orderedlist> <listitem> @@ -148,7 +130,7 @@ </listitem> <listitem> - <para>Root compromise through accessible servers.</para> + <para>Root compromise through accessible services.</para> </listitem> <listitem> @@ -171,50 +153,36 @@ </indexterm> <indexterm><primary>Denial of Service (DoS)</primary></indexterm> - <para>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 + <para>A Denial of Service <acronym>DoS</acronym> attack is an + action that deprives the machine of needed resources. + Typically, <acronym>DoS</acronym> 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.</para> + with. This type of attack may not be able to take the machine + down, but it can saturate the Internet connection.</para> <indexterm> <primary>security</primary> <secondary>account compromises</secondary> </indexterm> - <para>A user account compromise is even more common than a DoS - attack. Many sysadmins still run standard - <application>telnetd</application>, - <application>rlogind</application>, - <application>rshd</application>, and - <application>ftpd</application> 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.</para> - - <para>One must always assume that once an attacker has access to a - user account, the attacker can break <username>root</username>. - 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 <username>root</username>. The distinction - is important because without access to <username>root</username> - 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 + <para>A user account compromise is more common than a + <acronym>DoS</acronym> 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.</para> + + <para>In a well secured and maintained system, access to a user + account does not necessarily give the attacker access to + <username>root</username>. Without <username>root</username> + 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.</para> @@ -223,27 +191,14 @@ <secondary>backdoors</secondary> </indexterm> - <para>System administrators must keep in mind that there are - potentially many ways to break <username>root</username> on a - machine. The attacker may know the <username>root</username> - password, the attacker may find a bug in a root-run server and - be able to break <username>root</username> 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 - <username>root</username> once he has broken into a user's - account. If an attacker has found a way to break - <username>root</username> on a machine, the attacker may not - have a need to install a backdoor. Many of the - <username>root</username> 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 - <username>root</username> 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.</para> + <para>There are potentially many ways to break + <username>root</username>: the attacker may know the + <username>root</username> password, the attacker may exploit a + bug in a service which runs as <username>root</username>, 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.</para> <para>Security remedies should always be implemented with a multi-layered <quote>onion peel</quote> approach and can be @@ -251,26 +206,26 @@ <orderedlist> <listitem> - <para>Securing <username>root</username> and staff + <para>Secure <username>root</username> and staff accounts.</para> </listitem> <listitem> - <para>Securing <username>root</username>–run servers - and suid/sgid binaries.</para> + <para>Secure <username>root</username>–run servers + and SUID/SGID binaries.</para> </listitem> <listitem> - <para>Securing user accounts.</para> + <para>Secure user accounts.</para> </listitem> <listitem> - <para>Securing the password file.</para> + <para>Secure the password file.</para> </listitem> <listitem> - <para>Securing the kernel core, raw devices, and - file systems.</para> + <para>Secure the kernel core, raw devices, and + filesystems.</para> </listitem> <listitem> @@ -283,8 +238,7 @@ </listitem> </orderedlist> - <para>The next section of this chapter will cover the above bullet - items in greater depth.</para> + <para>The next section covers these items in greater depth.</para> </sect1> <sect1 id="securing-freebsd"> @@ -295,254 +249,141 @@ <secondary>securing &os;</secondary> </indexterm> - <note> - <title>Command Versus Protocol</title> - - <para>Throughout this document, we will use - <application>bold</application> text to refer to an - application, and a <command>monospaced</command> 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.</para> - </note> - - <para>The sections that follow will cover the methods of securing - your &os; system that were mentioned in the <link - linkend="security-intro">last section</link> of this - chapter.</para> + <para>This section describes methods for securing a &os; system + against the attacks that were mentioned in the <link + linkend="security-intro">previous section</link>.</para> <sect2 id="securing-root-and-staff"> - <title>Securing the <username>root</username> Account and - Staff Accounts</title> + <title>Securing the <username>root</username> Account</title> <indexterm> <primary><command>su</command></primary> </indexterm> - <para>First off, do not bother securing staff accounts if you - have not secured the <username>root</username> account. Most + <para>Most systems have a password assigned to the - <username>root</username> account. The first thing you do is - assume that the password is <emphasis>always</emphasis> - 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 <filename>/etc/ttys</filename> file so that - direct <username>root</username> logins via - <command>telnet</command> or <command>rlogin</command> are - disallowed. If using other login services such as - <application>sshd</application>, make sure that direct - <username>root</username> logins are disabled there as well. - You can do this by editing your - <filename>/etc/ssh/sshd_config</filename> file, and making - sure that <literal>PermitRootLogin</literal> is set to - <literal>no</literal>. Consider every access method — - services such as FTP often fall through the cracks. Direct - <username>root</username> logins should only be allowed via - the system console.</para> + <username>root</username> account. Assume that this password + is <emphasis>always</emphasis> 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 + <filename>/etc/ttys</filename> to <literal>insecure</literal> + prevents <username>root</username> logins to the specified + terminals. In &os;, <username>root</username> logins using + &man.ssh.1; are disabled by default as + <literal>PermitRootLogin</literal> is set to + <literal>no</literal> in + <filename>/etc/ssh/sshd_config</filename>. Consider every + access method as services such as FTP often fall through the + cracks. Direct <username>root</username> logins should only + be allowed via the system console.</para> <indexterm> <primary><groupname>wheel</groupname></primary> </indexterm> - <para>Of course, as a sysadmin you have to be able to get to - <username>root</username>, so we open up a few holes. But we - make sure these holes require additional password verification - to operate. One way to make <username>root</username> - accessible is to add appropriate staff accounts to the - <groupname>wheel</groupname> group (in - <filename>/etc/group</filename>). The staff members placed in - the <groupname>wheel</groupname> group are allowed to - <command>su</command> to <username>root</username>. You - should never give staff members native - <groupname>wheel</groupname> access by putting them in the - <groupname>wheel</groupname> group in their password entry. - Staff accounts should be placed in a - <groupname>staff</groupname> group, and then added to the - <groupname>wheel</groupname> group via the - <filename>/etc/group</filename> file. Only those staff - members who actually need to have <username>root</username> - access should be placed in the <groupname>wheel</groupname> - group. It is also possible, when using an authentication - method such as Kerberos, to use Kerberos' - <filename>.k5login</filename> file in the - <username>root</username> account to allow a &man.ksu.1; to - <username>root</username> without having to place anyone at - all in the <groupname>wheel</groupname> group. This may be - the better solution since the <groupname>wheel</groupname> - mechanism still allows an intruder to break - <username>root</username> if the intruder has gotten hold of - your password file and can break into a staff account. While - having the <groupname>wheel</groupname> mechanism is better - than having nothing at all, it is not necessarily the safest - option.</para> + <para>Since a sysadmin needs access to + <username>root</username>, additional password verification + should be configured. One method is to add appropriate user + accounts to <groupname>wheel</groupname> in + <filename>/etc/group</filename>. Members of + <groupname>wheel</groupname> are allowed to + &man.su.1; to <username>root</username>. Only + those users who actually need to have + <username>root</username> access should be placed in + <groupname>wheel</groupname>. When using Kerberos for + authentication, create a <filename>.k5login</filename> in + the home directory of <username>root</username> to allow + &man.ksu.1; to be used without having to place anyone in + <groupname>wheel</groupname>.</para> - <para>To lock an account completely, the &man.pw.8; command - should be used:</para> + <para>To lock an account completely, use &man.pw.8;:</para> <screen>&prompt.root; <userinput>pw lock <replaceable>staff</replaceable></userinput></screen> - <para>This will prevent the user from logging in using any - mechanism, including &man.ssh.1;.</para> + <para>This will prevent the specified user from logging in using + any mechanism, including &man.ssh.1;.</para> <para>Another method of blocking access to accounts would be to replace the encrypted password with a single <quote><literal>*</literal></quote> character. This character - would never match the encrypted password and thus block user - access. For example, the following staff account:</para> + would never match the encrypted password and thus blocks user + access. For example, the entry for the following + account:</para> <programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting> - <para>Should be changed to this:</para> + <para>could be changed to this using &man.vipw.8;:</para> <programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting> - <para>This will prevent the <username>foobar</username> user - from logging in using conventional methods. This method for - access restriction is flawed on sites using + <para>This prevents <username>foobar</username> from logging in + using conventional methods. This method for access + restriction is flawed on sites using <application>Kerberos</application> or in situations where the user has set up keys with &man.ssh.1;.</para> - <para>These security mechanisms also assume that you are logging + <para>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.</para> - - <para>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).</para> + 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.</para> + + <para>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.</para> </sect2> <sect2> <title>Securing Root-run Servers and SUID/SGID Binaries</title> <indexterm> - <primary><command>ntalk</command></primary> - </indexterm> - <indexterm> - <primary><command>comsat</command></primary> - </indexterm> - <indexterm> - <primary><command>finger</command></primary> - </indexterm> - <indexterm> <primary>sandboxes</primary> </indexterm> <indexterm> <primary><application>sshd</application></primary> </indexterm> - <indexterm> - <primary><application>telnetd</application></primary> - </indexterm> - <indexterm> - <primary><application>rshd</application></primary> - </indexterm> - <indexterm> - <primary><application>rlogind</application></primary> - </indexterm> - <para>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 - <application>imapd</application> or - <application>popper</application> is like giving a universal - <username>root</username> 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 - <username>root</username>. For example, the - <application>ntalk</application>, - <application>comsat</application>, and - <application>finger</application> daemons can be run in - special user <firstterm>sandboxes</firstterm>. 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 <username>root</username>, including - basic system servers. If you are running a machine through - which people only login via <application>sshd</application> - and never login via <application>telnetd</application> or - <application>rshd</application> or - <application>rlogind</application>, then turn off those - services!</para> - - <para>&os; now defaults to running - <application>ntalkd</application>, - <application>comsat</application>, and - <application>finger</application> in a sandbox. Another - program which may be a candidate for running in a sandbox is - &man.named.8;. <filename>/etc/defaults/rc.conf</filename> - includes the arguments necessary to run - <application>named</application> 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.</para> + <para>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 + <username>root</username> as many daemons can be run as a + separate service account or can be started in a + <firstterm>sandbox</firstterm>. Do not activate insecure + services such as <application>telnetd</application> or + <application>rlogind</application>.</para> - <indexterm> - <primary><application>sendmail</application></primary> - </indexterm> - - <para>There are a number of other servers that typically do not - run in sandboxes: <application>sendmail</application>, - <application>popper</application>, - <application>imapd</application>, - <application>ftpd</application>, 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 - <username>root</username> and rely on other mechanisms to - detect break-ins that might occur through them.</para> - - <para>The other big potential <username>root</username> holes in - a system are the suid-root and sgid binaries installed on the - system. Most of these binaries, such as + <para>Another potential security hole is SUID-root and SGID + binaries. Most of these binaries, such as <application>rlogin</application>, reside in <filename class="directory">/bin</filename>, <filename class="directory">/sbin</filename>, <filename class="directory">/usr/bin</filename>, or <filename class="directory">/usr/sbin</filename>. While nothing is - 100% safe, the system-default suid and sgid binaries can be - considered reasonably safe. Still, <username>root</username> - holes are occasionally found in these binaries. A - <username>root</username> hole was found in - <literal>Xlib</literal> in 1998 that made - <application>xterm</application> (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 (<command>chmod 000</command>) any suid binaries - that nobody uses. A server with no display generally does not - need an <application>xterm</application> 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 <filename>/dev/kmem</filename> 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 <literal>kmem</literal> 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 @@ <title>Securing User Accounts</title> <para>User accounts are usually the most difficult to secure. - While you can impose draconian access restrictions on your - staff and <quote>star</quote> 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.</para> + 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.</para> </sect2> <sect2> <title>Securing the Password File</title> <para>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 - (<filename>/etc/spwd.db</filename>) can only be read by - <username>root</username>, it may be possible for an intruder - to obtain read access to that file even if the attacker cannot - obtain root-write access.</para> + possible and use &man.ssh.1; or Kerberos + for access to those accounts. Even though the encrypted + password file (<filename>/etc/spwd.db</filename>) can only be + read by <username>root</username>, it may be possible for an + intruder to obtain read access to that file even if the + attacker cannot obtain root-write access.</para> - <para>Your security scripts should always check for and report - changes to the password file (see the <link + <para>Security scripts should be used to check for and report + changes to the password file as described in the <link linkend="security-integrity">Checking file integrity</link> - section below).</para> + section.</para> </sect2> <sect2> <title>Securing the Kernel Core, Raw Devices, and - File Systems</title> + Filesystems</title> - <para>If an attacker breaks <username>root</username> 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 - <devicename>bpf</devicename> 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 - <devicename>bpf</devicename> device compiled in.</para> + <para>Most modern kernels have a packet sniffing device driver + built in. Under &os; it is called + <devicename>bpf</devicename>. 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.</para> <indexterm> <primary><command>sysctl</command></primary> </indexterm> - <para>But even if you turn off the <devicename>bpf</devicename> - device, you still have <filename>/dev/mem</filename> and - <filename>/dev/kmem</filename> 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 <devicename>bpf</devicename> - 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.</para> - - <para>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 <command>sysctl</command> on the - <varname>kern.securelevel</varname> kernel variable:</para> + <para>Even if <devicename>bpf</devicename> is disabled, + <filename>/dev/mem</filename> and + <filename>/dev/kmem</filename> are still problematic. An + intruder can still write to raw disk devices. An enterprising + intruder can use &man.kldload.8; to install his own + <devicename>bpf</devicename>, 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.</para> + + <para>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 + <varname>kern.securelevel</varname>:</para> <screen>&prompt.root; <userinput>sysctl kern.securelevel=<replaceable>1</replaceable></userinput></screen> - <para>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 - <varname>kern_securelevel_enable</varname> variable to - <literal>YES</literal> in the - <filename>/etc/rc.conf</filename> file, and the value of the - <varname>kern_securelevel</varname> variable to the desired - secure level.</para> - - <para>The default secure level of a &os; system right after the - startup scripts are done is -1. This is called - <quote>insecure mode</quote> because immutable file flags may - be turned off, all devices may be read from or written to, and - so on.</para> + <para>By default, the &os; kernel boots with a security level of + -1. This is called <quote>insecure mode</quote> 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 + <varname>kern_securelevel_enable</varname> to + <literal>YES</literal> in <filename>/etc/rc.conf</filename>, + and the value of <varname>kern_securelevel</varname> to the + desired security level.</para> - <para>Once the secure level is set to 1 or a higher value, the + <para>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.</para> + of the effect of various security levels, refer to + &man.security.7; and &man.init.8;.</para> <note> - <para>Bumping the secure level to 1 or higher may cause a few - problems to X11 (access to <filename>/dev/io</filename> will - be blocked), or to the installation of &os; built from - source (the <maketarget>installworld</maketarget> 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 + <para>Bumping the security level to 1 or higher may cause a + few + problems to <application>&xorg;</application>, as access to + <filename>/dev/io</filename> will be blocked, or to the + installation of &os; built from source as + <maketarget>installworld</maketarget> needs to temporarily + reset the append-only and immutable flags of some files. + In the case of <application>&xorg;</application>, 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.</para> </note> - <para>If the kernel's secure level is raised to 1 or a higher + <para>If the kernel's security level is raised to 1 or a higher value, it may be useful to set the <literal>schg</literal> - 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 - <literal>schg</literal> 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 + <literal>schg</literal> flag. Another possibility is to mount <filename class="directory">/</filename> and <filename class="directory">/usr</filename> read-only. It should be noted that being too draconian about what is permitted may - prevent the all-important detection of an intrusion.</para> + prevent detection of an intrusion.</para> </sect2> <sect2 id="security-integrity"> - <title>Checking File Integrity: Binaries, Configuration Files, - Etc.</title> + <title>Checking File Integrity</title> - <para>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 - <command>chflags</command> to set the <literal>schg</literal> - bit on most of the files in <filename - class="directory">/</filename> and <filename + <para>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 <literal>schg</literal> bit on most of the files in + <filename class="directory">/</filename> and <filename class="directory">/usr</filename> 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.</para> + 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.</para> <para>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.</para> - - <para>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 + <acronym>NFS</acronym> export or by setting up + &man.ssh.1; key-pairs. Except for its + network traffic, <acronym>NFS</acronym> 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 <acronym>NFS</acronym> method is often the + better choice. If a limited-access server is connected to the + client boxes through several layers of routing, the + <acronym>NFS</acronym> method may be too insecure and + &man.ssh.1; may be the better + choice.</para> + + <para>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 <acronym>NFS</acronym> + 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 <filename class="directory">/etc</filename> and <filename class="directory">/usr/local/etc</filename> 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 <filename class="directory">/</filename> and <filename + should alert the sysadmin. A good security script will also + check for inappropriate SUID binaries and for new or deleted + files on system partitions such as <filename + class="directory">/</filename> and <filename class="directory">/usr</filename>.</para> - <para>When using ssh rather than NFS, writing the security - script is much more difficult. You essentially have to - <command>scp</command> the scripts to the client box in order - to run them, making them visible, and for safety you also need - to <command>scp</command> the binaries (such as find) that - those scripts use. The <application>ssh</application> 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.</para> - - <para>A good security script will also check for changes to user - and staff members access configuration files: - <filename>.rhosts</filename>, <filename>.shosts</filename>, - <filename>.ssh/authorized_keys</filename> and so forth, files - that might fall outside the purview of the + <para>When using &man.ssh.1; rather than + <acronym>NFS</acronym>, 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.</para> + + <para>A good security script will also check for changes to + hidden configuration files, such as + <filename>.rhosts</filename> and + <filename>.ssh/authorized_keys</filename>, as these files + might fall outside the purview of the <literal>MD5</literal> check.</para> - <para>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 <literal>nosuid</literal> 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.</para> + <para>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 <literal>nosuid</literal> 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.</para> <para>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.</para> + 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.</para> *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201304291244.r3TCiN1H004916>