Attachment #17723 for bug #32094

View | Details | Raw Unified | Return to bug 32094
Collapse All | Expand All




      successful logins.</para>

    <para>One must always assume that once an attacker has access to a
      user account, the attacker can break <username>root</username>.
      However, the reality is that in a well secured and maintained system,
      access to a user account does not necessarily give the attacker
      access to <username>root</username>.  The distinction is important
      because without access to <username>root</username> the attacker
      cannot generally hide his tracks and may, at best, be able to do
      nothing more than mess with the user's files, or crash the machine.
      User account compromises are very common because users tend not to

    </indexterm>

    <para>System administrators must keep in mind that there are
      potentially many ways to break <username>root</username> on a machine.
      The attacker may know the <username>root</username> password,
      the attacker may find a bug in a root-run server and be able
      to break <username>root</username> over a network
      connection to that server, or the attacker may know of a bug in
      a suid-root program that allows the attacker to break
      <username>root</username> once he has broken into a user's account.
      If an attacker has found a way to break <username>root</username>
      on a machine, the attacker may not have a need
      to install a backdoor.  Many of the <username>root</username> holes
      found and closed to date involve a considerable amount of work
      by the attacker to cleanup after himself, so most attackers install
      backdoors.  A backdoor provides the attacker with a way to easily
      regain <username>root</username> access to the system, but it
      also gives the smart system administrator a convenient way
      to detect the intrusion.
      Making it impossible for an attacker to install a backdoor may
      actually be detrimental to your security, because it will not
      close off the hole the attacker found to break in the first

      </listitem>

      <listitem>
	<para>Securing <username>root</username> &ndash; root-run servers
	  and suid/sgid binaries.</para>
      </listitem>

      <listitem>


    <para>The sections that follow will cover the methods of securing your
      FreeBSD system that were mentioned in the <link
        linkend="security-intro">last section</link> of this chapter.</para>

    <sect2 id="securing-root-and-staff">
      <title>Securing the <username>root</username> Account and
	Staff Accounts</title>
      <indexterm>
        <primary><command>su</command></primary>
      </indexterm>

      <para>First off, do not bother securing staff accounts if you have
	not secured the <username>root</username> account.
	Most systems have a password assigned to the <username>root</username>
	account.  The first thing you do is assume
	that the password is <emphasis>always</emphasis> compromised.
	This does not mean that you should remove the password.  The
	password is almost always necessary for console access to the

	possible to use the password outside of the console or possibly
	even with the &man.su.1; command.  For example, make sure that
	your pty's are specified as being unsecure in the
	<filename>/etc/ttys</filename> file so that direct
	<username>root</username> logins
	via <command>telnet</command> or <command>rlogin</command> are
	disallowed.  If using other login services such as
        <application>sshd</application>, make sure that direct
	<username>root</username> logins are disabled there as well.
	You can do this by editing
        your <filename>/etc/ssh/sshd_config</filename> file, and making
        sure that <literal>PermitRootLogin</literal> is set to
        <literal>NO</literal>.  Consider every access method &ndash;
        services such as FTP often fall through the cracks.
	Direct <username>root</username> logins should only be allowed
	via the system console.</para>
      <indexterm>
        <primary><groupname>wheel</groupname></primary>
      </indexterm>

      <para>Of course, as a sysadmin you have to be able to get to
	<username>root</username>, so we open up a few holes.
	But we make sure these holes require additional password
	verification to operate.  One way to make <username>root</username>
	accessible is to add appropriate staff accounts to the
	<groupname>wheel</groupname> group (in
	<filename>/etc/group</filename>). The staff members placed in the
	<groupname>wheel</groupname> group are allowed to
	<command>su</command> to <username>root</username>.
	You should never give staff
	members native wheel access by putting them in the
	<groupname>wheel</groupname> group in their password entry.  Staff
	accounts should be placed in a <groupname>staff</groupname> group, and
	then added to the <groupname>wheel</groupname> group via the
	<filename>/etc/group</filename> file.  Only those staff members
	who actually need to have <username>root</username> access
	should be placed in the
	<groupname>wheel</groupname> group.  It is also possible, when using
	an authentication method such as Kerberos, to use Kerberos'
	<filename>.k5login</filename> file in the <username>root</username>
	account to allow a &man.ksu.1; to <username>root</username>
	without having to place anyone at all in the
	<groupname>wheel</groupname> group.  This may be the better solution
	since the <groupname>wheel</groupname> mechanism still allows an
	intruder to break <username>root</username> if the intruder
	has gotten hold of your
	password file and can break into a staff account.  While having
	the <groupname>wheel</groupname> mechanism is better than having
	nothing at all, it is not necessarily the safest option.</para>

      <para>An indirect way to secure staff accounts, and ultimately
        <username>root</username> access is to use an alternative
	login access method and
        do what is known as <quote>starring</quote> out the crypted
        password for the staff accounts. Using the &man.vipw.8;
        command, one can replace each instance of a crypted password
        with a single <quote><literal>*</literal></quote> character.
	This command will update the <filename>/etc/master.passwd</filename>
	file and user/password database to disable password-authenticated
        logins.</para>

      <para>A staff account entry such as:</para>


      <para>This change will prevent normal logins from occurring,
        since the encrypted password will never match
        <quote><literal>*</literal></quote>.  With this done,
	staff members must use
        another mechanism to authenticate themselves such as
        &man.kerberos.1; or &man.ssh.1; using a public/private key
        pair.  When using something like Kerberos, one generally must

	most bug-prone.  For example, running an old version of
	<application>imapd</application> or
	<application>popper</application> is like giving a universal
	<username>root</username> ticket out to the entire world.
	Never run a server that you have not checked out carefully.
	Many servers do not need to be run as <username>root</username>.
	For example, the <application>ntalk</application>,
	<application>comsat</application>, and
	<application>finger</application> daemons can be run in special
	user <firstterm>sandboxes</firstterm>.  A sandbox is not perfect,

	break out of the sandbox.  The more layers the attacker must
	break through, the lower the likelihood of his success.  Root
	holes have historically been found in virtually every server
	ever run as <username>root</username>, including basic system servers.
	If you are running a machine through which people only login via
	<application>sshd</application> and never login via
	<application>telnetd</application> or
	<application>rshd</application> or

	and others.  There are alternatives to some of these, but
	installing them may require more work than you are willing to
	perform (the convenience factor strikes again). You may have to
	run these servers as <username>root</username> and rely on other
	mechanisms to detect break-ins that might occur through them.</para>

      <para>The other big potential <username>root</username> holes in a
	system are the
	suid-root and sgid binaries installed on the system.  Most of
	these binaries, such as <application>rlogin</application>, 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.  Still,
	<username>root</username> holes are occasionally found in these
	binaries.  A <username>root</username> hole was found in
	<literal>Xlib</literal> in 1998 that made
	<application>xterm</application> (which is typically suid)
	vulnerable.  It is better to be safe than sorry and the prudent

	passwords as you can and use ssh or
	Kerberos for access to those accounts.  Even though the crypted
	password file (<filename>/etc/spwd.db</filename>) can only be read
	by <username>root</username>, it may be possible for an intruder
	to obtain read access to that file even if the attacker cannot
	obtain root-write access.</para>

      <para>Your security scripts should always check for and report
	changes to the password file (see the <link
	  linkend="security-integrity">Checking file integrity</link> section
	below).</para>
    </sect2>


      <title>Securing the Kernel Core, Raw Devices, and
	Filesystems</title>

      <para>If an attacker breaks <username>root</username> he can do
        just about anything, but
	there are certain conveniences.  For example, most modern kernels
	have a packet sniffing device driver built in.  Under FreeBSD it
	is called the <devicename>bpf</devicename> device.  An intruder

	delivery you can run the queue at a much lower interval, such as
	<option>-q1m</option>, but be sure to specify a reasonable
	<literal>MaxDaemonChildren</literal> option for
	<emphasis>that</emphasis> sendmail to prevent cascade failures.</para>
	</para>

      <para><application>Syslogd</application> can be attacked directly
	and it is strongly recommended that you use the <option>-s</option>

	external access by firewalling them off at your border routers.
	The idea here is to prevent saturation attacks from outside your
	LAN, not so much to protect internal services from network-based
	<username>root</username> compromise.
	Always configure an exclusive firewall, i.e.,
	<quote>firewall everything <emphasis>except</emphasis> ports A, B,
	C, D, and M-Z</quote>.  This way you can firewall off all of your
	low ports except for certain specific services such as

	ssh to an unsecure machine, your keys
	becomes exposed.  The actual keys themselves are not exposed, but
	ssh installs a forwarding port for the
	duration of your login, and if an attacker has broken
	<username>root</username> on the
	unsecure machine he can utilize that port to use your keys to gain
	access to any other machine that your keys unlock.</para>


      <para>You should now edit the <filename>krb.conf</filename> and
	<filename>krb.realms</filename> files to define your Kerberos realm.
	In this case the realm will be <filename>EXAMPLE.COM</filename> and the
	server is <hostid role="fqdn">grunt.example.com</hostid>.  We edit
	or create the <filename>krb.conf</filename> file:</para>
	  
      <screen>&prompt.root; <userinput>cat krb.conf</userinput>
