svn commit: r41513 - projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security
Dru Lavigne
dru at FreeBSD.org
Mon Apr 29 12:44:23 UTC 2013
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 ***
More information about the svn-doc-projects
mailing list