<?xml version="1.0" encoding="iso-8859-1"?>
<!--
The FreeBSD Documentation Project
The FreeBSD Spanish Documentation Project
%SOURCE% en_US.ISO8859-1/books/handbook/security/chapter.xml
%SRCID% 0.0
$FreeBSD$
-->
<chapter id="security">
<chapterinfo>
<authorgroup>
<author>
<firstname>Matthew</firstname>
<surname>Dillon</surname>
<contrib>Gran parte del contenido de este capítulo
procede de la página de manual de security(7), de </contrib>
</author>
</authorgroup>
</chapterinfo>
<title>Seguridad</title>
<indexterm><primary>seguridad</primary></indexterm>
<sect1 id="security-synopsis">
<title>Sinopsis</title>
<para>Este capítulo contiene una introducción
básica a los conceptos de seguridad del sistema, unas
cuantas normas básicas de uso y algunos avanzados del
tema en &os;. Muchos de los temas expuestos se aplican a la
seguridad del sistema y de Internet en general.
Internet ya no es aquél lugar <quote>amistoso</quote>
en el que todo el mundo se comportaba como un buen ciudadano.
Si quiere proteger sus datos, su propiedad intelectual, su tiempo
y muchas más cosas de manos malintencionadas debe hacer
que su sistema sea seguro.</para>
<para>&os; proporciona un variado arsenal de utilidades y mecanismos para
asegurar la integridad y la seguridad de su sistema y red.</para>
<para>Después de leer este capítulo:
</para>
<itemizedlist>
<listitem>
<para>conocerá conceptos básicos de la seguridad
relacionados con &os;.
</para>
</listitem>
<listitem>
<para>Tendrá información sobre los diversos mecanismos
de cifrado disponibles en &os;, entre los cuales están
<acronym>DES</acronym> y <acronym>MD5</acronym>.
</para>
</listitem>
<listitem>
<para>Sabrá cómo configurar la autentificación
de contraseñas de un solo uso.</para>
</listitem>
<listitem>
<para>Sabrá cómo configurar <acronym>TCP</acronym>
Wrappers y usarlos con
<command>inetd</command>.</para>
</listitem>
<listitem>
<para>Sabrá cómo instalar
<application>KerberosIV</application> en versiones de &os;
anteriores a 5.0.</para>
</listitem>
<listitem>
<para>Sabrá cómo instalar
<application>Kerberos5</application> en versiones de &os;
posteriores a 5.0.</para>
</listitem>
<listitem>
<para>Podrá configurar IPsec y crear una
<acronym>VPN</acronym> entre
máquinas &os;/&windows;.</para>
</listitem>
<listitem>
<para>Sabrá cómo configurar y utilizar
<application>OpenSSH</application>,
la implementación de <acronym>SSH</acronym> en &os;.</para>
</listitem>
<listitem>
<para>Sabrá en qué consisten las
<acronym>ACL</acronym> del sistema de ficheros y cómo
utilizarlas.</para>
</listitem>
<listitem>
<para>Sabrá cómo usar
<application>Portaudit</application>, con la que podrá
auditar el software que instale desde la
desde la colección de ports.</para>
</listitem>
<listitem>
<para>Sabrá cómo sacar partido de los avisos de
seguridad que publica &os;.</para>
</listitem>
<listitem>
<para>Podrá hacerse una idea clara de en qué consiste
la contabilidad de procesos y de cómo activarla en
&os;.</para>
</listitem>
</itemizedlist>
<para>Antes de leer este capítulo:</para>
<itemizedlist>
<listitem>
<para>Comprender conceptos básicos de &os; e Internet.</para>
</listitem>
</itemizedlist>
<para>En otras secciones de este manual se cubren aspectos adicionales
sobre seguridad. Por ejemplo, MAC (controles de acceso obligatorio)
se explica en el <xref
linkend="mac"/> y los cortafuegos en el
<xref linkend="firewalls"/>.</para>
</sect1>
<sect1 id="security-intro">
<title>Introducción</title>
<para>La seguridad es un trabajo que que comienza y termina en el
administrador de sistema. Aunque que los sistemas multiusuario
BSD &unix; posean una seguridad inherente, el trabajo de construir y
mantener mecanismos de seguridad adicionales para que los
usuarios sean aún más <quote>honestos</quote> es
probablemente una de las mayores tareas de la administración
de sistemas. Los sistemas son tan seguros como uno los haga, y
no hay que olvidar que los problemas de seguridad compiten con la
comodidad a la que tendemos los humanos. Los sistemas &unix;
son capaces de ejecutar una gran cantidad de procesos
simultáneamente, muchos de los cuales son servidores, lo que
significa que las entidades externas pueden conectarse y
<quote>hablar</quote> con ellos. Del mismo modo que las
minicomputadoras de ayer se convirtieron en los sistemas de
escritorio de hoy en día, la seguridad se va convirtiendo
en un problemas más y más acuciante.</para>
<para>La seguridad bien entendida se implementa en capas, a la manera de
una <quote>cebolla</quote>. Básicamente lo que se hace es
crear la mayor cantidad posible de capas de seguridad, para más
tarde monitorizar el sistema en busca de intrusos. No es conveniente
exagerar la seguridad, ya que interferiría con la
detección, y la detección es uno de los aspectos
más importantes de cualquier mecanismo de seguridad.
Por ejemplo, no tiene mucho sentido activar la bandera
<literal>schg</literal> (consulte &man.chflags.1;) en cada binario del
sistema, ya que aunque protegería en cierto modo los binarios,
haría que cualquier cambio que pudiera realizar un atacante
una vez dentro del sistema fuera más difícil de detectar
o incluso hacerlo del todo imposible.</para>
<para>La seguridad del sistema depende también de estar preparados
para distintos tipos de ataque, incluyendo intentos de
<quote>tirar</quote> la máquina o dejarla en un estado
inutilizable, pero que no impliquen intentos de comprometer el usuario
<username>root</username> Los problemas de seguridad pueden
dividirse en diferentes categorías:</para>
<orderedlist>
<listitem>
<para>Ataques de denegación de servicio (DoS).</para>
</listitem>
<listitem>
<para>Comprometer cuentas de usuarios.</para>
</listitem>
<listitem>
<para>Comprometer root a través de servidores accesibles.
</para>
</listitem>
<listitem>
<para>Comprometer root desde cuentas de usuario.</para>
</listitem>
<listitem>
<para>Creación de puertas traseras
(<quote>Backdoors</quote>).</para>
</listitem>
</orderedlist>
<indexterm>
<primary>Ataques DoS</primary>
<see>Denegación de servicio (DoS)</see>
</indexterm>
<indexterm>
<primary>seguridad</primary>
<secondary>Ataques DoS</secondary>
<see>Denegación de servicios (DoS)</see>
</indexterm>
<indexterm><primary>Denegacion de servicio (DoS)</primary></indexterm>
<para>Un ataque de denegación de servicio es una acción que
priva al sistema de los recursos requeridos para su funcionamiento
normal. Generalmente, los ataques DoS son mecanismos de fuerza bruta
que intentan <quote>tumbar</quote> el sistema o hacerlo inutilizable
sobrecargando la capacidad de sus servidores o de la pila de red.
Algunos ataques DoS intentan aprovechar errores en la pila de red
para <quote>tumbar</quote> el sistema con un solo paquete.
Estos últimos únicamente pueden solucionarse aplicando
al kernel una actualización que subsane el error.
Los ataques a servidores muchas veces pueden solucionarse configurando
las opciones apropiadas para limitar la carga del sistema en
condiciones adversas. Los ataques de fuerza bruta a redes
son más complicados. Los ataques con paquetes enmascarados,
por ejemplo, son casi imposibles de detener, a menos que desconecte
el sistema de Internet. Puede ser que no <quote>tiren</quote> el
sistema, pero saturarán la conexión a Internet.</para>
<indexterm>
<primary>seguridad</primary>
<secondary>compromiso de cuentas</secondary>
</indexterm>
<para>Comprometer una cuenta de usuario es mucho más común
que un ataque DoS. Muchos administradores de sistemas
todavía ejecutan servidores estándar
<application>telnetd</application>, <application>rlogind</application>,
<application>rshd</application> y <application>ftpd</application> en
sus máquinas.
Estos servidores, por defecto no operan a través de conexiones
cifradas. El resultado es que se si se tiene una base de usuarios de
tamaño medio, tarde o temprando la contraseña de uno
(o más) de sus usuarios será descubierta durante
sus accesos al sistema desde ubicaciones remotas.(que es, por otra
parte, la forma más común y más cómoda
de acceder a un sistema). El administrador de sistemas atento
analizará sus logs de acceso remoto en busca de direcciones
origen spspechosas, incluso entre los accesos al sistema.</para>
<para>Se debe asumir <emphasis>siempre</emphasis> que, una vez que
el atacante tiene acceso a una cuenta de usuario, el atacante
puede comprometer la cuenta <username>root</username>. En realidad
en un sistema bien mantenido y asegurado el acceso a una cuenta de
usuario no necesariamente da al atacante acceso a
<username>root</username>. Esta precisión es importante
porque sin acceso a <username>root</username> el atacante
difícilmente podrá esconder sus huellas; podrá,
como mucho, hacer poco más que sembrar el caos en los ficheros
del usuario o <quote>tirar</quote> la máquina.
Comprometer cuentas de usuario es muy común porque los
usuarios tienden a no tomar las precauciones que toma el
administrador.</para>
<indexterm>
<primary>seguridad</primary>
<secondary>puertas traseras</secondary>
</indexterm>
<para>Los administradores de sistemas deben tener presente que
existen muchas formas potenciales de comprometer la cuenta
<username>root</username> de una máquina. El atacante puede
conocer la contraseña de <username>root</username>, el
atacante puede encontrar un error en un servidor que se ejecuta
como root y ser capaz de comprometer <username>root</username> a
través de una conexión de red a ese servidor; puede
ser que el atacante sepa de la existencia de un error en un
programa suid-root que le permita comprometer
<username>root</username> una vez dentro de una cuenta de usuario.
Si un atacante encuentra la manera de comprometer la cuenta
<username>root</username> de una máquina puede que no
necesite instalar una puerta trasera. Muchos de
los agujeros <username>root</username> encontrados y cerrados hasta
la fecha implican una cantidad considerable de trabajo para el atacante
limpiando todo después del ataque, así que
la mayoría de los atacantes instalan puertas traseras.
Una puerta trasera facilita al atacante una forma sencilla de
recuperar el acceso de <username>root</username> al sistema,
pero también proporciona al administrador de sistemas
inteligente una forma de detectar la intrusión. Si hace
imposible a un atacante la instalación de una puerta
trasera puede estar actuando en detrimento de su seguridad, porque
no cerrará el agujero que el atacante encontró
para accder al sistema la primera vez que lo hizo.</para>
<para>Las medidas de seguridad se implementan en un modelo
multicapa (tipo <quote>cebolla</quote>), que puede categorizarse
del siguiente modo:</para>
<orderedlist>
<listitem>
<para>Asegurar <username>root</username> y cuentas
administrativas.</para>
</listitem>
<listitem>
<para>Asegurar los servidores que se ejecuten como
<username>root</username> los binarios suid/sgid.</para>
</listitem>
<listitem>
<para>Asegurar cuentas de usuario.</para>
</listitem>
<listitem>
<para>Asegurar el fichero de contraseñas.</para>
</listitem>
<listitem>
<para>Asegurar el núcleo del kernel, los dispositivos
en bruto y el sistema de ficheros.</para>
</listitem>
<listitem>
<para>Detección rápida de cambios
hechos al sistema.</para>
</listitem>
<listitem>
<para>Paranoia.</para>
</listitem>
</orderedlist>
<para>La siguiente sección de este capítulo tratará
los puntos de arriba con mayor profundidad.</para>
</sect1>
<sect1 id="securing-freebsd">
<title>Asegurar &os;</title>
<indexterm>
<primary>seguridad</primary>
<secondary>asegurar &os;</secondary>
</indexterm>
<note>
<title>Orden vs. protocolo</title>
<para>En este capítulo usaremos el texto en
<application>negrita</application> para referirnos a una orden o
aplicación, y una fuente en <command>cursiva</command> para
referirnos a órdenes específicas. Usaremos un tipo normal
para los protocolos. Esta diferencia tipográfica nos
será útil por ejemplo con ssh, que es tanto un
protocolo como una orden.</para>
</note>
<para>Las siguientes secciones cubren los métodos a seguir para
asegurar su sistema &os; que se mencionados en la
<link linkend="security-intro"> sección anterior</link> de este
capítulo.</para>
<sect2 id="securing-root-and-staff">
<title>Asegurar la cuenta <username>root</username> y las
cuentas administrativas</title>
<indexterm>
<primary><command>su</command></primary>
</indexterm>
<para>En primer lugar, no se moleste en asegurar las cuentas
administrativas (o <quote>staff</quote>) si no ha asegurado la
cuenta <username>root</username>.
La mayoría de los sistemas tienen una contraseña
asignada para la cuenta <username>root</username>. Lo primero que
se hace es asumir que la contraseña está
<emphasis>siempre</emphasis> amenazada.
Esto no significa que deba eliminar la contraseña. La
contraseña es casi siempre necesaria para el acceso por
consola a la máquina; significa que no se debe permitir
el uso de la contraseña fuera de la consola o, mejor
aún, mediante &man.su.1;. Por ejemplo,
asegúrese de que sus ptys aparezcan como
<emphasis>inseguras</emphasis> en el fichero
<filename>/etc/ttys</filename>, con lo que hará que
los accesos como <username>root</username> vía
<command>telnet</command> o <command>rlogin</command> no sean
posibles.
Si utiliza otros tipos de login como
<application>sshd</application> asegúrese de que
los accesos al sistema como <username>root</username>
estén también deshabilitados.
Para ello edite su
<filename>/etc/ssh/sshd_config</filename> y asegúrese de
que <literal>PermitRootLogin</literal> esté puesto a
<literal>NO</literal>. Estudie cada método de acceso:
hay servicios como FTP que frecuentemente son origen de grietas
en la estructura del sistema. El acceso directo como usuario
<username>root</username> sólamente debe permitirse
a través de la consola.</para>
<indexterm>
<primary><groupname>wheel</groupname></primary>
</indexterm>
<para>Es evidente que, como administrador del sistema, debe usted
tener la posibilidad de acceder a <username>root</username>,
así que tendrá que abrir algunos agujeros, pero
debe asegurarse de que estos agujeros necesiten contraseñas
adicionales para verificar su correcto uso. Puede hacer
que <username>root</username> sea accesible añadiendo
cuentas administrativas al grupo
<groupname>wheel</groupname> (en
<filename>/etc/group</filename>). El personal que administra los
sistemas que aparezcan en el grupo
en el grupo <groupname>wheel</groupname> pueden hacer
<command>su</command> a <username>root</username>.
Nunca debe de proporcionar al personal administrativo el acceso
nativo a <groupname>wheel</groupname> poniéndolos
en el grupo <groupname>wheel</groupname> en su entrada de
contraseña. Las cuentas administrativas deben colocarse
en un grupo <groupname>staff</groupname>, y agregarse
después al grupo <groupname>wheel</groupname> en
<filename>/etc/group</filename>. Sólo aquellos
administradores que realmente necesiten acceder a
<username>root</username> deben pertenecer al grupo
<groupname>wheel</groupname>. También es posible,
mediante un método de autentificación como
Kerberos, usar el fichero <filename>.k5login</filename> en
la cuenta <username>root</username> para permitir un
&man.ksu.1; a <username>root</username> sin tener que
colocar a nadie en el grupo
<groupname>wheel</groupname>. Puede ser una mejor solución,
ya que el mecanismo <groupname>wheel</groupname> aún
permite a un atacante comprometer <username>root</username>
si el intruso ha conseguido el fichero de contraseñas
y puede comprometer una cuenta de administración.
Recurrir al mecanismo <groupname>wheel</groupname> es mejor que
no tener nada, pero no es necesariamente la opción
más segura.</para>
<!-- XXX:
This will need updating depending on the outcome of PR bin/71147.
Personally I know what I'd like to see, which puts this in definite
need of a rewrite, but we'll have to wait and see. ceri@
-->
<para>Una manera indirecta de asegurar las cuentas de staff y
el acceso a <username>root</username> es utilizar un método
de acceso alternativo: es lo que se conoce como
<quote>estrellar</quote> las contraseñas cifradas de las
cuentas administrativas. Use &man.vipw.8; para reemplazar
cada contraseña cifrada por un sólo caracter
asterisco (<quote><literal>*</literal></quote>). Esto
actualizará
<filename>/etc/master.passwd</filename> y la base de datos de
usuario/contraseña y deshabilitará los accesos
al sistema validados mediante
contraseñas.</para>
<para>Veamos una cuenta administrativa típica:</para>
<programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
<para>y cómo debería quedar:</para>
<programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
<para>Este cambio evitará que se efectúen logins normales,
ya que la contraseña cifrada nunca se corresponderá
con <quote><literal>*</literal></quote>. Hecho esto, el personal
de administración tendrá que usar otro mecanismo
de validación como &man.kerberos.1; o
&man.ssh.1; que use un par de llave pública/privada.
Si decide usar algo como Kerberos tendrá que asegurar
la máquina que ejecuta los servidores Kerberos
y su estación de trabajo. Si usa un par de llave
pública/privada con ssh, debe asegurar la
máquina <emphasis>desde</emphasis> desde la que se hace el
login (normalmente nuestra estación de trabajo). Puede
añadir una capa adicional de protección al par de
llaves protegiéndolas con contraseña al crearlo
con &man.ssh-keygen.1;.
El <quote>estrellado</quote> de las contraseñas
administrativas también garantiza que dicho personal
sólo pueda entrar a través de métodos de
acceso que haya usted configurado. Así obligará
al personal administrativo a usar conexiones seguras, cifradas,
en todas sus sesiones, lo que cierra un importante agujero
de seguridad al que recurren muchos intrusos: usar un
sniffer (olfateador) de red desde una máquina que le
permita hacer tal cosa.</para>
<para>Los mecanismos de seguridad más indirectos también
asumen que está validando su identidad desde un servidor
más restrictivo un servidor menos restrictivo.
Por ejemplo, si su máquina principal ejecuta toda clase de
servidores su estación de trabajo no debe ejecutar ninguno.
Para que su estación de trabajo sea razonablemente segura
debe ejecutar los mínimos servidores posibles, si es posible
ninguno, y debe usar un salvapantallas protegido por
contraseña. Es evidente que un atancante con acceso
físico al sistema puede romper cualquier barrera de seguridad
que se disponga. Es un problema a tener en cuenta, pero la
mayoría de las intrusiones tienen lugar de forma remota,
a través de la red, por parte de gente que no tiene acceso
físico a su estación de trabajo ni a sus
servidores.</para>
<indexterm><primary>KerberosIV</primary></indexterm>
<para>Usar Kerberos le ofrece también el poder
de deshabilitar o cambiar la contraseña para una cuenta
administrativa en un lugar, y que tenga un efecto inmediato en todas
las máquinas en las cuales ese administrador pueda
tener una cuenta. Si una de esas cuentas se ve comprometida
la posibilidad para cambiar instantáneamente su
contraseña en todas las máquinas no debe ser
desestimada. Con contraseñas distintas, el cambio
de una contraseña en N máquinas puede ser un
problema. También puede imponer restricciones de
re-contraseñas con Kerberos: no sólo se puede
hacer un ticket de Kerberos que expire después de un
tiempo, sino que el sistema Kerberos puede requerir al usuario
que escoja una nueva contraseña después de cierto
tiempo (digamos una vez al mes).</para>
</sect2>
<sect2>
<title>Asegurar servidores que se ejecutan como
<username>root</username>
y binarios SUID/SGID</title>
<indexterm>
<primary><command>ntalk</command></primary>
</indexterm>
<indexterm>
<primary><command>comsat</command></primary>
</indexterm>
<indexterm>
<primary><command>finger</command></primary>
</indexterm>
<indexterm>
<primary>cajas de arena <quote>sandboxes</quote></primary>
</indexterm>
<indexterm>
<primary><application>sshd</application></primary>
</indexterm>
<indexterm>
<primary><application>telnetd</application></primary>
</indexterm>
<indexterm>
<primary><application>rshd</application></primary>
</indexterm>
<indexterm>
<primary><application>rlogind</application></primary>
</indexterm>
<para>Un administrador de sistemas prudente sólo
ejecutará los servidores que necesita, ni uno más
ni uno menos. Dese cuenta de que los servidores ajenos son
los más propensos a contener errores. Por ejemplo,
ejecutando una versión desfasada de
<application>imapd</application> o
<application>popper</application> es como dar una entrada universal
de <username>root</username> al mundo entero.
Nunca ejecute un servidor que no haya revisado cuidadosamente.
Muchos servidores no necesitan ejecutarse como
<username>root</username>. Por ejemplo, los dæmons
<application>ntalk</application>,
<application>comsat</application> y
<application>finger</application> pueden ejecutarse en una
<firstterm>caja de arena (sandbox)</firstterm> especial de usuario.
Una caja de arena no es perfecta, a menos que pase por muchos
problemas, pero la aproximación de cebolla a la seguridad
prevalece aún y todo: Si alguien es capaz de penetrar a
través de un servidor ejecutándose en una caja
de arena, todavía tendrá que salir de la caja de
arena. Cuantas más capas tenga que romper el atacante
menor será la posibilidad de éxito que tenga.
Se han encontrado vías de entrada a
<username>root</username> en virtualmente todos los servidores
que se haya ejecutado como <username>root</username>,
incluyendo servidores básicos del sistema.
Si está tiene una máquina a través de
la cual la gente sólo entra por
<application>sshd</application>, y nunca entra por
<application>telnetd</application>,
<application>rshd</application>, o
<application>rlogind</application>
<emphasis>apague esos servicios</emphasis>.</para>
<para>&os; ejecuta por defecto
<application>ntalkd</application>,
<application>comsat</application> y
<application>finger</application> en una caja de arena.
Otro programa que puede ser candidato para ejecutarse en una
caja de arena es &man.named.8;.
<filename>/etc/defaults/rc.conf</filename> contiene las directrices
necesarias (con comentarios) para usar <application>named</application>
en una caja de arena. Dependiendo de si
está instalando un nuevo sistema o actualizando un sistema
ya existente, las cuentas especiales de usuario que usan
estas cajas de arena puede que no estén instaladas.
El administrador de sistemas prudente debe investigar e
implementar cajas de arena para servidores siempre que sea
posible.</para>
<indexterm>
<primary><application>sendmail</application></primary>
</indexterm>
<para>Existen numerosos servidores que no se suelen
ejecutar en cajas de arena:
<application>sendmail</application>,
<application>imapd</application>, <application>ftpd</application>,
y otros. Existen alternativas para algunos de ellos, pero
instalarlas puede requerir más trabajo del que tal vez
esté dispuesto a realizar (el factor comodidad ataca de
nuevo). Tal vez tenga que ejecutar estos servidores como
<username>root</username> y depender de otros mecanismos para
detectar intrusiones que puedan tener lugar a través de
ellos.</para>
<para>Los otros grandes agujeros potenciales de
<username>root</username> que encontramos en un sistema son los
binarios suid-root y sgid. La mayoría
de estos binarios, como <application>rlogin</application>,
están en <filename>/bin</filename>, <filename>/sbin</filename>,
<filename>/usr/bin</filename> o <filename>/usr/sbin</filename>.
Aunque no hay nada absolutamente seguro los binarios suid y sgid
del sistema por defecto pueden considerarse razonablemente
seguros. Aún así, de vez en cuando aparecen
agujeros <username>root</username> en estos binarios.
En 1998 se encontró un agujero
<username>root</username> en
<literal>Xlib</literal>, que hacía a
<application>xterm</application> (que suele ser suid)
vulnerable. Es mejor prevenir que curar, y el administrador de
sistemas prudente restringirá los binarios suid, que
sólo el personal de administración debe ejecutar,
a un grupo especial al que sólo dicho personal pueda acceder,
y deshacerse de cualquier binario suid
(<command>chmod 000</command>) que no se use.
Un servidor sin pantalla generalmente no necesita un binario
<application>xterm</application>. Los binarios sgid pueden ser
igual de peligrosos. Si un intruso logra comprometer un binario
sgid-kmem, el intruso podría leer
<filename>/dev/kmem</filename> y llegar a leer el fichero
cifrado de contraseñas, poniendo en compromiso potencial
cualquier cuenta con contraseña. Por otra parte, un intruso
que comprometa el grupo <literal>kmem</literal> puede monitorizar
las pulsaciones de teclado que se envien a través de ptys,
incluyendo las ptys a las que acceden usuarios que emplean
métodos seguros. Un intruso que comprometa el grupo
<groupname>tty</groupname> puede escribir en la pty de casi
cualquier usuario. Si un usuario ejecuta un programa de terminal
o un emulador capaz de simular un teclado, el intruso podría
generar un flujo de datos que provoque que la terminal del
usuario muestre una orden en pantalla, orden que el usuario
ejecutará.</para>
</sect2>
<sect2 id="secure-users">
<title>Asegurar las cuentas de usuario</title>
<para>Las cuentas de usuario suelen ser las más
difíciles de asegurar. Aunque puede imponer restricciones
de acceso draconianas a su personal administrativo y
<quote>estrellar</quote> sus contraseñas, tal vez no pueda
hacerlo con todas las cuentas de todos sus usuarios. Si mantiene
el control en un grado suficiente quizás lo logre y sea
capaz de hacer que las cuentas de sus usuarios sean seguras. Si no,
tendrá que ser más cuidadoso (aún) en la
monitorización de esas cuentas. Usar ssh y Kerberos en
cuentas de usuario da más problemas debido al soporte
técnico y administrativo que requerirá, pero sigue
siendo mejor solución que un fichero de
contraseñas cifradas.</para>
</sect2>
<sect2>
<title>Asegurar el fichero de contraseñas</title>
<para>La única manera segura es ponerle <literal>*</literal>
a tantas contraseñas como sea posible y utilizar ssh o
Kerberos para acceder a esas cuentas. Aunque el fichero
cifrado de contraseñas (<filename>/etc/spwd.db</filename>)
sólo puede ser legible para <username>root</username>, puede
que un intruso consiga acceso de lectura a ese fichero, incluso sin
haber alcanzado el acceso de escritura como root.</para>
<para>Sus <quote>scripts</quote> de seguridad deben buscar siempre
cambios en el fichero de contraseñas
(consulte <link linkend="security-integrity">Revisión de
integridad de ficheros</link> más abajo) e informar de
ellos.</para>
</sect2>
<sect2>
<title>Asegurar el Kernel, dispositivos en bruto y el sistema
sistema de ficheros</title>
<para>Si un atacante compromete <username>root</username> puede
hacer cualquier cosa, pero hay ciertas cosas que puede usted
preparar para <quote>curarse en salud</quote>. Por ejemplo,
la mayoría de los kernel modernos tienen un dispositivo
de los Kernels modernos tienen un integrado un
dispositivo de paquetes. En &os; se llama
<devicename>bpf</devicename>. Un intruso típico
tratará de ejecutar un <quote>sniffer</quote> de paquetes
en una máquina comprometida. No debería darle a
ese intruso tal recurso, y la mayoría de los sistemas no
necesitan el dispositivo
<devicename>bpf</devicename>.</para>
<indexterm>
<primary><command>sysctl</command></primary>
</indexterm>
<para>Pero si desactiva el dispositivo <devicename>bpf</devicename>
todavía tendrá que preocuparse por
<filename>/dev/mem</filename> y
<filename>/dev/kmem</filename>.
Desde ellos el intruso podría en dispositivos de disco
en bruto. También hay que tener muy en cuenta
una opción del kernel llamada cargador de módulos,
&man.kldload.8;. Un intruso con iniciativa puede usar un
módulo KLD para instalar su propio dispositivo
<devicename>bpf</devicename>, u otro dispositivo
que le permita el <quote>sniffing</quote> en un kernel en
ejecución. Para prevenir estos problemas debe ejecutar el
kernel en un nivel de seguridad mayor, al menos en securelevel 1.
Puede configurar el securelevel mediante una <command>sysctl</command>
en la variable <varname>kern.securelevel</varname>.
Una vez que tiene su securelevel a 1, los accesos de
escritura a dispositivos en bruto se
denegarán y se impondrán las banderas especiales
<literal>schg</literal>.
También debe cerciorarse de activar la bandera
<literal>schg</literal> en binarios críticos para el arranque,
directorios y scripts (dicho de otro modo, todo aquello que se
ejecuta <emphasis>antes</emphasis> de que se active el
securelevel). Puede ser que todo esto sea una exageración,
sobre todo teniendo en cuenta que la actualización del sistema
se complica bastante a medida que se incrementa el nivel de
seguridad. Puede ejecutar el sistema a un nivel de seguridad
superior pero no activar la bandera <literal>schg</literal>
en cada fichero y directorio del sistema. Otra posibilidad es
montar <filename>/</filename> y <filename>/usr</filename> como
sólo lectura. Recuerde que siendo demasiado draconiano
en aquello que busca proteger puede dificultar mucho la
detección de una intrusión.</para>
</sect2>
<sect2 id="security-integrity">
<title>Revisión de integridad de ficheros: binarios,
ficheros de configuración, etc.</title>
<para>Cuando se piensa de proteccón, sólo se puede
proteger la configuración central del sistema y los ficheros
de control hasta el momento en el que el factor comodidad salta
a la palestra. Por ejemplo, si usa
<command>chflags</command> para activar el bit <literal>schg</literal>
en la mayoría de los ficheros de <filename>/</filename>
y <filename>/usr</filename> probablemente sea contraproducente;
puede proteger los ficheros haciéndolo, pero también
cierra una vía de detección. La última capa
de su modelo de seguridad tipo cebolla es quizás la
más importante: la detección. El resto de su
estructura de seguridad será inútil (o peor
aún, le proporcionará un sentimiento de seguridad
totalmente infundado) si no puede detectar posibles intrusiones.
La mitad del trabajo de la cebolla es alentar al atacante, en lugar
de detenerlo, para darle a la parte de la ecuación de
detección una oportunidad de atraparlo con las manos en la
masa.</para>
<para>La mejor manera de detectar una intrusión es buscar
ficheros modificados, perdidos, o cuya presencia o estado sea
inesperado. La mejor forma de buscar ficheros modificados es
desde otro sistema (que muchas veces es centralizado) con acceso
restringido.
Escribir sus <quote>scripts</quote> de seguridad en un sistema
<quote>extraseguro</quote> y con acceso restringido los hace casi
invisibles a posibles atacantes, y esto es algo muy importante.
potenciales, y esto es importante. Para poderle sacar el
máximo partido debe proporcionar a esa máquina con
acceso restringido un acceso preferente al contenido de las otras
máquinas de su entorno; suele hacerse mediante la
importación vía NFS de sólo lectura de las
demás máquinas, o configurando pares de llaves ssh
para acceder a las otras máquinas desde la que tiene el
acceso restringido. Si exceptuamos el tráfico de red, NFS
es el método menos visible y le permite monitorizar los
sistemas de ficheros de cada máquina cliente de forma
prácticamente indetectable. Si su servidor de acceso
restringido está conectado a las máquinas clientes
a través de un concentrador o a través de varias
capas de encaminamiento el método NFS puede ser muy inseguro,
por lo que ssh puede ser la mejor opción, incluso con
las huellas de auditoría que ssh va dejando.</para>
<para>Una vez que le da a una máquina de acceso restringido
(al menos) acceso de lectura a los sistemas cliente que va
a monitorizar, tendrá que escribir <quote>scripts</quote>
para efectuar la monitorización. Si va a usar un montaje
NFS puede escribir <quote>scripts</quote> utilizando simples
herramientas del sistema como
&man.find.1; y &man.md5.1;. Es aconsejable ejecutar MD5
físicamente en los ficheros de las máquinas cliente
al menos una vez al día, y comprobar los ficheros de control
(los que hay en <filename>/etc</filename> y
<filename>/usr/local/etc</filename>) con una frecuencia incluso
mayor. Si aparecen discrepancias al compararlos con la
información basada en MD5 que la máquina de acceso
restringido usa como base debe hacer una comprobación
inmediata y profunda. Un buen <quote>script</quote> también
debe buscar binarios que sean suid sin razón aparente, y
ficheros nuevos o borrados en particiones del sistema como
<filename>/</filename> y <filename>/usr</filename>.</para>
<para>Si usa ssh en lugar de NFS será mucho más
complicado escribir el <quote>script</quote> de seguridad.
En esencia, tiene que pasar por <command>scp</command> los
<quote>scripts</quote> a la máquina cliente para poder
ejecutarlos, haciéndolos visibles; por seguridad,
también tendrá que pasar vía
<command>scp</command> los binarios (por ejemplo find) que
utilizan dichos <quote>scripts</quote>. El cliente
<application>ssh</application> de la máquina cliente
puede estar ya bajo el control del intruso. Con todo y con eso,
puede ser necesario usar ssh si trabaja sobre enlaces inseguros,
también es mucho más difícil de manejar.</para>
<para>Un buen <quote>script</quote> de seguridad buscará
también cambios en la configuración de los ficheros
de acceso de usuarios y miembros del personal de
administración:
<filename>.rhosts</filename>, <filename>.shosts</filename>,
<filename>.ssh/authorized_keys</filename>, etc; en resumen,
ficheros fuera del rango de revisión
<literal>MD5</literal>.</para>
<para>Si tiene que vérselas con una cantidad enorme de
espacio en disco para usuarios le llevará mucho tiempo
recorrer cada fichero de cada partición. En su caso
sería una buena idea configurar mediante opciones de
montaje la deshabilitación de binarios y dispositivos
suid en esas particiones. Revise las opciones
<literal>nodev</literal> y <literal>nosuid</literal> de
&man.mount.8;. Debería comprobarlos de todas maneras
al menos una vez por semana, ya que el objeto de esta capa es
detectar intrusiones, efectivas o no.</para>
<para>La contabilidad de procesos (vea &man.accton.8;) es una
opción con una carga relativamente ligera para el sistema
operativo, y puede ayudarle como mecanismo de
evaluación tras una intrusión. Es especialmente
útil para rastrear cómo consiguión realmente
acceder el intruso al sistema (asumiendo que el fichero
esté intacto después de la intrusión).</para>
<para>Los <quote>scripts</quote> de seguridad deben procesar los
logs, y los propios logs deben generarse de la forma más
segura posible: un syslog remoto puede ser muy
útil. Un intruso trata de cubrir sus huellas, los logs
son un recurso crítico cuando el administrador de sistemas
intenta determinar la hora y el método de la intrusión
inicial. La ejecución de la consola del sistema en un
puerto serie y recolectar la información de forma
periódica en una máquina segura de
monitorización de consolas es una forma de cumplir esta
tarea.</para>
</sect2>
<sect2>
<title>Paranoia</title>
<para>Un poco de paranoia nunca está de más.
Como norma, un administrador de sistemas puede añadir
cualquier tipo de mecanismo de seguridad siempre y cuando no
afecte a la comodidad, y puede añadir mecanismos de seguridad
que <emphasis>sí</emphasis> afecten a la comodidad
si tiene una buena razón para hacerlo. Más
aún, un administrador de seguridad debe mezclar
un poco de ambas cosas: si sigue al pie de la letra las
recomendaciones que se dan en este documento también
está sirviendo en bandeja de plata al posible atancante
su metodología. Ese posible atacante también
tiene acceso a este documento.</para>
</sect2>
<sect2>
<title>Ataques de denegación de servicio</title>
<indexterm><primary>Ataques de denegación de
servicio (DoS)</primary></indexterm>
<para>Esta sección cubre ataques de denegación de
servicio. Un ataque DoS suele consistir en un ataque mediante
paquetes. NO hay mucho que pueda hacerse contra un ataque
mediante paquetes falsificados (<quote>spoofed</quote>) que busque
saturar su red, pero puede limitar el daño
asegurándose de que los ataques no tiren sus servidores.</para>
<orderedlist>
<listitem>
<para>Limitación de forks en el servidor.</para>
</listitem>
<listitem>
<para>Limitación de ataques <quote>springboard</quote>
(ataques de respuesta ICMP, ping broadcast, etc.)</para>
</listitem>
<listitem>
<para>Caché de rutas del kernel.</para>
</listitem>
</orderedlist>
<para>Un típico ataque DoS contra un servidor con instancias
(forks) sería tratar de provocar que el servidor consuma
procesos, descriptores de fichero y memoria hasta tirar la
máquina.
<application>inetd</application> (consulte &man.inetd.8;)
dispone de varias opciones para limitar este tipo de ataque.
Recuerde que aunque es posible evitar que una máquina
caiga, generalmente no es posible evitar que un servicio sea
vea interrumpido a causa el ataque. Consulte la página
de manual de <application>inetd</application> atentamente y
sobre todo estudie las las opciones
<option>-c</option>, <option>-C</option>,
y <option>-R</option>. Observe que los ataques con direcciones IP
falsificadas sortearán la opción <option>-C</option> de
<application>inetd</application>, así que debe usar una
combinación de opciones. Algunos servidores
autónomos (<quote>standalone</quote>) cuentan con
parámetros de autolimitación de instancias.</para>
<para><application>Sendmail</application> tiene la opción
<option>-OMaxDaemonChildren</option>, que tiende a funcionar
mucho mejor que las opciones de límite
de carga de sendmail debido al retraso que provoca la carga.
Debe especificar un parámetro
<literal>MaxDaemonChildren</literal> al inicio de
<application>sendmail</application> que sea lo suficientemente alto
como para gestionar la carga esperada, pero no tan alto que la
computadora no pueda absorber tal número de
<application>sendmails</application> sin caerse de boca.
También es prudente ejecutar sendmail en modo de cola
(<option>-ODeliveryMode=queued</option>) y ejecutar el
dæmon (<command>sendmail -bd</command>)
de manera independiente de las ejecuciones de cola
(<command>sendmail -q15m</command>). Si a pesar de todo necesita
entregas en tiempo real puede ejecutar la cola a un intervalo
menor, como <option>-q1m</option>, pero asegúrese de
especificar una opción <literal>MaxDaemonChildren</literal>
razonable para <emphasis>ese</emphasis> sendmail y así
evitar fallos en cascada.</para>
<para><application>Syslogd</application> puede recibir ataques directos
y se recomienda encarecidamente que utilice la opción
<option>-s</option> siempre que sea posible, y si no la opción
<option>-a</option>.</para>
<para>También debe ser extremadamente cuidadoso con servicios
de conexión inversa como el ident inverso de
<application>TCP Wrapper</application>, que puede recibir ataques
directos. No se suele usar el ident inverso de
<application>TCP Wrapper</application> por esa misma
razón.</para>
<para>Es una muy buena idea proteger los servicios internos
de acceso externo protegiéndolos vía con un cortafuegos
en los routers de frontera. La idea es prevenir ataques de
saturación desde el exterior de la LAN, y no tanto para
proteger servicios internos de compromisos
<username>root</username> basados en red.
Configure siempre un cortafuegos exclusivo, esto es,
<quote>restringir todo <emphasis>menos</emphasis> los puertos
A, B, C, D y M-Z</quote>. De esta manera restringirá
todos sus puertos con números bajos excepto ciertos
servicios específicos como
<application>named</application> (si es el servidor primario de
una zona), <application>ntalkd</application>,
<application>sendmail</application>, y otros servicios accesibles
desde Internet. Si configura el cortafuegos de la otra
manera (como un cortafuegos inclusivo o permisivo), tiene grandes
posibilidades de que olvide <quote>cerrar</quote> un
par de servicios, o de que agregue un nuevo servicio interno y
olvide actualizar el cortafuegos. Puede incluso abrir el rango
de números de puerto altos en el cortafuegos para permitir
operaciones de tipo permisivo sin comprometer sus puertos
bajos. Recuerde también que &os; le permite controlar
el rango de números de puerto utilizados para asignación
dinámica a través de las numerosas
<varname>net.inet.ip.portrange</varname> de
<command>sysctl</command>
(<command>sysctl -a | fgrep portrange</command>), lo cual
también facilita la complejidad de la configuración
de su cortafuegos. Por ejemplo, puede utilizar un rango normal
primero/último de 4000 ó 5000, y un rango de puerto
alto de 49152 a 65535; bloquée todo por debajo de
4000 (excepto para ciertos puertos específicos
accesibles desde Internet, por supuesto).</para>
<indexterm><primary>ICMP_BANDLIM</primary></indexterm>
<para>Otro ataque DoS común es llamado ataque
<quote>springboard</quote>: atacar un servidor de forma que
genere respuestas que lo sobrecarguen, sobrecarguen la red local
o alguna otra máquina. Los ataques más
comunes de este tipo son los
<emphasis>ataques ICMP ping broadcast</emphasis>.
El atacante falsifica paquetes ping enviados a la dirección
broadcast de su LAN simulando que la dirección IP origen
es la de la máquina que desean atacar. Si sus routers
de frontera no están configurados para lidiar con pings a
direcciones de broadcast su LAN termina generando suficientes
respuestas a la dirección origen falsificada como para saturar
a la víctima, especialmente cuando el atacante utiliza
el mismo truco en varias docenas de direcciones broadcast en
varias docenas de redes diferentes a la vez. Se han medido
ataques de broadcast de más de ciento veinte megabits.
Un segundo tipo de ataque <quote>springboard</quote> bastante
común se da contra el sistema de informe de error de ICMP.
Un atacante puede saturar la conexión entrante de red de un
servidor mediante la construcción de paquetes que generen
respuestas de error ICMP, provocando que el servidor sature su
conexión saliente de red con respuestas ICMP. Este tipo
de ataque también puede tumbar el servidor agotando sus
<quote>mbufs</quote>, especialmente si el servidor no puede
drenar lo suficientemente rápido las respuestas ICMP que
genera. El kernel de &os; tiene una opción de
compilación llamada <option>ICMP_BANDLIM</option>,
que limita la efectividad de este tipo de ataques.
La última gran categoría de ataques
<quote>springboard</quote> está relacionada con
ciertos servicios de <application>inetd</application>, como
el servicio de eco udp. El atacante simplemente imita un paquete
UDP con el puerdo de eco del servidor A como dirección de
origen, y el puerto eco del servidor B como dirección de
destino, estando ambos servidores en la misma LAN. Un atacante
puede sobrecargar ambos servidores y la propia LAN inyectando
simplemente un par de paquetes. Existen problemas similares
con el puerto
<application>chargen</application>. Un administrador de sistemas
competente apagará todos estos servicios internos de
verificación de inetd.</para>
<para>Los ataques con paquetes falsificados pueden utilizarse
también para sobrecargar la caché de rutas del kernel.
Consulte los parámetros de <command>sysctl</command>
<varname>net.inet.ip.rtexpire</varname>,
<varname>rtminexpire</varname>, y
<varname>rtmaxcache</varname>.
Un ataque de paquetes falsificados que utiliza una dirección
IP origen aleatoria provocará que el kernel genere una
ruta temporal en caché en su tabla de rutas, visible con
<command>netstat -rna | fgrep W3</command>. Estas rutas
suelen expiran en 1600 segundos más o menos. Si el
kernel detecta que la tabla de rutas en caché es ya
demasiado grande reducirá dinámicamente
<varname>rtexpire</varname>, pero nunca la reducirá a un
valor que sea menor que <varname>rtminexpire</varname>.
Esto nos presenta dos problemas:</para>
<orderedlist>
<listitem>
<para>El kernel no reacciona con suficiente rapidez cuando
un servidor ligeramente cargado es atacado.</para>
</listitem>
<listitem>
<para>El <varname>rtminexpire</varname> no es lo suficientemente
bajo para que el kernel sobreviva a un ataque sostenido.</para>
</listitem>
</orderedlist>
<para>Si sus servidores están conectados a Internet mediante
mediante una línea T3 o superior puede ser prudente corregir
manualmente
<varname>rtexpire</varname> y <varname>rtminexpire</varname>
por medio de &man.sysctl.8;. Nunca ponga ambos parámetros
a cero (a menos que desée estrellar la máquina).
Configurar ambos parámetros a 2 segundos debería
bastar para proteger de ataques la tabla de rutas.</para>
</sect2>
<sect2>
<title>Otros aspectos del acceso con Kerberos y SSH</title>
<indexterm><primary><command>ssh</command></primary></indexterm>
<indexterm><primary>KerberosIV</primary></indexterm>
<para>Existen un par de detalles con respecto a
Kerberos y ssh que debe analizar sy pretende usarlos.
Kerberos V es un excelente protocolo de
protocolo de autentificación, pero hay errores en la
versión kerberizada de <application>telnet</application>
y <application>rlogin</application> que las hacen
inapropiadas para gestionar flujos binarios.
Ademé Kerberos no cifra por defecto una
sesión a menos que utilice la opción
<option>-x</option>. <application>ssh</application> cifra todo
por defecto.</para>
<para>ssh funciona bastante bien en todos los casos, con la sola
salvedad de que por defecto reenvía llaves de cifrado.
Esto significa que si usted tiene una estación de trabajo
segura, que contiene llaves que le dan acceso al resto del sistema,
y hace ssh a una máquina insegura, sus llaves se pueden
utilizar. Las llaves en sí no se exponen, pero ssh
crea un puerto de reenvío durante el login, y si un
atacante ha comprometido el <username>root</username>
de la máquina insegura, puede utilizar ese puerto
para usar sus llaves y obtener acceso a cualquier otra
máquina que sus llaves abran.</para>
<para>Le recomendamos que, siempre que sea posible, use ssh
combinado con Kerberos en los login de su personal de
administración.
para logins de staff. Puede compilar
<application>ssh</application> con soporte de Kerberos.
Esto reducirá su dependencia de llaves ssh expuestas,
al mismo tiempo que protege las contraseñas vía
Kerberos. Las llaves ssh deben usarse sólamente para
tareas automáticas desde máquinas seguras
(algo que Kerberos no hace por incompatibilidad). Recomendamos
también que desactive el reenvío de llaves
en la configuración de ssh, o que use la
opción <literal>from=IP/DOMAIN</literal> que ssh incluye
en <filename>authorized_keys</filename>; así la llave
sólo podrá ser utilizada por entidades que se
validen desde máquinas
específicas.</para>
</sect2>
</sect1>
<sect1 id="crypt">
<sect1info>
<authorgroup>
<author>
<firstname>Bill</firstname>
<surname>Swingle</surname>
<contrib>Secciones reescritas y actualizadas por </contrib>
</author>
</authorgroup>
<!-- 21 Mar 2000 -->
</sect1info>
<title>DES, MD5 y Crypt</title>
<indexterm>
<primary>seguridad</primary>
<secondary>crypt</secondary>
</indexterm>
<indexterm><primary>crypt</primary></indexterm>
<indexterm><primary>DES</primary></indexterm>
<indexterm><primary>MD5</primary></indexterm>
<para>Cada usuario de un sistema &unix; tiene una contraseña
asociada a su cuenta. Parece obvio que estas contraseñas
sólo deben ser conocidas por el usuario y por el sistema
operativo. Para que estas contraseñas permanezcan en secreto
se cifran con lo que se conoce como un
<quote>hash de una pasada</quote>, esto es, sólo pueden ser
fácilmente cifradas pero no descifradas. En otras palabras,
lo que acabamos de decir es tan obvio que ni siguiera es verdad:
el propio sistema operativo no sabe cuál es
<emphasis>realmente</emphasis> la contraseña.
Lo único que conoce es la versión
<emphasis>cifrada</emphasis> de la contrasenña.
La única manera de obtener la
contraseña en <quote>texto plano</quote> es por medio
de una búsqueda de fuerza bruta en el espacio de
contraseñas posibles.</para>
<para>Por desgracia la única manera segura de cifrar
contraseñas cuando &unix; empezó a hacerlo estaba
basada en DES, (<quote>Data Encryption Standard</quote>,
<quote>estándar de cifrado de datos</quote>).
Esto no era un gran problema para usuarios residentes en los EEUU,
pero el código fuente de &os; no se podía exportar desde
los EEUU, así que &os; hubo de buscar una forma de complir
las leyes de EEUU y al mismo tiempo mantener la compatibilidad con
otras variantes de &unix; que
que todavía utilizaban DES.</para>
<para>La solución fué dividir las bibliotecas de cifrado
para que los usuarios de EEUU pudieran instalar las bibliotecas DES
pero los usuarios del resto del mundo tuvieran un método
de cifrado que pudiera ser exportado. Así es como &os;
comenzó a usar MD5 como su método de cifrado por
defecto. MD5 se considera más seguro que DES, así
que se mantiene la opción de poder instalar DES por motivos
de compatibilidad.</para>
<sect2>
<title>Cómo reconocer su mecanismo de cifrado</title>
<para>En versiones anteriores a &os; 4.4
<filename>libcrypt.a</filename> era un enlace
simbólico que apuntaba a la biblioteca que se usaba para el
cifrado. En &os; 4.4 se cambió
<filename>libcrypt.a</filename> para ofrecer una biblioteca hash
configurable de validación de contraseñas.
Actualmente la biblioteca permite funciones hash DES, MD5 y
Blowfish. &os; utiliza por defecto MD5 para cifrar
contraseñas.</para>
<para>Es muy sencillo identificar qué método usa &os;
para cifrar. Una forma es examinando las contraseñas
cifradas en <filename>/etc/master.passwd</filename>.
Las contraseñas cifradas con el hash MD5 son más
largas que las cifradas con el hash DES, y también
comienzan por los caracteres
<literal>$1$</literal>. Las contraseñas
que comienzan por <literal>$2a$</literal> están
cifradas con la función hash de Blowfish. Las
contraseñas DES no tienen ninguna
característica particular, pero son más cortas que
las contraseñas MD5, y están codificadas en un
alfabeto de 64 caracteres que no incluye el caracter
<literal>$</literal>; es por esto que una cadena
relativamente corta que comience con un signo de
dólar es muy probablemente una contraseña
DES.</para>
<para>El formato de contraseña a usar en nuevas
contraseñas se define en
<filename>/etc/login.conf</filename> mediante
<literal>passwd_format</literal>, pudiendo tener los valores
<literal>des</literal>, <literal>md5</literal> o
<literal>blf</literal>. Consulte la página de manual
&man.login.conf.5; para más información.</para>
</sect2>
</sect1>
<sect1 id="one-time-passwords">
<title>Contraseñas de un solo uso</title>
<indexterm><primary>Contraseñas de un solo uso</primary></indexterm>
<indexterm>
<primary>seguridad</primary>
<secondary>Contraseñas de un solo uso</secondary>
</indexterm>
<para>S/Key es un esquema de contraseña de un solo uso
basado en una función de hash de sentido único.
&os; utiliza el
hash MD4 por compatibilidad, pero otros sistemas usan
MD5 y DES-MAC. S/Key forma parte del sistema base de &os;
desde la versión 1.1.5 y se usa también en
un número creciente de otros sistemas operativos. S/Key
es una marca registrada de Bell Communications Research, Inc.</para>
<para>A partir de la versión 5.0 de &os; S/Key fué
reemplazado por su equivalente OPIE (<quote>One-time Passwords
In Everything</quote>, <quote>Contraseñas de un solo
uso para todo</quote>). OPIE usa por defecto hash MD5.</para>
<para>En esta sección se explican tres tipos de
contraseña. La primera es la típica
contraseña al estilo &unix; o Kerberos; las llamaremos
<quote>contraseñas &unix;</quote>.
El segundo tipo es la contraseña de un solo uso,
que se genera con el programa <command>key</command> de S/Key o
con &man.opiekey.1; de OPIE, y que aceptan los programas
<command>keyinit</command>, &man.opiepasswd.1;, y el prompt de
login; llamaremos a esta una
<quote>contraseña de un solo uso</quote>.
El último tipo de contraseña es la contraseña
secreta que le da usted a los programas
<command>key</command>/<command>opiekey</command> (y a veces
<command>keyinit</command>/<command>opiepasswd</command>), que
se usa para generar contraseñas de un solo uso;
a estas las llamaremos <quote>contraseñas secretas</quote>,
o simplemente <quote>contraseña</quote>.</para>
<para>La contraseña secreta no tiene nada que ver con su
contraseña &unix;; pueden ser la misma, pero no es
recomendable. Las contraseñas secretas S/Key y OPIE no
están limitadas a 8 caracteres como las contraseñas
&unix; antiguas<footnote><para>En &os; la contraseña del
login estándar puede ser de hasta 128 caracteres de
longitud.</para></footnote>, pueden ser tan largas como se quiera.
Las contraseñas con frases de seis o siete palabras muy largas
son bastante comunes. El funcionamiento del sistema S/Key o el
OPIE es en gran parte completamente independiente del sistema de
contraseñas &unix;.</para>
<para>Además de la contraseña hay dos datos que son
importantes para S/Key y OPIE. Uno es lo que se conoce como
<quote>semilla</quote> o <quote>llave</quote>, que consiste en dos
letras y cinco dígitos. El otro dato importante se llama
la <quote>cuenta de iteración</quote>, que es un número
entre 1 y 100. S/Key genera la contraseña de un solo
uso concatenando la semilla y la contraseña secreta,
aplica el hash MD4/MD5 tantas veces como especifique la cuenta de
iteración y convierte el resultado en seis palabras
cortas en inglés. Estas seis palabras en inglés
son su contraseña de un solo uso. El sistema de
autentificación (principalmente PAM) mantiene un registro del
uso de contraseñas de un solo uso, y el usuario
puede validarse si el hash de la contraseña que proporciona
es igual a la contraseña previa. Como se utiliza un
hash de sentido único es imposible generar futuras
contraseñas de un solo uso si una contraseña
que ya ha sido usada fuera capturada;
la cuenta de iteración se reduce después de cada login
correcto para sincronizar al usuario con el programa login.
Cuanto la iteración llega a 1, S/Key y OPIE deben
reinicializar.</para>
<para>Hay tres programas involucrados en cada uno de estos
sistemas. Los programas <command>key</command> y
<command>opiekey</command> aceptan una cuenta iterativa,
una semilla y una contraseña secreta, y generan
una contraseña de un solo uso o una lista consecutiva
de contraseñas de un solo uso. Los programas
<command>keyinit</command> y <command>opiepasswd</command>
se usan respectivamente para inicializar S/Key y OPIE,
y para cambiar contraseñas, cuentas iterativas o
semillas; toman ya sea una frase secreta, o una cuenta
iterativa y una contraseña de un solo uso. Los
programas <command>keyinfo</command> y <command>opieinfo</command>
examinan los ficheros de credenciales correspondientes
(<filename>/etc/skeykeys</filename> o
<filename>/etc/opiekeys</filename>) e imprimen la cuenta
iterativa y semilla del usuario invocante.</para>
<para>Explicaremos cuatro tipos de operaciones diferentes.
La primera es usar <command>keyinit</command> o
<command>opiepasswd</command> a través de una conexión
segura para configurar contraseñas de un solo uso por
primera vez, o para cambiar su contraseña o semilla.
La segunda operación es utilizar <command>keyinit</command>
o <command>opiepasswd</command> a través de una conexión
insegura, además de usar <command>key</command> u
<command>opiekey</command> sobre una conexión segura para
hacer lo mismo. La tercera es usar
<command>key</command>/<command>opiekey</command> para conectarse a
través de una conexión insegura. La cuarta es usar
<command>opiekey</command> o <command>key</command> para generar
numerosas llaves, que pueden ser escritas para llevarlas con usted
al ir a algún lugar desde el que no se puedan hacer conexiones
seguras a ningún sitio.</para>
<sect2>
<title>Inicialización de conexiones seguras</title>
<para>Para inicializar S/Key por primera vez cambie su contraseña,
o cambie su semilla mientras está conectado a través de
una conexión segura (esto es, en la consola de una
máquina o vía <application>ssh</application>); use
<command>keyinit</command> sin ningún parámetro:</para>
<screen>&prompt.user; <userinput>keyinit</userinput>
Adding unfurl:
Reminder - Only use this method if you are directly connected.
If you are using telnet or rlogin exit with no password and use keyinit -s.
Enter secret password:
Again secret password:
ID unfurl s/key is 99 to17757
DEFY CLUB PRO NASH LACE SOFT</screen>
<para>En OPIE se utiliza <command>opiepasswd</command>:</para>
<screen>&prompt.user; <userinput>opiepasswd -c</userinput>
[grimreaper] ~ $ opiepasswd -f -c
Adding unfurl:
Only use this method from the console; NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase:
Again new secret pass phrase:
ID unfurl OTP key is 499 to4268
MOS MALL GOAT ARM AVID COED
</screen>
<para>En <prompt>Enter new secret pass phrase:</prompt> o
<prompt>Enter secret password:</prompt>, debe introducir
una contraseña o frase. Recuerde que no es la
contraseña que utilizará para entrar, se usará
para generar sus llaves de un solo uso. La línea
<quote>ID</quote> da los parámetros de su instancia
en particular: su nombre de login, la cuenta iterativa y
semilla. En el momento del login el sistema recordará estos
parámetros y los presentará de nuevo para que
no tenga que recordarlos. La última línea proporciona
las contraseéas de un solo uso que
corresponden a esos parámetros y su contraseña
secreta; si fuera a hacer login de manera inmediata,
debería usar esta contraseña de una sola vez.</para>
</sect2>
<sect2>
<title>Inicialización de conexiones inseguras</title>
<para>Para inicializar o cambiar su contraseña secreta
a través de una conexión insegura, necesitará
tener alguna conexión segura a algún lugar
donde pueda ejecutar <command>key</command> u
<command>opiekey</command>; puede ser gracias a un accesorio de
escritorio o en una &macintosh;, o un prompt de shell en una
máquina en la que confíe. Necesitará
también una cuenta iterativa (100 probablemente sea un
buen valor), y puede usar su propia semilla, o usar una generada
aleatoriamente. Siguiendo con la conexión insegura
(hacia la máquina que está inicializando), ejecute
<command>keyinit -s</command>:</para>
<screen>&prompt.user; <userinput>keyinit -s</userinput>
Updating unfurl:
Old key: to17758
Reminder you need the 6 English words from the key command.
Enter sequence count from 1 to 9999: <userinput>100</userinput>
Enter new key [default to17759]:
s/key 100 to 17759
s/key access password:
s/key access password:<userinput>CURE MIKE BANE HIM RACY GORE</userinput>
</screen>
<para>En OPIE debe usar <command>opiepasswd</command>:</para>
<screen>&prompt.user; <userinput>opiepasswd</userinput>
Updating unfurl:
You need the response from an OTP generator.
Old secret pass phrase:
otp-md5 498 to4268 ext
Response: GAME GAG WELT OUT DOWN CHAT
New secret pass phrase:
otp-md5 499 to4269
Response: LINE PAP MILK NELL BUOY TROY
ID mark OTP key is 499 gr4269
LINE PAP MILK NELL BUOY TROY
</screen>
<para>Para aceptar la semilla por defecto (la que
el programa <command>keyinit</command> llama
<literal>key</literal>, <quote>llave</quote>, para terminar de
complicar las cosas), pulse <keycap>Enter</keycap>.
Antes de introducir una una contraseña de acceso
cambie a su conexión o accesorio de escritorio S/Key y
dele el mismo parámetro:</para>
<screen>&prompt.user; <userinput>key 100 to17759</userinput>
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: <userinput><secret password></userinput>
CURE MIKE BANE HIM RACY GORE</screen>
<para>O para OPIE:</para>
<screen>&prompt.user; <userinput>opiekey 498 to4268</userinput>
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT
</screen>
<para>Vuelva a la conexión insegura y copie la
contraseña de un solo uso generada al programa
que quiera usar.</para>
</sect2>
<sect2>
<title>Generación una sola contraseña de un solo
uso</title>
<para>Una vez que ha inicializado S/Key u OPIE, cuando haga login
verá un <quote>prompt</quote> parecido al siguiente:</para>
<screen>&prompt.user; <userinput>telnet ejemplo.com</userinput>
Trying 10.0.0.1...
Connected to ejemplo.com
Escape character is '^]'.
FreeBSD/i386 (ejemplo.com) (ttypa)
login: <userinput><username></userinput>
s/key 97 fw13894
Password: </screen>
<para>O, en el caso de OPIE:</para>
<screen>&prompt.user; <userinput>telnet ejemplo.com</userinput>
Trying 10.0.0.1...
Connected to ejemplo.com
Escape character is '^]'.
FreeBSD/i386 (ejemplo.com) (ttypa)
login: <userinput><nombre_de_usuario></userinput>
otp-md5 498 gr4269 ext
Password: </screen>
<para>Como una nota aparte, el <quote>prompt</quote> de S/Key y OPIE
cuenta con una opción útil (que no se muestra
aquí): si pulsa <keycap>Enter</keycap> en el
<quote>prompt</quote> de contraseña el
<quote>prompt</quote> activará el eco para que pueda ver
en pantalla lo que teclea. Esto puede ser extremadamente
útil si está tecleando una contraseña a
a mano o desde un la lista impresa.</para>
<indexterm><primary>MS-DOS</primary></indexterm>
<indexterm><primary>Windows</primary></indexterm>
<indexterm><primary>MacOS</primary></indexterm>
<para>Ahora necesitará generar su contraseña de un
sólo uso para responder a este <quote>prompt</quote> de
login. Debe hacerlo en un sistema digno de confianza y en el que
pueda ejecutar <command>key</command> u <command>opiekey</command>.
Existen versiones DOS, &windows; y también para &macos;.
Ambos usarán la cuenta iterativa y la semilla como opciones
de línea de órdenes. Puede cortarlas y pegarlas desde el
<quote>prompt</quote> de login de la máquina en la
que se está identificando.</para>
<para>En el sistema de confianza:</para>
<screen>&prompt.user; <userinput>key 97 fw13894</userinput>
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password:
WELD LIP ACTS ENDS ME HAAG</screen>
<para>Con OPIE:</para>
<screen>&prompt.user; <userinput>opiekey 498 to4268</userinput>
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT</screen>
<para>Ahora que tiene su contraseña de un solo uso puede
proceder con el login:</para>
<screen>login: <userinput><nombre_de_usuario></userinput>
s/key 97 fw13894
Password: <userinput><<keycap>Enter</keycap> para activar el eco></userinput>
s/key 97 fw13894
Password [echo on]: WELD LIP ACTS ENDS ME HAAG
Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... </screen>
</sect2>
<sect2>
<title>Generación de múltiples contraseñas
de un solo uso</title>
<para>A veces usted hay que ir a lugares donde no hay
acceso a una máquina de fiar o a una conexión
segura. En estos casos, puede utilizar
<command>key</command> y <command>opiekey</command> para
generar previamente numerosas contraseñas de un solo uso
para, una vez impresas, llevárselas a donde hagan falta.
Por ejemplo:</para>
<screen>&prompt.user; <userinput>key -n 5 30 zz99999</userinput>
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: <userinput><secret password></userinput>
26: SODA RUDE LEA LIND BUDD SILT
27: JILT SPY DUTY GLOW COWL ROT
28: THEM OW COLA RUNT BONG SCOT
29: COT MASH BARR BRIM NAN FLAG
30: CAN KNEE CAST NAME FOLK BILK</screen>
<para>O para OPIE:</para>
<screen>&prompt.user; <userinput>opiekey -n 5 30 zz99999</userinput>
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase: <userinput><secret password></userinput>
26: JOAN BORE FOSS DES NAY QUIT
27: LATE BIAS SLAY FOLK MUCH TRIG
28: SALT TIN ANTI LOON NEAL USE
29: RIO ODIN GO BYE FURY TIC
30: GREW JIVE SAN GIRD BOIL PHI</screen>
<para>El <option>-n 5</option> pide cinco llaves en secuencia, la
opción <option>30</option> especifica que ese debe ser el
último número de iteración. Observe que se
imprimen en el orden <emphasis>inverso</emphasis> de uso.
Si es realmente paranoico escriba los resultados a mano; si no,
puede enviar la salida a <command>lpr</command>. Observe que
cada línea muestra la cuenta iterativa y la
contraseña de un solo uso; puede ir tachando las
contraseñas según las vaya utilizando.</para>
</sect2>
<sect2>
<title>Restricción del uso de contraseñas &unix;</title>
<para>S/Key puede implantar restricciones en el uso de contraseñas
&unix; basándose en el nombre de equipo, nombre de usuario,
puerto de terminal o dirección IP de una sesión de
login. Consulte el fichero de configuración
<filename>/etc/skey.access</filename>. La página de manual
de &man.skey.access.5; contiene más información sobre el
formato del fichero y detalla también algunas precauciones
de seguridad que hay que tener en cuenta antes de basar nuestra
seguridad en este fichero.</para>
<para>Si <filename>/etc/skey.access</filename> no existiera
(por defecto es así en sistemas &os; 4.X) todos los
usuarios podrán disponer de contraseñas &unix;.
Si el fichero existe se exigirá a todos los usuarios
el uso de S/Key, a menos que se configure de otro modo en
<filename>skey.access</filename>. En todos los casos las
contraseñas &unix; son admiten en consola.</para>
<para>Aquí hay un ejemplo del fichero de configuración
<filename>skey.access</filename> que muestra las tres formas más
comunes de configuración:</para>
<programlisting>permit internet 192.168.0.0 255.255.0.0
permit user fnord
permit port ttyd0</programlisting>
<para>La primera línea (<literal>permit internet</literal>)
permite a usuarios cuyas direcciones IP origen (las cuales son
vulnerables a una falsificación) concuerden con los valores
y máscara especificados utilizar contraseñas &unix;.
Esto no debe usarse como mecanismo de seguridad, sino como
medio de recordarle a los usuarios autorizados que están
usando una red insegura y necesitan utilizar S/Key para
la validación.</para>
<para>La segunda línea (<literal>permit user</literal>)
permite al nombre de usuario especificado, en este caso
<username>fnord</username>, utilizar contraseñas &unix;
en cualquier momento. Hablando en general, esto solo debe ser
usado por gente que no puede usar el programa <command>key</command>,
como aquellos con terminales tontas o refractarios al
aprendizaje.</para>
<para>La tercera línea (<literal>permit port</literal>)
permite a todos los usuarios validados en la línea de
terminal especificada utilizar contraseñas &unix;;
esto puede usarse para usuarios que se conectan mediante
<quote>dial-ups</quote>.</para>
<para>OPIE puede restringir el uso de contraseñas &unix;
basándose en la dirección IP de una sesión
de login igual que lo haría S/Key. El fichero que gestiona
esto es <filename>/etc/opieaccess</filename>, que está
incluído por defecto en sistemas &os; 5.0 o posteriores.
Revise &man.opieaccess.5; para más información sobre
este fichero y qué consideraciones de seguridad debe tener
presentes a la hora de usarlo.</para>
<para>Veamos un ejemplo de <filename>opieaccess</filename>:</para>
<programlisting>permit 192.168.0.0 255.255.0.0</programlisting>
<para>Esta línea permite a usuarios cuya dirección
IP de origen (vulnerable a falsificación) concuerde
con los valores y máscara especificados, utilizar
contraseñas &unix; en cualquier momento.</para>
<para>Si no concuerda ninguna regla en <filename>opieaccess</filename>
se niegan por defecto los logins no-OPIE.</para>
</sect2>
</sect1>
<sect1 id="tcpwrappers">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Escrito por: </contrib>
</author>
</authorgroup>
</sect1info>
<title>TCP Wrappers</title>
<indexterm><primary>TCP Wrappers</primary></indexterm>
<para>Cualquiera que esté familiarizado con &man.inetd.8;
probablemente haya oído hablar de
<acronym>TCP</acronym> Wrappers, pero poca gente parece comprender
completamente su utilidad en un entorno de red. Parece que
todos quieren instalar un cortafuegos para manejar conexiones
de red. Aunque un cortafuegos tiene una amplia variedad de
usos hay cosas que un cortafuegos no es capaz de gestionar,
como el envío de texto como respuesta al creador de la
conexión. El software <acronym>TCP</acronym> hace esto
y más. En las siguientes secciones se explicarán
unas cuantas opciones de
<acronym>TCP</acronym> Wrappers y, cuando sea necesario, se
mostrarán ejemplos de configuraciones.</para>
<para>El software <acronym>TCP</acronym> Wrappers extiende
las habilidades de <command>inetd</command> para ofrecer
soporte para cada servidor dæmon bajo su control.
Utilizando este método es posible proveer soporte de
logs, devolver mensajes a conexiones, permitir a un dæmon
aceptar solamente conexiones internas, etc. Aunque algunas de estas
opciones pueden conseguirse gracias a un cortafuegos, no sólo
añadirá una capa extra de seguridad, sino que irá
más allá del nivel de control ue un cortafuegos
puede ofrecerle.</para>
<para>Las brillantes capacidades de <acronym>TCP</acronym> Wrappers
no deben considerarse una alternativa a un buen cortafuegos.
<acronym>TCP</acronym> Wrappers puede usarse conjuntamente con un
cortafuegos u otro sistema de de seguridad, pues ofrece una capa
extra de protección para el sistema.</para>
<para>Ya que es una extensión de la configuración
de <command>inetd</command>, se da por hecho que el lector ha
leído la sección
<link linkend="network-inetd">configuración de inetd</link>.</para>
<note>
<para>Aunque los programas ejecutados por &man.inetd.8; no son
exactamente <quote>dæmons</quote> tradicionalmente han
recibido ese nombre. Dæmon es, por tanto, el término
que usaremos en esta sección.</para>
</note>
<sect2>
<title>Configuración inicial</title>
<para>El único requisito para usar
<acronym>TCP</acronym> Wrappers en &os; es que el servidor
<command>inetd</command> se inicie desde
<filename>rc.conf</filename> con la opción
<option>-Ww</option> (es la configuración
por defecto). Por descontado, se presupone que
<filename>/etc/hosts.allow</filename> estará correctamente
configurado, pero &man.syslogd.8; enviará mensajes
a los logs del sistema si no es así.</para>
<note>
<para>A diferencia de otras implementaciones de <acronym>TCP</acronym>
Wrappers, se ha dejado de usar
<filename>hosts.deny</filename>. Todas las opciones de
configuración deben ir en
<filename>/etc/hosts.allow</filename>.</para>
</note>
<para>En la configuración más simple las
políticas de conexión de dæmons están
configuradas ya sea a permitir o bloquear, dependiendo de
las opciones en <filename>/etc/hosts.allow</filename>.
La configuración por defecto en &os; consiste en
permitir una conexión a cada dæmon iniciado por
<command>inetd</command>. Es posible modificar esta
configuración, pero explicaremos cómo hacerlo
después de exponer la configuración
básica.</para>
<para>La configuración básica tiene la estructura
<literal>dæmon : dirección : acción</literal>,
donde <literal>dæmon</literal> es el nombre de dæmon
que inicia <command>inetd</command>. La
<literal>dirección</literal> puede ser un nombre
de equipo válido, una dirección IP o
IPv6 encerrada en corchetes ([ ]). El campo
acción puede ser permitir o denegar para el
dar el acceso apropiado. Tenga presente que la
configuración funciona en base a la primera
regla cuya semántica concuerde;
esto significa que el fichero de configuración se
lee en orden ascendente hasta que concuerde una regla.
Cuando se encuentra una concordancia se aplica la regla
y el proceso se detendrá.</para>
<para>Existen muchas otras opciones pero estas se
explican en una sección posterior. Una línea
de configuración simple puede generarse mediante datos
así de simples. Por ejemplo, para permitir conexiones
<acronym>POP</acronym>3 mediante el dæmon
<filename role="package">mail/qpopper</filename>, añada
las siguientes líneas a
<filename>hosts.allow</filename>:</para>
<programlisting># This line is required for POP3 connections:
qpopper : ALL : allow</programlisting>
<para>Despues de añadir esta línea tendrá que
reiniciar <command>inetd</command>. Use &man.kill.1; o use el
parámetro <parameter>restart</parameter> de
<filename>/etc/rc.d/inetd</filename>.</para>
</sect2>
<sect2>
<title>Configuración avanzada</title>
<para>Las opciones avanzadas de <acronym>TCP</acronym> Wrappers
le permiten un mayor control sobre la gestión de
conexiones. En algunos casos puede convenir el enío de
un comentario a ciertos equipos o conexiones de dæmons.
En otros casos, quizás se deba registrar una entrada en
un log o enviar un correo al administrador. Otro tipo de
situaciones pueden requerir el uso de un servicio
solamente para conexiones locales. Todo esto es posible gracias
al uso de unas opciones de configuración conocidas
como <literal>comodines</literal>, caracteres de expansión
y ejecución de órdenes externas. Las siguientes dos
secciones intentarán cubrir estas situaciones.</para>
<sect3>
<title>Órdenes externas</title>
<para>Imaginemos una situación en la que una
conexión debe ser denegada pero se debe mandar un motivo
a quien intentó establecer esa conexión.
?Cómo? Mediante la opción
<option>twist</option>. Ante un intento de conexión se
invoca a <option>twist</option>, que ejecuta una orden de shell
o un <quote>script</quote>. Tiene un ejemplo en el fichero
<filename>hosts.allow</filename>:</para>
<programlisting># The rest of the daemons are protected.
ALL : ALL \
: severity auth.info \
: twist /bin/echo "No se permite utilizar %d desde %h."</programlisting>
<para>Este ejemplo muestra que el mensaje,
<quote>No se permite utilizar <literal>dæmon</literal>
desde <literal>nombre de equipo</literal>.</quote> se
enviará en el caso de cualquier dæmon no configurado
previamente en el fichero de acceso.
Esto es extremadamente útil para enviar una respuesta
al creador de la conexión justo después de
que la conexión establecida es rechazada. Observe que
cualquier mensaje que se desee enviar <emphasis>debe ir</emphasis>
entre comillas <literal>"</literal>; esta regla no tiene
excepciones.</para>
<warning>
<para> Es posible lanzar un ataque de denegación
de servicio al servidor si un atacante o grupo de
atacantes pueden llegar a sobrecargar estos dæmons
con peticiones de conexión.</para>
</warning>
<para>Otra posibilidad en estos casos es usar la opción
<option>spawn</option>. Igual que <option>twist</option>,
<option>spawn</option> niega implícitamente la
conexión, y puede usarse para ejecutar órdenes de
shell externos o <quote>scripts</quote>. A diferencia de
<option>twist</option>, <option>spawn</option> no
enviará una respuesta al origen de la conexión.
Veamos un ejemplo; observe la siguiente línea de
configuración:</para>
<programlisting># No permitimos conexiones desde ejemplo.com:
ALL : .ejemplo.com \
: spawn (/bin/echo %a desde %h intento acceder a %d >> \
/var/log/connections.log) \
: deny</programlisting>
<para>Esto denegará todos los intentos de conexión
desde el dominio <hostid role="fqdn">*.ejemplo.com</hostid>;
simultáneamente creará una entrada con
el nombre del equipo, dirección <acronym>IP</acronym>
y el dæmon al que intentó conectarse al fichero
<filename>/var/log/connections.log</filename>.</para>
<para>Además de la sustitución de caracteres ya
expuesta más arriba (por ejemplo %a) existen unas
cuantas más. Si quiere ver la lista completa consulte
la página de manual &man.hosts.access.5;.</para>
</sect3>
<sect3>
<title>Opciones comodín</title>
<para>Hasta ahora se ha usado <literal>ALL</literal> en todos
los ejemplos, pero hay otras opciones interesantes para
extender un poco más la funcionalidad. Por ejemplo,
<literal>ALL</literal> puede usarse para concordar con cualquier
instancia ya sea un dæmon, dominio o
dirección <acronym>IP</acronym>. Otro comodín
es <literal>PARANOID</literal>, que puede utilizarse para
concordar con cualquier equipo que presente una
dirección <acronym>IP</acronym> que pueda estar
falsificada. En otras palabras, <literal>paranoid</literal>
puede usarse para definir una acción a tomar
siempre que tenga lugar una conexión desde una
dirección <acronym>IP</acronym> que difiera de su
nombre de equipo. Quizás todo se vea más claro
con el siguiente ejemplo:</para>
<programlisting># Bloquear peticiones posiblemente falsificadas a sendmail:
sendmail : PARANOID : deny</programlisting>
<para>En ese ejemplo todas las peticiones de conexión
a <command>sendmail</command> que tengan una
dirección <acronym>IP</acronym> que varíe
de su nombre de equipo serán denegadas.</para>
<caution>
<para>Utilizando <literal>PARANOID</literal> puede bloquear el
acceso a servidores si el cliente o el servidor
tiene una configuración de
<acronym>DNS</acronym> incorrecta. Recomendamos al
administrador la máxima cautela en su uso.</para>
</caution>
<para>Consulte &man.hosts.access.5; si quiere saber más
sobre los comodines y sus posibilidades de uso.</para>
<para>Si quiere que cualquiera de los ejemplos citados
funcione debe comentar la primera línea de
<filename>hosts.allow</filename> (tal y como se dijo
al principio de la sección.</para>
</sect3>
</sect2>
</sect1>
<sect1 id="kerberosIV">
<sect1info>
<authorgroup>
<author>
<firstname>Mark</firstname>
<surname>Murray</surname>
<contrib>Escrito por </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Mark</firstname>
<surname>Dapoz</surname>
<contrib>Basado en un texto de </contrib>
</author>
</authorgroup>
</sect1info>
<title><application>KerberosIV</application></title>
<para>Kerberos es un sistema/protocolo de red agregado que permite
a los usuarios identificarse a través de los servicios de un
servidor seguro. Los servicios como login remoto, copia remota, copias
de ficheros de un sistema a otro y otras tantas tareas arriesgadas
pasan a ser considerablemente seguras y más controlables.</para>
<para>Las siguientes instrucciones pueden usarse como una guía
para configurar Kerberos tal y como se distribuye con &os;. De todas
maneras, debe consultar diversas páginas de manual para
conocer todos los detalles.</para>
<sect2>
<title>Instalación de <application>KerberosIV</application></title>
<indexterm><primary>MIT</primary></indexterm>
<indexterm>
<primary>KerberosIV</primary>
<secondary>instalación</secondary>
</indexterm>
<para>Kerberos es un componente opcional de &os;. La manera
más fácil de instalar este software es
seleccionando la distribución <literal>krb4</literal> o
<literal>krb5</literal> en <application>sysinstall</application>
durante la instalación inicial de &os;. Desde ahí
instalará la implementación de Kerberos
<quote>eBones</quote> (KerberosIV) o
<quote>Heimdal</quote> (Kerberos5).
Estas implementaciones se incluyen porque a que han sido
desarrolladas fuera de EEUU y Canadá, lo que las
convertía en accesibles para administradores de sistemas
del resto del mundo durante la época restrictiva de control
control de exportaciones de código
criptográfico desde EEUU.</para>
<para>También puede instalar la implementación de
Kerberos del MIT desde la colección de ports
(<filename role="package">security/krb5</filename>).</para>
</sect2>
<sect2>
<title>Creación de la base de datos inicial</title>
<para>Esto solo debe hacerse en el servidor Kerberos. Lo primero
es asegurarse de que no tiene bases de datos de Kerberos
anteriores. Entre al directorio <filename>/etc/kerberosIV</filename>
y asegúrese de que solo estén los siguientes
ficheros:</para>
<screen>&prompt.root; <userinput>cd /etc/kerberosIV</userinput>
&prompt.root; <userinput>ls</userinput>
README krb.conf krb.realms</screen>
<para>Si existe cualquier otro fichero (como
<filename>principal.*</filename>
o <filename>master_key</filename>) utilice
<command>kdb_destroy</command> para destruir la base
de datos antigua de Kerberos. Si Kerberos no está
funcionando simplemente borre los ficheros sobrantes.</para>
<para>Edite <filename>krb.conf</filename>
y <filename>krb.realms</filename> para definir su dominio
Kerberos. En nuestro ejemplo el dominio será
<literal>EJEMPLO.COM</literal> y el servidor es
<hostid role="fqdn">grunt.ejemplo.com</hostid>.
Editamos o creamos <filename>krb.conf</filename>:</para>
<screen>&prompt.root; <userinput>cat krb.conf</userinput>
EJEMPLO.COM
EJEMPLO.COM grunt.ejemplo.com admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.gov</screen>
<para>Los demás dominios no deben estar forzosamente en la
configuración. Los hemos incluido como ejemplo de
cómo puede hacerse que una máquina trabaje con
múltiples dominios. Si quiere mantener todo simple puede
abstenerse de incluirlos.</para>
<para>La primera línea es el dominio en el que el
sistema funcionará. Las demás líneas
contienen entradas dominio/equipo. El primer componente de cada
línea es un dominio y el segundo es un equipo de ese
dominio, que actúa como
<quote>centro de distribución de llaves</quote>.
Las palabras <literal>admin server</literal> que siguen al
nombre de equipo significan que ese equipo también
ofrece un servidor de base da datos administrativo.
Si quiere consultar una explicación más completa de
estos términos consulte las páginas de manual de
de Kerberos.</para>
<para>Ahora añadiremos
<hostid role="fqdn">grunt.ejemplo.com</hostid> al dominio
<literal>EJEMPLO.COM</literal> y también una entrada
para poner todos los equipos en el dominio
<hostid role="domainname">.ejemplo.com</hostid> Kerberos
<literal>EJEMPLO.COM</literal>. Puede actualizar su
<filename>krb.realms</filename> del siguiente modo:</para>
<screen>&prompt.root; <userinput>cat krb.realms</userinput>
grunt.ejemplo.com EJEMPLO.COM
.ejemplo.com EJEMPLO.COM
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDU</screen>
<para>Igual que en caso previo, no tiene por qué incluir
los demás dominios. Se han incluido para mostrar
cómo puede usar una máquina en múltiples
dominios. Puede eliminarlos y simplificar la
configuración.</para>
<para>La primera línea pone al sistema
<emphasis>específico</emphasis>
en el dominio nombrado. El resto de las líneas muestran
cómo asignar por defecto sistemas de un subdominio
a un dominio Kerberos.</para>
<para>Ya podemos crear la base de datos. Solo se ejecuta en el
servidor Kerberos (o centro de distribución de
llaves). Ejecute <command>kdb_init</command>:</para>
<screen>&prompt.root; <userinput>kdb_init</userinput>
<prompt>Realm name [default ATHENA.MIT.EDU ]:</prompt> <userinput>EJEMPLO.COM</userinput>
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
<prompt>Enter Kerberos master key:</prompt> </screen>
<para>Ahora tendremos que guardar la llave para que los servidores en
la máquina local puedan recogerla. Utilice
<command>kstash</command>:</para>
<screen>&prompt.root; <userinput>kstash</userinput>
<prompt>Enter Kerberos master key:</prompt>
Current Kerberos master key version is 1.
Master key entered. BEWARE!</screen>
<para>Esto guarda la contraseña cifrada
maestra en <filename>/etc/kerberosIV/master_key</filename>.</para>
</sect2>
<sect2>
<title>Puesta en marcha del sistema</title>
<indexterm>
<primary>KerberosIV</primary>
<secondary>encendido inicial</secondary>
</indexterm>
<para>Tendrá que añadir a la base de datos dos
entradas en concreto para <emphasis>cada</emphasis> sistema
que vaya a usar Kerberos: <literal>kpasswd</literal> y
<literal>rcmd</literal>. Se hacen para cada sistema individualmente
cada sistema, y el campo <quote>instance</quote> es el nombre
individual del sistema.</para>
<para>Estos dæmons <application>kpasswd</application> y
<application>rcmd</application> permiten a otros sistemas
cambiar contraseñas de Kerberos y ejecutar órdenes
como &man.rcp.1;, &man.rlogin.1; y &man.rsh.1;.</para>
<para>Ahora vamos a añadir estas entradas:</para>
<screen>&prompt.root; <userinput>kdb_edit</userinput>
Opening database...
<prompt>Enter Kerberos master key:</prompt>
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
<prompt>Principal name:</prompt> <userinput>passwd</userinput>
<prompt>Instance:</prompt> <userinput>grunt</userinput>
<Not found>, <prompt>Create [y] ?</prompt> <userinput>y</userinput>
Principal: passwd, Instance: grunt, kdc_key_ver: 1
<prompt>New Password:</prompt> <---- tecleo aleatorio
Verifying password
<prompt>New Password:</prompt> <---- tecleo aleatorio
<prompt>Random password [y] ?</prompt> <userinput>y</userinput>
Principal's new key version = 1
<prompt>Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?</prompt>
<prompt>Max ticket lifetime (*5 minutes) [ 255 ] ?</prompt>
<prompt>Attributes [ 0 ] ?</prompt>
Edit O.K.
<prompt>Principal name:</prompt> <userinput>rcmd</userinput>
<prompt>Instance:</prompt> <userinput>grunt</userinput>
<Not found>, <prompt>Create [y] ?</prompt>
Principal: rcmd, Instance: grunt, kdc_key_ver: 1
<prompt>New Password:</prompt> <---- tecleo aleatorio
Verifying password
<prompt>New Password:</prompt> <---- tecleo aleatorio
<prompt>Random password [y] ?</prompt>
Principal's new key version = 1
<prompt>Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?</prompt>
<prompt>Max ticket lifetime (*5 minutes) [ 255 ] ?</prompt>
<prompt>Attributes [ 0 ] ?</prompt>
Edit O.K.
<prompt>Principal name:</prompt> <---- si introduce datos nulos saldrá del programa</screen>
</sect2>
<sect2>
<title>Creación del fichero del servidor</title>
<para>Ahora tendremos que extraer todas las instancias que definen
los servicios en cada máquina; para ello usaremos
<command>ext_srvtab</command>. Esto creará un
fichero que debe ser copiado o movido <emphasis>por medios
seguros</emphasis> al directorio
<filename>/etc/kerberosIV</filename> de cada
cliente Kerberos. Este fichero debe existir en todos los
servidores y clientes dada su importancia clave para el
funcionamiento de Kerberos.</para>
<screen>&prompt.root; <userinput>ext_srvtab grunt</userinput>
<prompt>Enter Kerberos master key:</prompt>
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....</screen>
<para>Esta orden solo genera un fichero temporal al que tendrá
que cambiar el nombre a <filename>srvtab</filename> para que todos
los servidores puedan recogerlo. Utilice
&man.mv.1; para moverlo al lugar correcto en el sistema
original:</para>
<screen>&prompt.root; <userinput>mv grunt-new-srvtab srvtab</userinput></screen>
<para>Si el fichero es para un sistema cliente y la red no puede
considerarse segura copie el
<filename><replaceable>cliente</replaceable>-new-srvtab</filename>
en un medio extraíble y transpórtelo por medios
físicos seguros. Asegúrese de cambiar su nombre a
<filename>srvtab</filename> en el directorio
<filename>/etc/kerberosIV</filename> del cliente, y
asegúrese también de que tiene modo 600:</para>
<screen>&prompt.root; <userinput>mv grumble-new-srvtab srvtab</userinput>
&prompt.root; <userinput>chmod 600 srvtab</userinput></screen>
</sect2>
<sect2>
<title>Añadir entradas a la base de datos</title>
<para>Ahora tenemos que añadir entradas de usuarios a la
base de datos. Primero vamos a crear una entrada para el usuario
<username>jane</username>. Para ello usaremos
<command>kdb_edit</command>:</para>
<screen>&prompt.root; <userinput>kdb_edit</userinput>
Opening database...
<prompt>Enter Kerberos master key:</prompt>
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
<prompt>Principal name:</prompt> <userinput>jane</userinput>
<prompt>Instance:</prompt>
<Not found>, <prompt>Create [y] ?</prompt> <userinput>y</userinput>
Principal: jane, Instance: , kdc_key_ver: 1
<prompt>New Password:</prompt> <---- introduzca una constraseña segura
Verifying password
<prompt>New Password:</prompt> <---- introduzca de nuevo la contraseña
Principal's new key version = 1
<prompt>Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?</prompt>
<prompt>Max ticket lifetime (*5 minutes) [ 255 ] ?</prompt>
<prompt>Attributes [ 0 ] ?</prompt>
Edit O.K.
<prompt>Principal name:</prompt> <---- si introduce datos nulos saldrá del programa</screen>
</sect2>
<sect2>
<title>Prueba del sistema</title>
<para>Primero tenemos que iniciar los dæmons de Kerberos.
Tenga en cuenta que si su <filename>/etc/rc.conf</filename>
está configurado correctamente el inicio tendrá
ligar cuando reinicie el sistema. Esta prueba solo es necesaria
en el servidor Kerberos; los clientes Kerberos tomarán
lo que necesiten automáticamente desde el directorio
<filename>/etc/kerberosIV</filename>.</para>
<screen>&prompt.root; <userinput>kerberos &</userinput>
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: EJEMPLO.COM
&prompt.root; <userinput>kadmind -n &</userinput>
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead
Current Kerberos master key version is 1.
Master key entered. BEWARE!</screen>
<para>Ahora podemos probar a usar <command>kinit</command>
para obtener un ticket para el ID <username>jane</username>
que creamos antes:</para>
<screen>&prompt.user; <userinput>kinit jane</userinput>
MIT Project Athena (grunt.ejemplo.com)
Kerberos Initialization for "jane"
<prompt>Password:</prompt> </screen>
<para>Pruebe a listar los tokens con <command>klist</command> para ver
si realmente están:</para>
<screen>&prompt.user; <userinput>klist</userinput>
Ticket file: /tmp/tkt245
Principal: jane@EJEMPLO.COM
Issued Expires Principal
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EJEMPLO.COM@EJEMPLO.COM</screen>
<para>Ahora trate de cambiar la contraseña usando
&man.passwd.1; para comprobar si el dæmon
<application>kpasswd</application> está autorizado
a acceder a la base de datos Kerberos:</para>
<screen>&prompt.user; <userinput>passwd</userinput>
realm EJEMPLO.COM
<prompt>Old password for jane:</prompt>
<prompt>New Password for jane:</prompt>
Verifying password
<prompt>New Password for jane:</prompt>
Password changed.</screen>
</sect2>
<sect2>
<title>Añadir privilegios de <command>su</command></title>
<para>Kerberos nos permite dar a <emphasis>cada</emphasis>
usuario que necesite privilegios de <username>root</username>
su <emphasis>propia</emphasis> contraseña para &man.su.1;.
Podemos agregar un ID que esté autorizado a ejecutar
&man.su.1; <username>root</username>. Esto se controla
con una instancia de <username>root</username>
asociada con un usuario. Vamos a crear una entrada
<literal>jane.root</literal> en la base de datos, para lo que
recurrimos a <command>kdb_edit</command>:</para>
<screen>&prompt.root; <userinput>kdb_edit</userinput>
Opening database...
<prompt>Enter Kerberos master key:</prompt>
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
<prompt>Principal name:</prompt> <userinput>jane</userinput>
<prompt>Instance:</prompt> <userinput>root</userinput>
<Not found>, Create [y] ? y
Principal: jane, Instance: root, kdc_key_ver: 1
<prompt>New Password:</prompt> <---- introduzca una contraseña SEGURA
Verifying password
<prompt>New Password:</prompt> <---- introduzca otra vez la constraseña
Principal's new key version = 1
<prompt>Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?</prompt>
<prompt>Max ticket lifetime (*5 minutes) [ 255 ] ?</prompt> <userinput>12</userinput> <--- Keep this short!
<prompt>Attributes [ 0 ] ?</prompt>
Edit O.K.
<prompt>Principal name:</prompt> <---- si introduce datos nulos saldrá del programa</screen>
<para>Ahora trate de obtener los tokens para comprobar que
todo funciona:</para>
<screen>&prompt.root; <userinput>kinit jane.root</userinput>
MIT Project Athena (grunt.ejemplo.com)
Kerberos Initialization for "jane.root"
<prompt>Password:</prompt></screen>
<para>Hemos de agregar al usuario al
<filename>.klogin</filename> de <username>root</username>:</para>
<screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
jane.root@EJEMPLO.COM</screen>
<para>Ahora trate de hacer &man.su.1;:</para>
<screen>&prompt.user; <userinput>su</userinput>
<prompt>Password:</prompt></screen>
<para>y eche un vistazo a qué tokens tenemos:</para>
<screen>&prompt.root; <userinput>klist</userinput>
Ticket file: /tmp/tkt_root_245
Principal: jane.root@EJEMPLO.COM
Issued Expires Principal
May 2 20:43:12 May 3 04:43:12 krbtgt.EJEMPLO.COM@EJEMPLO.COM</screen>
</sect2>
<sect2>
<title>Uso de otras órdenes</title>
<para>En un ejemplo anterior creamos un usuario llamado
<literal>jane</literal> con una instancia <literal>root</literal>.
Nos basamos en un usuario con el mismo nombre del
<quote>principal</quote> (<literal>jane</literal>),
el procedimiento por defecto en Kerberos:
<literal><principal>.<instancia></literal> con la
estructura
<literal><nombre de usuario>.</literal><username>root</username>
permitirá que <literal><nombre de usuario></literal>
haga &man.su.1; a <username>root</username> si existen
las entradas necesarias en el
<filename>.klogin</filename> que hay en el directorio home de
<username>root</username>:</para>
<screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
jane.root@EJEMPLO.COM</screen>
<para>De la misma manera, si un usuario tiene en su directorio home
lo siguiente:</para>
<screen>&prompt.user; <userinput>cat ~/.klogin</userinput>
jane@EJEMPLO.COM
jack@EJEMPLO.COM</screen>
<para>significa que cualquier usuario del dominio
<literal>EJEMPLO.COM</literal> que se identifique como
<username>jane</username> o como <username>jack</username>
(vía <command>kinit</command>, ver más arriba)
podrá acceder a la cuenta de <username>jane</username> o
a los ficheros de este sistema (<hostid>grunt</hostid>) vía
&man.rlogin.1;, &man.rsh.1; o
&man.rcp.1;.</para>
<para>Veamos por ejemplo cómo <username>jane</username> se
se identifica en otro sistema mediante Kerberos:</para>
<screen>&prompt.user; <userinput>kinit</userinput>
MIT Project Athena (grunt.ejemplo.com)
<prompt>Password:</prompt>
&prompt.user; <userinput>rlogin grunt</userinput>
Last login: Mon May 1 21:14:47 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<para>Aquí <username>jack</username> se identifica con la
cuenta de <username>jane</username> en la misma
máquina (<username>jane</username> tiene configurado
su fichero <filename>.klogin</filename> como se ha mostrado
antes, y la persona encargada de la administración de
Kerberos ha configurado un usuario principal
<emphasis>jack</emphasis> con una instancia nula):</para>
<screen>&prompt.user; <userinput>kinit</userinput>
&prompt.user; <userinput>rlogin grunt -l jane</userinput>
MIT Project Athena (grunt.ejemplo.com)
<prompt>Password:</prompt>
Last login: Mon May 1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
</sect2>
</sect1>
<sect1 id="kerberos5">
<sect1info>
<authorgroup>
<author>
<firstname>Tillman</firstname>
<surname>Hodgson</surname>
<contrib>Texto de </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Mark</firstname>
<surname>Murray</surname>
<contrib>Basado en un texto de </contrib>
</author>
</authorgroup>
</sect1info>
<title><application>Kerberos5</application></title>
<para>Cada versión de &os; posterior a &os;-5.1 incluye
soporte solamente para <application>Kerberos5</application>.
Por esta razón <application>Kerberos5</application> es
la única versión incluida. Su configuración
es similar en muchos aspectos a la de
<application>KerberosIV</application>.
La siguiente información solo atañe a
<application>Kerberos5</application> en versiones de
&os;-5.0 o posteriores. Los usuarios que deséen
utilizar <application>KerberosIV</application> pueden
instalar el port
<filename role="package">security/krb4</filename>.</para>
<para><application>Kerberos</application> es un sistema/protocolo
agregado para red que permite a los usuarios validar su identidad
a través de los servicios de un servidor seguro.
Los servicios como login remoto, copia remota, copias
de fichero de un sistema a otro y otras tareas generalmente
consideradas poco seguras pasan a ser considerablemente
seguras y más controlables.</para>
<para><application>Kerberos</application> puede describirse como
un sistema proxy identificador/verificador. También
puede describirse como un sistema confiable de autentificación
de terceros.
<application>Kerberos</application> solamente ofrece una
función: la validación segura de usuarios a
través de una red. No proporciona funciones de
autorización (es decir, lo que los usuarios tienen
permitido hacer) o funciones de auditoría (lo que esos
usuarios hicieron). Después de que un servidor y un
cliente han usado <application>Kerberos</application> para
demostrar su identidad pueden también cifrar todas sus
sus comunicaciones, asegurando de este modo su intimidad y la
integridad de sus datos durante su uso del sistema.</para>
<para>Es, por tanto, altamente recomendable que se use
<application>Kerberos</application>
<emphasis>además</emphasis> de otros métodos de
seguridad que ofrezcan servicios de autorización
y auditoría.</para>
<para>Puede usar las siguientes instrucciones como una guía
para configurar <application>Kerberos</application> tal y como se
distribuye en &os;. De todas maneras, debería consultar
las páginas de manual adecuadas para tener toda la
información.</para>
<para>Vamos a mostrar una instalación
<application>Kerberos</application>, para lo cual usaremos
los siguientes espacios de nombres:</para>
<itemizedlist>
<listitem>
<para>El dominio <acronym>DNS</acronym> (<quote>zona</quote>)
será ejemplo.org.</para>
</listitem>
<listitem>
<para>El dominio <application>Kerberos</application> (realm)
será EJEMPLO.ORG.</para>
</listitem>
</itemizedlist>
<note>
<para>Debe utilizar nombres de dominio reales al
configurar <application>Kerberos</application> incluso si
pretende ejecutarlo internamente. Esto le evitará problemas
de <acronym>DNS</acronym> y asegura la interoperación
con otros dominios <application>Kerberos</application>.</para>
</note>
<sect2>
<title>Historia</title>
<indexterm>
<primary>Kerberos5</primary>
<secondary>historia</secondary>
</indexterm>
<para><application>Kerberos</application> fué creado
en el Massachusetts Institute of Technology
(<acronym>MIT</acronym>) como una solución
a los problemas de seguridad de la red.
El protocolo <application>Kerberos</application> utiliza
criptografía fuerte para que un cliente pueda
demostrar su identidad en un servidor (y viceversa) a
través de una conexión de red insegura.</para>
<para><application>Kerberos</application> es el nombre de un
protocolo de autentificación vía red y un adjetivo
para describir programas que implementan el programa
(<application>Kerberos</application> telnet, por ejemplo,
conocido también como el
<quote>telnet kerberizado</quote>).
La versión actual del protocolo es la 5, descrita en
<acronym>RFC</acronym> 1510.</para>
<para>Existen diversas implementaciones libres de este protocolo,
cubriendo un amplio rango de sistemas operativos.
El <acronym>MIT</acronym>, donde <application>Kerberos</application>
fué desarrollado, continúa desarrollando su
propio paquete <application>Kerberos</application>.
Suele usarse en los EEUU como producto criptográfico
y como tal ha sufrido las regulaciones de exportación
de los EEUU. El
<application>Kerberos</application> del <acronym>MIT</acronym>
existe como un port en
(<filename role="package">security/krb5</filename>). Heimdal
<application>Kerberos</application> es otra implementación
de la versión 5, y fué desarrollada de forma
intencionada fuera de los <acronym>EEUU</acronym> para sortear las
regulaciones de exportación (y por eso puede incluirse
en versiones no comerciales de &unix;). La distribución
Heimdal <application>Kerberos</application> está en el
port (<filename role="package">security/heimdal</filename>), y
se incluye una instalación mínima en el sistema
base de &os;.</para>
<para>Para alcanzar la mayor audiencia estas instrucciones asumen
el uso de la distribución Heimdal incluída en &os;.</para>
</sect2>
<sect2>
<title>Configuración de un <acronym>KDC</acronym> Heimdal</title>
<indexterm>
<primary>Kerberos5</primary>
<secondary>Centro de distribución de llaves</secondary>
</indexterm>
<para>El centro de distribución de llaves (<acronym>KDC</acronym>,
Key Distribution Center) es el servicio centralizado de
validación que proporciona
<application>Kerberos</application>: es el sistema que emite
tickets <application>Kerberos</application>.
El <acronym>KDC</acronym> goza del estátus de ser
considerado como <quote>confiable</quote> por las demás
computadoras del dominio <application>Kerberos</application>,
y por eso tiene consideraciones de seguridad más
elevadas.</para>
<para>Tenga en cuenta que, aunque la ejecución del servidor
<application>Kerberos</application> requiere muy pocos recursos,
se recomienda el uso de una máquina dedicada a
<acronym>KDC</acronym> por razones de seguridad.</para>
<para>Para empezar a configurar un <acronym>KDC</acronym> asegúrese
de que su <filename>/etc/rc.conf</filename> contenga la
configuración adecuada para actuar como <acronym>KDC</acronym>
(tal vez deba ajustar algunas rutas para que cuadren con su
sistema):</para>
<programlisting>kerberos5_server_enable="YES"
kadmind5_server_enable="YES"
kerberos_stash="YES"</programlisting>
<note>
<para><option>kerberos_stash</option> solo existe en
&os; 4.X.</para>
</note>
<para>A continuación configuraremos el fichero de
configuración de <application>Kerberos</application>,
<filename>/etc/krb5.conf</filename>:</para>
<programlisting>[libdefaults]
default_realm = EJEMPLO.ORG [realms]
EXAMPLE.ORG = {
kdc = kerberos.ejemplo.org
admin_server = kerberos.ejemplo.org
}
[domain_realm]
.ejemplo.org = EJEMPLO.ORG</programlisting>
<para>Tenga en cuenta que este <filename>/etc/krb5.conf</filename>
implica que su <acronym>KDC</acronym> tendrá el nombre
de equipo completo calificado de
<hostid role="fqdn">kerberos.ejemplo.org</hostid>.
Necesitará añadir una entrada CNAME (alias) a su
fichero de zona si su <acronym>KDC</acronym> tiene un
nombre de equipo diferente.</para>
<note>
<para>En grandes redes con un servidor <acronym>DNS</acronym>
<acronym>BIND</acronym> bien configurado, el ejemplo
de arriba puede quedar del siguiente modo:</para>
<programlisting>[libdefaults]
default_realm = EJEMPLO.ORG</programlisting>
<para>Con las siguientes líneas agregadas al
fichero de zona <hostid role="fqdn">ejemplo.org</hostid>:</para>
<programlisting>_kerberos._udp IN SRV 01 00 88 kerberos.ejemplo.org.
_kerberos._tcp IN SRV 01 00 88 kerberos.ejemplo.org.
_kpasswd._udp IN SRV 01 00 464 kerberos.ejemplo.org.
_kerberos-adm._tcp IN SRV 01 00 749 kerberos.ejemplo.org.
_kerberos IN TXT EJEMPLO.ORG</programlisting></note>
<note>
<para>Para que los clientes sean capaces de encontrar los
servicios <application>Kerberos</application>
<emphasis>debe</emphasis> tener ya sea un
<filename>/etc/krb5.conf</filename> configurado o
un <filename>/etc/krb5.conf</filename> configurado de forma
mínima <emphasis>y</emphasis> un servidor DNS
configurado correctamente.</para>
</note>
<para>A continuación crearemos la base de datos
<application>Kerberos</application>. Esta base de datos contiene
las llaves de todos los principales cifradas con una
contraseña maestra. No es necesario que recuerde
esta contraseña, pues se almacenará en
<filename>/var/heimdal/m-key</filename>. Para crear la llave
maestra ejecute <command>kstash</command> e introduzca una
contraseña.</para>
<para>Una vez que se ha creado la llave maestra puede inicializar
la base de datos usando el programa <command>kadmin</command>
con la opción <literal>-l</literal> (que significa
<quote>local</quote>). Esta opción le dice a
<command>kadmin</command> que modifique los ficheros de la base
de datos directamente en lugar de ir a través del servicio
de red <command>kadmind</command>. Esto gestiona el problema del
huevo y la gallina de tratar de conectar a la base de datos
antes de que ésta exista. Una vez que tiene el
<quote>prompt</quote> de <command>kadmin</command>, utilice
<command>init</command> para crear su base de datos de
dominios iniciales.</para>
<para>Para terminar, mientras está todavía en
<command>kadmin</command> puede crear su primer principal
mediante <command>add</command>. Utilice las opciones por
defecto por ahora, más tarde puede cambiarlas mediante
<command>modify</command>. Recuerde que puede usar
<literal>?</literal> en cualquier <quote>prompt</quote> para
consultar las opciones disponibles.</para>
<para>Veamos un ejemplo de sesión de creación de una
base de datos:</para>
<screen>&prompt.root; <userinput>kstash</userinput>
Master key: <userinput>xxxxxxxx</userinput>
Verifying password - Master key: <userinput>xxxxxxxx</userinput>
&prompt.root; <userinput>kadmin -l</userinput>
kadmin> <userinput>init EJEMPLO.ORG</userinput>
Realm max ticket life [unlimited]:
kadmin> <userinput>add tillman</userinput>
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
Password: <userinput>xxxxxxxx</userinput>
Verifying password - Password: <userinput>xxxxxxxx</userinput></screen>
<para>Ahora puede arrancar los servicios <acronym>KDC</acronym>.
Ejecute <command>/etc/rc.d/kerberos start</command> y
<command>/etc/rc.d/kadmind start</command> para levantar dichos
servicios. Recuerde que no tendrá ningún
dæmon kerberizado ejecutándose pero debe
poder confirmar que <acronym>KDC</acronym> funciona por el
procedimiento de obtener y listar un boleto del principal
(usuario) que acaba de crear en la línea de órdenes de
<acronym>KDC</acronym>:</para>
<screen>&prompt.user; <userinput>k5init <replaceable>tillman</replaceable></userinput>
tillman@EJEMPLO.ORG's Password:
&prompt.user; <userinput>k5list</userinput>
Credentials cache: FILE:<filename>/tmp/krb5cc_500</filename>
Principal: tillman@EJEMPLO.ORG
Issued Expires Principal
Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EJEMPLO.ORG@EJEMPLO.ORG</screen>
</sect2>
<sect2>
<title>Creación de un servidor
<application>Kerberos</application> con servicios
Heimdal</title>
<indexterm>
<primary>Kerberos5</primary>
<secondary>habilitación de servicios</secondary>
</indexterm>
<para>Antes de nada necesitaremos una copia del fichero de
configuración de <application>Kerberos</application>,
<filename>/etc/krb5.conf</filename>. Cópielo al cliente
desde <acronym>KDC</acronym> de forma segura (mediante
&man.scp.1;, o usando un disquete).</para>
<para>A continuación necesitará un fichero
<filename>/etc/krb5.keytab</filename>.
Esta es la mayor diferencia entre un servidor que proporciona
dæmons habilitados con <application>Kerberos</application>
y una estación de trabajo: el servidor debe
tener un fichero <filename>keytab</filename>. Dicho fichero
contiene las llaves de equipo del servidor, las cuales
le permiten a él y al <acronym>KDC</acronym>
verificar la identidad entre ellos. Deben transmitirse
al servidor de forma segura ya que la seguridad del servidor
puede verse comprometida si la llave se hace pública.
Por decirlo más claro, transferirla como texto plano a
través de la red (por ejemplo por
<acronym>FTP</acronym>) es una <emphasis>pésima
idea</emphasis>.</para>
<para>Lo normal es que transmita su <filename>keytab</filename>
al servidor mediante el programa <command>kadmin</command>.
Esto es práctico porque también debe crear
el principal del equipo (el <acronym>KDC</acronym> que aparece
al final de <filename>krb5.keytab</filename>)
usando <command>kadmin</command>.</para>
<para>Tenga en cuenta que ya debe disponer de un ticket, y que
este ticket debe poder usar el interfaz
<command>kadmin</command> en <filename>kadmind.acl</filename>.
Consulte la sección
<quote>administración remota</quote> en la página
info de Heimdal (<command>info heimdal</command>), donde se
exponen los detalles de diseño de las listas de control de
acceso. Si no quiere habilitar acceso remoto
<command>kadmin</command>, puede conectarse de forma segura al
<acronym>KDC</acronym> (por medio de consola
local, &man.ssh.1; o &man.telnet.1;
<application>Kerberos</application>) y administrar en local
mediante <command>kadmin -l</command>.</para>
<para>Después de instalar el fichero
<filename>/etc/krb5.conf</filename> puede usar
<command>kadmin</command> desde el servidor
<application>Kerberos</application>.
<command>add --random-key</command> le permitirá
añadir el principal del equipo servidor, y
<command>ext</command> le permitirá extraer el principal
del equipo servidor a su propio keybat. Por ejemplo:</para>
<screen>&prompt.root; <userinput>kadmin</userinput>
kadmin><userinput> add --random-key host/myserver.ejemplo.org</userinput>
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
kadmin><userinput> ext host/miservidor.ejemplo.org</userinput>
kadmin><userinput> exit</userinput></screen>
<para>Tenga en cuenta que <command>ext</command>
(contracción de <quote>extract</quote>) almacena la
llave extraída por defecto en
en <filename>/etc/krb5.keytab</filename>.</para>
<para>Si no tiene <command>kadmind</command>
ejecutándose en
<acronym>KDC</acronym> (posiblemente por razones de seguridad)
y por lo tanto carece de acceso remoto a <command>kadmin</command>
puede añadir el principal de equipo
(<username>host/miservidor.EJEMPLO.ORG</username>) directamente
en el <acronym>KDC</acronym> y entonces extraerlo a un fichero
temporal (para evitar sobreescribir
<filename>/etc/krb5.keytab</filename> en el
<acronym>KDC</acronym>) mediante algo parecido a esto:</para>
<screen>&prompt.root; <userinput>kadmin</userinput>
kadmin><userinput> ext --keytab=/tmp/ejemplo.keytab host/miservidor.ejemplo.org</userinput>
kadmin><userinput> exit</userinput></screen>
<para>Puede entonces copiar de forma segura el keytab al
servidor (usando <command>scp</command> o un diquete).
Asegúrese de usar un nombre de keytab diferente
para evitar sobreescribir el keytab en el
<acronym>KDC</acronym>.</para>
<para>Su servidor puede comunicarse con el
<acronym>KDC</acronym> (gracias a su fichero
<filename>krb5.conf</filename>) y puede probar su propia
identidad (gracias al fichero <filename>krb5.keytab</filename>).
Ahora está listo para que usted habilite algunos
servicios <application>Kerberos</application>.
En este ejemplo habilitaremos el servicio <command>telnet</command>
poniendo una línea como esta en su
<filename>/etc/inetd.conf</filename> y reiniciando el
servicio &man.inetd.8; con
<command>/etc/rc.d/inetd restart</command>:</para>
<programlisting>telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user</programlisting>
<para>La parte crítica es <command>-a</command>,
de autentificación de usuario. Consulte
la página de manual &man.telnetd.8; para
más información.</para>
</sect2>
<sect2>
<title><application>Kerberos</application> con un cliente
Heimdal</title>
<indexterm>
<primary>Kerberos5</primary>
<secondary>configurar clientes</secondary>
</indexterm>
<para>Configurar una computadora cliente es extremadamente
fácil. Lo único que necesita es el
fichero de configuración de
<application>Kerberos</application> que encontrará
en <filename>/etc/krb5.conf</filename>.
Simplemente cópielo de forma segura a la computadora
cliente desde el <acronym>KDC</acronym>.</para>
<para>Pruebe su computadora cliente mediante
<command>kinit</command>, <command>klist</command>, y
<command>kdestroy</command> desde el cliente para obtener,
mostrar y luego borrar un ticket para el principal que
creó antes. Debería poder usar aplicaciones
<application>Kerberos</application> para conectarse a
servidores habilitados con <application>Kerberos</application>,
aunque si no funciona y tiene problemas al intentar obtener
el boleto lo más probable es que el problema
esté en el servidor y no en el cliente o el
<acronym>KDC</acronym>.</para>
<para>Al probar una aplicación como <command>telnet</command>,
trate de usar un <quote>sniffer</quote> de paquetes
( como &man.tcpdump.1;) para confirmar que su contraseña
no viaja en claro por la red.
Trate de usar <command>telnet</command> con la opción
<literal>-x</literal>, que cifra el flujo de datos por
entero (algo parecido a lo que hace
<command>ssh</command>).</para>
<para>Las aplicaciones clientes <application>Kerberos</application>
principales (llamadas tradicionalmente <command>kinit</command>,
<command>klist</command>, <command>kdestroy</command> y
<command>kpasswd</command>) están incluidas en
la instalación base de &os;. Tenga en cuenta que
en las versiones de &os; anteriores a 5.0 reciben los nombres de
<command>k5init</command>,
<command>k5list</command>, <command>k5destroy</command>,
<command>k5passwd</command> y <command>k5stash</command>.</para>
<para>También se instalan por defecto diversas aplicaciones
<application>Kerberos</application> que no entran dentro de
la categoría de <quote>imprescindibles</quote>.
Es aquí donde la naturaleza
<quote>mínima</quote> de la instalación base de
Heimdal salta a la palestra: <command>telnet</command> es el
único servicio <application>Kerberos</application>
habilitado.</para>
<para>El port Heimdal añade algunas de las aplicaciones
cliente que faltan: versiones <application>Kerberos</application>
de <command>ftp</command>, <command>rsh</command>,
<command>rcp</command>, <command>rlogin</command> y algunos
otros programas menos comunes. El port del <acronym>MIT</acronym>
también contiene una suite completa de aplicaciones
cliente de <application>Kerberos</application>.</para>
</sect2>
<sect2>
<title>Ficheros de configuración de usuario: <filename>.k5login</filename> y <filename>.k5users</filename></title>
<indexterm>
<primary><filename>.k5login</filename></primary>
</indexterm>
<indexterm>
<primary><filename>.k5users</filename></primary>
</indexterm>
<para>Suele ser habitual que los usuarios de un dominio
<application>Kerberos</application> (o <quote>principales</quote>)
tengan su usuario
(por ejemplo <username>tillman@EJEMPLO.ORG</username>) mapeado
a una cuenta de usuario local (por ejemplo un usuario llamado
llamado <username>tillman</username>). Las aplicaciones cliente
como <command>telnet</command> normalmente no requieren un
nombre de usuario o un principal.</para>
<para>Es posible que de vez en cuando quiera dar acceso a una
una cuenta de usuario local a alguien que no tiene un
principal <application>Kerberos</application>.
Por ejemplo, <username>tillman@EJEMPLO.ORG</username> puede
necesitar acceso a la cuenta de usuario local
<username>webdevelopers</username>.
Otros principales tal vez necesiten acceso a esas
cuentas locales.</para>
<para>Los ficheros <filename>.k5login</filename> y
<filename>.k5users</filename>, ubicados en el directorio
home del usuario, pueden usarse de un modo similar a
una combinación potente de
<filename>.hosts</filename> y <filename>.rhosts</filename>.
Por ejemplo, si pusiera un fichero
<filename>.k5login</filename> con el siguiente
contenido</para>
<screen>tillman@example.org
jdoe@example.org</screen>
<para>en el directorio home del usuario local
<username>webdevelopers</username> ambos
principales listados tendrían acceso a esa cuenta
sin requerir una contraseña compartida.</para>
<para>Le recomendamos encarecidamente la lectura de las
páginas de manual de estas órdenes. Recuerde que
la página de manual de
<command>ksu</command> abarca
<filename>.k5users</filename>.</para>
</sect2>
<sect2>
<title><application>Kerberos</application> Sugerencias, trucos y
solución de problemas</title>
<indexterm>
<primary>Kerberos5</primary>
<secondary>solución de problemas</secondary>
</indexterm>
<itemizedlist>
<listitem>
<para>Tanto si utiliza el port de Heimdal o
el <application>Kerberos</application>
del <acronym>MIT</acronym> asegúrese de que su
variable de entorno <envar>PATH</envar> liste las
versiones de <application>Kerberos</application> de las
aplicaciones cliente antes que las versiones del
sistema.</para>
</listitem>
<listitem>
<para>?Todas las computadoras de su dominio Kerberos
tienen la hora sincronizada? Si no, la autentificación
puede fallar.
<xref linkend="network-ntp"/> describe como sincronizar
los relojes utilizando <acronym>NTP</acronym>.</para>
</listitem>
<listitem>
<para><acronym>MIT</acronym> y Heimdal conviven bien, con la
excepción de <command>kadmin</command>, protocolo
no está estandarizado.</para>
</listitem>
<listitem>
<para>Si cambia su nombre de equipo debe cambiar también
el <quote>apellido</quote> de su principal y actualizar su
keytab. Esto también se aplica a entradas especiales
en keytab como el principal <username>www/</username>
que usa el <filename role="package">www/mod_auth_kerb</filename>
de Apache.</para>
</listitem>
<listitem>
<para>Todos los equipos en su dominio Kerberos deben poder
resolverse (tanto en la forma normal normal como en la
inversa) en el <acronym>DNS</acronym> (o en
<filename>/etc/hosts</filename> como mínimo).
Los CNAME funcionarán, pero los registros A y PTR
deben ser correctos y estar en su sitio. El mensaje de error
que recibirá de no hacerlo así no es muy
intuitivo:
<errorname>Kerberos5 refuses authentication because Read req
failed: Key table entry not found</errorname>.</para>
</listitem>
<listitem>
<para>Algunos sistemas operativos que puede usar como clientes
de su <acronym>KDC</acronym> no activan
los permisos para <command>ksu</command> como
setuid <username>root</username>. Esto hará que
<command>ksu</command> no funcione, lo cual es muy seguro
pero un tanto molesto. Tenga en cuenta que no se debe a
un error de <acronym>KDC</acronym>.</para>
</listitem>
<listitem>
<para>Si desea permitir que un principal tenga un ticket con
una validez más larga que el valor por defecto de diez
horas en <application>Kerberos</application> del
<acronym>MIT</acronym> debe usar
<command>modify_principal</command> en <command>kadmin</command>
para cambiar <quote>maxlife</quote> tanto del principal en
cuestión como del <username>krbtgt</username> del
principal. Hecho esto,
el principal puede utilizar la opción
<literal>-l</literal> con <command>kinit</command> para
solicitar un boleto con más tiempo de vida.</para>
</listitem>
<listitem>
<note><para>Si ejecuta un <quote>sniffer</quote> de paquetes en su
<acronym>KDC</acronym> para ayudar con la resolución
de problemas y ejecuta <command>kinit</command> desde una
estación de trabajo puede encontrarse con que su
<acronym>TGT</acronym> se envía inmediatamente
después de ejecutar <command>kinit</command>:
<emphasis>incluso antes de que escriba su
contraseña</emphasis> La explicación es que el
servidor <application>Kerberos</application> transmite
tranquilamente un <acronym>TGT</acronym> (Ticket Granting
Ticket) a cualquier petición no autorizada; de todas
maneras, cada <acronym>TGT</acronym> está cifrado
en una llave derivada de la contraseña del usuario.
Por tanto, cuando un usuario teclea su contraseña
no la está enviando al <acronym>KDC</acronym>,
se está usando para descifrar el <acronym>TGT</acronym>
que <command>kinit</command> ya obtuvo. Si el proceso de
descifrado termina en un ticket válido con
una marca de tiempo válida, el usuario tiene
credenciales <application>Kerberos</application> válidas.
Estas credenciales incluyen una llave de sesión para
establecer comunicaciones seguras con el servidor
<application>Kerberos</application> en el futuro, así
como el TGT en sí, que se cifra con la llave del propio
servidor <application>Kerberos</application>.
Esta segunda capa de cifrado es invisible para el usuario, pero
es lo que permite al servidor <application>Kerberos</application>
verificar la autenticidad de cada
<acronym>TGT</acronym>.</para></note>
</listitem>
<listitem>
<para>Si desea utilizar tickets con un tiempo largo de vida (una
semana, por ejemplo) y está utilizando
<application>OpenSSH</application>
para conectarse a la máquina donde se almacena su
boleto asgúrese de que
<application>Kerberos</application>
<option>TicketCleanup</option> esté configurado a
<literal>no</literal> en su <filename>sshd_config</filename>
o de lo contrario sus tickets serán eliminados cuando
termine la sesión.</para>
</listitem>
<listitem>
<para>Recuerde que los principales de equipos también
pueden tener tener un tiempo de vida más largo.
Si su principal de usuario tiene un tiempo de vida de una
semana pero el equipo al que se conecta tiene un
tiempo de vida de nueve horas, tendrá un principal de
equipo expirado en su caché, y la caché de
ticket no funcionará como esperaba.</para>
</listitem>
<listitem>
<para>Cuando esté configurando un fichero
<filename>krb5.dict</filename> pensando específicamente
en prevenir el uso de contraseñas defectuosas (la
página de manual de
de <command>kadmind</command> trata el tema brevemente), recuerde
que solamente se aplica a principales que tienen una
política de contraseñas asignada. El formato
de los ficheros <filename>krb5.dict</filename> es simple:
una cadena de texto por línea. Puede serle
útil crear un enlace simbólico a
<filename>/usr/share/dict/words</filename>.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Diferencias con el port del <acronym>MIT</acronym></title>
<para>Las diferencias más grandes entre las instalaciones
<acronym>MIT</acronym> y Heimdal están relacionadas
con <command>kadmin</command>, que tiene un conjunto
diferente (pero equivalente) de órdenes y utiliza un protocolo
diferente. Esto tiene implicaciones muy grandes si su
<acronym>KDC</acronym> es <acronym>MIT</acronym>, ya que no
podrá utilizar el programa <command>kadmin</command>
de Heimdal para administrar remotamente su <acronym>KDC</acronym>
(o viceversa).</para>
<para>Las aplicaciones cliente pueden también disponer de
diferentes opciones de línea de órdenes para
lograr lo mismo. Le recomendamos seguir las instrucciones de
la página web de <application>Kerberos</application>
del <acronym>MIT</acronym>
(<ulink url="http://web.mit.edu/Kerberos/www/"></ulink>).
Sea cuidadoso con los parches: el port
del <acronym>MIT</acronym> se instala por defecto en
<filename>/usr/local/</filename>, y las
aplicaciones <quote>normales</quote> del sistema pueden
ser ejecutadas en lugar de las del <acronym>MIT</acronym>
si su variable de entorno <envar>PATH</envar> lista antes los
directorios del sistema.</para>
<note><para>Si usa el port del <acronym>MIT</acronym>
<filename role="package">security/krb5</filename>
proporcionado por &os; asegúrese de leer el fichero
<filename>/usr/local/share/doc/krb5/README.FreeBSD</filename>
instalado por el port si quiere entender por qué los
login vía <command>telnetd</command> y
<command>klogind</command> se comportan de un modo un tanto
extraño. Más importante aún, corregir la
conducta de <quote>permisos incorrectos en el fichero
caché</quote> requiere que el binario
<command>login.krb5</command> se use para la
validación para que pueda cambiar correctamente los
permisos de propiedad de credenciales reenviadas.</para></note>
</sect2>
<sect2>
<title>Mitigación de limitaciones encontradas en
<application>Kerberos</application></title>
<indexterm>
<primary>Kerberos5</primary>
<secondary>limitaciones y deficiencias</secondary>
</indexterm>
<sect3>
<title><application>Kerberos</application> es un enfoque
<quote>todo o nada</quote></title>
<para>Cada servicio habilitado en la red debe modificarse
para funcionar con <application>Kerberos</application> (o
debe ser asegurado contra ataques de red) o de lo
contrario las credenciales de usuario pueden robarse y
reutilizarse. Un ejemplo de esto podría ser que
<application>Kerberos</application> habilite todos los shells
remotos ( vía <command>rsh</command> y
<command>telnet</command>, por ejemplo) pero que no cubra
el servidor de correo <acronym>POP3</acronym>, que
envía contraseñas en texto plano.</para>
</sect3>
<sect3>
<title><application>Kerberos</application> está pensado
para estaciones de trabajo monousuario</title>
<para>En un entorno multiusuario
<application>Kerberos</application> es menos seguro.
Esto se debe a que almacena los tickets en el
directorio <filename>/tmp</filename>, que puede
ser leído por todos los usuarios. Si un
usuario está compartiendo una computadora con
varias personas (esto es, si utiliza un sistema
multiusuario) es posible que los tickets sean robados
(copiados) por otro usuario.</para>
<para>Esto puede solventarse con la opción de línea
de órdenes <literal>-c</literal> nombre-de-fichero o
(mejor aún) la variable de entorno
<envar>KRB5CCNAME</envar>, pero raramente se hace.
Si almacena los tickets en el directorio home de los
usuarios y utiliza sin mucha complicación los permisos
de fichero puede mitigar este problema.</para>
</sect3>
<sect3>
<title>El KDC es el punto crítico de fallo</title>
<para>Por motivos de diseño el <acronym>KDC</acronym>
es tan seguro como la base de datos principal de
contraseñas que contiene. El
<acronym>KDC</acronym> no debe ejecutar ningún
otro servicio ejecutándose en él y debe ser
físicamente seguro. El peligro es grande debido a que
<application>Kerberos</application> almacena todas las
contraseñas cifradas con la misma llave
(la llave <quote>maestra</quote>, que a su vez se guarda
como un fichero en el
<acronym>KDC</acronym>).</para>
<para>De todos modos una llave maestra comprometida no es
algo tan terrible como parece a primera vista. La llave maestra
solo se usa para cifrar la base de datos
<application>Kerberos</application> y como semilla para el
generador de números aleatorios. Mientras sea seguro
el acceso a su <acronym>KDC</acronym> un atancante no puede
hacer demasiado con la llave maestra.</para>
<para>Además, si el <acronym>KDC</acronym> no está
disponible (quizás debido a un ataque de denegación
de servicio o problemas de red) no se podrán utilizar
los servicios de red ya que no se puede efectuar la
validación, lo que hace que esta sea una buena forma de
lanzar un ataque de denegación de servicio.
Este problema puede aliviarse con múltiples
<acronym>KDC</acronym>s (un maestro y uno o más esclavos)
y con una implementación cautelosa de secundarios o
autentificación de respaldo (para esto
<acronym>PAM</acronym> es excelente).</para>
</sect3>
<sect3>
<title>Limitaciones de <application>Kerberos</application></title>
<para><application>Kerberos</application> le permite a usuarios,
equipos y servicios validarse entre sí, pero no
dispone de ningún mecanismo para autentificar el
<acronym>KDC</acronym> a los usuarios, equipos o servicios.
Esto significa que una versión
(por ejemplo) <quote>troyanizada</quote>
<command>kinit</command> puede grabar todos los usuarios y sus
contraseñas. Puede usar
<filename role="package">security/tripwire</filename> o
alguna otra herramienta de revisión de integridad
de sistemas de ficheros para intentar evitar problemas como
este.</para>
</sect3>
</sect2>
<sect2>
<title>Recursos y más información</title>
<indexterm>
<primary>Kerberos5</primary>
<secondary>recursos externos</secondary>
</indexterm>
<itemizedlist>
<listitem>
<para><ulink
url="http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html">
Las preguntas frecuentes (FAQ) de
<application>Kerberos</application></ulink></para>
</listitem>
<listitem>
<para><ulink url="http://web.mit.edu/Kerberos/www/dialogue.html">Designing an
Authentication System: a Dialog in Four Scenes</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://www.ietf.org/rfc/rfc1510.txt?number=1510">RFC 1510,
The <application>Kerberos</application> Network Authentication Service
(V5)</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://web.mit.edu/Kerberos/www/">Página web de <application>Kerberos</application>
del <acronym>MIT</acronym></ulink></para>
</listitem>
<listitem>
<para><ulink url="http://www.pdc.kth.se/heimdal/">Página web de
<application>Kerberos</application> Heimdal</ulink></para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="openssl">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Escrito por: </contrib>
</author>
</authorgroup>
</sect1info>
<title>OpenSSL</title>
<indexterm>
<primary>seguridad</primary>
<secondary>OpenSSL</secondary>
</indexterm>
<para>El conjunto de herramientas <application>OpenSSL</application>
es una característica de &os; que muchos usuarios
pasan por alto. <application>OpenSSL</application> ofrece una
capa de cifrada de transporte sobre la capa normal de
comunicación, permitiendo la combinación con
con muchas aplicaciones y servicios de red.</para>
<para>Algunos usos de <application>OpenSSL</application> son
la validación cifrada de clientes de correo, las
transacciones basadas en web como pagos con tarjetas de
crédito, etc. Muchos ports, como
<filename role="package">www/apache13-ssl</filename> y
<filename role="package">mail/sylpheed-claws</filename>
ofrecen soporte de compilación para
<application>OpenSSL</application>.</para>
<note>
<para>En la mayoría de los casos la colección
de ports tratará de compilar el port
<filename role="package">security/openssl</filename> a menos
que la variable de make <makevar>WITH_OPENSSL_BASE</makevar>
sea puesta explícitamente a <quote>yes</quote>.</para>
</note>
<para>La versión de <application>OpenSSL</application>
incluida en &os; soporta los protocolos de seguridad
de red Secure Sockets Layer v2/v3 (SSLv2/SSLv3) y
Transport Layer Security v1 (TLSv1) y puede utilizarse como
biblioteca criptográfica general.</para>
<note>
<para><application>OpenSSL</application> soporta el
algoritmo <acronym>IDEA</acronym> pero estáa deshabilitado
por defecto debido a patentes en vigor en los Estados Unidos.
Si quiere usarlo debe revisar la licencia, y si las
restricciones le parecen aceptables active la variable
<makevar>MAKE_IDEA</makevar> en
<filename>make.conf</filename>.</para>
</note>
<para>Uno de los usos más comunes de
<application>OpenSSL</application> es ofrecer certificados para
usar con aplicaciones de software. Estos certificados aseguran
que las credenciales de la compañia o individuo son
válidos y no son fraudulentos. Si el certificado en
cuestión no ha sido verificado por uno de las diversas
<quote>autoridades certificadoras</quote>
o <acronym>CA</acronym>, suele generarse una advertencia al respecto.
Una autoridad de certificados es una compañia, como
<ulink url="http://www.verisign.com">VeriSign</ulink>, que
firma certificados para validar credenciales de individuos
o compañias. Este proceso tiene un costo asociado y no es
un requisito imprescindible para usar certificados, aunque
puede darle un poco de tranquilidad a los usuarios
más paranóicos.</para>
<sect2>
<title>Generación de certificados</title>
<indexterm>
<primary>OpenSSL</primary>
<secondary>generación de certificados</secondary>
</indexterm>
<para>Para generar un certificado ejecute lo siguiente:</para>
<screen>&prompt.root; <userinput>openssl req -new -nodes -out req.pem -keyout cert.pem</userinput>
Generating a 1024 bit RSA private key
................++++++
.......................................++++++
writing new private key to 'cert.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:<userinput><replaceable>US</replaceable></userinput>
State or Province Name (full name) [Some-State]:<userinput><replaceable>PA</replaceable></userinput>
Locality Name (eg, city) []:<userinput><replaceable>Pittsburgh</replaceable></userinput>
Organization Name (eg, company) [Internet Widgits Pty Ltd]:<userinput><replaceable>Mi compañía</replaceable></userinput>
Organizational Unit Name (eg, section) []:<userinput><replaceable>Administrador de sistemas</replaceable></userinput>
Common Name (eg, YOUR name) []:<userinput><replaceable>localhost.ejemplo.org</replaceable></userinput>
Email Address []:<userinput><replaceable>trhodes@FreeBSD.org</replaceable></userinput>
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<userinput><replaceable>UNA CONTRASEÑA</replaceable></userinput>
An optional company name []:<userinput><replaceable>Otro nombre</replaceable></userinput></screen>
<para>Tenga en cuenta que la respuesta directamente después
de <quote>prompt</quote> <quote>Common Name</quote> muestra un
nombre de dominio. Este <quote>prompt</quote> requiere que se
introduzca un nombre de servidor para usarlo en la
verificación; si escribe cualquier otra cosa
producirá un certificado inválido.
Otras opciones, por ejemplo el tiempo
de expiración, alternan algoritmos de cifrado,
etc. Puede ver una lista completa en la página
de manual de &man.openssl.1;.</para>
<para>Debería tener dos ficheros en el directorio
donde ha ejecutado la orden anterior. La petición
de certificado,
<filename>req.pem</filename>, es lo que debe enviar a una
autoridad certificadora para que valide las credenciales que
introdujo; firmará la petición y le devolverá
el certificado. El segundo fichero es
<filename>cert.pem</filename> y es la llave privada para
el certificado, que debe proteger a toda costa; si cae en
malas manos podrí usarse para suplantarle a usted o a
sus servidores.</para>
<para>Si no necesita la firma de una <acronym>CA</acronym>
puede crear y firmar usted mismo su certificado.
Primero, genere la llave <acronym>RSA</acronym>:</para>
<screen>&prompt.root; <userinput>openssl dsaparam -rand -genkey -out <filename>myRSA.key</filename> 1024</userinput></screen>
<para>A continuación genere la llave <acronym>CA</acronym>:</para>
<screen>&prompt.root; <userinput>openssl gendsa -des3 -out <filename>myca.key</filename> <filename>myRSA.key</filename></userinput></screen>
<para>Utilice esta llave para crear el certificado:</para>
<screen>&prompt.root; <userinput>openssl req -new -x509 -days 365 -key <filename>myca.key</filename> -out <filename>new.crt</filename></userinput></screen>
<para>Deberín aparecer dos nuevos ficheros en su directorio:
un fichero de firma de autoridad de certificados
(<filename>myca.key</filename>) y el certificado en sí,
<filename>new.crt</filename>. Deben ubicarse en un directorio,
que se recomienda que sea
<filename class="directory">/etc</filename>, que es legible
solo para <username>root</username>. Para terminar, es recomendable
asignar permisos 0700 para el fichero con
<command>chmod</command>.</para>
</sect2>
<sect2>
<title>Uso de certificados; un ejemplo</title>
<para>?Qué pueden hacer estos ficheros?
Cifrar conexiones al <acronym>MTA</acronym>
<application>Sendmail</application> es un buen sitio para
usarlos. De este modo eliminará el uso de validación
mediante texto en claro para los usuarios que envían
correo a través del <acronym>MTA</acronym>
local.</para>
<note>
<para>No es el mejor uso en el mundo, ya que algunos
<acronym>MUA</acronym>s enviarán al usuario un
mensaje de error si no tiene instalados localmente los
certificados. Consulte la documentación
para más datos sobre la
instalación de certificados.</para>
</note>
<para>Debe añadir las siguientes líneas
en su fichero local <filename>.mc</filename>:</para>
<programlisting>dnl SSL Options
define(`confCACERT_PATH',`/etc/certs')dnl
define(`confCACERT',`/etc/certs/new.crt')dnl
define(`confSERVER_CERT',`/etc/certs/new.crt')dnl
define(`confSERVER_KEY',`/etc/certs/myca.key')dnl
define(`confTLS_SRV_OPTIONS', `V')dnl</programlisting>
<para><filename class="directory">/etc/certs/</filename>
es el directorio destinado a almacenamiento de
los ficheros de certificado y llave en local.
El último requisito es una reconstrucción
del fichero <filename>.cf</filename> local. Solo tiene que
teclear <command>make</command>
<parameter>install</parameter> en el directorio
<filename class="directory">/etc/mail</filename>.
A continuación ejecute un <command>make</command>
<parameter>restart</parameter>, que debería reiniciar el
dæmon <application>Sendmail</application>.</para>
<para>Si todo fué bien no habrá mensajes de error
en el fichero <filename>/var/log/maillog</filename>
y <application>Sendmail</application> aparecerá en
la lista de procesos.</para>
<para>Puede probarlo todo de una forma muy sencilla;
conéctese al servidor de correo mediante
&man.telnet.1;:</para>
<screen>&prompt.root; <userinput>telnet <replaceable>ejemplo.com</replaceable> 25</userinput>
Trying 192.0.34.166...
Connected to <hostid role="fqdn">ejemplo.com</hostid>.
Escape character is '^]'.
220 <hostid role="fqdn">ejemplo.com</hostid> ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT)
<userinput>ehlo <replaceable>ejemplo.com</replaceable></userinput>
250-ejemplo.com Hello ejemplo.com [192.0.34.166], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP
<userinput>quit</userinput>
221 2.0.0 <hostid role="fqdn">ejemplo.com</hostid> closing connection
Connection closed by foreign host.</screen>
<para>Si la línea <quote>STARTTLS</quote> aparece en la
salida, todo está funcionando correctamente.</para>
</sect2>
</sect1>
<sect1 id="ipsec">
<sect1info>
<authorgroup>
<author>
<firstname>Nik</firstname>
<surname>Clayton</surname>
<affiliation>
<address><email>nik@FreeBSD.org</email></address>
</affiliation>
<contrib>Escrito por </contrib>
</author>
</authorgroup>
</sect1info>
<title>VPN sobre IPsec</title>
<indexterm>
<primary>IPsec</primary>
</indexterm>
<para>Creación de una VPN entre dos redes, a través de
Internet, mediante puertas de enlace
(<quote>gateways</quote>) &os;.</para>
<sect2>
<sect2info>
<authorgroup>
<author>
<firstname>Hiten M.</firstname>
<surname>Pandya</surname>
<affiliation>
<address><email>hmp@FreeBSD.org</email></address>
</affiliation>
<contrib>Escrito por </contrib>
</author>
</authorgroup>
</sect2info>
<title>Qué es IPsec</title>
<para>Esta sección le guiará a través del
proceso de configuración de IPsec, y de su uso en un
entorno consistente en máquinas &os; y
<application>µsoft.windows; 2000/XP</application>, para
hacer que se comuniquen de manera segura. Para configurar
IPsec es necesario que esté familiarizado con los
conceptos de construcción de un kernel personalizado
(consulte el <xref linkend="kernelconfig"/>).</para>
<para><emphasis>IPsec</emphasis> es un protocolo que está
sobre la capa del protocolo de Internet (IP). Le permite
a dos o más equipos comunicarse de forma segura (de ahí
el nombre). La <quote>pila de red</quote> IPsec de &os;
se basa en la implementación
<ulink url="http://www.kame.net/">KAME</ulink>, que incluye
soporte para las dos familias de protocolos, IPv4 e IPv6.</para>
<note>
<para>FreeBSD 5.X contiene una pila IPsec <quote>acelerada
por hardware</quote>, conocida como <quote>Fast
IPsec</quote>, que fué obtenida de OpenBSD.
Emplea hardware criptográfico (cuando es posible)
a través del subsistema &man.crypto.4; para
optimizar el rendimiento de IPsec. Este subsistema es
nuevo, y no soporta todas las opciones disponibles en la
versión KAME de IPsec. Para poder habilitar IPsec
acelerado por hardware debe añadir las siguientes
opciones al fichero de configuración de su kernel:</para>
<indexterm>
<primary>opciones de kernel</primary>
<secondary>FAST_IPSEC</secondary>
</indexterm>
<screen>
options FAST_IPSEC # new IPsec (cannot define w/ IPSEC)
</screen>
<para>Tenga en cuenta que no es posible utilizar el subsistema
<quote>Fast IPsec</quote> y la implementación
KAME de IPsec en la misma computadora. Consulte la
página de manual &man.fast.ipsec.4; para más
información.</para>
</note>
<indexterm>
<primary>IPsec</primary>
<secondary>ESP</secondary>
</indexterm>
<indexterm>
<primary>IPsec</primary>
<secondary>AH</secondary>
</indexterm>
<para>IPsec consta de dos sub-protocolos:</para>
<itemizedlist>
<listitem>
<para><emphasis>Encapsulated Security Payload
(ESP)</emphasis>, que protege los datos del paquete IP
de interferencias de terceros, cifrando el contenido
utilizando algoritmos de criptografía simétrica
(como Blowfish, 3DES).</para>
</listitem>
<listitem>
<para><emphasis>Authentication Header (AH)</emphasis>, que
protege la cabecera del paquete IP de interferencias de
terceros así como contra la falsificación
(<quote>spoofing</quote>), calculando una suma de
comprobación criptográfica y aplicando a
los campos de cabecera IP una función hash segura.
Detrás de todo esto va una cabecera adicional que
contiene el hash para permitir la validación de
la información que contiene el paquete.</para>
</listitem>
</itemizedlist>
<para><acronym>ESP</acronym> y <acronym>AH</acronym> pueden
utilizarse conjunta o separadamente, dependiendo del
entorno.</para>
<indexterm>
<primary>VPN</primary>
</indexterm>
<indexterm>
<primary>Red privada virtual</primary>
<see>VPN</see>
</indexterm>
<para>IPsec puede utilizarse para cifrar directamente el
tráfico entre dos equipos (conocido como
<emphasis>modo de transporte</emphasis>) o para construir
<quote>túneles virtuales</quote> entre dos subredes,
que pueden usarse para comunicación segura
entre dos redes corporativas (conocido como <emphasis>modo
de túnel</emphasis>). Este último es muy
conocido como una <emphasis>red privada virtual (Virtual
Private Network, o VPN)</emphasis>. &man.ipsec.4; contiene
información detallada sobre el subsistema IPsec de
&os;.</para>
<para>Si quiere añdir soporte IPsec a su kernel debe
incluir las siguientes opciones al fichero de configuración
de su kernel:</para>
<indexterm>
<primary>opciones de kernel</primary>
<secondary>IPSEC</secondary>
</indexterm>
<indexterm>
<primary>opciones de kernel</primary>
<secondary>IPSEC_ESP</secondary>
</indexterm>
<screen>
options IPSEC #IP security
options IPSEC_ESP #IP security (crypto; define w/ IPSEC)
</screen>
<indexterm>
<primary>opciones de kernel</primary>
<secondary>IPSEC_DEBUG</secondary>
</indexterm>
<para>Si quiere soporte para la depuración de
errores no olvide la siguiente opción:</para>
<screen>
options IPSEC_DEBUG #debug for IP security
</screen>
</sect2>
<sect2>
<title>El Problema</title>
<para>No existe un estándar para lo que constituye una VPN.
Las VPN pueden implementarse utilizando numerosas
tecnologías diferentes, cada una de las cuales tiene sus
pros y sus contras. Esta sección presenta un
escenario, y las estrategias usadas para implementar una VPN
para este escenario.</para>
</sect2>
<sect2>
<title>El escenario: dos redes, conectadas por Internet, que
queremos que se comporten como una sola</title>
<indexterm>
<primary>VPN</primary>
<secondary>creación</secondary>
</indexterm>
<para>Este es el punto de partida:</para>
<itemizedlist>
<listitem>
<para>Usted tiene al menos dos sitios</para>
</listitem>
<listitem>
<para>Ambos sitios utilizan IP internamente</para>
</listitem>
<listitem>
<para>Ambos sitios están conectados a Internet, a
través de una puerta de enlace &os;.</para>
</listitem>
<listitem>
<para>La puerta de enlace de cada red tiene al menos una
dirección IP pública.</para>
</listitem>
<listitem>
<para>Las direcciones internas de las dos redes pueden ser
direcciones IP públicas o privadas, no importa.
Puede ejecutar NAT en la máquina que hace de
puerta de enlace si es necesario.</para>
</listitem>
<listitem>
<para>Las direcciones IP internas de las dos redes
<emphasis>no colisionan</emphasis>. Aunque espero
que sea teóricamente posible utilizar una
combinación de tecnología VPN y NAT
para hacer funcionar todo esto sospecho que
configurarlo sería una pesadilla.</para>
</listitem>
</itemizedlist>
<para>Si lo que intenta es conectar dos redes y ambas usan el
mismo rango de direcciones IP privadas (por ejemplo las dos usan
<hostid role="ipaddr">192.168.1.x</hostid>)debería renumerar
una de las dos redes.</para>
<para>La topología de red se parecería a esto:</para>
<mediaobject>
<imageobject>
<imagedata fileref="security/ipsec-network" align="center"/>
</imageobject>
<textobject>
<literallayout class="monospaced">Network #1 [ Internal Hosts ] Private Net, 192.168.1.2-254
[ Win9x/NT/2K ]
[ UNIX ]
|
|
.---[fxp1]---. Private IP, 192.168.1.1
| FreeBSD |
`---[fxp0]---' Public IP, A.B.C.D
|
|
-=-=- Internet -=-=-
|
|
.---[fxp0]---. Public IP, W.X.Y.Z
| FreeBSD |
`---[fxp1]---' Private IP, 192.168.2.1
|
|
Network #2 [ Internal Hosts ]
[ Win9x/NT/2K ] Private Net, 192.168.2.2-254
[ UNIX ]</literallayout>
</textobject>
</mediaobject>
<para>Observe las dos direcciones IP públicas. Usaré
letras para referirme a ellas en el resto de este artículo.
El cualquier lugar que vea esas letras en este artículo
reemplácelas con su propia dirección IP pública.
Observe también que internamente las dos máquinas
que hacen de puerta de enlace tienen la dirección IP .1,
y que las dos redes tienen direcciones IP privadas diferentes
(<hostid
role="ipaddr">192.168.1.x</hostid> y <hostid
role="ipaddr">192.168.2.x</hostid> respectivamente). Todas las
máquinas de las redes privadas están configuradas para
utilizar la máquina <hostid role="ipaddr">.1</hostid>
como su puerta de enlace por defecto.</para>
<para>La intención es que, desde el punto de vista de la
red, cada red debe ver las máquinas en la otra red como
si estuvieran directamente conectadas al mismo router (aunque
aunque sea un router ligeramente lento con una tendencia
ocasional a tirar paquetes).</para>
<para>Esto significa que (por ejemplo), la máquina
<hostid role="ipaddr">192.168.1.20</hostid> debe ser
capaz de ejecutar</para>
<programlisting>ping 192.168.2.34</programlisting>
<para>y recibir de forma transparente una respuesta. Las
máquinas &windows; deben ser capaces de ver las
máquinas de la otra red, acceder a sus ficheros
compartidos, etc, exactamente igual que cuando acceden a
las máquinas de la red local.</para>
<para>Y todo debe hacerse de forma segura. Esto significa que el
tráfico entre las dos redes tiene que ser
cifrado.</para>
<para>La creación de una VPN entre estas dos redes es un
proceso que requiere varios pasos. Las etapas son estas:</para>
<orderedlist>
<listitem>
<para>Crear un enlace de red <quote>virtual</quote> entre las dos
redes, a través de Internet. Probarlo usando herramientas
como &man.ping.8; para asegurarse de que funcione.</para>
</listitem>
<listitem>
<para>Aplicar políticas de seguridad para asegurarse
de que el tráfico entre las dos redes sea cifrado
y descifrado de forma transparente. Comprobarlo mediante
herramientas como &man.tcpdump.1; para asegurarse de que
el tráfico esté siendo efectivamente
cifrado.</para>
</listitem>
<listitem>
<para>Configurar software adicional en las puertas de
enlace &os; para permitir a las máquinas &windows;
verse entre ellas a través de la VPN.</para>
</listitem>
</orderedlist>
<sect3>
<title>Paso 1: Creación y prueba de un enlace de
red <quote>virtual</quote></title>
<para>Suponga que está en la puerta de enlace de la red
red #1 (con dirección IP pública <hostid
role="ipaddr">A.B.C.D</hostid>, dirección IP privada
<hostid role="ipaddr">192.168.1.1</hostid>), y ejecuta
<command>ping 192.168.2.1</command>, que es la dirección
privada de la máquina con dirección IP
<hostid role="ipaddr">W.X.Y.Z</hostid>. ?Qué
hace falta para esto?</para>
<orderedlist>
<listitem>
<para>La puerta de enlace necesita saber cómo alcanzar
a <hostid role="ipaddr">192.168.2.1</hostid>. En otras
palabras, necesita tener una ruta hasta <hostid
role="ipaddr">192.168.2.1</hostid>.</para>
</listitem>
<listitem>
<para>Las direcciones IP privadas, como las que están
en el rango <hostid role="ipaddr">192.168.x</hostid>
no deberían aparecer en Internet. Por eso, cada paquete
que mande a <hostid role="ipaddr">192.168.2.1</hostid>
necesitará encerrarse dentro de otro paquete.
Este paquete debe tener todas las características
de haber sido enviado desde
<hostid role="ipaddr">A.B.C.D</hostid>,
y tendrá que ser enviado a <hostid
role="ipaddr">W.X.Y.Z</hostid>. Este proceso recibe el nombre
de <firstterm>encapsulado</firstterm>.</para>
</listitem>
<listitem>
<para>Una vez que este paquete llega a
<hostid role="ipaddr">W.X.Y.Z</hostid> necesitará
ser <quote>desencapsulado</quote>, y entregado a
<hostid role="ipaddr">192.168.2.1</hostid>.</para>
</listitem>
</orderedlist>
<para>Puede verlo como si necesitara un <quote>túnel</quote>
entre las dos redes. Las dos <quote>bocas del túnel</quote>
son las direcciones IP <hostid role="ipaddr">A.B.C.D</hostid> y
<hostid role="ipaddr">W.X.Y.Z</hostid>, y debe hacer que el
túnel sepa cuáles serán las direcciones
IP privadas que tendrán permitido el paso a través
de él. El túnel se usa para transferir tráfico
con direcciones IP privadas a través de la Internet
pública.</para>
<para>Este túnel se crea mediante la interfaz genérica,
o dispositivo <devicename>gif</devicename> en &os;. Como
puede imaginarse la interfaz <devicename>gif</devicename>
de cada puerta de enlace debe configurarse con cuatro
direcciones IP: dos para las direcciones IP públicas,
y dos para las direcciones IP privadas.</para>
<para>El soporte para el dispositivo gif debe compilarse en el
kernel de &os; en ambas máquinas añadiendo
la línea</para>
<programlisting>device gif</programlisting>
<para>a los ficheros de configuración del kernel de
ambas máquinas, compilarlo, instalarlo y reiniciar.</para>
<para>La configuración del túnel es un proceso
que consta de dos partes. Primero se le debe decir al
túnel cuáles son las direcciones IP exteriores
(o públicas) mediante &man.gifconfig.8;. Después
configure las direcciones IP con &man.ifconfig.8;.</para>
<note>
<para>En &os; 5.X las funciones de &man.gifconfig.8;
se han incluido en &man.ifconfig.8;.</para></note>
<para>En la puerta de enlace de la red #1 debe ejecutar
las siguientes dos órdenes para configurar el
túnel.</para>
<programlisting>gifconfig gif0 A.B.C.D W.X.Y.Z
ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff
</programlisting>
<para>En la otra puerta de enlace ejecute las mismas
órdenes, pero con el orden las direcciones IP
invertido.</para>
<programlisting>gifconfig gif0 W.X.Y.Z A.B.C.D
ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff
</programlisting>
<para>Ahora ejecute:</para>
<programlisting>gifconfig gif0</programlisting>
<para>y podrá ver la configuración. Por ejemplo, en la
puerta de enlace de la red #1 vería algo parecido
a esto:</para>
<screen>&prompt.root; <userinput>gifconfig gif0</userinput>
gif0: flags=8011<UP,POINTTOPOINT,MULTICAST> mtu 1280
inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff
physical address inet A.B.C.D --> W.X.Y.Z
</screen>
<para>Como puede ver se ha creado un túnel entre las direcciones
físicas <hostid role="ipaddr">A.B.C.D</hostid> y
<hostid role="ipaddr">W.X.Y.Z</hostid>, y el tráfico
que puede pasar a través del túnel es entre
<hostid role="ipaddr">192.168.1.1</hostid> y
<hostid role="ipaddr">192.168.2.1</hostid>.</para>
<para>Esto también habrá agregado una entrada en
la tabla de rutas de ambas máquinas, que puede
examinar con <command>netstat -rn</command>.
Esta salida es de la puerta de enlace de la red #1.</para>
<screen>&prompt.root; <userinput>netstat -rn</userinput>
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
...
192.168.2.1 192.168.1.1 UH 0 0 gif0
...
</screen>
<para>Como el valor de <quote>Flags</quote> lo indica, esta
es una ruta de equipo, lo que significa que cada puerta de
enlace sabe como alcanzar la otra puerta de enlace, pero no saben
cómo llegar al resto de sus respectivas redes. Ese
problema se solucionará en breve.</para>
<para>Es posible que disponga de un cortafuegos en ambas
máquinas, por lo que tendrá que buscar la
forma de que el tráfico de la VPN pueda entrar y
salir limpiamente. Puede permitir todo el tráfico
de ambas redes, o puede que quiera incluir reglas en el
cortafuegos para que protejan ambos extremos de la VPN uno
del otro.</para>
<para>Las pruebas se simplifican enormemente si configura
el cortafuegos para permitir todo el tráfico a
través de la VPN. Siempre puede ajustar las cosas
después. Si utiliza &man.ipfw.8; en las puertas de
enlace una orden similar a</para>
<programlisting>ipfw add 1 allow ip from any to any via gif0</programlisting>
<para>permitirá todo el tráfico entre los dos
extremos de la VPN, sin afectar al resto de reglas del
cortafuegos. Obviamente tendrá que ejecutar esta orden
en ambas puertas de enlace.</para>
<para>Esto es suficiente para permitir a cada puerta de enlace
hacer un ping entre ellas. En
<hostid role="ipaddr">192.168.1.1</hostid> deberí poder
ejecutar</para>
<programlisting>ping 192.168.2.1</programlisting>
<para>y obtener una respuesta; es obvio que debería poder
hacer los mismo en la otra puerte de enlace.</para>
<para>Aún no podrá acceder a las máquinas
internas de las redes. El problema está en el
encaminamiento: aunque las puertas de enlace saben
cómo alcanzarse mútuamente no saben cómo
llegar a la red que hay detrás de la otra.</para>
<para>Para resolver este problema debe añadir una ruta
estática en cada puerta de enlace. La orden
en la primera puerta de enlace podría ser:</para>
<programlisting>route add 192.168.2.0 192.168.2.1 netmask 0xffffff00
</programlisting>
<para>Esto significa <quote>Para alcanzar los equipos en
la red <hostid role="ipaddr">192.168.2.0</hostid>, envía
los paquetes al equipo
<hostid role="ipaddr">192.168.2.1</hostid></quote>.
Necesitará ejecutar una orden similar en la otra
puerta de enlace, pero obviamente con las direcciones
<hostid role="ipaddr">192.168.1.x</hostid>.</para>
<para>El tráfico IP de equipos en una red no será
capaz de alcanzar equipos en la otra red.</para>
<para>Ya tiene dos tercios de una VPN, puesto que ya es
<quote>virtual</quote> y es una <quote>red</quote>.
Todavía no es privada. Puede comprobarlo con
&man.ping.8; y &man.tcpdump.1;. Abra una sesión en
la puerta de enlace y ejecute</para>
<programlisting>tcpdump dst host 192.168.2.1</programlisting>
<para>En otra sesión en el mismo equipo ejecute</para>
<programlisting>ping 192.168.2.1</programlisting>
<para>Verá algo muy parecido a esto:</para>
<programlisting>
16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply
16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply
16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply
</programlisting>
<para>Como puede ver los mensajes ICMP van y vienen sin
cifrar. Si usa el parámetro <option>-s</option>
en &man.tcpdump.1; para tomar más bytes de datos de
estos paquetes verá más información.</para>
<para>Obviamente esto es inaceptable. La siguiente sección
explicará cómo asegurar el enlace entre las dos
redes para que todo el tráfico se cifre
automáticamente.</para>
<itemizedlist>
<title>Sumario:</title>
<listitem>
<para>Configure ambos kernel con <quote>pseudo-device
gif</quote>.</para>
</listitem>
<listitem>
<para>Edite <filename>/etc/rc.conf</filename> en la puerta de
enlace #1 y añada las siguientes líneas
(reemplazando las direcciones IP según sea necesario).</para>
<programlisting>gifconfig_gif0="A.B.C.D W.X.Y.Z"
ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff"
static_routes="vpn"
route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00"
</programlisting>
</listitem>
<listitem>
<para>Edite la configuración de su cortafuegos
(<filename>/etc/rc.firewall</filename>, o lo que corresponda)
en ambos equipos y añada</para>
<programlisting>ipfw add 1 allow ip from any to any via gif0</programlisting>
</listitem>
<listitem>
<para>Haga los cambios oportunos en el
<filename>/etc/rc.conf</filename> de la puerta de
enlace #2, invirtiendo el orden de las direcciones IP.</para>
</listitem>
</itemizedlist>
</sect3>
<sect3>
<title>Paso 2: Asegurar el enlace</title>
<para>Para asegurar el enlace usaremos IPsec. IPsec ofrece un
mecanismo para que dos equipos coincidan en una llave de
cifrado, y usar esta llave para cifrar los datos
entre los dos equipos.</para>
<para>Existen dos áreas de configuración a
tener en cuenta:</para>
<orderedlist>
<listitem>
<para>Debe existir un mecanismo para que los dos equipos
se pongan de acuerdo en el mecanismo de cifrado que van a
utilizar. Una vez que los dos equipos se han puesto de
acuerdo dice que existe una
<quote>asociación de seguridad</quote> entre
ellos.</para>
</listitem>
<listitem>
<para>Debe existir un mecanismo para especificar que tráfico
debe ser cifrado. Obviamente, usted no querrá
cifrar todo su tráfico saliente: solo querrá
cifrar el tráfico que es parte de la VPN. Las
reglas con las que determinará qué tráfico
será cifrado se llaman <quote>políticas
de seguridad</quote>.</para>
</listitem>
</orderedlist>
<para>Tanto las asociaciones de seguridad como las
políticas de seguridad son responsabilidad del kernel,
pero pueden ser modificadas desde el espacio de usuario.
Antes de poder hacerlo, tendrá que configurar el kernel
para que incluya IPsec y el protocolo ESP
(Encapsulated Security Payload). Incluya en el fichero de
configuración de su kernel lo siguiente:</para>
<indexterm>
<primary>opciones de kernel</primary>
<secondary>IPSEC</secondary>
</indexterm>
<programlisting>options IPSEC
options IPSEC_ESP
</programlisting>
<para>Recompile y resintale su kernel y reinicie. Como se dijo
anteriormente, tendrá que hacer lo mismo en el kernel
de las dos puertas de enlace.</para>
<indexterm>
<primary>IKE</primary>
</indexterm>
<para>Tiene dos opciones cuando se trata de configurar
asociaciones de seguridad. Puede configurarlas a mano en
los dos equipos, lo que significa elegir el algoritmo de
cifrado, las llaves de cifrado, etc, o puede utilizar
alguno de los dæmons que implementan el protocolo
de intercambio de llaves de Internet (IKE, Internet Key
Exchange).</para>
<para>Le recomiendo la segunda opción. Aparte de
otras consideraciones es más fácil de
configurar.</para>
<indexterm>
<primary>IPsec</primary>
<secondary>políticas de seguridad</secondary>
</indexterm>
<indexterm>
<primary><command>setkey</command></primary>
</indexterm>
<para>La edición y despliegue se efectúa con
&man.setkey.8;. Todo esto se entiende mejor con una
analogía. <command>setkey</command> es a las tablas
de políticas de seguridad del kernel lo que &man.route.8;
es a las tablas de rutas del kernel.
También puede usar <command>setkey</command>
ver las asociaciones de seguridad en vigor, siguiendo con
la analogía, igual que puede usar
<command>netstat -r</command>.</para>
<para>Existen numerosos dæmons que pueden encargarse de
la gestión de asociaciones de seguridad en &os;. En
este texto se muestra cómo usar uno de ellos,
racoon (que puede instalar desde
<filename role="package">security/racoon</filename> en la
colección de ports de &os;.</para>
<indexterm>
<primary>racoon</primary>
</indexterm>
<para>El software <filename role="package">security/racoon</filename>
debe ejecutarse en las dos puertas de enlace. En cada equipo
debe configurar la dirección IP del otro extremo de la
VPN y una llave secreta (que usted puede y debe elegir, y debe ser
la misma en ambas puertas de enlace).</para>
<para>Los dos dæmons entran en contacto uno con otro, y confirman
que son quienes dicen ser (utilizando la llave secreta que usted
configuró). Los dæmons generan una nueva llave
secreta, y la utilizan para cifrar el tráfico que discurre a
través de la VPN. Periódicamente cambian esta
llave, para que incluso si un atacante comprometiera una
de las llaves (lo cual es teóricamente cercano a
imposible) no le serviriía de mucho: para cuando el
atacante haya <quote>crackeado</quote> la llave los dæmons
ya habrán escogido una nueva.</para>
<para>El fichero de configuración de racoon
está en <filename>${PREFIX}/etc/racoon</filename>.
No debería tener que hacer demasiados cambios a ese
fichero. El otro componente de la configuración de
racoon (que <emphasis>sí</emphasis> tendrá que
modificar) es la <quote>llave pre-compartida</quote>.</para>
<para>La configuración por defecto de racoon
espera encontrarla en
<filename>${PREFIX}/etc/racoon/psk.txt</filename>.
Es importante saber que la llave precompartida <emphasis>no</emphasis>
es la llave que se utilizará para cifrar el
tráfico a través del enlace VPN; solamente es una
muestra que permite a los dæmons que administran las
llaves confiar el uno en el otro.</para>
<para><filename>psk.txt</filename> contiene una línea
por cada sitio remoto con el que esté tratando. En
nuestro ejemplo, donde existen dos sitios, cada fichero
<filename>psk.txt</filename> contendrá una línea
(porque cada extremo de la VPN solo está tratando
con un sitio en el otro extremo).</para>
<para>En la puerta de enlace #1 esta línea debería
parecerse a esta:</para>
<programlisting>W.X.Y.Z secreto</programlisting>
<para>Esto es, la dirección IP
<emphasis>pública</emphasis> del extremo remoto, un
espacio en blanco, y una cadena de texto que es el secreto
en sí.
en el extremo remoto, espacio en blanco, y un texto de cadena que
proporcina el secreto. Obviamente, no debe utilizar
<quote>secret</quote> como su llave; aplique aquí las
reglas y recomendaciones habituales para la elección de
contraseñas.</para>
<para>En la puerta de enlace #2 la línea se parecería
a esta</para>
<programlisting>A.B.C.D secreto</programlisting>
<para>Esto es, la dirección IP pública del
extremo remoto, y la misma llave secreta.
<filename>psk.txt</filename> debe tener modo
<literal>0600</literal> (es decir, modo de solo
lectura/escritura para <username>root</username>) antes de
que ejecute racoon.</para>
<para>Debe ejecutar racoon en ambas puertas de enlace.
También tendrá que añadir algunas reglas
a su cortafuegos para permitir el tráfico IKE, que se
transporta sobre UDP al puerto ISAKMP (Internet Security
Association Key Management Protocol). Esto debe estar
al principio de las reglas de su cortafuegos.</para>
<programlisting>ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
</programlisting>
<para>Una vez que ejecute racoon puede tratar de hacer un
ping a una puerta de enlace desde la otra. La conexión
todavía no está cifrada porque aún no se
han creado las asociaciones de seguridad entre los dos
equipos: esto puede llevar un poco de tiempo; es posible que
advierta un pequeño retraso antes de los ping empiecen
responder.</para>
<para>Una vez creadas las asociaciones de seguridad
puede verlas utilizando &man.setkey.8;. Ejecute</para>
<programlisting>setkey -D</programlisting>
<para>en cualquiera de los equipos para comprobar la información
de la asociación de seguridad.</para>
<para>Ya está resuelta la mitad del problema. La otra mitad es
configurar sus políticas de seguridad.</para>
<para>Queremos crear una política de seguridad sensata,
así que vamos a revisar lo que tenemos configurado
hasta el momento. Esta revisión abarca ambos extremos
del enlace.</para>
<para>Cada paquete IP que usted manda tiene una cabecera que
contiene datos acerca del paquete. La cabecera incluye la
dirección IP de destino y del origen. Como ya sabemos,
las direcciones IP privadas como el rango
<hostid role="ipaddr">192.168.x.y</hostid> no deberían
aparezcan en Internet. Dado que es a través de Internet
por donde los queremos transmitir los debemos encapsular dentro
de otro paquete. Este paquete debe contener tanto la dirección
IP de destino y origen públicas sustituidas por las
direcciones privadas.</para>
<para>Así que si su paquete saliente empezó
pareciendose a este:</para>
<mediaobject>
<imageobject>
<imagedata fileref="security/ipsec-out-pkt" align="center"/>
</imageobject>
<textobject>
<literallayout class="monospaced">
.----------------------.
| Src: 192.168.1.1 |
| Dst: 192.168.2.1 |
| <other header info> |
+----------------------+
| <packet data> |
`----------------------'</literallayout>
</textobject>
</mediaobject>
<para>tras el encapsulado se parecerá bastante a este:</para>
<mediaobject>
<imageobject>
<imagedata fileref="security/ipsec-encap-pkt" align="center"/>
</imageobject>
<textobject>
<literallayout class="monospaced">
.--------------------------.
| Src: A.B.C.D |
| Dst: W.X.Y.Z |
| <other header info> |
+--------------------------+
| .----------------------. |
| | Src: 192.168.1.1 | |
| | Dst: 192.168.2.1 | |
| | <other header info> | |
| +----------------------+ |
| | <packet data> | |
| `----------------------' |
`--------------------------'</literallayout>
</textobject>
</mediaobject>
<para>El dispositivo <devicename>gif</devicename> se encarga
del encapsulado. Como puede ver el paquete tiene una
dirección IP real en el exterior, y nuestro paquete
original ha sido envuelto como dato dentro del paquete que
enviaremos a través de Internet.</para>
<para>Obviamente, queremos que todo el tráfico entre
las VPN vaya cifrado. Pongamos esto último en
palabras para comprenderlo mejor:</para>
<para><quote>Si un paquete sale desde <hostid
role="ipaddr">A.B.C.D</hostid>, y tiene como destino
<hostid role="ipaddr">W.X.Y.Z</hostid>, cífralo
utilizando las asociaciones de seguridad necesarias.</quote></para>
<para><quote>Si un paquete llega desde <hostid
role="ipaddr">W.X.Y.Z</hostid>, y tiene como destino
<hostid role="ipaddr">A.B.C.D</hostid>, descífralo
utilizando las asociaciones de seguridad necesarias.</quote></para>
<para>Este planteamiento se aproxima bastante, pero no es
exactamente lo que queremos hacer. Si lo hiciera así
todo el tráfico desde y hacia
<hostid role="ipaddr">W.X.Y.Z</hostid>, incluso el tráfico
que no forma parte de la VPN, será cifrado; esto no es lo que
queremos. La política correcta es la siguiente:</para>
<para><quote>Si un paquete sale desde <hostid
role="ipaddr">A.B.C.D</hostid>, y está
encapsulando a otro paquete, y tiene como destino
<hostid role="ipaddr">W.X.Y.Z</hostid>, cífralo
utilizando las asociaciones de seguridad necesarias.</quote></para>
<para><quote>Si un paquete llega desde <hostid
role="ipaddr">W.X.Y.Z</hostid>, y está
encapsulando a otro paquete, y tiene como destino
<hostid role="ipaddr">A.B.C.D</hostid>, descífralo
utilizando las asociaciones de seguridad necesarias.</quote></para>
<para>Un cambio sutil, pero necesario.</para>
<para>Las políticas de seguridad también se
imponen utilizando &man.setkey.8;. &man.setkey.8; proporciona
un lenguaje de configuración para definir la
política. Puede introducir las instrucciones de
configuración a través de la entrada estándar
(stdin), o puede usar la opción
<option>-f</option> para especificar un fichero que
contenga las instrucciones de configuración.</para>
<para>La configuración en la puerta de enlace #1 (que
tiene la dirección IP pública
<hostid role="ipaddr">A.B.C.D</hostid>) para forzar que todo
el tráfico saliente hacia
<hostid role="ipaddr">W.X.Y.Z</hostid> vaya cifrado es:</para>
<programlisting>
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
</programlisting>
<para>Ponga estas órdenes en un fichero (por ejemplo
<filename>/etc/ipsec.conf</filename>) y ejecute</para>
<screen>&prompt.root; <userinput>setkey -f /etc/ipsec.conf</userinput></screen>
<para><option>spdadd</option> le dice a &man.setkey.8; que
queremos añadir una regla a la base de datos de
políticas de seguridad. El resto de la línea
especifica qué paquetes se ajustarán a esta
política.
<hostid role="ipaddr">A.B.C.D/32</hostid> y
<hostid role="ipaddr">W.X.Y.Z/32</hostid> son las direcciones IP
y máscaras de red que identifican la red o equipos a los
que se aplicará esta política. En nuestro caso
queremos aplicarla al tráfico entre estos dos equipos.
<option>-P out</option> dice que esta política se aplica
a paquetes salientes, e <option>ipsec</option> hace que el
paquete sea asegurado.</para>
<para>La segunda línea especifica cómo será
cifrado este paquete. <option>esp</option> es el
protocolo que se utilizará, mientras que
<option>tunnel</option> indica que el paquete será
después encapsulado en un paquete IPsec. El uso repetido de
<hostid role="ipaddr">A.B.C.D</hostid> y
<hostid role="ipaddr">W.X.Y.Z</hostid> se utiliza para
seleccionar la asociación de seguridad a usar, y
por último <option>require</option> exige que los
paquetes deben cifrarse si concuerdan con esta
regla.</para>
<para>Esta regla solo concuerda con paquetes salientes.
Necesitará una regla similar para los paquetes
entrantes.</para>
<programlisting>spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;</programlisting>
<para>Observe el <option>in</option> en lugar del <option>out</option>
en este caso, y la inversión necesaria de las direcciones
IP.</para>
<para>La otra puerta de enlace (que tiene la dirección
IP pública <hostid role="ipaddr">W.X.Y.Z</hostid>)
necesitará reglas similares.</para>
<programlisting>spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;</programlisting>
<para>Finalmente, necesita añadir reglas a su cortafuegos
para permitir la circulación de paquetes ESP e IPENCAP
de ida y vuelta. Tendrá que añadir reglas como
estas a ambos equipos.</para>
<programlisting>ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
</programlisting>
<para>Debido a que las reglas son simétricas puede utilizar
las mismas reglas en ambas puertas de enlace.</para>
<para>Los paquetes salientes tendrán ahora este aspecto:</para>
<mediaobject>
<imageobject>
<imagedata fileref="security/ipsec-crypt-pkt" align="center"/>
</imageobject>
<textobject>
<literallayout class="monospaced">
.------------------------------. --------------------------.
| Src: A.B.C.D | |
| Dst: W.X.Y.Z | |
| <other header info> | | Encrypted
+------------------------------+ | packet.
| .--------------------------. | -------------. | contents
| | Src: A.B.C.D | | | | are
| | Dst: W.X.Y.Z | | | | completely
| | <other header info> | | | |- secure
| +--------------------------+ | | Encap'd | from third
| | .----------------------. | | -. | packet | party
| | | Src: 192.168.1.1 | | | | Original |- with real | snooping
| | | Dst: 192.168.2.1 | | | | packet, | IP addr |
| | | <other header info> | | | |- private | |
| | +----------------------+ | | | IP addr | |
| | | <packet data> | | | | | |
| | `----------------------' | | -' | |
| `--------------------------' | -------------' |
`------------------------------' --------------------------'
</literallayout>
</textobject>
</mediaobject>
<para>Cuando los paquetes llegan al otro extremo de la VPN
serán descifrados (utilizando las
asociaciones de seguridad que han sido negociadas por racoon).
Después entrarán al interfaz
<devicename>gif</devicename>, que desenvuelve la segunda capa,
hasta que nos quedamos con paquete má interno, que puede
entonces viajar a la red interna.</para>
<para>Puede revisar la seguridad utilizando la misma prueba de
&man.ping.8; anterior. Primero, inicie una sesión en
la puerta de enlace <hostid role="ipaddr">A.B.C.D</hostid>,
y ejecute:</para>
<programlisting>tcpdump dst host 192.168.2.1</programlisting>
<para>En otra sesión en la misma máquina ejecute</para>
<programlisting>ping 192.168.2.1</programlisting>
<para>Debería ver algo similar a lo siguiente:</para>
<programlisting>XXX tcpdump output</programlisting>
<para>ahora, como puede ver, &man.tcpdump.1; muestra los paquetes ESP.
Si trata de examinarlos con la opción <option>-s</option>
verá basura (aparentemente), debido al
cifrado.</para>
<para>Felicidades. Acaba de configurar una VPN entre dos sitios
remotos.</para>
<itemizedlist>
<title>Sumario</title>
<listitem>
<para>Configure ambos kernel con:</para>
<programlisting>options IPSEC
options IPSEC_ESP
</programlisting>
</listitem>
<listitem>
<para>Instale <filename role="package">security/racoon</filename>.
Edite <filename>${PREFIX}/etc/racoon/psk.txt</filename> en ambas
puertas de enlace añadiendo una entrada para la
dirección IP del equipo remoto y una llave secreta que
ambos conozcan. Asegúrese de que este fichero esté
en modo 0600.</para>
</listitem>
<listitem>
<para>Añada las siguientes líneas a
<filename>/etc/rc.conf</filename> en ambos equipos:</para>
<programlisting>ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"
</programlisting>
</listitem>
<listitem>
<para>Crée en ambos equipos un
<filename>/etc/ipsec.conf</filename> que contenga las
líneas spdadd necesarias. En la puerta de enlace
#1 sería:</para>
<programlisting>
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec
esp/tunnel/A.B.C.D-W.X.Y.Z/require;
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec
esp/tunnel/W.X.Y.Z-A.B.C.D/require;
</programlisting>
<para>En la puerta de enlace #2 sería:</para>
<programlisting>
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec
esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec
esp/tunnel/A.B.C.D-W.X.Y.Z/require;
</programlisting>
</listitem>
<listitem>
<para>Añada a su(s) cortafuegos las reglas necesarias para
que permita(n) el paso de tráfico IKE, ESP e
IPENCAP en ambos equipos:</para>
<programlisting>
ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
</programlisting>
</listitem>
</itemizedlist>
<para>Los dos pasos previos deben bastar para levantar la VPN.
Las máquinas en cada red seán capaces de
dirigirse una a otra utilizando direcciones IP, y todo el
tráfico a través del enlace será cifrado de
forma automática y segura.</para>
</sect3>
</sect2>
</sect1>
<sect1 id="openssh">
<sect1info>
<authorgroup>
<author>
<firstname>Chern</firstname>
<surname>Lee</surname>
<contrib>Escrito por </contrib>
</author>
<!-- 21 April 2001 -->
</authorgroup>
</sect1info>
<title>OpenSSH</title>
<indexterm><primary>OpenSSH</primary></indexterm>
<indexterm>
<primary>seguridad</primary>
<secondary>OpenSSH</secondary>
</indexterm>
<para><application>OpenSSH</application> es un conjunto de herramientas
de conectividad que se usan para acceder a sistemas remotos de
forma segura. Puede usarse como sustituto directo de
<command>rlogin</command>,
<command>rsh</command>, <command>rcp</command> y
<command>telnet</command>. Además cualquier otra conexión
TCP/IP puede reenviarse o enviarse a través de un túnel a
través de SSH.
<application>OpenSSH</application> cifra todo el tráfico para
eliminar de forma efectiva el espionaje, el secuestro de conexiones, y
otros ataques en la capa de red.</para>
<para><application>OpenSSH</application> está a cargo del proyecto
OpenBSD, y está basado en SSH v1.2.12, con todos los errores
recientes corregidos y todas las actualizaciones correspondientes.
Es compatible con los protocolos SSH 1 y 2.
<application>OpenSSH</application> forma parte del sistema base desde
&os; 4.0.</para>
<sect2>
<title>Ventajas de utilizar OpenSSH</title>
<para>Normalmente, al utilizar &man.telnet.1; o &man.rlogin.1;
los datos se envían a través de la red en limpio,
es decir, sin cifrar. Cualquier <quote>sniffer</quote> de red
entre el cliente y el servidor puede robar la información
de usuario/contraseña o los datos transferidos durante
su sesión. <application>OpenSSH</application> ofrece
diversos métodos de validación y cifrado para
evitar que sucedan estas cosas.</para>
</sect2>
<sect2>
<title>Habilitar sshd</title>
<indexterm>
<primary>OpenSSH</primary>
<secondary>habilitar</secondary>
</indexterm>
<para>El dæmon <application>sshd</application> está
habilitado por defecto &os; 4.X y puede elegir habilitarlo
o no durante la instalación en &os; 5.X. Si quiere
saber si está habilitado revise si la siguiente
línea está en <filename>rc.conf</filename>:</para>
<screen>sshd_enable="YES"</screen>
<para>Esta línea cargará &man.sshd.8;, el programa
dæmon de <application>OpenSSH</application>, en el arranque
de su sistema. Puede ejecutar el dæmon
<application>sshd</application> tecleando
<command>sshd</command> en la línea de órdenes.</para>
</sect2>
<sect2>
<title>Cliente SSH</title>
<indexterm>
<primary>OpenSSH</primary>
<secondary>cliente</secondary>
</indexterm>
<para>&man.ssh.1; funciona de manera
similar a &man.rlogin.1;.</para>
<screen>&prompt.root; <userinput>ssh <replaceable>user@example.com</replaceable></userinput>
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? <userinput>yes</userinput>
Host 'ejemplo.com' added to the list of known hosts.
usuario@ejemplo.com's password: <userinput>*******</userinput></screen>
<para>El login continuará como lo haría si fuera
una sesión de <command>rlogin</command> o
<command>telnet</command>. SSH utiliza un sistema de huellas de
llaves para verificar la autenticidad del servidor cuando el
cliente se conecta. Se le pide al usuario que introduzca
<literal>yes</literal> solamente la primera vez que se
conecta. Todos los intentos futuros de login se verifican
contra la huella de la llave guardada la primera vez.
El cliente SSH le alertará si la huella guardada difiere
de la huella recibida en futuros intentos de acceso al sistema.
Las huellas se guardan en
<filename>~/.ssh/known_hosts</filename>, y en
<filename>~/.ssh/known_hosts2</filename> las huellas
SSH v2.</para>
<para>Por defecto las versiones recientes de
los servidores <application>OpenSSH</application> solamente
aceptan conexiones SSH v2. El cliente utilizará la
versión 2 si es posible y pasará como
respaldo a la versión 1. El cliente puede también
ser obligado a utilizar una u otra pasándole
<option>-1</option> o <option>-2</option>, respectivamente para
la versión 1 y la versión 2. Se mantiene la
compatibilidad del cliente con la versión 1 para
mantener la compatibilidad con versiones antiguas.</para>
</sect2>
<sect2>
<title>Copia segura</title>
<indexterm>
<primary>OpenSSH</primary>
<secondary>copia segura</secondary>
</indexterm>
<indexterm><primary><command>scp</command></primary></indexterm>
<para>&man.scp.1; funciona de manera muy similar a &man.rcp.1;;
copia un fichero desde o hacia un sistema remoto, con la
diferencia de que lo hace de una forma segura.</para>
<screen>&prompt.root; <userinput> scp <replaceable>usuario@ejemplo.com:/COPYRIGHT COPYRIGHT</replaceable></userinput>
usuario@ejemplo.com's password: <userinput>*******</userinput>
COPYRIGHT 100% |*****************************| 4735
00:00
&prompt.root;</screen>
<para>Ya que la huella se guardó en este equipo durante
el ejemplo anterior se verifica ahora al utilizar
&man.scp.1;.</para>
<para>Los argumentos de &man.scp.1; son similares
a &man.cp.1;, con el fichero o ficheros como primer
argumento, y el destino como segundo. Ya que el fichero
se transfiere a través de la red, a través de
SSH, uno o más argumentos tienen la estructura
<option>user@host:<ruta_al_fichero_remoto></option>.</para>
</sect2>
<sect2>
<title>Configuración</title>
<indexterm>
<primary>OpenSSH</primary>
<secondary>configuración</secondary>
</indexterm>
<para>Los ficheros de configuración del sistema
tanto para el dæmon <application>OpenSSH</application>
como para el cliente están en
<filename>/etc/ssh</filename>.</para>
<para><filename>ssh_config</filename> contiene las opciones
del cliente, mientras que <filename>sshd_config</filename>
configura el dæmon.</para>
<para>Además las opciones <option>sshd_program</option>
(<filename>/usr/sbin/sshd</filename> por defecto),
y <option>sshd_flags</option> de <filename>rc.conf</filename>
ofrecer más niveles de configuración.</para>
</sect2>
<sect2 id="security-ssh-keygen">
<title>ssh-keygen</title>
<para>&man.ssh-keygen.1; le permite validar a un usuario sin
pedirle la contraseña:</para>
<screen>&prompt.user; <userinput>ssh-keygen -t <replaceable>dsa</replaceable></userinput>
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 usuario@host.ejemplo.com
</screen>
<para>&man.ssh-keygen.1; creará un par de llaves
pública y privada para usar en la validación.
La llave privada se guarda en
<filename>~/.ssh/id_dsa</filename> o en
<filename>~/.ssh/id_rsa</filename>, mientras que la llave
pública se guarda en <filename>~/.ssh/id_dsa.pub</filename>
o en <filename>~/.ssh/id_rsa.pub</filename>, respectivamente para
llaves DSA y RSA. La llave pública debe guardarse en
el <filename>~/.ssh/authorized_keys</filename> de la
máquina remota para que la configuración funcione.
Las llaves RSA versión 1 deben guardarse en
<filename>~/.ssh/authorized_keys</filename>.</para>
<para>De este modo permitirá conexiones a la máquina
remota mediante llaves SSH en lugar de contraseñas.</para>
<para>Si usa una contraseña al ejecutar &man.ssh-keygen.1;, se
le pedirá al usuario una contraseña cada
vez que quiera utilizar la llave privada. &man.ssh-agent.1;
puede evitar la molestia de introducir repetidamente
frases largas. esto se explica má adelante, en la
<xref linkend="security-ssh-agent"/>.</para>
<warning><para>Las opciones y ficheros pueden ser
diferentes según la versión de
<application>OpenSSH</application> que tenga en su sistema; para
evitar problemas consulte la página de manual
&man.ssh-keygen.1;.</para></warning>
</sect2>
<sect2 id="security-ssh-agent">
<title>ssh-agent y ssh-add</title>
<para>&man.ssh-agent.1; y &man.ssh-add.1; ofrecen
métodos para que las llaves <application>SSH</application>
se puedan cargar en memoria, permitiendo eliminar la necesidad de
teclear la contraseña cada vez que haga falta.</para>
<para>&man.ssh-agent.1; gestionará la
validación utilizando la llave (o llaves) privada que
le cargue. &man.ssh-agent.1; se usa para lanzar otras
aplicaciones. En el nivel más básico
puede generar una shell o a un nivel más avanzado un
gestor de ventanas.</para>
<para>Para usar &man.ssh-agent.1; en una shell necesitará
primero ser invocado como argumento por una shell. Segundo,
añada la identidad ejecutando &man.ssh-add.1; y facilitando
la contraseña de la llave privada. Completados estos
pasos el usuario puede hacer &man.ssh.1; a cualquier equipo
que tenga instalada la llave pública correspondiente.
Por ejemplo:</para>
<screen>&prompt.user; ssh-agent <replaceable>csh</replaceable>
&prompt.user; ssh-add
Enter passphrase for /home/user/.ssh/id_dsa:
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
&prompt.user;</screen>
<para>Para utilizar &man.ssh-agent.1; en X11 tendrá que
incluir una llamada a &man.ssh-agent.1; en
<filename>~/.xinitrc</filename>. De este modo ofrecerá
los servicios de &man.ssh-agent.1; a todos los programas
lanzados en X11. Veamos un ejemplo de
<filename>~/.xinitrc</filename>:</para>
<programlisting>exec ssh-agent <replaceable>startxfce4</replaceable></programlisting>
<para>Esto lanzaría &man.ssh-agent.1;, que a su
vez lanzaría <application>XFCE</application> cada
vez que inicie X11. Hecho esto y una vez reiniciado X11
para aplicar los cambios puede ejecutar &man.ssh-add.1; para
cargar todas sus llaves SSH.</para>
</sect2>
<sect2 id="security-ssh-tunneling">
<title>Túneles SSH</title>
<indexterm>
<primary>OpenSSH</primary>
<secondary>túneles</secondary>
</indexterm>
<para><application>OpenSSH</application> permite crear un túnel
en el que encapsular otro protocolo en una sesión
cifrada.</para>
<para>La siguiente orden le dice a &man.ssh.1; que cree un
túnel para <application>telnet</application>:</para>
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5023:localhost:23 usuario@foo.ejemplo.com</replaceable></userinput>
&prompt.user;</screen>
<para>Veamos las opciones que se le han suministrado a
<command>ssh</command>:</para>
<variablelist>
<varlistentry>
<term><option>-2</option></term>
<listitem>
<para>Obliga a <command>ssh</command> a utilizar la
versión 2 del protocolo. (No la use si
está trabajando con servidores SSH antiguos)</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-N</option></term>
<listitem>
<para>Indica que no se ejecutará una orden remota, o
solamente túnel. Si se omite,
<command>ssh</command> iniciaría una sesión
normal.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-f</option></term>
<listitem>
<para>Obliga a <command>ssh</command> a ejecutarse
en segundo plano.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-L</option></term>
<listitem>
<para>Indica un túnel local según el esquema
<replaceable>puerto local:equipo remoto:puerto remoto</replaceable>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>usuario@foo.ejemplo.com</option></term>
<listitem>
<para>El servidor SSH remoto.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Un túnel SSH crea un socket que escucha
en <hostid>localhost</hostid> en el puerto especificado.
Luego reenvía cualquier conexión
recibida en el puerto/equipo local vía la
conexión SSH al puerto o equipo remoto especificado.</para>
<para>En el ejemplo el puerto <replaceable>5023</replaceable> en
<hostid>localhost</hostid> se reenvía al puerto
<replaceable>23</replaceable> del <hostid>localhost</hostid>
de la máquina remota. Ya que <replaceable>23</replaceable>
es <application>telnet</application>, esto crearía una
sesión <application>telnet</application> segura a
través de un túnel SSH.</para>
<para>Puede usar esto para encapsular cualquier otro
protocolo TCP inseguro como SMTP, POP3, FTP, etc.</para>
<example>
<title>Uso de SSH para crear un túnel seguro para SMTP</title>
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5025:localhost:25 usuario@correo.ejemplo.com</replaceable></userinput>
usuario@correo.ejemplo.com's password: <userinput>*****</userinput>
&prompt.user; <userinput>telnet localhost 5025</userinput>
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 correo.ejemplo.com ESMTP</screen>
<para>Puede usar esta técnica junto con &man.ssh-keygen.1;
y cuentas adicionales de usuario para crear un entorno
más transparente, esto es, más cómodo.
Puede usar llaves en lugar de teclear contraseñas y
puede ejecutar los túneles de varios usuarios.</para>
</example>
<sect3>
<title>Ejemplos prácticos de túneles SSH</title>
<sect4>
<title>Acceso seguro a un servidor POP3</title>
<para>En el trabajo hay un servidor SSH que acepta
conexiones desde el exterior. En la misma red de la
oficina reside un servidor de correo que ejecuta un
servidor POP3. La red, o ruta de red entre su casa y
oficina puede o no ser completamente de fiar. Debido
a esto necesita revisar su correo electrónico
de forma segura. La solución es crear una
conexión SSH al servidor SSH de su oficina y
llegar por un túnel al servidor de correo.</para>
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>2110:correo.ejemplo.com:110 usuario@servidor-ssh.ejemplo.com</replaceable></userinput>
usuario@servidor-ssh.ejemplo.com's password: <userinput>******</userinput></screen>
<para>cuando el túnel esté funcionando
haga que su cliente de correo envíe peticiones
POP3 a <hostid>localhost</hostid> en el puerto 2110.
La conexión será reenviada de forma totalmente
segura a traveés del túnel a
<hostid>correo.ejemplo.com</hostid>.</para>
</sect4>
<sect4>
<title>Saltarse un cortafuegos draconiano</title>
<para>Algunos administradores de red imponen reglas de
cortafuegos extremadamente draconianas, filtrando no
solo las conexiones entrantes, sino también
las salientes. Tal vez solo se le otorgue acceso
a máquinas remotas a través de los puertos 22
y 80 para ssh y navegar en web.</para>
<para>Tal vez quiera acceder a otros servicios
(que tal vez ni siquiera estén relacionados con el
trabajo), como un servidor Ogg Vorbis para escuchar
música. Si ese servidor Ogg Vorbis transmite en
un puerto que no sea el 22 o el 80 no podrá tener
acceso a él.</para>
<para>La solución es crear una conexión SSH
fuera del cortafuegos de su red y utilizarla para hacer un
túnel al servidor Ogg Vorbis.</para>
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>8888:musica.ejemplo.com:8000 usuario@sistema-no-filtrado.ejemplo.org</replaceable></userinput>
usuario@sistema-no-filtrado.ejemplo.org's password: <userinput>*******</userinput></screen>
<para>Haga que el programa con el que suele escuchar
música haga peticiones a
<hostid>localhost</hostid> puerto 8888, que será
reenviado a <hostid>musica.ejemplo.com</hostid>
puerto 8000, evadiendo con éxito el cortafuegos.</para>
</sect4>
</sect3>
</sect2>
<sect2>
<title>La opción de usuarios <varname>AllowUsers</varname></title>
<para>Limitar qué usuarios pueden entrar y desde dónde
suele ser razonable. La opción
<literal>AllowUsers</literal> le permite configurarlo, por
ejemplo, para permitir entrar solamente al usuario
<username>root</username> desde
<hostid role="ipaddr">192.168.1.32</hostid>. Puede hacerlo
con algo parecido a esto en
<filename>/etc/ssh/sshd_config</filename>:</para>
<programlisting>AllowUsers root@192.168.1.32</programlisting>
<para>Para permitir al usuario <username>admin</username> la
entrada desde cualquier lugar, solamente introduzca el nombre
de usuario:</para>
<programlisting>AllowUsers admin</programlisting>
<para>Puede listar múltiples usuarios en la misma
línea:</para>
<programlisting>AllowUsers root@192.168.1.32 admin</programlisting>
<note>
<para>Es importante que incluya a cada usuario que necesite entrar
a esta máquina o no podrán entrar.</para>
</note>
<para>Después de hacer los cambios a b
<filename>/etc/ssh/sshd_config</filename> debe decirle a
&man.sshd.8; que cargue de nuevo sus ficheros de
configuración ejecutando:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/sshd reload</userinput></screen>
</sect2>
<sect2>
<title>Lecturas complementarias</title>
<para><ulink url="http://www.openssh.com/">OpenSSH</ulink></para>
<para>&man.ssh.1; &man.scp.1; &man.ssh-keygen.1;
&man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5;</para>
<para>&man.sshd.8; &man.sftp-server.8; &man.sshd.config.5;</para>
</sect2>
</sect1>
<sect1 id="fs-acl">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Contribuido por </contrib>
</author>
</authorgroup>
</sect1info>
<title>Listas de control de acceso a sistemas de ficheros</title>
<indexterm>
<primary>ACL</primary>
</indexterm>
<para>Además de otras mejoras del sistema de ficheros como
las instantáneas (<quote>snapshots</quote>), &os; 5.0 y
siguientes ofrecen las ACL (<quote>Access Control Lists</quote>,
listas de control de acceso) como un elemento más de
seguridad.</para>
<para>Las listas de control de acceso extienden el modelo de
permisos estándar de &unix; de una manera altamente
compatible (&posix;.1e). Esta opción permite al
administrador usar con gran provecho un modelo de seguridad
más sofisticado.</para>
<para>Para habilitar soporte de <acronym>ACL</acronym> en sistemas
de ficheros <acronym>UFS</acronym> la siguiente opción:</para>
<programlisting>options UFS_ACL</programlisting>
<para>debe ser compilada en el kernel. Si esta opción
no ha sido compilada, se mostrará un mensaje de advertencia
si se intenta montar un sistema de ficheros que soporte
<acronym>ACL</acronym>. Esta opción viene incluida
en el kernel <filename>GENERIC</filename>.
Las <acronym>ACL</acronym> dependen de los atributos extendidos
habilitados en el sistema de ficheros. Los atributos extendidos
están incluidos por defecto en la nueva generación
de sistemas de ficheros &unix; <acronym>UFS2</acronym>.</para>
<note><para>Los atributos extendidos pueden usarse también
en <acronym>UFS1</acronym> pero requieren una carga de trabajo
mucho más elevada que en <acronym>UFS2</acronym>.
El rendimiento de los atributos extendidos es, también,
notablemente mayor en <acronym>UFS2</acronym>. Por todo esto
si quiere usar ACL le recomendamos encarecidamente que use
<acronym>UFS2</acronym>.</para></note>
<para>Las<acronym>ACL</acronym> se habilitadan mediante una bandera
administrativa durante el montaje, <option>acls</option>, en el fichero
<filename>/etc/fstab</filename>. La bandera de montaje puede
también activarse de forma permanente mediante
&man.tunefs.8; para modificar una bandera de superbloque
<acronym>ACLs</acronym> en la cabecera del sistema de ficheros.
En general es preferible usar la bandera de superbloque por
varios motivos:</para>
<itemizedlist>
<listitem>
<para>La bandera de montaje <acronym>ACL</acronym> no puede cambiarse
por un remontaje (&man.mount.8; <option>-u</option>), sino con un
completo &man.umount.8; y un &man.mount.8;. Esto significa
que no se pueden habilitar las <acronym>ACL</acronym> en el sistema
de ficheros raíz después del arranque. También
significa que no se puede cambiar la disposición de un
de ficheros una vez que se ha comenzado a usar.</para>
</listitem>
<listitem>
<para>Activar la bandera de superbloque provocará que el sistema
de ficheros se monte siempre con las <acronym>ACL</acronym>
habilitadas incluso si no existe una entrada en
<filename>fstab</filename> o si los dispositivos se reordenan.
Esto es así para prevenir un montaje accidental del
sistema de ficheros sin tener las <acronym>ACL</acronym> habilitadas,
que podría resultar en que se impongan de forma inadecuada las
<acronym>ACL</acronym>, y en consecuencia problema de
seguridad.</para>
</listitem>
</itemizedlist>
<note><para>Podemos cambiar el comportamiento de las
<acronym>ACL</acronym> para permitirle a la bandera ser habilitada
sin un &man.mount.8; completo, pero puede salirle el tiro por la
culata si activa las <acronym>ACL</acronym>, luego las desactiva,
y después las vuelve a activar sin configurar desde cero las
atributos extendidos. En general, una vez que se han deshabilitado
las <acronym>ACL</acronym> en un sistema de ficheros no deben
dehabilitarse, ya que la protección de ficheros resultante
puede no ser compatible las que esperan los usuarios del sistema,
y al volver a activar las <acronym>ACL</acronym> volver a asignar
las <acronym>ACL</acronym> a ficheros cuyos permisos hubieran sido
cambiados, lo que puede desenbocar en un escenario
impredecible.</para></note>
<para>Los sistemas de ficheros con <acronym>ACL</acronym> habilitadas
tienen un signo <literal>+</literal> (más) al visualizar
sus configuraciones de permisos. Por ejemplo:</para>
<programlisting>drwx------ 2 robert robert 512 Dec 27 11:54 private
drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directorio1
drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directorio2
drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directorio3
drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting>
<para>Aquí vemos que los directorios
<filename>directorio1</filename>,
<filename>directorio2</filename>, y <filename>directorio3</filename>
están usando <acronym>ACL</acronym>.
El directorio <filename>public_html</filename> no.</para>
<sect2>
<title>Uso de <acronym>ACL</acronym></title>
<para>Las <acronym>ACL</acronym>s del sistema de ficheros pueden
comprobarse con &man.getfacl.1;. Por ejemplo,
para ver las configuraciones de <acronym>ACL</acronym> del
fichero <filename>test</filename>, uno podría
usar lo siguiente:</para>
<screen>&prompt.user; <userinput>getfacl <filename>test</filename></userinput>
#file:test
#owner:1001
#group:1001
user::rw-
group::r--
other::r--</screen>
<para>Para cambiar las configuraciones de las <acronym>ACL</acronym> en
este fichero use &man.setfacl.1;. Observe:</para>
<screen>&prompt.user; <userinput>setfacl -k <filename>test</filename></userinput></screen>
<para>La bandera <option>-k</option> eliminará todas
las <acronym>ACL</acronym>s definidas para un fichero o sistema
ficheros. El método preferible sería utilizar
<option>-b</option>, ya que deja los campos básicos
imprescindibles para que las <acronym>ACL</acronym> sigan
funcionando.</para>
<screen>&prompt.user; <userinput>setfacl -m u:trhodes:rwx,group:web:r--,o::--- <filename>test</filename></userinput></screen>
<para>La opción <option>-m</option> se usa para modificar
las entradas por defecto de las <acronym>ACL</acronym>.
Debido a que no había entradas predefinidas puesto que
fueron eliminadas por la orden anterior, restauraremos las
opciones por defecto y asignará las opciones listadas.
Tenga en cuenta que si añade un nuevo usuario o grupo
aparecerá el error <errorname>Invalid argument</errorname>
en la salida estándar
<devicename>stdout</devicename>.</para>
</sect2>
</sect1>
<sect1 id="security-portaudit">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Texto de </contrib>
</author>
</authorgroup>
</sect1info>
<title>Monitorización de fallos de seguridad de aplicaciones</title>
<indexterm>
<primary>Portaudit</primary>
</indexterm>
<para>En estos últimos años el mundo de la seguridad
ha hecho grandes avances en cuanto a la gestión de las
vulnerabilidades. La amenaza de asaltos a los sistemas se
incrementa cuando se instalan y configuran aplicaciones de
muy diversas procedencias en virtualmente cualquier sistema
operativo disponible.</para>
<para>La evaluación de vulnerabilidades es un factor
clave en la seguridad; aunque &os; libere avisos de seguridad
relacionados con el sistema base, llevar la gestión
de vulnerabilidades hasta cada aplicación que se puede
instalar en &os; va mucho más allá de la capacidad
del proyecto &os;. A pesar de esto existe una forma de
mitigar las vulnerabilidades de esas aplicaciones y advertir
a los administradores sobre los problemas de seguridad a
medida que se detectan. <application>Portaudit</application>
existe para hacer ese trabajo.</para>
<para>El port <filename role="port">security/portaudit</filename>
consulta una base de datos, actualizada y mantenida por el
equipo de seguridad y por los desarrolladores de &os; en busca de
incidentes de seguridad que hayan sido detectados.</para>
<para>Si quiere usar <application>Portaudit</application>
instálelo desde la colección de ports:</para>
<screen>&prompt.root; <userinput>cd /usr/ports/security/portaudit && make install clean</userinput></screen>
<para>Durante el proceso de instalación los ficheros
de configuración de &man.periodic.8; se actualizan
haciendo que <application>Portaudit</application>
aparezca en el mensaje sobre la seguridad del sistema que diariamente
Recuerde que ese correo (que se envia a la cuenta
<username>root</username> es muy importante y debería
leerlo. No hay ninguna
configuración que deba modificar o crear.</para>
<para>Después de la instalación un administrador debe
actualizar la base de datos alojada en local en
<filename class="directory">/var/db/portaudit</filename>
mediante:</para>
<screen>&prompt.root; <userinput>portaudit -F</userinput></screen>
<note>
<para>La base de datos será actualizada
automáticamente durante la ejecución de
&man.periodic.8;; así que la orden anterior es
totalmente opcional. Solo se necesita para los siguientes
ejemplos.</para>
</note>
<para>Si quiere comproblar si entre las aplicaciones que haya
instalado desde el árbol de ports en su sistema hay
problemas de seguridad sólo tiene que ejecutar lo
siguiente:</para>
<screen>&prompt.root; <userinput>portaudit -a</userinput></screen>
<para>Este es un ejemplo de la salida:</para>
<programlisting>Affected package: cups-base-1.1.22.0_1
Type of problem: cups-base -- HPGL buffer overflow vulnerability.
Reference: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html>
1 problem(s) in your installed packages found.
You are advised to update or deinstall the affected package(s) immediately.</programlisting>
<para>El administrador del sistema obtendrá mucha más
información sobre el problema de seguridad dirigiendo su
navegador web a la <acronym>URL</acronym> que aparece en el
mensaje. Esto incluye versiones afectadas (por versión de
port de &os;), junto con otros sitios web que contengan advertencias
de seguridad.</para>
<para>En pocas palabras, <application>Portaudit</application> es un
programa muy poderoso y extremadamente útil cuando se
combina con el port <application>Portupgrade</application>.</para>
</sect1>
<sect1 id="security-advisories">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Texto de </contrib>
</author>
</authorgroup>
</sect1info>
<title>&os; Security Advisories</title>
<indexterm>
<primary>Advertencias de seguridad en FreeBSD</primary>
</indexterm>
<para>Como muchos sistemas operativos con calidad de producción,
&os; publica <quote>Security Advisories</quote> (advertencias de
seguridad. Estas advertencias suelen enviarse por correo a las
listas de seguridad e incluidas en la Errata solamente después
de que la versión apropiada haya sido corregida. Esta
sección tiene como fin explicar en qué consiste una
advertencia de seguridad, cómo entenderla y qué
medidas hay que tomar para parchear el sistema.</para>
<sect2>
<title>?Qué aspecto tiene una advertencia de
seguridad?</title>
<para>Las advertencias de seguridad de &os; tienen un aspecto
similar a la que se muestra aquí. Fué enviada a la
lista de correo &a.security-notifications.name;.</para>
<programlisting>=============================================================================
&os;-SA-XX:XX.UTIL Security Advisory
The &os; Project
Topic: denial of service due to some problem<co id="co-topic"/>
Category: core<co id="co-category"/>
Module: sys<co id="co-module"/>
Announced: 2003-09-23<co id="co-announce"/>
Credits: Person@EMAIL-ADDRESS<co id="co-credit"/>
Affects: All releases of &os;<co id="co-affects"/>
&os; 4-STABLE prior to the correction date
Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE)
2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6)
2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15)
2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8)
2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18)
2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21)
2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33)
2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43)
2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39)<co id="co-corrected"/>
&os; only: NO<co id="co-only"/>
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
http://www.FreeBSD.org/security/.
I. Background<co id="co-backround"/>
II. Problem Description<co id="co-descript"/>
III. Impact<co id="co-impact"/>
IV. Workaround<co id="co-workaround"/>
V. Solution<co id="co-solution"/>
VI. Correction details<co id="co-details"/>
VII. References<co id="co-ref"/></programlisting>
<calloutlist>
<callout arearefs="co-topic">
<para>El campo <literal>Topic</literal> indica cuál es
exactamente el problema. Básicamente es la
introducción de la advertencia de seguridad actual
e indica el uso malintencionado que puede darse a la
vulnerabilidad.</para>
</callout>
<callout arearefs="co-category">
<para><literal>Category</literal> se refiere a la parte afectada del
sistema, que puede ser
<literal>core</literal>, <literal>contrib</literal> o
<literal>ports</literal>. La categoría
<literal>core</literal> significa que la vulnerabilidad afecta
a un componente central del sistema operativo &os;. La
categoría <literal>contrib</literal> significa que la
vulnerabilidad afecta a software que no ha sido desarrollado por
el proyecto &os;, como <application>sendmail</application>.
La categoría <literal>ports</literal> indica que la
vulnerabilidad afecta a software incluido en la colección
de ports.</para>
</callout>
<callout arearefs="co-module">
<para>El campo <literal>Module</literal> se refiere a la
ubicación del componente, por ejemplo
<literal>sys</literal>. En este ejemplo vemos que está
afectado el módulo <literal>sys</literal>;
por lo tanto esta vulnerabilidad afecta a componentes
utilizados dentro del kernel.</para>
</callout>
<callout arearefs="co-announce">
<para>El campo <literal>Announced</literal> refleja la fecha
de publicación de la advertencia de seguridad fué
publicada o anunciada al mundo. Esto significa que el equipo
de seguridad ha verificado que el que el problema existe y que
se ha incluido un parche que soluciona el problema en el
repositorio de código fuente de &os;.</para>
</callout>
<callout arearefs="co-credit">
<para>El campo <literal>Credits</literal> le da el crédito al
individuo u organización que descubrió y reportó
la vulnerabilidad.</para>
</callout>
<callout arearefs="co-affects">
<para>El campo <literal>Affects</literal> explica a qué
versiones de &os; afecta esta vulnerabilidad. En el caso del
kernel una rápida revisión de la salida de
<command>ident</command> en los ficheros afectados
ayudará a determinar la versión. En el caso de
de los ports el número de versión aparece
después del nombre del port en
<filename>/var/db/pkg</filename>. Si el sistema no se
sincroniza con el repositorio <acronym>CVS</acronym> de
&os; y se reconstruye diariamente, existe la posibilidad de
que esté afectado por el problema de seguridad.</para>
</callout>
<callout arearefs="co-corrected">
<para>El campo <literal>Corrected</literal> indica la fecha, hora,
zona horaria y versión de &os; en que fué
corregido.</para>
</callout>
<callout arearefs="co-only">
<para>El campo <literal>&os; only</literal> indica si la
vulnerabilidad afecta solamente a &os; o si afecta
también a otros sistemas operativos.</para>
</callout>
<callout arearefs="co-backround">
<para>El campo <literal>Background</literal> informa acerca de
qué es exactamente la aplicación afectada.
La mayor parte de las veces se refiere a por qué la
aplicación existe en &os;, para qué se usa y
un poco de información de cómo llegó
llegó a ocupar el lugar que ocupa en el sistema o el
árbol de ports.</para>
</callout>
<callout arearefs="co-descript">
<para>El campo <literal>Problem Description</literal> explica el
problema de seguridad en profundidad. Puede incluir
información del código erróneo,
o incluso cómo puede usarse maliciosamente el error
para abrir un agujero de seguridad.</para>
</callout>
<callout arearefs="co-impact">
<para>El campo <literal>Impact</literal> describe el tipo de
impacto que el problema pueda tener en un sistema. Por ejemplo,
esto puede ser desde un ataque de denegación de servicio,
hasta una escalada de privilegios de usuario, o incluso
ofrecer al atacante acceso de superusuario.</para>
</callout>
<callout arearefs="co-workaround">
<para>El campo <literal>Workaround</literal> ofrece una
solución temoral posible para los administradores
de sistemas que tal vez no puedan actualizar el sistema.
Esto puede deberse a la falta de tiempo, disponibilidad de
de red, o a muchas otras razones. A pesar de todo la
la seguridad no se debe tomar a la ligera y un sistema
afectado debe parchearse al menos aplicar una
solución temporal para el agujero de
seguridad.</para>
</callout>
<callout arearefs="co-solution">
<para>El campo <literal>Solution</literal> ofrece instrucciones
para parchear el sistema afectado. Este es un método paso
a paso, probado y verificado para parchear un sistema y que
trabaje seguro.</para>
</callout>
<callout arearefs="co-details">
<para>El campo <literal>Correction Details</literal> despliega
la rama del <acronym>CVS</acronym> o el nombre de la
versión con los puntos cambiados a guiones bajos.
También muestra el número de revisión de
los ficheros afectados dentro de cada rama.</para>
</callout>
<callout arearefs="co-ref">
<para>El campo <literal>References</literal> suele ofrecer fuentes
adicionales de información:
<acronym>URL</acronym>, libros, listas de correo y grupos
de noticias.</para>
</callout>
</calloutlist>
</sect2>
</sect1>
<sect1 id="security-accounting">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Texto de </contrib>
</author>
</authorgroup>
</sect1info>
<title>Contabilidad de procesos</title>
<indexterm>
<primary>Contabilidad de procesos</primary>
</indexterm>
<para>La contabilidad de procesos es un método de
seguridad en el cual un administrador puede mantener un
seguimiento de los recursos del sistema utilizados,
su distribución entre los usuarios, ofrecer
monitorización del sistema y seguir la pista
mínimamente a las órdenes de usuario.</para>
<para>Esto en realidad tiene sus puntos positivos y negativos.
Uno de los positivos es que una intrusión puede
minimizarse en el momento de producirse. Uno negativo
es la cantidad de logs generados por la contabilidad de
procesos y el espacio de disco que requieren. Esta
sección guiará al administrador a
través de los fundamentos de la contabilidad de
procesos.</para>
<sect2>
<title>Cómo habilitar y utilizar la contabilidad
de procesos</title>
<para>Antes de poder usar la contabilidad de procesos
tendrá que habilitarla. Ejecute la
siguiente orden:</para>
<screen>&prompt.root; <userinput>touch <filename>/var/account/acct</filename></userinput>
&prompt.root; <userinput>accton <filename>/var/account/acct</filename></userinput>
&prompt.root; <userinput>echo 'accounting_enable="YES"' >> <filename>/etc/rc.conf</filename></userinput></screen>
<para>Una vez habilitada, la contabilidad de procesos
empezará a seguir el rastro de estadísticas
de la <acronym>CPU</acronym>, órdenes, etc. Todos los logs
de contabilidad están en un formato ilegible
para humanos, pero accesibles para &man.sa.8;.
Si se ejecuta sin opciones, <command>sa</command>
imprimirá información sobre el número
de llamadas por usuario, el tiempo total transcurrido expresado
en minutos, el tiempo total de <acronym>CPU</acronym> y de usuario
en minutos, el número medio de operaciones de E/S,
etc.</para>
<para>Para ver información acerca de las órdenes
que se están ejecutados puede usar la
&man.lastcomm.1;. <command>lastcomm</command> imprime
órdenes ejecutadas por los usuarios en &man.ttys.5;
específicas. Veamos un ejemplo:</para>
<screen>&prompt.root; <userinput>lastcomm ls
<username>trhodes</username> ttyp1</userinput></screen>
<para>Imprimiría todas las veces (conocidas) que
el usuario <username>trhodes</username> ha usado
<command>ls</command> en la terminal
ttyp1.</para>
<para>Hay muchas más opciones que pueden serle muy
útiles. Si quiere conocerlas consulte
las páginas de manual &man.lastcomm.1;, &man.acct.5;
y &man.sa.8;.</para>
</sect2>
</sect1>
</chapter>