EXAMPLE.COM

	<literal>&lt;principal&gt;.&lt;instance&gt;</literal> of the form
	<literal>&lt;username&gt;.</literal><username>root</username> will allow
	that <literal>&lt;username&gt;</literal> to <command>su</command> to
	<username>root</username> if the necessary entries are in the
	<filename>.klogin</filename> file in <username>root</username>'s
	home directory:</para>
	  
      <screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
jane.root@EXAMPLE.COM</screen>


FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
	  
      <para>Or Jack logs into Jane's account on the same machine
	(<username>jane</username> having
	set up the <filename>.klogin</filename> file as above, and the person
	in charge of Kerberos having set up principal
	<emphasis>jack</emphasis> with a null instance:</para>

      elsewhere, and is not available for unrestricted use.
      IDEA is included in the OpenSSL sources in FreeBSD, but it is not
      built by default.  If you wish to use it, and you comply with the
      license terms, enable the <literal>MAKE_IDEA</literal> switch in
      <filename>/etc/make.conf</filename> and
      rebuild your sources using <command>make world</command>.</para>

    <para>Today, the RSA algorithm is free for use in USA and other

        From HOST B to HOST A, new AH and new ESP are combined.</para>

      <para>Now we should choose an algorithm to be used corresponding to
        <quote>AH</quote>/<quote>new AH</quote>/<quote>ESP</quote>/
	<quote>new ESP</quote>.  Please refer to the &man.setkey.8; man
        page to know algorithm names.  Our choice is MD5 for AH, new-HMAC-SHA1
        for new AH, and new-DES-expIV with 8 byte IV for new ESP.</para>

      <para>Key length highly depends on each algorithm.  For example, key
        length must be equal to 16 bytes for MD5, 20 for new-HMAC-SHA1,
        and 8 for new-DES-expIV.  Now we choose <quote>MYSECRETMYSECRET</quote>,
        <quote>KAMEKAMEKAMEKAMEKAME</quote>, <quote>PASSWORD</quote>,
	respectively.</para>

      <para>OK, let us assign SPI (Security Parameter Index) for each protocol.
        Please note that we need 3 SPIs for this secure channel since three
        security headers are produced (one for from HOST A to HOST B, two for
        from HOST B to HOST A).  Please also note that SPI MUST be greater
        than or equal to 256.  We choose, 1000, 2000, and 3000,
	respectively.</para>

      <screen>
	         (1)

          fec0::10 -------------------- fec0::11
</screen>

      <para>Encryption algorithm is blowfish-cbc whose key is
	<quote>kamekame</quote>, and authentication algorithm is hmac-sha1
	whose key is <quote>this is the test key</quote>.
	Configuration at Host-A:</para>

      <screen>
        &prompt.root; <command>setkey -c</command> &lt;&lt;<filename>EOF</filename>

        EOF
</screen>

      <para>If the port number field is omitted such as above then
	<literal>[any]</literal> is employed. <literal>-m</literal>
	specifies the mode of SA to be used. <literal>-m any</literal> means
	wild-card of mode of security protocol. You can use this SA for both
	tunnel and transport mode.</para>

      <para>and at Gateway-B:</para>


      </indexterm>

      <para>Be sure to make the following additions to your 
        <filename>rc.conf</filename> file:</para>
      </para>
      <screen>sshd_enable="YES"</screen>
      <para>This will load the <application>ssh</application> daemon
	the next time your system initializes.  Alternatively, you can
	simply run the <application>sshd</application> daemon.</para>
    </sect2>

    <sect2>

        created using <command>rlogin</command> or telnet.  SSH utilizes a 
	key fingerprint
        system for verifying the authenticity of the server when the 
        client connects.  The user is prompted to enter
	<literal>yes</literal> only when
        connecting for the first time.  Future attempts to login are all
        verified against the saved fingerprint key.  The SSH client
        will alert you if the saved fingerprint differs from the

      </indexterm>
      <indexterm><primary><command>scp</command></primary></indexterm>

      <para>The <command>scp</command> command works similarly to
	<command>rcp</command>; it copies a file to or from a remote machine,
	except in a secure fashion.</para>

      <screen>&prompt.root <userinput> scp <replaceable>user@example.com:/COPYRIGHT COPYRIGHT</replaceable></userinput>
user@example.com's password: 

&prompt.root</screen>
      <para>Since the fingerprint was already saved for this host in the
        previous example, it is verified when using <command>scp</command>
        here.</para>
      </para>

      <para>The arguments passed to <command>scp</command> are similar
	to <command>cp</command>, with the file or files in the first

      </variablelist>


      <para>An SSH tunnel works by creating a listen socket on
	<hostid>localhost</hostid> on the specified port.
	It then forwards any connection received
	on the local host/port via the SSH connection to the specified
	remote host and port.</para>

      <para>In the example, port <replaceable>5023</replaceable> on
	<hostid>localhost</hostid> is being forwarded to port
	<replaceable>23</replaceable> on <hostid>localhost</hostid>
	of the remote machine.  Since <replaceable>23</replaceable> is telnet,
	this would create a secure telnet session through an SSH tunnel.</para>

      <para>This can be used to wrap any number of insecure TCP protocols 
        such as smtp, pop3, ftp, etc.</para>

       <para>A typical SSH Tunnel</para>
       <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5025:localhost:25 user@mailserver.example.com</replaceable></userinput>

Return to bug 32094