<!--
     The FreeBSD Documentation Project

     $FreeBSD$
-->

<chapter id="security">
  <chapterinfo>
    <authorgroup>
      <author>
	<firstname>Matthew</firstname>
	<surname>Dillon</surname>
	<contrib>Gran parte de este cap&iacute;tulo ha sido
	tomado del manual de security(7) por </contrib>
      </author>
    </authorgroup>
  </chapterinfo>    

  <title>Seguridad</title>
  <indexterm><primary>seguridad</primary></indexterm>

  <sect1 id="security-synopsis">
    <title>Sin&oacute;psis</title>

    <para>Este cap&iacute;tulo proveera una introducci&oacute;n b&aacute;sica
      a los conceptos de seguridad de sistema y algunos temas avanzados en 
      &os;.  Muchos de los temas se pueden aplicar a la seguridad del sistema
      asi como tambi&eacute;n a la de Internet en general.  Internet ya no es
      un lugar <quote>amistoso</quote> en el cual cada qui&eacute;n desea ser
      un buen vecino.  Asegurar su sistema es imprecindible para proteger sus
      datos, caracter&iacute;stica intelectual, tiempo, y mucho mas de las 
      manos de hackers y similares.</para>

    <para>FreeBSD proporciona un arcenal de utilidades y mecanisimos para
      asegurar la integridad y la seguridad de su sistema y red.</para>

    <para>Despu&eacute;s de leer este cap&iacute;tulo, usted sabr&aacute;:
      </para>

    <itemizedlist>
      <listitem>
	<para>Conceptos b&aacute;sicos de seguridad, con respecto a &os;.
	  </para>
      </listitem>

      <listitem>
	<para>Sobre algunos mecanisimos de encriptaci&oacute;n disponibles en
	  &os;, como <acronym>DES</acronym> y <acronym>MD5</acronym>.</para>
      </listitem>

      <listitem>
	<para>Como instalar <application>KerberosIV</application> en versiones
	  anteriores a 5.0.</para>
      </listitem>

      <listitem>
	<para>Como instalar <application>Kerberos5</application> en versiones
	  posteriores a 5.0.</para>
      </listitem>

      <listitem>
	<para>Como crear cortafuegos usando <acronym>IPFW</acronym>.</para>
      </listitem>

      <listitem>
	<para>Como configurar IPsec y crear un <acronym>VPN</acronym> entre
	  computadoras &os;/&windows;.</para>
      </listitem>

      <listitem>
	<para>Como configurar y usar <acronym>OpenSSH</acronym>,
	  implementaci&oacute;n de <acronym>SSH</acronym> en &os;.</para>
      </listitem>

      <listitem>
	<para>Como configurar y cargar los modulos de extensi&oacute;n de 
	  control de acceso usando TrustedBSD <acronym>MAC</acronym> 
	  Framework.</para>
      </listitem>

      <listitem>
	<para>Que sistema de archivos <acronym>ACL</acronym>s son y como 
	  usarlos.</para>
      </listitem>

      <listitem>
	<para>Como utilizar las publicaciones de advertencias de seguridad en
	  &os;.</para>
      </listitem>

    </itemizedlist>

    <para>Antes de leer este cap&iacute;tulo, usted debe saber:</para>

    <itemizedlist>
      <listitem>
	<para>Conceptos b&aacute;sicos de &os; y el Internet.</para>
      </listitem>
    </itemizedlist>
    
  </sect1>

  <sect1 id="security-intro">
    <title>Introducci&oacute;n</title>

    <para>La seguridad es una funci&oacute;n que comienza y termina con el 
      administrador de sistema.  Mientras que los sistemas multi-usuario
      BSD &unix; tienen una inherente seguridad, el trabajo de construir y
      mantener mecanismos de seguridad adicionales para mantener a los 
      usuarios de manera <quote>honesta</quote> es probablemente una de las 
      unicas tareas del administrador del sistema.  Los sistemas son tan 
      seguros como uno los haga, los problemas de seguridad compiten con la
      necesidad humana de conveniencia.  Los sistemas &unix; en general, son
      capaces de correr una gran cantidad de procesos simult&aacute;neos,
      de los cuales muchos de estos son servidores &ndash; lo que significa
      que entidades externas pueden conectarse y <quote>hablar</quote> con 
      ellos.  Asi como las mini-computadoras del ayer se convirtieron en los
      ahora escritorios de trabajo, y las computadoras se interconectaron,
      la seguridad cada ves se hace un problema mas grande.</para>

    <para>La seguridad es mejor implementada como <quote>cebolla</quote> en
      capas.  Basicamente, lo que se quiere hacer es crear la mayor cantidad
      posible de convenientes capas de seguridad para luego cuidadosamente
      monitorear el sistema para detectar intrusos.  No es conveniente 
      sobreconstruir la seguridad, ya que esta interferira con el aspecto
      de detecci&oacute;n, y la detecci&oacute;n es uno de los mas importantes
      aspectos de cualquier mecanismo de seguridad.  Por ejemplo, no tiene 
      mucho sentido usar los flags de <literal>schg</literal> (ver 
      &man.chflags.1;) en cada sistema binario, ya que mientras este puede
      protejer los binarios temporalmente, hace que el algun cambio hecho
      por un atacante sea dif&iacute;cil de detectar y puede resultar que
      el mecanismo de seguridad no detecte al atacante en lo absoluto.</para>

    <para>La seguridad del sistema depende tambi&eacute;n de estar preparado
      para diferentes formas de ataque, incluyendo intentos de quebrar el 
      sistema, o hacer un sistema inservible, pero no intentos de comprometer
      al usuario <username>root</username> (<quote>quebrar root</quote>). Los
      problemas de seguridad estan separados en diferentes categorias:</para>

    <orderedlist>
      <listitem>
	<para>Ataques de Negaci&oacute;n de servicio (DoS).</para>
      </listitem>

      <listitem>
	<para>Compromisos en cuentas de usuarios.</para>
      </listitem>

      <listitem>
	<para>Compromisos de root por medio de servidores accesibles.</para>
      </listitem>

      <listitem>
	<para>Compromisos de root por medio de cuentas de usuarios.</para>
      </listitem>

      <listitem>
	<para>Creaci&oacute;n de puertas de entrada.</para>
      </listitem>
    </orderedlist>

    <indexterm>
      <primary>Ataques DoS</primary>
      <see>Negaci&oacute;n de servicio (DoS)</see>
    </indexterm>
    <indexterm>
      <primary>security</primary>
      <secondary>Ataques DoS</secondary>
      <see>Negaci&oacute;n de servicio (DoS)</see>
    </indexterm>
    <indexterm><primary>Negaci&oacute;n de servicio (DoS)</primary></indexterm>

    <para>Un ataque de negaci&oacute;n de servicio es una acci&oacute;n que 
      priva al sistema de los recursos requeridos. Generalmente, los ataques 
      DoS son mecanismos de fuerza bruta que intentan quebrar el sistema 
      forzando sus servidores.  Algunos ataques DoS intentan aprovecharse de 
      bugs en la red para quebrar el sistema con un solo paquete. Esto puede 
      ser solucionado aplicando en el kernel una actualizaci&oacute;n que 
      arregle el bug.  Los ataques en servidores muchas veces pueden ser 
      solucionados aplicando opciones apropiadas para limitar la carga del 
      sistema en condiciones adversas.  Los ataques de fuerza bruta en redes 
      son mas complicados.  Los ataques con paquetes enmascarados, por 
      ejemplo, son casi imposible de detener, el cual puede desconectar el 
      sistema de Internet.  Pueden no quebrar el sistema, pero saturaran la 
      conexi&oacute;n a Internet.</para>

  </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> 
	est&aacute; comprometida.  Esto no significa que tenga que
	eliminar la contrase&ntilde;a.  La contrase&ntilde;a es casi siempre 
	necesaria para el acceso a la c&oacute;nsola de la computadora.  Esto
	significa que usted no debe permitir utilizar la contrase&ntilde;a 
	fuera de la c&oacute;nsola o usarla 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> v&iacute;a <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> est&eacute;n deshabilitadas.  Es
	posible hacer esto editando el fichero 
	<filename>/etc/ssh/sshd_config</filename>, asegurando que 
	<literal>PermitRootLogin</literal> est&eacute; fijado como 
	<literal>NO</literal>.  Considere cada m&eacute;todo de acceso
	- Servicios como FTP puedes tener problemas de seguridad.  Las 
	conexiones directas a <username>root</username> deben ser s&oacute;lo
	permitidas f&iacute;sicamente en la c&oacute;nsola de sistema.</para>
      <indexterm>
	<primary><groupname>wheel</groupname></primary>
      </indexterm>

      <para>Por supuesto, como administrador de sistema usted debe poder
	acceder como <username>root</username>, y nosotros tenemos algunas 
	formas de conseguirlo.  Nos aseguraremos de que &eacute;stas formas 
	tengan 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 acceder <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&eacute;n 
	posible usar un m&eacute;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 mecanismo de 
	<groupname>wheel</groupname> todav&iacute;a permite al intruso romper 
	<username>root</username>, si el intruso ha conseguido quebrar el 
	archivo de contrase&ntilde;as y el grupo del staff.  Mientr&aacute;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&eacute;todo marca las 
	contrase&ntilde;as cifradas con un solo 
	<quote><literal>*</literal></quote>.  Este comando actualizar&aacute;
	fichero de <filename>/etc/master.passwd</filename> y la base de datos
	de usuario/contrase&ntilde;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 cambiada 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&eacute;todos de 
	autentificaci&oacute;n como &man.kerberos.1; o &man.ssh.1;, usando 
	pares de claves p&uacute;blicas/privadas.  Al usar algo como 
	Kereberos, uno debe asegurar generalmente las m&aacute;quinas que 
	corran los servidores Kereberos, asi como tambi&eacute;n su 
	estaci&oacute;n de trabajo.  Al usar pares de claves 
	p&uacute;blicas/privadas con ssh, uno debe asegurar generalmente la 
	m&aacute;quina usada para hacer el login (generalmente una 
	estaci&oacute;n de trabajo).  Una capa adicional de protecci&oacute;n
	se puede agregar a los pares de claves
	p&uacute;blicas/privadas protegiendolas con contrase&ntilde;a en el 
	momento de crearlas con &man.ssh-keygen.1;.  Pudiendo 
	<quote>marcar</quote> las contrase&ntilde;as de las cuentas del staff
	tambi&eacute;n garantiza que los miembros del staff solamente pueden 
	acceder al sistema por medio de un m&eacute;todo seguro.  Esto fuerza
	a los miembros del staff a acceder al sistema usando solamente formas
	seguras y conexiones cifradas para todas sus sesiones, lo que
	protege de una de las vulnerabilidades m&aacute;s usadas por
	los intrusos.</para>

</chapter>

<!--      
     Local Variables:
     mode: sgml
     sgml-declaration: "../chapter.decl" 
     sgml-indent-data: t
     sgml-omittag: nil
     sgml-always-quote-attributes: t
     sgml-parent-document: ("../handbook.sgml" "part" "chapter")
     End: 
-->
