</sect1>

  <sect1 id="securing-freebsd">

    <title>Asegurando FreeBSD</title>

    <indexterm>

      <primary>seguridad</primary>

      <secondary>asegurando FreeBSD</secondary>

    </indexterm>

    <note>

      <title>Comando vs. Protocolo</title>

      <para>A trav&eacute;s de este documento usaremos el texto en <application>

	negrita</application> para referirnos a un comando o aplicaci&oacute;n.

	Esto se utiliza para casos tales como ssh, puesto que es tanto un protocolo

	como un comando.</para>

    </note>

    <para>Las siguientes secciones cubrir&aacute;n los m&eacute;todos para asegurar

      su sistema FreeBSD que fueron mencionados en la <link linkend="security-intro">

      secci&oacute;n anterior</link> a este cap&iacute;tulo.</para>

    <sect2 id="seuring-root-and-staff">

      <title>Asegurando la cuenta <username>root</username> y las cuentas de

	staff</title>

      <indexterm>

	<primary><command>su</command></primary>

      </indexterm>

      <para>Ant&eacute;s que nada, no se preocupe en asegurar las cuentas 

	del staff si aun no ha asegurado la cuenta <username>root</username>.

	La mayor parte de los sistemas tienen asignada una clave de acceso 

	a la cuenta <username>root</username>.  Lo primero que usted debe 

	asumir es que la contrase&ntilde;a <emphasis>siempre</emphasis> 

	comprometida.  Esto no significa que tenga que remover la

	contraseña.  La contraseña es casi siempre necesaria 

	para el acceso a la consola de la computadora.  Esto significa que 

	usted no debe permitir utilizar la contraseña fuera de la consola o 

	igualarla posiblemente con el comando &man.su.1;.  Por ejemplo, 

	cerciorese de que sus ptys sean correctamente especificados como 

	inseguros en el archivo <filename>/etc/ttys</filename> para rechazar 

	conexiones directas a <username>root</username> via <command>telnet

	</command> o <command>rlogin</command>.  Si se usan otros servicios

	tales como <application>sshd</application>, asegurese de que las

	conexiones directas a <username>root</username> esten deshabilitadas.

	Es posible hacer esto editando el fichero <filename>/etc/ssh/sshd_config

	</filename>, asegurando que <literal>PermitRootLogin</literal> este 

	fijado como <literal>NO</literal>.  Considere cada m&eacute;todo de 

	servicio tal como FTP que puede caer a menudo en cracks.  Las

	conexiones directas a <username>root</username> deben ser solamente 

	permitidas fisicamente en la consola de sistema.</para>

      <indexterm>

	<primary><groupname>wheel</groupname></primary>

      </indexterm>

      <para>Por supuesto, como administrador de sistema usted debe poder

	accesar <username>root</username>, nosotros tenemos algunas formas

	de conseguirlo.  Nos aseguraremos de que estas formas tengas 

	autenticaci&oacute;n adicional.  Una de las formas de hacer <username>

	root</username> accesible es agregar cuentas apropiadas del staff al

	grupo <groupname>wheel</groupname> (en <filename>/etc/group</filename>).

	Se permite a los miembros del staff puestos en el grupo <groupname>wheel

	</groupname> usar el comando <command>su</command> para accesar <username>

	root</username>.  Nunca debe dar a miembros del staff acceso nativo a 

	<groupname>wheel</groupname> cuando se crea la cuenta.  Las cuentas del 

	staff deben estar colocadas en grupos de <groupname>staff</groupname>,

	 para despu&eacute;s agregar a aquellos deseados al grupo <groupname>

	wheel</groupname> en el fichero <filename>/etc/group</filename>.  

	Solamente a aquellos que realmente se necesiten en este grupo deben ser

	 agregados.  Es también posible usar un método de 

	autentificaci&oacute;n tal como Kerberos, utilizar el fichero <filename>

	.k5login</filename> en la cuenta <username>root</username> para permitir

	a &man.ksu.1; que <username>root</username> no necesite	a nadie en el 

	grupo <groupname>wheel</groupname>.  Esta puede ser una mejor

	soluci&oacute;n puesto que el meanismo de <groupname>wheel</groupname>

	todav&iacute;a permite al intruso romper <username>root</username>,

	si el intruso ha conseguido quebrar el archivo de contraseñas

	y el grupo del staff.  Mientrás que usar el mecanismo de

	<groupname>wheel</groupname> es mejor que no tener nada en lo absoluto,

	no es necesariamente la opci&oacute;n mas segura.</para>

      <para>Una manera indirecta de asegurar las cuentas del staff y usar el

	acceso a <username>root</username> de ultima instancia es usar un

	m&eacute;todo de acceso alternativo conocido como <quote>starring</quote>.

	Este método marca las contraseñas cifradas con un solo

	<quote><literal>*</literal></quote>.  Este comando pondra al dia el 

	fichero de <filename>/etc/master.passwd</filename> y la base de datos

	de usuario/contraseña para desabilitar los logins con 

	autentificaci&oacute;n de contrase&ntilde;a.</para>

      <para>Una cuenta del staff como esta:</para>

      <programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>

      <para>Debe ser cambiado a:</para>

      <programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/home/local/bin/tcsh</programlisting>

      <para>Este cambio evitar&aacute; que las conexiones normales ocurran, ya que

	la contrase&ntilde;a cifrada nunca coincidir&aacute; con <quote><literal>

	*</literal></quote>.  Habiendo hecho esto, los miembros del staff deber&aacute;n

	usar otros métodos de autentificación como &man.kerberos.1;

	o &man.ssh.1;, usando public/private keys.  Al usar algo como Kereberos,

	uno debe asegurar generalmente las máquinas que corran los 

	servidores Kereberos, asi como también su estación de trabajo.

	Al usar public/private keys con ssh, uno debe asegurar generalmente la

	máquina usada para hacer el login (generalmente una estación

	de trabajo).  Una capa adicional de protección se puede agregar

	a los public/private keys protegiendo con contraseña al momento de 

	crearlo con &man.ssh-keygen.1;.  Pudiendo <quote>marcar</quote> las

	contraseñas de las cuentas del staff también garantiza

	que los miembros del staff pueden solamente accesar el sistema por medio

	de un método seguro.  Esto forza a los miembros del staff a accesar

	el sistema usando solamente formas seguras y conexiones cifradas para

	todas sus sesiones, lo que cierra un hoyo importante usado por muchos

	intrusos.</para>