<title>Securing User Accounts</title>

      <title>Securing User Accounts</title>

      <para>User accounts are usually the most difficult to secure.  While

      <para>User accounts are usually the most difficult to secure.  While

	<quote>star</quote> out their passwords, you may not be able to

	<quote>star</quote> out their passwords, you may not be able to

	do so with any general user accounts you might have.  If you do

	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

	have sufficient control, then you may win out and be able to secure

	ssh and Kerberos for user accounts is

	ssh and Kerberos for user accounts is

	more problematic, due to the extra administration and technical

	more problematic, due to the extra administration and technical

	support required, but still a very good solution compared to a

	support required, but still a very good solution compared to a

    </sect2>

    </sect2>

    <sect2>

    <sect2>

      <title>Securing the Password File</title>

      <title>Securing the Password File</title>

	passwords as you can and use ssh or

	passwords as you can and use ssh or

	Kerberos for access to those accounts.  Even though the encrypted

	Kerberos for access to those accounts.  Even though the encrypted

	password file (<filename>/etc/spwd.db</filename>) can only be read

	password file (<filename>/etc/spwd.db</filename>) can only be read

	<literal>schg</literal> flag for every system file and directory

	<literal>schg</literal> flag for every system file and directory

	under the sun.  Another possibility is to simply mount

	under the sun.  Another possibility is to simply mount

	<filename>/</filename> and <filename>/usr</filename> read-only.

	<filename>/</filename> and <filename>/usr</filename> read-only.

	protect may prevent the all-important detection of an

	protect may prevent the all-important detection of an

	intrusion.</para>

	intrusion.</para>

    </sect2>

    </sect2>

	The last layer of your security onion is perhaps the most

	The last layer of your security onion is perhaps the most

	important — detection.  The rest of your security is pretty

	important — detection.  The rest of your security is pretty

	much useless (or, worse, presents you with a false sense of

	much useless (or, worse, presents you with a false sense of

	of the onion is to slow down the attacker, rather than stop him, in

	of the onion is to slow down the attacker, rather than stop him, in

	missing, or unexpected files.  The best way to look for modified

	missing, or unexpected files.  The best way to look for modified

	files is from another (often centralized) limited-access system.

	files is from another (often centralized) limited-access system.

	Writing your security scripts on the extra-secure limited-access

	Writing your security scripts on the extra-secure limited-access

	the audit-trail tracks that ssh

	the audit-trail tracks that ssh

	lays.</para>

	lays.</para>

	client systems it is supposed to monitor, you must write scripts

	client systems it is supposed to monitor, you must write scripts

	to do the actual monitoring.  Given an NFS mount, you can write

	to do the actual monitoring.  Given an NFS mount, you can write

	scripts out of simple system utilities such as &man.find.1; and

	scripts out of simple system utilities such as &man.find.1; and

      <para>A good security script will also check for changes to user and

      <para>A good security script will also check for changes to user and

	staff members access configuration files:

	staff members access configuration files:

	<filename>.rhosts</filename>, <filename>.shosts</filename>,

	<filename>.rhosts</filename>, <filename>.shosts</filename>,

	files that might fall outside the purview of the

	files that might fall outside the purview of the

	<literal>MD5</literal> check.</para>

	<literal>MD5</literal> check.</para>

	<literal>nosuid</literal> options (see &man.mount.8;) are what you

	<literal>nosuid</literal> options (see &man.mount.8;) are what you

	want to look into.  You should probably scan them anyway, at least

	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

	once a week, since the object of this layer is to detect a break-in

      <para>Process accounting (see &man.accton.8;) is a relatively

      <para>Process accounting (see &man.accton.8;) is a relatively

	low-overhead feature of the operating system which might help

	low-overhead feature of the operating system which might help

	as a post-break-in evaluation mechanism.  It is especially

	as a post-break-in evaluation mechanism.  It is especially

	useful in tracking down how an intruder has actually broken into

	useful in tracking down how an intruder has actually broken into

      <para>Finally, security scripts should process the log files, and the

      <para>Finally, security scripts should process the log files, and the

	logs themselves should be generated in as secure a manner as

	logs themselves should be generated in as secure a manner as

	possible — remote syslog can be very useful.  An intruder

	possible — remote syslog can be very useful.  An intruder

	sysadmin trying to track down the time and method of the initial

	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

	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

	to run the system console to a serial port and collect the

    </sect2>

    </sect2>

    <sect2>

    <sect2>

	is typically a packet attack.  While there is not much you can do

	is typically a packet attack.  While there is not much you can do

	about modern spoofed packet attacks that saturate your network,

	about modern spoofed packet attacks that saturate your network,

	you can generally limit the damage by ensuring that the attacks

	you can generally limit the damage by ensuring that the attacks

      <orderedlist>

      <orderedlist>

	<listitem>

	<listitem>

	</listitem>

	</listitem>

	<listitem>

	<listitem>

	</listitem>

	</listitem>

      </orderedlist>

      </orderedlist>

	(see &man.inetd.8;) has several

	(see &man.inetd.8;) has several

	options to limit this sort of attack.  It should be noted that

	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

	while it is possible to prevent a machine from going down, it is

	The attacker spoofs ping packets sent to your LAN's broadcast

	The attacker spoofs ping packets sent to your LAN's broadcast

	address with the source IP address set to the actual machine they

	address with the source IP address set to the actual machine they

	wish to attack.  If your border routers are not configured to

	wish to attack.  If your border routers are not configured to

	generating sufficient responses to the spoofed source address to

	generating sufficient responses to the spoofed source address to

	saturate the victim, especially when the attacker uses the same

	saturate the victim, especially when the attacker uses the same

	trick on several dozen broadcast addresses over several dozen

	trick on several dozen broadcast addresses over several dozen

	attacker can saturate a server's incoming network and cause the

	attacker can saturate a server's incoming network and cause the

	server to saturate its outgoing network with ICMP responses.  This

	server to saturate its outgoing network with ICMP responses.  This

	type of attack can also crash the server by running it out of

	type of attack can also crash the server by running it out of

	it generates fast enough.

	it generates fast enough.

	Use the <application>sysctl</application>

	Use the <application>sysctl</application>

	variable <literal>net.inet.icmp.icmplim</literal> to limit these attacks.

	variable <literal>net.inet.icmp.icmplim</literal> to limit these attacks.

      <para>There are a few issues with both Kerberos and

      <para>There are a few issues with both Kerberos and

	ssh that need to be addressed if

	ssh that need to be addressed if

	authentication protocol, but there are bugs in the kerberized

	authentication protocol, but there are bugs in the kerberized

	<application>telnet</application> and

	<application>telnet</application> and

	<application>rlogin</application> applications that make them

	<application>rlogin</application> applications that make them

	<option>-x</option> option.  <application>ssh</application>

	<option>-x</option> option.  <application>ssh</application>

	encrypts everything by default.</para>

	encrypts everything by default.</para>

	respect except that it forwards encryption keys by default.  What

	respect except that it forwards encryption keys by default.  What

	this means is that if you have a secure workstation holding keys

	this means is that if you have a secure workstation holding keys

	that give you access to the rest of the system, and you

	that give you access to the rest of the system, and you

      <para>We recommend that you use ssh in

      <para>We recommend that you use ssh in

	combination with Kerberos whenever possible for staff logins.

	combination with Kerberos whenever possible for staff logins.

	support.  This reduces your reliance on potentially exposed

	support.  This reduces your reliance on potentially exposed

	ssh keys while at the same time

	ssh keys while at the same time

	keys should only be used for automated tasks from secure machines

	keys should only be used for automated tasks from secure machines

	(something that Kerberos is unsuited to do).  We also recommend that

	(something that Kerberos is unsuited to do).  We also recommend that

	you either turn off key-forwarding in the

	you either turn off key-forwarding in the