Attachment #16031 for bug #29566

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




      at all.</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 break root.  Security concerns
      can be split up into several categories:</para>

    <orderedlist>

      machine of needed resources.  Typically, D.O.S. attacks are
      brute-force mechanisms that attempt to crash or otherwise make a
      machine unusable by overwhelming its servers or network stack.  Some
      D.O.S. attacks try to take advantage of bugs in the networking
      stack to crash a machine with a single packet.  The latter can only
      be fixed by applying a bug fix to the kernel.  Attacks on servers
      can often be fixed by properly specifying options to limit the load
      the servers incur on the system under adverse conditions.
      Brute-force network attacks are harder to deal with.  A
      spoofed-packet attack, for example, is nearly impossible to stop,
      short of cutting your system off from the Internet.  It may not be
      able to take your machine down, but it can saturate your
      Internet connection.</para>

      account does not necessarily give the attacker access to root.  The
      distinction is important because without access to root 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
      take the precautions that sysadmins take.</para>


      to install a backdoor.  Many of the root 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 root access to the system, but it also gives the smart
      system administrator a convenient way to detect the intrusion.
      Making it impossible for an attacker to install a backdoor may
      actually be detrimental to your security, because it will not
      close off the hole the attacker found to break in the first
      place.</para>


        guarantees that staff members can only login through secure
        access methods that you have setup.  This forces all staff
        members to use secure, encrypted connections for all of their
        sessions, which closes an important hole used by many
        intruders: That of sniffing the network from an unrelated,
        less secure machine.</para>


	you should run a password-protected screen blanker.  Of course,
	given physical access to a workstation an attacker can break any
	sort of security you put on it.  This is definitely a problem that
	you should consider, but you should also consider the fact that the
	vast majority of break-ins occur remotely, over a network, from
	people who do not have physical access to your workstation or
	servers.</para>
      <indexterm><primary>Kerberos</primary></indexterm>

      <para>Using something like kerberos also gives you the ability to
	disable or change the password for a staff account in one place,
	and have it immediately effect all the machines on which the staff
	member may have an account.  If a staff member's account gets
	compromised, the ability to instantly change his password on all
	machines should not be underrated.  With discrete passwords,
	changing a password on N machines can be a mess.  You can also

	example, the <application>ntalk</application>,
	<application>comsat</application>, and
	<application>finger</application> daemons can be run in special
	user <literal>sandboxes</literal>.  A sandbox is not perfect, unless
	you go to a large amount of trouble, but the onion approach to
	security still stands:  If someone is able to break in through
	a server running in a sandbox, they still have to break out of the

	run these servers as root and rely on other mechanisms to detect
	break-ins that might occur through them.</para>

      <para>The other big potential root 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>,

	<literal>Xlib</literal> in 1998 that made
	<application>xterm</application> (which is typically suid)
	vulnerable.  It is better to be safe than sorry and the prudent
	sysadmin will restrict suid binaries, that only staff should run,
	to a special group that only staff can access, and get rid of
	(<command>chmod 000</command>) any suid binaries that nobody uses.
	A server with no display generally does not need an
	<application>xterm</application> binary.  Sgid binaries can be
	almost as dangerous.  If an intruder can break an sgid-kmem binary,
	the intruder might be able to read <filename>/dev/kmem</filename>
	and thus read the crypted password file, potentially compromising
	any passworded account.  Alternatively an intruder who breaks

	you can impose Draconian access restrictions on your staff and
	<literal>*</literal> out their passwords, you may not be able to
	do so with any general user accounts you might have.  If you do
	have sufficient control, then you may win out and be able to secure
	the user accounts properly.  If not, you simply have to be more
	vigilant in your monitoring of those accounts.  Use of
	<application>ssh</application> and kerberos for user accounts is
	more problematic, due to the extra administration and technical
	support required, but still a very good solution compared to a
	crypted password file.</para>
    </sect2>

	to worry about.  For that matter, the intruder can still write to
	raw disk devices.  Also, there is another kernel feature called
	the module loader, &man.kldload.8;.  An enterprising intruder can
	use a KLD module to install his own bpf device, or other sniffing
	device, on a running kernel.  To avoid these problems you have to
	run the kernel at a higher secure level, at least securelevel 1.
	The securelevel can be set with a <command>sysctl</command> on
	the <literal>kern.securelevel</literal> variable.  Once you have

	convenience factor rears its ugly head.  For example, using
	<command>chflags</command> to set the <literal>schg</literal> bit
	on most of the files in <filename>/</filename> and
	<filename>/usr</filename> is probably counterproductive, because
	while it may protect the files, it also closes a detection window.
	The last layer of your security onion is perhaps the most
	important &ndash; detection.  The rest of your security is pretty
	much useless (or, worse, presents you with a false sense of
	safety) if you cannot detect potential incursions.  Half the job
	of the onion is to slow down the attacker, rather than stop him, in
	order to give the detection side of the equation a chance to catch
	him in the act.</para>


	other machines in the business, usually either by doing a
	read-only NFS export of the other machines to the limited-access
	box, or by setting up <application>ssh</application> key-pairs to
	allow the limited-access box to <application>ssh</application> to
	the other machines.  Except for its network traffic, NFS is the
	least visible method &ndash; allowing you to monitor the
	filesystems on each client box virtually undetected.  If your
	limited-access server is connected to the client boxes through a
	switch, the NFS method is often the better choice.  If your
	limited-access server is connected to the client boxes through a
	hub, or through several layers of routing, the NFS method may be
	too insecure (network-wise) and using
	<application>ssh</application> may be the better choice even with
	the audit-trail tracks that <application>ssh</application>
	lays.</para>

      <para>Once you give a limited-access box, at least read access to the
	client systems it is supposed to monitor, you must write scripts
	to do the actual monitoring.  Given an NFS mount, you can write
	scripts out of simple system utilities such as &man.find.1; and
	&man.md5.1;.  It is best to physically md5 the client-box files
	at least once a day, and 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 scream at a
	sysadmin to go check it out.  A good security script will also
	check for inappropriate suid binaries and for new or deleted files

	scripts use.  The <application>ssh</application> daemon on the
	client box may already be compromised.  All in all, using
	<application>ssh</application> may be necessary when running over
	unsecure links, but it is also a lot harder to deal with.</para>

      <para>A good security script will also check for changes to user and
	staff members access configuration files:

	files that might fall outside the purview of the
	<literal>MD5</literal> check.</para>

      <para>If you have a huge amount of user disk space, it may take too
	long to run through every file on those partitions.  In this case,
	setting mount flags to disallow suid binaries and devices on those
	partitions is a good idea.  The <literal>nodev</literal> and
	<literal>nosuid</literal> options (see &man.mount.8;) are what you
	want to look into.  You should probably scan them anyway, at least
	once a week, since the object of this layer is to detect a break-in
	whether or not the break-in is effective.</para>


	a system, assuming the file is still intact after the break-in
	occurs.</para>

      <para>Finally, security scripts should process the log files, and the
	logs themselves should be generated in as secure a manner as
	possible &ndash; remote syslog can be very useful.  An intruder
	tries to cover his tracks, and log files are critical to the

      <title>Paranoia</title>

      <para>A little paranoia never hurts.  As a rule, a sysadmin can add
	any number of security features, as long as they do not effect
	convenience, and can add security features that
	<emphasis>do</emphasis> effect convenience with some added thought.
	Even more importantly, a security administrator should mix it up a
	bit &ndash; if you use recommendations such as those given by this
	document verbatim, you give away your methodologies to the
	prospective attacker who also has access to this document.</para>
    </sect2>

    <sect2>

      </orderedlist>

      <para>A common DoS attack is against a forking server that attempts
	to cause the server to eat processes, file descriptors, and memory,
	until the machine dies.  Inetd (see &man.inetd.8;) has several
	options 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 the inetd manual page carefully and pay
	specific attention to the <option>-c</option>, <option>-C</option>,

	servers have self-fork-limitation parameters.</para>

      <para><application>Sendmail</application> has its
	<option>-OMaxDaemonChildren</option> option, which tends to work
	much better than trying to use sendmail's load limiting options
	due to the load lag.  You should specify a
	<literal>MaxDaemonChildren</literal> parameter, when you start
	<application>sendmail</application>, high enough to handle your
	expected load, but not so high that the computer cannot handle that
	number of <application>sendmails</application> without falling on
	its face.  It is also prudent to run sendmail in queued mode
	(<option>-ODeliveryMode=queued</option>) and to run the daemon

	(<command>sendmail -q15m</command>). If you still want real-time
	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><application>Syslogd</application> can be attacked directly
	and it is strongly recommended that you use the <option>-s</option>

	services.  If you try to configure the firewall the other way
	&ndash; as an inclusive or permissive firewall, there is a good
	chance that you will forget to <quote>close</quote> a couple of
	services, or that you will add a new internal service and forget
	to update the firewall.  You can still open up the high-numbered
	port range on the firewall, to allow permissive-like operation,
	without compromising your low ports.  Also take note that FreeBSD
	allows you to control the range of port numbers used for dynamic
	binding, via the various <literal>net.inet.ip.portrange</literal>
	<command>sysctl</command>'s (<command>sysctl -a | fgrep
	portrange</command>), which can also ease the complexity of your
	firewall's configuration.  For example, you might use a normal
	first/last range of 4000 to 5000, and a hiport range of 49152 to
	65535, then block off everything under 4000 in your firewall
	(except for certain specific Internet-accessible ports, of
	course).</para>


      </orderedlist>
      
      <para>If your servers are connected to the Internet via a T3 or
        better, it may be prudent to manually override both
	<literal>rtexpire</literal> and <literal>rtminexpire</literal>
	via &man.sysctl.8;.  Never set either parameter to zero (unless
	you want to crash the machine).  Setting both
	parameters to 2 seconds should be sufficient to protect the route
	table from attack.</para>
    </sect2>

      <para>There are a few issues with both kerberos and
	<application>ssh</application> that need to be addressed if
	you intend to use them.  Kerberos V is an excellent
	authentication protocol, but there are bugs in the kerberized
	<application>telnet</application> and
	<application>rlogin</application> applications that make them
	unsuitable for dealing with binary streams.  Also, by default

	<application>ssh</application> to an unsecure machine, your keys
	becomes exposed.  The actual keys themselves are not exposed, but
	<application>ssh</application> installs a forwarding port for the
	duration of your login, and if an attacker has broken root 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>Unfortunately the only secure way to encrypt passwords when
      Unix came into being was based on DES, the Data Encryption
      Standard.  This was not such a problem for users resident in
      the US, but since the source code for DES could not be exported
      outside the US, FreeBSD had to find a way to both comply with
      US law and retain compatibility with all the other Unix
      variants that still used DES.</para>

    <para>The solution was to divide up the encryption libraries 
      so that US users could install the DES libraries and use

      <para>It is pretty easy to identify which encryption method 
	FreeBSD is set up to use.  Examining the encrypted passwords in
	the <filename>/etc/master.passwd</filename> file is one way.
	Passwords encrypted with the MD5 hash are longer than those
	encrypted with the DES hash and also begin with the characters
	<literal>&dollar;1&dollar;</literal>.  DES password strings do not
	have any particular identifying characteristics, but they are

  
      <para>Identifying which library is being used by the programs on
	your system is easy as well. Any program that uses crypt is linked
	against libcrypt, which for each type of library is a symbolic link
	to the appropriate implementation. For example, on a system using
	the DES versions:</para>


      will discuss below.  The <command>key</command> program accepts an
      iteration count, a seed, and a secret password, and generates a
      one-time password.  The <command>keyinit</command> program is used
      to initialize S/Key, and to change passwords, iteration counts, or
      seeds; it takes either a secret password, or an iteration count,
      seed, and one-time password.  The <command>keyinfo</command> program
      examines the <filename>/etc/skeykeys</filename> file and prints out

      <para>If any additional files (such as <filename>principal.*</filename>
	or <filename>master_key</filename>) exist, then use the
	<command>kdb_destroy</command> command to destroy the old Kerberos
	database, or if Kerberos is not running, simply delete the extra
	files.</para>
	  
      <para>You should now edit the <filename>krb.conf</filename> and

