svn commit: r43744 - head/en_US.ISO8859-1/books/handbook/security
Tom Rhodes
trhodes at FreeBSD.org
Tue Feb 4 00:31:28 UTC 2014
Author: trhodes
Date: Tue Feb 4 00:31:27 2014
New Revision: 43744
URL: http://svnweb.freebsd.org/changeset/doc/43744
Log:
Rewrite the front of the security section. This version
adds a small discussion on using sudo, shows and example
of using an IDS rather than just discussing what they are,
update of threats, discussion on rootkits and back doors,
adds more sysctls and more.
Modified:
head/en_US.ISO8859-1/books/handbook/security/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Tue Feb 4 00:16:12 2014 (r43743)
+++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Tue Feb 4 00:31:27 2014 (r43744)
@@ -7,8 +7,13 @@
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security">
<info><title>Security</title>
<authorgroup>
- <author><personname><firstname>Matthew</firstname><surname>Dillon</surname></personname><contrib>Much of this chapter has been taken from the
- security(7) manual page by </contrib></author>
+ <author>
+ <personname>
+ <firstname>Tom</firstname>
+ <surname>Rhodes</surname>
+ </personname>
+ <contrib>Rewritten by </contrib>
+ </author>
</authorgroup>
</info>
@@ -19,17 +24,17 @@
<sect1 xml:id="security-synopsis">
<title>Synopsis</title>
- <para>This chapter provides a basic introduction to system
- security concepts, some general good rules of thumb, and some
- 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>Security, whether physical or virtual, is a topic
+ so broad that an entire industry has grown up around it.
+ Hundreds of standard practices have been authored about
+ how to secure systems and networks, and as a user of &os;,
+ understanding how to protect against attacks and intruders
+ is a must.</para>
+
+ <para>In this chapter, several fundamentals and techniques will
+ be discussed. The &os; system comes with multiple layers of
+ security, and many more third party utilities may be added to
+ enhance security.</para>
<para>After reading this chapter, you will know:</para>
@@ -108,341 +113,357 @@
<sect1 xml:id="security-intro">
<title>Introduction</title>
- <para>Security is a function that begins and ends with the system
- 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
- <systemitem class="username">root</systemitem> account. Security concerns can be
- split up into several categories:</para>
-
- <orderedlist>
- <listitem>
- <para>Denial of service attacks.</para>
- </listitem>
-
- <listitem>
- <para>User account compromises.</para>
- </listitem>
-
- <listitem>
- <para>Root compromise through accessible services.</para>
- </listitem>
-
- <listitem>
- <para>Root compromise via user accounts.</para>
- </listitem>
-
- <listitem>
- <para>Backdoor creation.</para>
- </listitem>
- </orderedlist>
-
- <indexterm>
- <primary>DoS attacks</primary>
- <see>Denial of Service (DoS)</see>
- </indexterm>
- <indexterm>
- <primary>security</primary>
- <secondary>DoS attacks</secondary>
- <see>Denial of Service (DoS)</see>
- </indexterm>
- <indexterm><primary>Denial of Service (DoS)</primary></indexterm>
-
- <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. 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 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
- <systemitem class="username">root</systemitem>. Without <systemitem class="username">root</systemitem>
- 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>
-
- <indexterm>
- <primary>security</primary>
- <secondary>backdoors</secondary>
- </indexterm>
-
- <para>There are potentially many ways to break
- <systemitem class="username">root</systemitem>: the attacker may know the
- <systemitem class="username">root</systemitem> password, the attacker may exploit a
- bug in a service which runs as <systemitem class="username">root</systemitem>, 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
- categorized as follows:</para>
-
- <orderedlist>
- <listitem>
- <para>Secure <systemitem class="username">root</systemitem> and staff
- accounts.</para>
- </listitem>
-
- <listitem>
- <para>Secure <systemitem class="username">root</systemitem>–run servers
- and SUID/SGID binaries.</para>
- </listitem>
-
- <listitem>
- <para>Secure user accounts.</para>
- </listitem>
-
- <listitem>
- <para>Secure the password file.</para>
- </listitem>
-
- <listitem>
- <para>Secure the kernel core, raw devices, and
- filesystems.</para>
- </listitem>
-
- <listitem>
- <para>Quick detection of inappropriate changes made to the
- system.</para>
- </listitem>
-
- <listitem>
- <para>Paranoia.</para>
- </listitem>
- </orderedlist>
-
- <para>The next section covers these items in greater depth.</para>
- </sect1>
-
- <sect1 xml:id="securing-freebsd">
- <title>Securing &os;</title>
-
- <indexterm>
- <primary>security</primary>
- <secondary>securing &os;</secondary>
- </indexterm>
-
- <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>
+ <para>Security is everyone's responsibility. A weak entry point
+ in any system could allow intruders to gain access to critical
+ information and cause havoc on an entire network. In most
+ security training, they discuss the security triad
+ <acronym>CIA</acronym> which stands for the confidentiality,
+ integrity, and availability of information systems.</para>
+
+ <para>The <acronym>CIA</acronym> triad is a bedrock concept of
+ computer security, customers and end users expect privacy
+ of their data. They expect orders they place to not be changed
+ or their information altered behind the scenes. They also expect
+ access to information at all times. Together they make up the
+ confidentiality, integrity, and availability of the
+ system.</para>
- <sect2 xml:id="securing-root-and-staff">
- <title>Securing the <systemitem class="username">root</systemitem> Account</title>
+ <para>To protect <acronym>CIA</acronym>, security professionals
+ apply a defense in depth strategy. The idea of defense in
+ depth is to add several layers of security to prevent one single
+ layer failing and the entire security system collapsing. A
+ systems administrator cannot simply turn on a firewall and
+ consider the network or system secure, they must audit accounts,
+ check the integrity of binaries, and ensure malicious tools are
+ not installed. To do this, they must understand what the
+ threats are.</para>
+
+ <sect2 xml:id="security-threats">
+ <title>Threats</title>
+
+ <para>What is a threat as pertaining to computer security? For
+ years it was assumed that threats are remote attackers, people
+ whom will attempt to access the system without permission, from
+ a remote location. In today's world, this definition has been
+ expanded to include employees, malicious software, rogue
+ network devices, natural disasters, security vulnerabilities,
+ and even competing corporations.</para>
+
+ <para>Every day thousands of systems and networks are attacked and
+ several hundred are accessed without permission. Sometimes
+ by simple accident, others by remote attackers, and in some
+ cases, corporate espionage or former employees. As a system
+ user, it is important to prepare for and admit when a mistake
+ has lead to a security breach and report possible issues to
+ the security team. As an administrator, it is important to
+ know of the threats and be prepared to mitigate them.</para>
+ </sect2>
+
+ <sect2 xml:id="security-groundup">
+ <title>A Ground Up Approach</title>
+
+ <para>In security, it is sometimes best to take a ground up
+ approach, whereas the administrator begins with the basic
+ accounts, system configuration, and then begins to work with
+ third party utilities and work up to the network layer. It
+ is in these latter configuration aspects that system policy
+ and procedures should take place.</para>
+
+ <para>Many places of business already have a security policy that
+ covers the configuration technology devices in use. They
+ should contain, at minimal, the security configuration of end
+ user workstations and desktops, mobile devices such as phones
+ and laptops, and both production and development servers. In
+ many cases, when applying computer security, standard operating
+ procedures (<acronym>SOP</acronym>s) already exist. When in
+ doubt, ask the security team.</para>
+ </sect2>
+
+ <sect2 xml:id="security-accounts">
+ <title>System and User Accounts</title>
+
+ <para>In securing a system, the best starting point is auditing
+ accounts. Ensure that the root account has a strong password,
+ disable accounts that do not need shell access, for users who
+ need to augment their privileges, install the
+ <package>security/sudo</package> and only allow them access
+ to applications they need. The root user password should
+ never be shared.</para>
- <indexterm>
- <primary>&man.su.1;</primary>
- </indexterm>
-
- <para>Most
- systems have a password assigned to the
- <systemitem class="username">root</systemitem> 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 <systemitem class="username">root</systemitem> logins to the specified
- terminals. In &os;, <systemitem class="username">root</systemitem> 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 <systemitem class="username">root</systemitem> logins should only
- be allowed via the system console.</para>
-
- <indexterm>
- <primary><systemitem class="groupname">wheel</systemitem></primary>
- </indexterm>
-
- <para>Since a sysadmin needs access to
- <systemitem class="username">root</systemitem>, additional password verification
- should be configured. One method is to add appropriate user
- accounts to <systemitem class="groupname">wheel</systemitem> in
- <filename>/etc/group</filename>. Members of
- <systemitem class="groupname">wheel</systemitem> are allowed to &man.su.1; to
- <systemitem class="username">root</systemitem>. Only those users who actually need
- to have <systemitem class="username">root</systemitem> access should be placed in
- <systemitem class="groupname">wheel</systemitem>. When using Kerberos for
- authentication, create a <filename>.k5login</filename> in
- the home directory of <systemitem class="username">root</systemitem> to allow
- &man.ksu.1; to be used without having to place anyone in
- <systemitem class="groupname">wheel</systemitem>.</para>
-
- <para>To lock an account completely, use &man.pw.8;:</para>
-
- <screen>&prompt.root; <userinput>pw lock staff</userinput></screen>
-
- <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 blocks user
- access. For example, the entry for the following
+ <para>To deny access to accounts, two methods exist. The first
+ one is to lock an account, for example, to lock the toor
account:</para>
- <programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
+ <screen>&prompt.root; <userinput>pw lock toor</userinput></screen>
- <para>could be changed to this using &man.vipw.8;:</para>
+ <para>This command will change the account from this
+ <quote>toor:*:0:0::0:0:Bourne-again Superuser:/root:</quote>
+ to <quote>toor:*LOCKED**:0:0::0:0:Bourne-again
+ Superuser:/root:</quote></para>
+
+ <para>In some cases, this is not possible, perhaps because of
+ an additional service. In those cases, login access
+ could be prevented by changing the shell to /sbin/nologin
+ like in this example:</para>
- <programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
+ <screen>&prompt.root; <userinput>chsh -s /usr/sbin/nologin toor</userinput></screen>
- <para>This prevents <systemitem class="username">foobar</systemitem> 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 assume that users are logging
- in from a more restrictive server to a less restrictive
- 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>sandboxes</primary>
- </indexterm>
- <indexterm>
- <primary>&man.sshd.8;</primary>
- </indexterm>
-
- <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
- <systemitem class="username">root</systemitem> 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 &man.telnetd.8; or &man.rlogind.8;.</para>
-
- <para>Another potential security hole is SUID-root and SGID
- binaries. Most of these binaries, such as &man.rlogin.1;,
- reside in <filename>/bin</filename>,
- <filename>/sbin</filename>, <filename>/usr/bin</filename>, or <filename>/usr/sbin</filename>. While nothing is
- 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 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
- <systemitem class="groupname">tty</systemitem> group can write to almost any
- user's tty. If a user is running a terminal program or
- emulator with a keyboard-simulation feature, the intruder can
- potentially generate a data stream that causes the user's
- terminal to echo a command, which is then run as that
- user.</para>
- </sect2>
-
- <sect2 xml:id="secure-users">
- <title>Securing User Accounts</title>
-
- <para>User accounts are usually the most difficult to secure.
- 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>
+ <note>
+ <para>Only super users are able to change the shell for
+ other users. Attempting to perform this as a regular user
+ will fail.</para>
+ </note>
- <para>The only sure fire way is to star out as many passwords as
- 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
- <systemitem class="username">root</systemitem>, 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>The account structure will now look like this, with
+ the <quote>nologin</quote> shell as the last entry:</para>
- <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.</para>
- </sect2>
-
- <sect2>
- <title>Securing the Kernel Core, Raw Devices, and
- Filesystems</title>
+ <programlisting>toor:*:0:0::0:0:Bourne-again Superuser:/root:/usr/sbin/nologin</programlisting>
- <para>Most modern kernels have a packet sniffing device driver
- built in. Under &os; it is called
- <filename>bpf</filename>. 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>
+ <para>The <filename>/usr/sbin/nologin</filename> shell will block
+ the &man.login.1; command from assigning a shell to this
+ user.</para>
+ </sect2>
- <indexterm>
- <primary>&man.sysctl.8;</primary>
- </indexterm>
+ <sect2 xml:id="security-sudo">
+ <title>Permitted Account Escalation</title>
- <para>Even if <filename>bpf</filename> 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
- <filename>bpf</filename>, 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>In some cases, system administration access needs to
+ be shared with other users. &os; has two methods to
+ handle this. The first one, which is not recommended,
+ is a shared root password and adding users to the
+ <systemitem class="groupname">wheel</systemitem> group.
+ To achieve this, edit the <filename>/etc/group</filename>
+ and add the user to the end of the first group. This
+ user must be separated by a comma character.</para>
+
+ <para>The correct way to permit this privilege escalation is
+ using the <package>security/sudo</package> port which will
+ provide additional auditing, more fine grained user
+ control, and even lock users into running only single,
+ privileged commands such as &man.service.8;</para>
+
+ <para>After installation, edit the
+ <filename>/usr/local/etc/sudoers</filename> file by using
+ the <command>visudo</command> interface. In this example,
+ a new webadmin group will be added, the user
+ <systemitem class="username">trhodes</systemitem> to that
+ group, and then give the user
+ access to restart <package>apache24</package>, the following
+ procedure may be followed:</para>
+
+ <screen>&prompt.root; <userinput>pw groupadd webadmin -M trhodes -g 6000</userinput></screen>
+
+ <screen>&prompt.root; <userinput>visudo</userinput></screen>
+
+ <programlisting>%webadmin ALL=(ALL) /usr/sbin/service apache24 *</programlisting>
+
+ <para>The <package>security/sudo</package> provides an
+ invaluable resource when it comes to local user management.
+ It is also possible to not require passwords and just default
+ to the &man.ssh.1; key method. To disable password login
+ via &man.sshd.8; and only use local passwords for
+ <command>sudo</command>, see <xref linkend="openssh"/>.</para>
+ </sect2>
+
+ <sect2 xml:id="security-passwords">
+ <title>Passwords</title>
+
+ <para>Passwords are a necessary evil of technology. In the cases
+ they must be used, not only should the password be extremely
+ complex, but also use a powerful hash mechanism to protect it.
+ At the time of this writing, &os; supports
+ <acronym>DES</acronym>, <acronym>MD</acronym>5, Blowfish,
+ <acronym>SHA</acronym>256, and <acronym>SHA</acronym>512 in
+ the <function>crypt()</function> library. The default is
+ <acronym>SHA</acronym>512 and should not be changed backwards;
+ however, some users like to use the Blowfish option. Each
+ mechanism, aside from <acronym>DES</acronym>, has a unique
+ beginning to designate the hash mechanism assigned. For the
+ <acronym>MD</acronym>5 mechanism, the symbol is a
+ <quote>$</quote> sign. For the <acronym>SHA</acronym>256 or
+ <acronym>SHA</acronym>512, the symbol is <quote>$6$</quote>
+ and Blowfish uses <quote>$2a$</quote>. Any weaker passwords
+ should be re-hashed by asking the user to run &man.passwd.1;
+ during their next login.</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>
+ <note>
+ <para>At the time of this writing, Blowfish is not part of
+ <acronym>AES</acronym> nor is it considered compliant
+ with any <acronym>FIPS</acronym> (Federal Information
+ Processing Standards) standard and it's use may not be
+ permitted in some environments.</para>
+ </note>
- <screen>&prompt.root; <userinput>sysctl kern.securelevel=1</userinput></screen>
+ <para>For any system connected to the network, two factor
+ authentication should be used. This is normally considered
+ something you have and something you know. With
+ <application>OpenSSH</application> being part of the &os;
+ base system and the use of ssh-keys being available for some
+ time, all network logins should avoid the use of passwords in
+ exchange for this two factor authentication method. For
+ more information see the <xref linkend="openssh"/> section of
+ the handbook. Kerberose users may need to make additional
+ changes to implement <application>OpenSSH</application> in
+ their network.</para>
+ </sect2>
+
+ <sect2 xml:id="security-rkhunter">
+ <title>Backdoors and Rootkits</title>
+
+ <para>Backdoors and rootkits are only a threat after they have
+ been installed. Once installed, this malicious software will
+ normally open up another avenue of entry for an attacker.
+ Realistically, once a system has been compromised, and an
+ investigation has been performed, it should be erased. There
+ is tremendous risk that even the most prudent security or
+ systems engineer will miss something an attacker left
+ behind.</para>
+
+ <para>A backdoor or rootkit software does do one thing useful
+ for administrators - once detected, it is a sign that a
+ compromise happened at some point. But normally these types
+ types of applications are hidden very well. Tools do exist
+ to detect backdoors and rootkits, one of them is
+ <package>security/rkhunter</package>.</para>
+
+ <para>After installation the system may be checked using the
+ following command which will produce a lot of
+ information:</para>
+
+ <screen>&prompt.root; <userinput>rkhunter -c</userinput></screen>
+
+ <para>After the process complete, which will require some manual
+ pressing of the <keycap>ENTER</keycap> key, a status message
+ will be printed to the screen. This message will include the
+ amount of files checked, suspect files, possible rootkits,
+ and more. During the check, some generic security warnings may
+ be produced about hidden files, the
+ <application>OpenSSH</application> protocol selection, and
+ occasionally known vulnerable versions of installed software.
+ These can be handled now or later after a more detailed
+ analysis has been performed.</para>
+
+ <para>Every administrator should know what is running on the
+ systems they are responsible for. Using tools like
+ <application>rkhunter</application>,
+ <application>lsof</application> and native commands such
+ as &man.netstat.1; and &man.ps.1; can show a great deal of
+ information on the system. Take notes on what is normal,
+ ask questions when something seems out of place and be
+ paranoid. And remember, preventing a compromise is ideal
+ but detecting a compromise is a must.</para>
+ </sect2>
+
+ <sect2 xml:id="security-ids">
+ <title>Binary Verification</title>
+
+ <para>Verification of system files and binaries is important
+ because it provides the system administration and security
+ team with information about system changes. In any system,
+ no internal command or application should change without
+ the system admin team knowing. A software application that
+ monitors the system for changes is called an Intrusion
+ Detection System or <acronym>IDS</acronym>.</para>
+
+ <para>&os; provides native support for a basic
+ <acronym>IDS</acronym> system. In fact, as part of the nightly
+ &man.periodic.8; security emails will notify an administrator
+ of changes. Since the information is stored locally, there is
+ a change a malicious user could modify and <quote>spoof</quote>
+ the information. As such, it is recommended to create a
+ separate set of binary signatures and store them on a read
+ only, root owned directory or, preferably, off system such
+ as a <acronym>USB</acronym> disk or
+ <application>rsync</application> server.</para>
+
+ <para>To being, a seed needs to be generated. This is a numeric
+ constant that will be used as to help generate the hash values
+ and to check the hash values. Lacking this seed value will make
+ faking or checking the checksum values of files difficult it not
+ impossible. In the following example, the key will be passed
+ with the <option>-s</option> flag. First, generate a set of
+ hashes and checksums for <filename>/bin</filename> using the
+ following command:</para>
+
+ <screen>&prompt.root; <userinput>mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > bin_chksum_mtree</userinput></screen>
+
+ <para>This should have produced something similar to:</para>
+
+ <screen>&prompt.root; mtree: /bin checksum: 3427012225</screen>
+
+ <para>Viewing the <filename>bin_cksum_mtree</filename> file
+ should yield output similar to the following as well:</para>
+
+ <programlisting># user: root
+# machine: dreadnaught
+# tree: /bin
+# date: Mon Feb 3 10:19:53 2014
+
+# .
+/set type=file uid=0 gid=0 mode=0555 nlink=1 flags=none
+. type=dir mode=0755 nlink=2 size=1024 \
+ time=1380277977.000000000
+ \133 nlink=2 size=11704 time=1380277977.000000000 \
+ cksum=484492447 \
+ sha256digest=6207490fbdb5ed1904441fbfa941279055c3e24d3a4049aeb45094596400662a
+ cat size=12096 time=1380277975.000000000 cksum=3909216944 \
+ sha256digest=65ea347b9418760b247ab10244f47a7ca2a569c9836d77f074e7a306900c1e69
+ chflags size=8168 time=1380277975.000000000 cksum=3949425175 \
+ sha256digest=c99eb6fc1c92cac335c08be004a0a5b4c24a0c0ef3712017b12c89a978b2dac3
+ chio size=18520 time=1380277975.000000000 cksum=2208263309 \
+ sha256digest=ddf7c8cb92a58750a675328345560d8cc7fe14fb3ccd3690c34954cbe69fc964
+ chmod size=8640 time=1380277975.000000000 cksum=2214429708 \
+ sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7</programlisting>
+
+ <para>Notice the machine's hostname, the current date and time,
+ and the user who executed &man.mtree.8; are all included in
+ this report. There is also a checksum, size, time and
+ <acronym>SHA</acronym>256 digest for each binary that was
+ found.</para>
+
+ <para>To verify binary signatures, the following command will
+ read in the current list of signatures and provide an
+ output:</para>
+
+ <screen>&prompt.root; <userinput>mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output</userinput></screen>
+
+ <para>This should produce the same checksum for
+ <filename>/bin</filename> that was produced when the command
+ was originally ran. Since no changes occurred in the time these
+ commands were ran, the <filename>bin_chksum_output</filename>
+ output will be empty. To simulate a change, change the date
+ on the <filename>/bin/cat</filename> file using
+ &man.touch.1; and run the verification command again:</para>
+
+ <screen>&prompt.root; <userinput>touch /bin/cat</userinput></screen>
+ <screen>&prompt.root; <userinput>mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output</userinput></screen>
+ <screen>&prompt.root; <userinput>cat bin_chksum_output</userinput></screen>
+ <programlisting>cat changed
+ modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014</programlisting>
+
+ <para>More advanced <acronym>IDS</acronym> systems exist, such as
+ <package>security/aide</package> but in most cases,
+ &man.mtree.8; provides the functionality administrators need.
+ It is important to keep the seed value and the checksum output
+ hidden from malicious users.</para>
+ </sect2>
+
+ <sect2 xml:id="security-tuning">
+ <title>System Tuning for Security</title>
+
+ <para>Many of the systems features may be tuned through the use
+ of &man.sysctl.8;. This is also true for a few security
+ features which could be used to prevent denial of service
+ (<acronym>DOS</acronym>) style attacks. Some of the more
+ important will be covered here. Any time a setting is changed
+ with &man.sysctl.8;, the chance to cause undesired harm is
+ increased affecting the availability of the system. Considering
+ the <acronym>CIA</acronym> of the system should be done during
+ any system-wide configuration change.</para>
+
+ <para>The following is a list of &man.sysctl.8;'s and a short
+ description of what effects the changes will have on the
+ system.</para>
<para>By default, the &os; kernel boots with a security level of
-1. This is called <quote>insecure mode</quote> because
@@ -451,413 +472,58 @@
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
+ 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 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 is denied. Higher
- levels restrict even more operations. For a full description
- of the effect of various security levels, refer to
- &man.security.7; and &man.init.8;.</para>
-
- <note>
- <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
- <buildtarget>installworld</buildtarget> 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 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 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, 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>/</filename> and <filename>/usr</filename> read-only. It should be
- noted that being too draconian about what is permitted may
- prevent detection of an intrusion.</para>
- </sect2>
-
- <sect2 xml:id="security-integrity">
- <title>Checking File Integrity</title>
-
- <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>/</filename> and <filename>/usr</filename> is probably
- counterproductive, because while it may protect the files, it
- 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,
- limited-access system. Writing security scripts on the
- 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>/etc</filename> and <filename>/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 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>/</filename> and <filename>/usr</filename>.</para>
-
- <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>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 &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>
-
- <para>Finally, security scripts should process the log files,
- and the logs themselves should be generated in as secure a
- manner as possible and sent to a remote syslog server. An
- intruder will try to cover his tracks, and log files are
- critical to the sysadmin trying to track down the time and
- method of the initial break-in. One way to keep a permanent
- record of the log files is to run the system console to a
- serial port and collect the information to a secure machine
- monitoring the consoles.</para>
- </sect2>
-
- <sect2>
- <title>Paranoia</title>
-
- <para>A little paranoia never hurts. As a rule, a sysadmin can
- add any number of security features which do not affect
- convenience and can add security features that
- <emphasis>do</emphasis> affect convenience with some added
- thought. More importantly, a security administrator should
- mix it up a bit. If recommendations, such as those mentioned
- in this section, are applied verbatim, those methodologies are
- given to the prospective attacker who also has access to this
- document.</para>
- </sect2>
-
- <sect2>
- <title>Denial of Service Attacks</title>
-
- <indexterm>
- <primary>Denial of Service (DoS)</primary>
- </indexterm>
-
- <para>A <acronym>DoS</acronym> attack is typically a packet
- attack. While there is not much one can do about spoofed
- packet attacks that saturate a network, one can generally
- limit the damage by ensuring that the attack cannot take down
- servers by:</para>
-
- <orderedlist>
- <listitem>
- <para>Limiting server forks.</para>
- </listitem>
-
- <listitem>
- <para>Limiting springboard attacks such as ICMP response
- attacks and ping broadcasts.</para>
- </listitem>
-
- <listitem>
- <para>Overloading the kernel route cache.</para>
- </listitem>
- </orderedlist>
-
- <para>A common <acronym>DoS</acronym> attack scenario is to
- force a forking server to spawn so many child processes that
- the host system eventually runs out of memory and file
- descriptors, and then grinds to a halt. There are several
- options to &man.inetd.8; to limit this sort of attack. It
- should be noted that while it is possible to prevent a machine
- from going down, it is not generally possible to prevent a
- service from being disrupted by the attack. Read
- &man.inetd.8; carefully and pay specific attention to
- <option>-c</option>, <option>-C</option>, and
- <option>-R</option>. Spoofed IP attacks will circumvent
- <option>-C</option> to &man.inetd.8;, so typically a
- combination of options must be used. Some standalone servers
- have self-fork-limitation parameters.</para>
-
- <para><application>Sendmail</application> provides
- <option>-OMaxDaemonChildren</option>, which tends to work
- better than trying to use
- <application>Sendmail</application>'s load limiting options
- due to the load lag. Specify a
- <literal>MaxDaemonChildren</literal> when starting
- <application>Sendmail</application> which is high enough to
- handle the expected load, but not so high that the computer
- cannot handle that number of
- <application>Sendmail</application> instances. It is prudent
- to run <application>Sendmail</application> in queued mode
- using <option>-ODeliveryMode=queued</option> and to run the
- daemon (<command>sendmail -bd</command>) separate from the
- queue-runs (<command>sendmail -q15m</command>). For
- real-time delivery, run the queue at a much lower interval,
- such as <option>-q1m</option>, but be sure to specify a
- reasonable <literal>MaxDaemonChildren</literal> to prevent
- cascade failures.</para>
-
- <para>&man.syslogd.8; can be attacked directly and it is
- strongly recommended to use
- <option>-s</option> whenever possible, and
- <option>-a</option> otherwise.</para>
-
- <para>Be careful with connect-back services such as
- reverse-identd, which can be attacked directly. The
- reverse-ident feature of
- <application>TCP Wrappers</application> is not recommended for
- this reason.</para>
-
- <para>It is recommended to protect internal services from
- external access by firewalling them at the border routers.
- This is to prevent saturation attacks from outside the LAN,
- not so much to protect internal services from network-based
- <systemitem class="username">root</systemitem> compromise. Always configure an
- exclusive firewall which denies everything by default except
- for traffic which is explicitly allowed. The range of port
- numbers used for dynamic binding in &os; is controlled by
- several <varname>net.inet.ip.portrange</varname>
- &man.sysctl.8; variables.</para>
-
- <para>Another common <acronym>DoS</acronym> attack, called a
- springboard attack, causes the server to generate responses
- which overloads the server, the local network, or some other
- machine. The most common attack of this nature is the
- <emphasis>ICMP ping broadcast attack</emphasis>. The attacker
- spoofs ping packets sent to the LAN's broadcast address with
- the source IP address set to the machine to attack. If the
- border routers are not configured to drop ping packets sent to
- broadcast addresses, the LAN generates sufficient responses to
- the spoofed source address to saturate the victim, especially
- when the attack is against several dozen broadcast addresses
- over several dozen different networks at once. A second
- common springboard attack constructs packets that generate
- ICMP error responses which can saturate a server's incoming
- network and cause the server to saturate its outgoing network
- with ICMP responses. This type of attack can crash the
- server by running it out of memory, especially if the server
- cannot drain the ICMP responses it generates fast enough. Use
- the &man.sysctl.8; variable
- <literal>net.inet.icmp.icmplim</literal> to limit these
- attacks. The last major class of springboard attacks is
- related to certain internal &man.inetd.8; services such as the
- UDP echo service. An attacker spoofs a UDP packet with a
- source address of server A's echo port and a destination
- address of server B's echo port, where server A and B on the
- same LAN. The two servers bounce this one packet back and
- forth between each other. The attacker can overload both
- servers and the LAN by injecting a few packets in this manner.
- Similar problems exist with the
- <application>chargen</application> port. These inetd-internal
- test services should remain disabled.</para>
-
- <para>Spoofed packet attacks may be used to overload the kernel
- route cache. Refer to the
- <varname>net.inet.ip.rtexpire</varname>,
- <varname>rtminexpire</varname>, and
- <varname>rtmaxcache</varname> &man.sysctl.8; parameters. A
- spoofed packet attack that uses a random source IP will cause
- the kernel to generate a temporary cached route in the route
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-all
mailing list