Hi,
After talking to a few people, I've written up two new sections,
one is a huge cleanup of the security chapter and the second
adds a shell redirection section to the handbook. Right now
I'm seeking some comments and suggestions here. Want to
commit sometime this week. Cheers,
--
Tom Rhodes
Index: handbook/basics/chapter.xml
===================================================================
--- handbook/basics/chapter.xml (revision 43727)
+++ handbook/basics/chapter.xml (working copy)
@@ -987,7 +987,7 @@
<primary><command>pw</command></primary>
</indexterm>
- <para>&man.pw.8; is a command line utility to create, remove,
+ <para>The &man.pw.8; command line utility can create, remove,
modify, and display users and groups. It functions as a
front end to the system user and group files. &man.pw.8;
has a very powerful set of command line options that make it
@@ -3432,6 +3432,79 @@
<para>Then, rerun &man.chsh.1;.</para>
</note>
</sect2>
+
+ <sect2>
+ <info>
+ <title>Advanced Shell Techniques</title>
+
+ <authorgroup>
+ <author>
+ <personname>
+ <firstname>Tom</firstname>
+ <surname>Rhodes</surname>
+ </personname>
+ <contrib>Written by </contrib>
+ </author>
+ </authorgroup>
+ </info>
+
+ <para>The &unix; shell is not just a command interpreter, it
+ acts as a powerful tool which allows users to execute commands,
+ redirect their output, redirect their input and chain commands
+ together to improve the final command output. When this functionality
+ is mixed with built in commands, the user is provided with
+ an environment that can maximize efficiency.</para>
+
+ <para>Shell redirection is the action of sending the output
+ or the input of a command into another command or into a
+ file. To capture the output of the &man.ls.1; command, for
+ example, into a file, simply redirect the output:</para>
+
+ <screen>&prompt.user; <userinput>ls >
directory_listing.txt</userinput></screen>
+
+ <para>The <filename>directory_listing.txt</filename> file will
+ now contain the directory contents. Some commands allow you
+ to read input in a similar one, such as &man.sort.1;. To sort
+ this listing, redirect the input:</para>
+
+ <screen>&prompt.user; <userinput>sort <
directory_listing.txt</userinput></screen>
+
+ <para>The input will be sorted and placed on the screen. To
+ redirect that input into another file, one could redirect
+ the output of &man.sort.1; by mixing the direction:</para>
+
+ <screen>&prompt.user; <userinput>sort < directory_listing.txt >
sorted.txt</userinput></screen>
+
+ <para>In all of the previous examples, the commands are performing
+ redirection using file descriptors. Every unix system has file
+ descriptors; however, here we will focus on three, so named as
+ Standard Input, Standard Output, and Standard Error. Each one
+ has a purpose, where input could be a keyboard or a mouse,
+ something that provides input. Output could be a screen or
+ paper in a printer for example. And error would be anything
+ that is used for diagnostic or error messages. All three
+ are considered <acronym>I/O</acronym> based file descriptors
+ and sometimes considered streams.</para>
+
+ <para>Through the use of these descriptors, short named
+ stdin, stdout, and stderr, the shell allows output and
+ input to be passed around through various commands and
+ redirected to or from a file. Another method of redirection
+ is the pipe operator.</para>
+
+ <para>The &unix; pipe operator, <quote>|</quote> allows the
+ output of one command to be directly passed, or directed
+ to another program. Basically a pipe will allow the
+ standard output of a command to be passed as standard
+ input to another command, for example:</para>
+
+ <screen>&prompt.user; <userinput>du -h | less</userinput></screen>
+
+ <para>In that example, the &man.du.1; command will direct the
+ output to the &man.less.1; command. This allows the user
+ to scroll through the output at their own pace and prevent
+ it from scrolling off the screen.</para>
+ </sect2>
</sect1>
<sect1 xml:id="editors">
Index: handbook/security/chapter.xml
===================================================================
--- handbook/security/chapter.xml (revision 43727)
+++ handbook/security/chapter.xml (working copy)
@@ -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>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>&os; provides an array of utilities and mechanisms to
- protect the integrity and security of the system and
- network.</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,758 +113,202 @@
<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>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>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>
+ <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, and they expect
+ access to information at all times. Together they make up the
+ confidentiality, integrity, and availability of the
+ system.</para>
- <orderedlist>
- <listitem>
- <para>Denial of service attacks.</para>
- </listitem>
+ <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>
- <listitem>
- <para>User account compromises.</para>
- </listitem>
+ <sect2 xml:id="security-threats">
+ <title>Threats</title>
- <listitem>
- <para>Root compromise through accessible services.</para>
- </listitem>
+ <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>
- <listitem>
- <para>Root compromise via user accounts.</para>
- </listitem>
+ <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>
- <listitem>
- <para>Backdoor creation.</para>
- </listitem>
- </orderedlist>
+ <sect2 xml:id="security-groundup">
+ <title>A Ground Up Approach</title>
- <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>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>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>
+ <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>
- <indexterm>
- <primary>security</primary>
- <secondary>account compromises</secondary>
- </indexterm>
+ <sect2 xml:id="security-accounts">
+ <title>System and User Accounts</title>
- <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 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>
- <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>
+ <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>
- <indexterm>
- <primary>security</primary>
- <secondary>backdoors</secondary>
- </indexterm>
+ <screen>&prompt.root; <userinput>pw lock toor</userinput></screen>
- <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>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>Security remedies should always be implemented with a
- multi-layered <quote>onion peel</quote> approach and can be
- categorized as follows:</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>
- <orderedlist>
- <listitem>
- <para>Secure <systemitem class="username">root</systemitem> and staff
- accounts.</para>
- </listitem>
+ <screen>&prompt.root; <userinput>chsh -s /usr/sbin/nologin
toor</userinput></screen>
- <listitem>
- <para>Secure <systemitem class="username">root</systemitem>–run
servers
- and SUID/SGID binaries.</para>
- </listitem>
+ <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>
- <listitem>
- <para>Secure user accounts.</para>
- </listitem>
+ <para>The account structure will now look like this, with
+ the <quote>nologin</quote> shell as the last entry:</para>
- <listitem>
- <para>Secure the password file.</para>
- </listitem>
+ <programlisting>toor:*:0:0::0:0:Bourne-again
Superuser:/root:/usr/sbin/nologin</programlisting>
- <listitem>
- <para>Secure the kernel core, raw devices, and
- filesystems.</para>
- </listitem>
+ <para>The <filename>/usr/sbin/nologin</filename> shell will block
+ the &man.login.1; command from assigning a shell to this
+ user.</para>
+ </sect2>
- <listitem>
- <para>Quick detection of inappropriate changes made to the
- system.</para>
- </listitem>
+ <sect2 xml:id="security-sudo">
+ <title>Permitted Account Escalation</title>
- <listitem>
- <para>Paranoia.</para>
- </listitem>
- </orderedlist>
+ <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 next section covers these items in greater depth.</para>
- </sect1>
+ <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>
- <sect1 xml:id="securing-freebsd">
- <title>Securing &os;</title>
+ <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>
- <indexterm>
- <primary>security</primary>
- <secondary>securing &os;</secondary>
- </indexterm>
+ <screen>&prompt.root; <userinput>pw groupadd webadmin -M trhodes -g
6000</userinput></screen>
- <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>
+ <screen>&prompt.root; <userinput>visudo</userinput></screen>
- <sect2 xml:id="securing-root-and-staff">
- <title>Securing the <systemitem class="username">root</systemitem>
Account</title>
+ <programlisting>%webadmin ALL=(ALL) /usr/sbin/service apache24
*</programlisting>
- <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
- account:</para>
-
- <programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo
Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
-
- <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 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>
-
- <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>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>
+ <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 the <xref linkend="openssh"/>
section.</para>
</sect2>
- <sect2>
- <title>Securing the Kernel Core, Raw Devices, and
- Filesystems</title>
+ <sect2 xml:id="security-passwords">
+ <title>Passwords</title>
- <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>Passwords are a necessary evil of the past. 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>
- <indexterm>
- <primary>&man.sysctl.8;</primary>
- </indexterm>
-
- <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>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=1</userinput></screen>
-
- <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 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>
+ <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>
- <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>
+ <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-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
- table, viewable with <command>netstat -rna | fgrep
- W3</command>. These routes typically timeout in 1600
- seconds or so. If the kernel detects that the cached route
- table has gotten too big, it will dynamically reduce the
- <varname>rtexpire</varname> but will never decrease it to less
- than <varname>rtminexpire</varname>. This creates two
- problems:</para>
-
- <orderedlist>
- <listitem>
-
- <para>The kernel does not react quickly enough when a
- lightly loaded server is suddenly attacked.</para>
- </listitem>
-
- <listitem>
- <para>The <varname>rtminexpire</varname> is not low enough
- for the kernel to survive a sustained attack.</para>
- </listitem>
- </orderedlist>
-
- <para>If the servers are connected to the Internet via a T3 or
- better, it may be prudent to manually override both
- <varname>rtexpire</varname> and <varname>rtminexpire</varname>
- via &man.sysctl.8;. Never set either parameter to zero
- as this could crash the machine. Setting both parameters to 2
- seconds should be sufficient to protect the route table from
- attack.</para>
- </sect2>
-
- <sect2>
- <title>Access Issues with Kerberos and &man.ssh.1;</title>
-
- <indexterm><primary>&man.ssh.1;</primary></indexterm>
-
- <para>There are a few issues with both Kerberos and &man.ssh.1;
- that need to be addressed if they are used. Kerberos is an
- excellent authentication protocol, but there are bugs in the
- kerberized versions of &man.telnet.1; and &man.rlogin.1; that
- make them unsuitable for dealing with binary streams. By
- default, Kerberos does not encrypt a session unless
- <option>-x</option> is used whereas &man.ssh.1; encrypts
- everything.</para>
-
- <para>While &man.ssh.1; works well, it forwards encryption keys
- by default. This introduces a security risk to a user who
- uses &man.ssh.1; to access an insecure machine from a secure
- workstation. The keys themselves are not exposed, but
- &man.ssh.1; installs a forwarding port for the duration of the
- login. If an attacker has broken <systemitem
class="username">root</systemitem> on
- the insecure machine, he can utilize that port to gain access
- to any other machine that those keys unlock.</para>
-
- <para>It is recommended that &man.ssh.1; is used in combination
- with Kerberos whenever possible for staff logins and
- &man.ssh.1; can be compiled with Kerberos support. This
- reduces reliance on potentially exposed <acronym>SSH</acronym>
- keys while protecting passwords via Kerberos. Keys should
- only be used for automated tasks from secure machines as this
- is something that Kerberos is unsuited to. It is recommended
- to either turn off key-forwarding in the
- <acronym>SSH</acronym> configuration, or to make use
- of <literal>from=IP/DOMAIN</literal> in
- <filename>authorized_keys</filename> to make the key only
- usable to entities logging in from specific machines.</para>
- </sect2>
</sect1>
- <sect1 xml:id="crypt">
- <info><title>DES, Blowfish, MD5, SHA256, SHA512, and Crypt</title>
- <authorgroup>
-
<author><personname><firstname>Bill</firstname><surname>Swingle</surname></personname><contrib>Parts
rewritten and updated by </contrib></author>
- </authorgroup>
-
- </info>
-
-
-
- <indexterm>
- <primary>security</primary>
- <secondary>crypt</secondary>
- </indexterm>
-
- <indexterm><primary>crypt</primary></indexterm>
- <indexterm><primary>Blowfish</primary></indexterm>
- <indexterm><primary>DES</primary></indexterm>
- <indexterm><primary>MD5</primary></indexterm>
- <indexterm><primary>SHA256</primary></indexterm>
- <indexterm><primary>SHA512</primary></indexterm>
-
- <para>Every user on a &unix; system has a password associated with
- their account. In order to keep these passwords secret, they
- are encrypted with a <quote>one-way hash</quote>, as they can
- be easily encrypted but not decrypted. The operating system
- itself does not know the password. It only knows the
- <emphasis>encrypted</emphasis> form of the password. The only
- way to get the <quote>plain-text</quote> password is by a brute
- force search of the space of possible passwords.</para>
-
- <para>Originally, the only secure way to encrypt passwords in
- &unix; was based on the Data Encryption Standard
- (<acronym>DES</acronym>). Since the source code for
- <acronym>DES</acronym> could not be exported outside the US,
- &os; had to find a way to both comply with US law and retain
- compatibility with other &unix; variants that used
- <acronym>DES</acronym>. The solution was MD5 which is believed
- to be more secure than <acronym>DES</acronym>.</para>
-
- <sect2>
- <title>Recognizing the Crypt Mechanism</title>
-
- <para>Currently the library supports <acronym>DES</acronym>,
- MD5, Blowfish, SHA256, and SHA512 hash functions. To identify
- which encryption method &os; is set up to use, examine the
- encrypted passwords in
- <filename>/etc/master.passwd</filename>. Passwords encrypted
- with the MD5 hash are longer than those encrypted with the
- <acronym>DES</acronym> hash and begin with the characters
- <literal>$1$</literal>. Passwords starting with
- <literal>$2a$</literal> are encrypted with the
- Blowfish hash function. <acronym>DES</acronym> password
- strings do not have any particular identifying
- characteristics, but they are shorter than MD5 passwords, and
- are coded in a 64-character alphabet which does not include
- the <literal>$</literal> character, so a relatively
- short string which does not begin with a dollar sign is very
- likely a <acronym>DES</acronym> password. Both SHA256 and
- SHA512 begin with the characters
- <literal>$6$</literal>.</para>
-
- <para>The password format used for new passwords is controlled
- by the <literal>passwd_format</literal> login capability in
- <filename>/etc/login.conf</filename>, which takes values of
- <literal>des</literal>, <literal>md5</literal>,
- <literal>blf</literal>, <literal>sha256</literal> or
- <literal>sha512</literal>. Refer to &man.login.conf.5; for
- more information about login capabilities.</para>
- </sect2>
- </sect1>
-
<sect1 xml:id="one-time-passwords">
<title>One-time Passwords</title>
@@ -1970,6 +1419,44 @@
</sect2>
<sect2>
+ <title>Access Issues with Kerberos and &man.ssh.1;</title>
+
+ <indexterm><primary>&man.ssh.1;</primary></indexterm>
+
+ <para>There are a few issues with both Kerberos and &man.ssh.1;
+ that need to be addressed if they are used. Kerberos is an
+ excellent authentication protocol, but there are bugs in the
+ kerberized versions of &man.telnet.1; and &man.rlogin.1; that
+ make them unsuitable for dealing with binary streams. By
+ default, Kerberos does not encrypt a session unless
+ <option>-x</option> is used whereas &man.ssh.1; encrypts
+ everything.</para>
+
+ <para>While &man.ssh.1; works well, it forwards encryption keys
+ by default. This introduces a security risk to a user who
+ uses &man.ssh.1; to access an insecure machine from a secure
+ workstation. The keys themselves are not exposed, but
+ &man.ssh.1; installs a forwarding port for the duration of the
+ login. If an attacker has broken
+ <systemitem class="username">root</systemitem> on
+ the insecure machine, he can utilize that port to gain access
+ to any other machine that those keys unlock.</para>
+
+ <para>It is recommended that &man.ssh.1; is used in combination
+ with Kerberos whenever possible for staff logins and
+ &man.ssh.1; can be compiled with Kerberos support. This
+ reduces reliance on potentially exposed <acronym>SSH</acronym>
+ keys while protecting passwords via Kerberos. Keys should
+ only be used for automated tasks from secure machines as this
+ is something that Kerberos is unsuited to. It is recommended
+ to either turn off key-forwarding in the
+ <acronym>SSH</acronym> configuration, or to make use
+ of <literal>from=IP/DOMAIN</literal> in
+ <filename>authorized_keys</filename> to make the key only
+ usable to entities logging in from specific machines.</para>
+ </sect2>
+
+ <sect2>
<title>Resources and Further Information</title>
<indexterm>
_______________________________________________
freebsd-doc@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-doc
To unsubscribe, send any mail to "freebsd-doc-unsubscr...@freebsd.org"