Generating 'grunt-new-srvtab'....</screen>
	  
      <para>Now, this command only generates a temporary file which must be
	renamed to <filename>srvtab</filename> so that all the servers can pick
	it up.  Use the <command>mv</command> command to move it into place on
	the original system:</para>
	  

	  separate firewall and accounting entries.  The present version
	  provides packet accounting with each firewall entry.</para>
	    
	<para>If an <emphasis>index</emphasis> value is supplied, it is used to
	  place the entry at a specific point in the chain. Otherwise, the
	  entry is placed at the end of the chain at an index 100 greater than
	  the last chain entry (this does not include the default policy, rule

	    
	    <listitem>
	      <para>Matches if the packet is an attempt to establish a TCP
		connection (the SYN bit is set but the ACK bit is
		not).</para>
	    </listitem>
	  </varlistentry>

	  through the firewall, so large FTP/http transfers, etc, will really
	  slow the system down.  It also increases the latencies on those
	  packets as it requires more work to be done by the kernel before the
	  packet can be passed on.  syslogd will also start using up a lot
	  more processor time as it logs all the extra data to disk, and it
	  could quite easily fill the partition <filename>/var/log</filename>
	  is located on.</para>

	<listitem>
	  <para>Block <emphasis>all</emphasis> incoming UDP traffic.  There
	    are very few useful services that travel over UDP, and what useful
	    traffic there is, is normally a security threat (e.g. Suns RPC and
	    NFS protocols).  This has its disadvantages also, since UDP is a
	    connectionless protocol, denying incoming UDP traffic also blocks
	    the replies to outgoing UDP traffic.  This can cause a problem for
	    people (on the inside) using external archie (prospero) servers.
	    If you want to allow access to archie, you will have to allow
	    packets coming from ports 191 and 1525 to any internal UDP port
	    through the firewall.  ntp is another service you may consider
	    allowing through, which comes from port 123.</para>

    <para><emphasis>Contributed by &a.shin;, 5 March
	2000.</emphasis></para>

    <para>The IPsec mechanism provides secure communication for IP
    layer and socket layer communication.  This section should
    explain how to use them.  For implementation details, please
    refer to <ulink

    <sect2>
      <title>Transport mode example with IPv4</title>

      <para>Let us setup security association to deploy a secure channel
      between HOST A (10.2.3.4) and HOST B (10.6.7.8).  Here we show a little
      complicated example.  From HOST A to HOST B, only old AH is used.
      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
      "AH"/"new AH"/"ESP"/"new ESP".  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>

      and 8 for new-DES-expIV.  Now we choose "MYSECRETMYSECRET",
      "KAMEKAMEKAMEKAMEKAME", "PASSWORD", 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

		SPI=3000
</screen>

      <para>Now, let us setup security association.  Execute &man.setkey.8;
      on both HOST A and B:</para>

      <screen>

^D
</screen>

     <para>Actually, IPsec communication does not process until security policy
     entries are defined.  In this case, you must setup each host.</para>

     <screen>
At A:

        EOF
</screen>

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

      <para>The login will continue just as it would have if a session was
        created using rlogin 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 'yes' 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
        received fingerprint on future login attempts.  The fingerprints

Return to bug 29566