Capítulo 14. Seguridad

En primer lugar, no se moleste en asegurar las cuentas administrativas (o "staff") si no ha asegurado la cuenta root. La mayoría de los sistemas tienen una contraseña asignada para la cuenta root. Lo primero que se hace es asumir que la contraseña está siempre 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 su(1). Por ejemplo, asegúrese de que sus ptys aparezcan como inseguras en el fichero /etc/ttys, con lo que hará que los accesos como root vía telnet o rlogin no sean posibles. Si utiliza otros tipos de login como sshd asegúrese de que los accesos al sistema como root estén también deshabilitados. Para ello edite su /etc/ssh/sshd_config y asegúrese de que PermitRootLogin esté puesto a NO. 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 root sólamente debe permitirse a través de la consola.

Es evidente que, como administrador del sistema, debe usted tener la posibilidad de acceder a root, 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 root sea accesible añadiendo cuentas administrativas al grupo wheel (en /etc/group). El personal que administra los sistemas que aparezcan en el grupo en el grupo wheel pueden hacer su a root. Nunca debe de proporcionar al personal administrativo el acceso nativo a wheel poniéndolos en el grupo wheel en su entrada de contraseña. Las cuentas administrativas deben colocarse en un grupo staff, y agregarse después al grupo wheel en /etc/group. Sólo aquellos administradores que realmente necesiten acceder a root deben pertenecer al grupo wheel. También es posible, mediante un método de autentificación como Kerberos, usar el fichero .k5login en la cuenta root para permitir un ksu(1) a root sin tener que colocar a nadie en el grupo wheel. Puede ser una mejor solución, ya que el mecanismo wheel aún permite a un atacante comprometer root si el intruso ha conseguido el fichero de contraseñas y puede comprometer una cuenta de administración. Recurrir al mecanismo wheel es mejor que no tener nada, pero no es necesariamente la opción más segura.

Una manera indirecta de asegurar las cuentas de staff y el acceso a root es utilizar un método de acceso alternativo: es lo que se conoce como "estrellar" las contraseñas cifradas de las cuentas administrativas. Use vipw(8) para reemplazar cada contraseña cifrada por un sólo caracter asterisco (“*”). Esto actualizará /etc/master.passwd y la base de datos de usuario/contraseña y deshabilitará los accesos al sistema validados mediante contraseñas.

Veamos una cuenta administrativa típica:

y cómo debería quedar:

Este cambio evitará que se efectúen logins normales, ya que la contraseña cifrada nunca se corresponderá con “*”. Hecho esto, el personal de administración tendrá que usar otro mecanismo de validación como kerberos(1) o 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 desde 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 ssh-keygen(1). El "estrellado" 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.

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.

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).

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 imapd o popper es como dar una entrada universal de root al mundo entero. Nunca ejecute un servidor que no haya revisado cuidadosamente. Muchos servidores no necesitan ejecutarse como root. Por ejemplo, los dæmons ntalk, comsat y finger pueden ejecutarse en una caja de arena (sandbox) 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 root en virtualmente todos los servidores que se haya ejecutado como root, incluyendo servidores básicos del sistema. Si está tiene una máquina a través de la cual la gente sólo entra por sshd, y nunca entra por telnetd, rshd, o rlogind apague esos servicios.

FreeBSD ejecuta por defecto ntalkd, comsat y finger en una caja de arena. Otro programa que puede ser candidato para ejecutarse en una caja de arena es named(8). /etc/defaults/rc.conf contiene las directrices necesarias (con comentarios) para usar named 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.

Existen numerosos servidores que no se suelen ejecutar en cajas de arena: sendmail, imapd, ftpd, 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 root y depender de otros mecanismos para detectar intrusiones que puedan tener lugar a través de ellos.

Los otros grandes agujeros potenciales de root que encontramos en un sistema son los binarios suid-root y sgid. La mayoría de estos binarios, como rlogin, están en /bin, /sbin, /usr/bin o /usr/sbin. 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 root en estos binarios. En 1998 se encontró un agujero root en Xlib, que hacía a xterm (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 (chmod 000) que no se use. Un servidor sin pantalla generalmente no necesita un binario xterm. Los binarios sgid pueden ser igual de peligrosos. Si un intruso logra comprometer un binario sgid-kmem, el intruso podría leer /dev/kmem 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 kmem 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 tty 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á.

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 "estrellar" 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.

La única manera segura es ponerle * a tantas contraseñas como sea posible y utilizar ssh o Kerberos para acceder a esas cuentas. Aunque el fichero cifrado de contraseñas (/etc/spwd.db) sólo puede ser legible para root, puede que un intruso consiga acceso de lectura a ese fichero, incluso sin haber alcanzado el acceso de escritura como root.

Sus "scripts" de seguridad deben buscar siempre cambios en el fichero de contraseñas (consulte Revisión de integridad de ficheros más abajo) e informar de ellos.

Si un atacante compromete root puede hacer cualquier cosa, pero hay ciertas cosas que puede usted preparar para "curarse en salud". Por ejemplo, la mayoría de los kernel modernos tienen un dispositivo de los Kernels modernos tienen un integrado un dispositivo de paquetes. En FreeBSD se llama bpf. Un intruso típico tratará de ejecutar un "sniffer" 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 bpf.

Pero si desactiva el dispositivo bpf todavía tendrá que preocuparse por /dev/mem y /dev/kmem. 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, kldload(8). Un intruso con iniciativa puede usar un módulo KLD para instalar su propio dispositivo bpf, u otro dispositivo que le permita el "sniffing" 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 sysctl en la variable kern.securelevel. 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 schg. También debe cerciorarse de activar la bandera schg en binarios críticos para el arranque, directorios y scripts (dicho de otro modo, todo aquello que se ejecuta antes 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 schg en cada fichero y directorio del sistema. Otra posibilidad es montar / y /usr como sólo lectura. Recuerde que siendo demasiado draconiano en aquello que busca proteger puede dificultar mucho la detección de una intrusión.

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 chflags para activar el bit schg en la mayoría de los ficheros de / y /usr 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.

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 "scripts" de seguridad en un sistema "extraseguro" 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.

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 "scripts" para efectuar la monitorización. Si va a usar un montaje NFS puede escribir "scripts" utilizando simples herramientas del sistema como find(1) y 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 /etc y /usr/local/etc) 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 "script" también debe buscar binarios que sean suid sin razón aparente, y ficheros nuevos o borrados en particiones del sistema como / y /usr.

Si usa ssh en lugar de NFS será mucho más complicado escribir el "script" de seguridad. En esencia, tiene que pasar por scp los "scripts" a la máquina cliente para poder ejecutarlos, haciéndolos visibles; por seguridad, también tendrá que pasar vía scp los binarios (por ejemplo find) que utilizan dichos "scripts". El cliente ssh 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.

Un buen "script" de seguridad buscará también cambios en la configuración de los ficheros de acceso de usuarios y miembros del personal de administración: .rhosts, .shosts, .ssh/authorized_keys, etc; en resumen, ficheros fuera del rango de revisión MD5.

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 nodev y nosuid de 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.

La contabilidad de procesos (vea 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).

Los "scripts" 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.

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 sí 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.

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 ("spoofed") que busque saturar su red, pero puede limitar el daño asegurándose de que los ataques no tiren sus servidores.

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. inetd (consulte 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 inetd atentamente y sobre todo estudie las las opciones -c, -C, y -R. Observe que los ataques con direcciones IP falsificadas sortearán la opción -C de inetd, así que debe usar una combinación de opciones. Algunos servidores autónomos ("standalone") cuentan con parámetros de autolimitación de instancias.

Sendmail tiene la opción -OMaxDaemonChildren, 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 MaxDaemonChildren al inicio de sendmail 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 sendmails sin caerse de boca. También es prudente ejecutar sendmail en modo de cola (-ODeliveryMode=queued) y ejecutar el dæmon (sendmail -bd) de manera independiente de las ejecuciones de cola (sendmail -q15m). Si a pesar de todo necesita entregas en tiempo real puede ejecutar la cola a un intervalo menor, como -q1m, pero asegúrese de especificar una opción MaxDaemonChildren razonable para ese sendmail y así evitar fallos en cascada.

Syslogd puede recibir ataques directos y se recomienda encarecidamente que utilice la opción -s siempre que sea posible, y si no la opción -a.

También debe ser extremadamente cuidadoso con servicios de conexión inversa como el ident inverso de TCP Wrapper, que puede recibir ataques directos. No se suele usar el ident inverso de TCP Wrapper por esa misma razón.

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 root basados en red. Configure siempre un cortafuegos exclusivo, esto es, "restringir todo menos los puertos A, B, C, D y M-Z". De esta manera restringirá todos sus puertos con números bajos excepto ciertos servicios específicos como named (si es el servidor primario de una zona), ntalkd, sendmail, 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 "cerrar" 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 FreeBSD le permite controlar el rango de números de puerto utilizados para asignación dinámica a través de las numerosas net.inet.ip.portrange de sysctl (sysctl -a | fgrep portrange), 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).

Otro ataque DoS común es llamado ataque "springboard": 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 ataques ICMP ping broadcast. 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 "springboard" 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 "mbufs", especialmente si el servidor no puede drenar lo suficientemente rápido las respuestas ICMP que genera. El kernel de FreeBSD tiene una opción de compilación llamada ICMP_BANDLIM, que limita la efectividad de este tipo de ataques. La última gran categoría de ataques "springboard" está relacionada con ciertos servicios de inetd, 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 chargen. Un administrador de sistemas competente apagará todos estos servicios internos de verificación de inetd.

Los ataques con paquetes falsificados pueden utilizarse también para sobrecargar la caché de rutas del kernel. Consulte los parámetros de sysctl net.inet.ip.rtexpire, rtminexpire, y rtmaxcache. 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 netstat -rna | fgrep W3. 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 rtexpire, pero nunca la reducirá a un valor que sea menor que rtminexpire. Esto nos presenta dos problemas:

Si sus servidores están conectados a Internet mediante mediante una línea T3 o superior puede ser prudente corregir manualmente rtexpire y rtminexpire por medio de 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.

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 telnet y rlogin que las hacen inapropiadas para gestionar flujos binarios. Ademé Kerberos no cifra por defecto una sesión a menos que utilice la opción -x. ssh cifra todo por defecto.

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 root 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.

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 ssh 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 from=IP/DOMAIN que ssh incluye en authorized_keys; así la llave sólo podrá ser utilizada por entidades que se validen desde máquinas específicas.

En versiones anteriores a FreeBSD 4.4 libcrypt.a era un enlace simbólico que apuntaba a la biblioteca que se usaba para el cifrado. En FreeBSD 4.4 se cambió libcrypt.a para ofrecer una biblioteca hash configurable de validación de contraseñas. Actualmente la biblioteca permite funciones hash DES, MD5 y Blowfish. FreeBSD utiliza por defecto MD5 para cifrar contraseñas.

Es muy sencillo identificar qué método usa FreeBSD para cifrar. Una forma es examinando las contraseñas cifradas en /etc/master.passwd. 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 $1$. Las contraseñas que comienzan por $2a$ 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 $; es por esto que una cadena relativamente corta que comience con un signo de dólar es muy probablemente una contraseña DES.

El formato de contraseña a usar en nuevas contraseñas se define en /etc/login.conf mediante passwd_format, pudiendo tener los valores des, md5 o blf. Consulte la página de manual login.conf(5) para más información.

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 ssh); use keyinit sin ningún parámetro:

En OPIE se utiliza opiepasswd:

En Enter new secret pass phrase: o Enter secret password:, 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 "ID" 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 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 key u opiekey; 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 keyinit -s:

En OPIE debe usar opiepasswd:

Para aceptar la semilla por defecto (la que el programa keyinit llama key, "llave", para terminar de complicar las cosas), pulse Enter. 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:

O para OPIE:

Vuelva a la conexión insegura y copie la contraseña de un solo uso generada al programa que quiera usar.

Una vez que ha inicializado S/Key u OPIE, cuando haga login verá un "prompt" parecido al siguiente:

O, en el caso de OPIE:

Como una nota aparte, el "prompt" de S/Key y OPIE cuenta con una opción útil (que no se muestra aquí): si pulsa Enter en el "prompt" de contraseña el "prompt" 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.

Ahora necesitará generar su contraseña de un sólo uso para responder a este "prompt" de login. Debe hacerlo en un sistema digno de confianza y en el que pueda ejecutar key u opiekey. Existen versiones DOS, Windows® y también para Mac OS®. Ambos usarán la cuenta iterativa y la semilla como opciones de línea de órdenes. Puede cortarlas y pegarlas desde el "prompt" de login de la máquina en la que se está identificando.

En el sistema de confianza:

Con OPIE:

Ahora que tiene su contraseña de un solo uso puede proceder con el login:

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 key y opiekey para generar previamente numerosas contraseñas de un solo uso para, una vez impresas, llevárselas a donde hagan falta. Por ejemplo:

O para OPIE:

El -n 5 pide cinco llaves en secuencia, la opción 30 especifica que ese debe ser el último número de iteración. Observe que se imprimen en el orden inverso de uso. Si es realmente paranoico escriba los resultados a mano; si no, puede enviar la salida a lpr. 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.

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 /etc/skey.access. La página de manual de 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.

Si /etc/skey.access no existiera (por defecto es así en sistemas FreeBSD 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 skey.access. En todos los casos las contraseñas UNIX® son admiten en consola.

Aquí hay un ejemplo del fichero de configuración skey.access que muestra las tres formas más comunes de configuración:

La primera línea (permit internet) 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.

La segunda línea (permit user) permite al nombre de usuario especificado, en este caso fnord, utilizar contraseñas UNIX® en cualquier momento. Hablando en general, esto solo debe ser usado por gente que no puede usar el programa key, como aquellos con terminales tontas o refractarios al aprendizaje.

La tercera línea (permit port) 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 "dial-ups".

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 /etc/opieaccess, que está incluído por defecto en sistemas FreeBSD 5.0 o posteriores. Revise opieaccess(5) para más información sobre este fichero y qué consideraciones de seguridad debe tener presentes a la hora de usarlo.

Veamos un ejemplo de opieaccess:

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.

Si no concuerda ninguna regla en opieaccess se niegan por defecto los logins no-OPIE.

El único requisito para usar TCP Wrappers en FreeBSD es que el servidor inetd se inicie desde rc.conf con la opción -Ww (es la configuración por defecto). Por descontado, se presupone que /etc/hosts.allow estará correctamente configurado, pero syslogd(8) enviará mensajes a los logs del sistema si no es así.

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 /etc/hosts.allow. La configuración por defecto en FreeBSD consiste en permitir una conexión a cada dæmon iniciado por inetd. Es posible modificar esta configuración, pero explicaremos cómo hacerlo después de exponer la configuración básica.

La configuración básica tiene la estructura dæmon : dirección : acción, donde dæmon es el nombre de dæmon que inicia inetd. La dirección 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á.

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 POP3 mediante el dæmon mail/qpopper, añada las siguientes líneas a hosts.allow:

Despues de añadir esta línea tendrá que reiniciar inetd. Use kill(1) o use el parámetro restart de /etc/rc.d/inetd.

Las opciones avanzadas de TCP 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 comodines, caracteres de expansión y ejecución de órdenes externas. Las siguientes dos secciones intentarán cubrir estas situaciones.

Kerberos es un componente opcional de FreeBSD. La manera más fácil de instalar este software es seleccionando la distribución krb4 o krb5 en sysinstall durante la instalación inicial de FreeBSD. Desde ahí instalará la implementación de Kerberos "eBones" (KerberosIV) o "Heimdal" (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.

También puede instalar la implementación de Kerberos del MIT desde la colección de ports (security/krb5).

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 /etc/kerberosIV y asegúrese de que solo estén los siguientes ficheros:

Si existe cualquier otro fichero (como principal.* o master_key) utilice kdb_destroy para destruir la base de datos antigua de Kerberos. Si Kerberos no está funcionando simplemente borre los ficheros sobrantes.

Edite krb.conf y krb.realms para definir su dominio Kerberos. En nuestro ejemplo el dominio será EJEMPLO.COM y el servidor es grunt.ejemplo.com. Editamos o creamos krb.conf:

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.

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 "centro de distribución de llaves". Las palabras admin server 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.

Ahora añadiremos grunt.ejemplo.com al dominio EJEMPLO.COM y también una entrada para poner todos los equipos en el dominio .ejemplo.com Kerberos EJEMPLO.COM. Puede actualizar su krb.realms del siguiente modo:

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.

La primera línea pone al sistema específico en el dominio nombrado. El resto de las líneas muestran cómo asignar por defecto sistemas de un subdominio a un dominio Kerberos.

Ya podemos crear la base de datos. Solo se ejecuta en el servidor Kerberos (o centro de distribución de llaves). Ejecute kdb_init:

Ahora tendremos que guardar la llave para que los servidores en la máquina local puedan recogerla. Utilice kstash:

Esto guarda la contraseña cifrada maestra en /etc/kerberosIV/master_key.

Tendrá que añadir a la base de datos dos entradas en concreto para cada sistema que vaya a usar Kerberos: kpasswd y rcmd. Se hacen para cada sistema individualmente cada sistema, y el campo "instance" es el nombre individual del sistema.

Estos dæmons kpasswd y rcmd permiten a otros sistemas cambiar contraseñas de Kerberos y ejecutar órdenes como rcp(1), rlogin(1) y rsh(1).

Ahora vamos a añadir estas entradas:

Ahora tendremos que extraer todas las instancias que definen los servicios en cada máquina; para ello usaremos ext_srvtab. Esto creará un fichero que debe ser copiado o movido por medios seguros al directorio /etc/kerberosIV de cada cliente Kerberos. Este fichero debe existir en todos los servidores y clientes dada su importancia clave para el funcionamiento de Kerberos.

Esta orden solo genera un fichero temporal al que tendrá que cambiar el nombre a srvtab para que todos los servidores puedan recogerlo. Utilice mv(1) para moverlo al lugar correcto en el sistema original:

Si el fichero es para un sistema cliente y la red no puede considerarse segura copie el cliente-new-srvtab en un medio extraíble y transpórtelo por medios físicos seguros. Asegúrese de cambiar su nombre a srvtab en el directorio /etc/kerberosIV del cliente, y asegúrese también de que tiene modo 600:

Ahora tenemos que añadir entradas de usuarios a la base de datos. Primero vamos a crear una entrada para el usuario jane. Para ello usaremos kdb_edit:

Primero tenemos que iniciar los dæmons de Kerberos. Tenga en cuenta que si su /etc/rc.conf 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 /etc/kerberosIV.

Ahora podemos probar a usar kinit para obtener un ticket para el ID jane que creamos antes:

Pruebe a listar los tokens con klist para ver si realmente están:

Ahora trate de cambiar la contraseña usando passwd(1) para comprobar si el dæmon kpasswd está autorizado a acceder a la base de datos Kerberos:

Kerberos nos permite dar a cada usuario que necesite privilegios de root su propia contraseña para su(1). Podemos agregar un ID que esté autorizado a ejecutar su(1) root. Esto se controla con una instancia de root asociada con un usuario. Vamos a crear una entrada jane.root en la base de datos, para lo que recurrimos a kdb_edit:

Ahora trate de obtener los tokens para comprobar que todo funciona:

Hemos de agregar al usuario al .klogin de root:

Ahora trate de hacer su(1):

y eche un vistazo a qué tokens tenemos:

En un ejemplo anterior creamos un usuario llamado jane con una instancia root. Nos basamos en un usuario con el mismo nombre del "principal" (jane), el procedimiento por defecto en Kerberos: <principal>.<instancia> con la estructura <nombre de usuario>. root permitirá que <nombre de usuario> haga su(1) a root si existen las entradas necesarias en el .klogin que hay en el directorio home de root:

De la misma manera, si un usuario tiene en su directorio home lo siguiente:

significa que cualquier usuario del dominio EJEMPLO.COM que se identifique como jane o como jack (vía kinit, ver más arriba) podrá acceder a la cuenta de jane o a los ficheros de este sistema (grunt) vía rlogin(1), rsh(1) o rcp(1).

Veamos por ejemplo cómo jane se se identifica en otro sistema mediante Kerberos:

Aquí jack se identifica con la cuenta de jane en la misma máquina (jane tiene configurado su fichero .klogin como se ha mostrado antes, y la persona encargada de la administración de Kerberos ha configurado un usuario principal jack con una instancia nula):

Kerberos fué creado en el Massachusetts Institute of Technology (MIT) como una solución a los problemas de seguridad de la red. El protocolo Kerberos 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.

Kerberos es el nombre de un protocolo de autentificación vía red y un adjetivo para describir programas que implementan el programa (Kerberos telnet, por ejemplo, conocido también como el "telnet kerberizado"). La versión actual del protocolo es la 5, descrita en RFC 1510.

Existen diversas implementaciones libres de este protocolo, cubriendo un amplio rango de sistemas operativos. El MIT, donde Kerberos fué desarrollado, continúa desarrollando su propio paquete Kerberos. Suele usarse en los EEUU como producto criptográfico y como tal ha sufrido las regulaciones de exportación de los EEUU. El Kerberos del MIT existe como un port en (security/krb5). Heimdal Kerberos es otra implementación de la versión 5, y fué desarrollada de forma intencionada fuera de los EEUU para sortear las regulaciones de exportación (y por eso puede incluirse en versiones no comerciales de UNIX®). La distribución Heimdal Kerberos está en el port (security/heimdal), y se incluye una instalación mínima en el sistema base de FreeBSD.

Para alcanzar la mayor audiencia estas instrucciones asumen el uso de la distribución Heimdal incluída en FreeBSD.

El centro de distribución de llaves (KDC, Key Distribution Center) es el servicio centralizado de validación que proporciona Kerberos: es el sistema que emite tickets Kerberos. El KDC goza del estátus de ser considerado como "confiable" por las demás computadoras del dominio Kerberos, y por eso tiene consideraciones de seguridad más elevadas.

Tenga en cuenta que, aunque la ejecución del servidor Kerberos requiere muy pocos recursos, se recomienda el uso de una máquina dedicada a KDC por razones de seguridad.

Para empezar a configurar un KDC asegúrese de que su /etc/rc.conf contenga la configuración adecuada para actuar como KDC (tal vez deba ajustar algunas rutas para que cuadren con su sistema):

A continuación configuraremos el fichero de configuración de Kerberos, /etc/krb5.conf:

Tenga en cuenta que este /etc/krb5.conf implica que su KDC tendrá el nombre de equipo completo calificado de kerberos.ejemplo.org. Necesitará añadir una entrada CNAME (alias) a su fichero de zona si su KDC tiene un nombre de equipo diferente.

A continuación crearemos la base de datos Kerberos. 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 /var/heimdal/m-key. Para crear la llave maestra ejecute kstash e introduzca una contraseña.

Una vez que se ha creado la llave maestra puede inicializar la base de datos usando el programa kadmin con la opción -l (que significa "local"). Esta opción le dice a kadmin que modifique los ficheros de la base de datos directamente en lugar de ir a través del servicio de red kadmind. 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 "prompt" de kadmin, utilice init para crear su base de datos de dominios iniciales.

Para terminar, mientras está todavía en kadmin puede crear su primer principal mediante add. Utilice las opciones por defecto por ahora, más tarde puede cambiarlas mediante modify. Recuerde que puede usar ? en cualquier "prompt" para consultar las opciones disponibles.

Veamos un ejemplo de sesión de creación de una base de datos:

Ahora puede arrancar los servicios KDC. Ejecute /etc/rc.d/kerberos start y /etc/rc.d/kadmind start para levantar dichos servicios. Recuerde que no tendrá ningún dæmon kerberizado ejecutándose pero debe poder confirmar que KDC funciona por el procedimiento de obtener y listar un boleto del principal (usuario) que acaba de crear en la línea de órdenes de KDC:

Antes de nada necesitaremos una copia del fichero de configuración de Kerberos, /etc/krb5.conf. Cópielo al cliente desde KDC de forma segura (mediante scp(1), o usando un disquete).

A continuación necesitará un fichero /etc/krb5.keytab. Esta es la mayor diferencia entre un servidor que proporciona dæmons habilitados con Kerberos y una estación de trabajo: el servidor debe tener un fichero keytab. Dicho fichero contiene las llaves de equipo del servidor, las cuales le permiten a él y al KDC 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 FTP) es una pésima idea.

Lo normal es que transmita su keytab al servidor mediante el programa kadmin. Esto es práctico porque también debe crear el principal del equipo (el KDC que aparece al final de krb5.keytab) usando kadmin.

Tenga en cuenta que ya debe disponer de un ticket, y que este ticket debe poder usar el interfaz kadmin en kadmind.acl. Consulte la sección "administración remota" en la página info de Heimdal (info heimdal), donde se exponen los detalles de diseño de las listas de control de acceso. Si no quiere habilitar acceso remoto kadmin, puede conectarse de forma segura al KDC (por medio de consola local, ssh(1) o telnet(1) Kerberos) y administrar en local mediante kadmin -l.

Después de instalar el fichero /etc/krb5.conf puede usar kadmin desde el servidor Kerberos. add --random-key le permitirá añadir el principal del equipo servidor, y ext le permitirá extraer el principal del equipo servidor a su propio keybat. Por ejemplo:

Tenga en cuenta que ext (contracción de "extract") almacena la llave extraída por defecto en en /etc/krb5.keytab.

Si no tiene kadmind ejecutándose en KDC (posiblemente por razones de seguridad) y por lo tanto carece de acceso remoto a kadmin puede añadir el principal de equipo (host/miservidor.EJEMPLO.ORG) directamente en el KDC y entonces extraerlo a un fichero temporal (para evitar sobreescribir /etc/krb5.keytab en el KDC) mediante algo parecido a esto:

Puede entonces copiar de forma segura el keytab al servidor (usando scp o un diquete). Asegúrese de usar un nombre de keytab diferente para evitar sobreescribir el keytab en el KDC.

Su servidor puede comunicarse con el KDC (gracias a su fichero krb5.conf) y puede probar su propia identidad (gracias al fichero krb5.keytab). Ahora está listo para que usted habilite algunos servicios Kerberos. En este ejemplo habilitaremos el servicio telnet poniendo una línea como esta en su /etc/inetd.conf y reiniciando el servicio inetd(8) con /etc/rc.d/inetd restart:

La parte crítica es -a, de autentificación de usuario. Consulte la página de manual telnetd(8) para más información.

Configurar una computadora cliente es extremadamente fácil. Lo único que necesita es el fichero de configuración de Kerberos que encontrará en /etc/krb5.conf. Simplemente cópielo de forma segura a la computadora cliente desde el KDC.

Pruebe su computadora cliente mediante kinit, klist, y kdestroy desde el cliente para obtener, mostrar y luego borrar un ticket para el principal que creó antes. Debería poder usar aplicaciones Kerberos para conectarse a servidores habilitados con Kerberos, 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 KDC.

Al probar una aplicación como telnet, trate de usar un "sniffer" de paquetes ( como tcpdump(1)) para confirmar que su contraseña no viaja en claro por la red. Trate de usar telnet con la opción -x, que cifra el flujo de datos por entero (algo parecido a lo que hace ssh).

Las aplicaciones clientes Kerberos principales (llamadas tradicionalmente kinit, klist, kdestroy y kpasswd) están incluidas en la instalación base de FreeBSD. Tenga en cuenta que en las versiones de FreeBSD anteriores a 5.0 reciben los nombres de k5init, k5list, k5destroy, k5passwd y k5stash.

También se instalan por defecto diversas aplicaciones Kerberos que no entran dentro de la categoría de "imprescindibles". Es aquí donde la naturaleza "mínima" de la instalación base de Heimdal salta a la palestra: telnet es el único servicio Kerberos habilitado.

El port Heimdal añade algunas de las aplicaciones cliente que faltan: versiones Kerberos de ftp, rsh, rcp, rlogin y algunos otros programas menos comunes. El port del MIT también contiene una suite completa de aplicaciones cliente de Kerberos.

Suele ser habitual que los usuarios de un dominio Kerberos (o "principales") tengan su usuario (por ejemplo tillman@EJEMPLO.ORG) mapeado a una cuenta de usuario local (por ejemplo un usuario llamado llamado tillman). Las aplicaciones cliente como telnet normalmente no requieren un nombre de usuario o un principal.

Es posible que de vez en cuando quiera dar acceso a una una cuenta de usuario local a alguien que no tiene un principal Kerberos. Por ejemplo, tillman@EJEMPLO.ORG puede necesitar acceso a la cuenta de usuario local webdevelopers. Otros principales tal vez necesiten acceso a esas cuentas locales.

Los ficheros .k5login y .k5users, ubicados en el directorio home del usuario, pueden usarse de un modo similar a una combinación potente de .hosts y .rhosts. Por ejemplo, si pusiera un fichero .k5login con el siguiente contenido

en el directorio home del usuario local webdevelopers ambos principales listados tendrían acceso a esa cuenta sin requerir una contraseña compartida.

Le recomendamos encarecidamente la lectura de las páginas de manual de estas órdenes. Recuerde que la página de manual de ksu abarca .k5users.

Las diferencias más grandes entre las instalaciones MIT y Heimdal están relacionadas con kadmin, que tiene un conjunto diferente (pero equivalente) de órdenes y utiliza un protocolo diferente. Esto tiene implicaciones muy grandes si su KDC es MIT, ya que no podrá utilizar el programa kadmin de Heimdal para administrar remotamente su KDC (o viceversa).

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 Kerberos del MIT (http://web.mit.edu/Kerberos/www/). Sea cuidadoso con los parches: el port del MIT se instala por defecto en /usr/local/, y las aplicaciones "normales" del sistema pueden ser ejecutadas en lugar de las del MIT si su variable de entorno PATH lista antes los directorios del sistema.

Para generar un certificado ejecute lo siguiente:

Tenga en cuenta que la respuesta directamente después de "prompt""Common Name" muestra un nombre de dominio. Este "prompt" 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 openssl(1).

Debería tener dos ficheros en el directorio donde ha ejecutado la orden anterior. La petición de certificado, req.pem, 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 cert.pem 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.

Si no necesita la firma de una CA puede crear y firmar usted mismo su certificado. Primero, genere la llave RSA:

A continuación genere la llave CA:

Utilice esta llave para crear el certificado:

Deberín aparecer dos nuevos ficheros en su directorio: un fichero de firma de autoridad de certificados (myca.key) y el certificado en sí, new.crt. Deben ubicarse en un directorio, que se recomienda que sea /etc, que es legible solo para root. Para terminar, es recomendable asignar permisos 0700 para el fichero con chmod.

?Qué pueden hacer estos ficheros? Cifrar conexiones al MTASendmail 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 MTA local.

Debe añadir las siguientes líneas en su fichero local .mc:

/etc/certs/ es el directorio destinado a almacenamiento de los ficheros de certificado y llave en local. El último requisito es una reconstrucción del fichero .cf local. Solo tiene que teclear makeinstall en el directorio /etc/mail. A continuación ejecute un makerestart, que debería reiniciar el dæmon Sendmail.

Si todo fué bien no habrá mensajes de error en el fichero /var/log/maillog y Sendmail aparecerá en la lista de procesos.

Puede probarlo todo de una forma muy sencilla; conéctese al servidor de correo mediante telnet(1):

Si la línea "STARTTLS" aparece en la salida, todo está funcionando correctamente.

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 FreeBSD y Microsoft® Windows® 2000/XP, 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 Configuración del kernel de FreeBSD).

IPsec 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 "pila de red" IPsec de FreeBSD se basa en la implementación KAME, que incluye soporte para las dos familias de protocolos, IPv4 e IPv6.

IPsec consta de dos sub-protocolos:

ESP y AH pueden utilizarse conjunta o separadamente, dependiendo del entorno.

IPsec puede utilizarse para cifrar directamente el tráfico entre dos equipos (conocido como modo de transporte) o para construir "túneles virtuales" entre dos subredes, que pueden usarse para comunicación segura entre dos redes corporativas (conocido como modo de túnel). Este último es muy conocido como una red privada virtual (Virtual Private Network, o VPN). ipsec(4) contiene información detallada sobre el subsistema IPsec de FreeBSD.

Si quiere añdir soporte IPsec a su kernel debe incluir las siguientes opciones al fichero de configuración de su kernel:

Si quiere soporte para la depuración de errores no olvide la siguiente opción:

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.

Este es el punto de partida:

Si lo que intenta es conectar dos redes y ambas usan el mismo rango de direcciones IP privadas (por ejemplo las dos usan 192.168.1.x)debería renumerar una de las dos redes.

La topología de red se parecería a esto:

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 (192.168.1.x y 192.168.2.x respectivamente). Todas las máquinas de las redes privadas están configuradas para utilizar la máquina .1 como su puerta de enlace por defecto.

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).

Esto significa que (por ejemplo), la máquina 192.168.1.20 debe ser capaz de ejecutar

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.

Y todo debe hacerse de forma segura. Esto significa que el tráfico entre las dos redes tiene que ser cifrado.

La creación de una VPN entre estas dos redes es un proceso que requiere varios pasos. Las etapas son estas:

Normalmente, al utilizar telnet(1) o rlogin(1) los datos se envían a través de la red en limpio, es decir, sin cifrar. Cualquier "sniffer" 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. OpenSSH ofrece diversos métodos de validación y cifrado para evitar que sucedan estas cosas.

El dæmon sshd está habilitado por defecto FreeBSD 4.X y puede elegir habilitarlo o no durante la instalación en FreeBSD 5.X. Si quiere saber si está habilitado revise si la siguiente línea está en rc.conf:

Esta línea cargará sshd(8), el programa dæmon de OpenSSH, en el arranque de su sistema. Puede ejecutar el dæmon sshd tecleando sshd en la línea de órdenes.

ssh(1) funciona de manera similar a rlogin(1).

El login continuará como lo haría si fuera una sesión de rlogin o telnet. 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 yes 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 ~/.ssh/known_hosts, y en ~/.ssh/known_hosts2 las huellas SSH v2.

Por defecto las versiones recientes de los servidores OpenSSH 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 -1 o -2, 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.

scp(1) funciona de manera muy similar a rcp(1); copia un fichero desde o hacia un sistema remoto, con la diferencia de que lo hace de una forma segura.

Ya que la huella se guardó en este equipo durante el ejemplo anterior se verifica ahora al utilizar scp(1).

Los argumentos de scp(1) son similares a 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 user@host:<ruta_al_fichero_remoto>.

Los ficheros de configuración del sistema tanto para el dæmon OpenSSH como para el cliente están en /etc/ssh.

ssh_config contiene las opciones del cliente, mientras que sshd_config configura el dæmon.

Además las opciones sshd_program (/usr/sbin/sshd por defecto), y sshd_flags de rc.conf ofrecer más niveles de configuración.

ssh-keygen(1) le permite validar a un usuario sin pedirle la contraseña:

ssh-keygen(1) creará un par de llaves pública y privada para usar en la validación. La llave privada se guarda en ~/.ssh/id_dsa o en ~/.ssh/id_rsa, mientras que la llave pública se guarda en ~/.ssh/id_dsa.pub o en ~/.ssh/id_rsa.pub, respectivamente para llaves DSA y RSA. La llave pública debe guardarse en el ~/.ssh/authorized_keys de la máquina remota para que la configuración funcione. Las llaves RSA versión 1 deben guardarse en ~/.ssh/authorized_keys.

De este modo permitirá conexiones a la máquina remota mediante llaves SSH en lugar de contraseñas.

Si usa una contraseña al ejecutar ssh-keygen(1), se le pedirá al usuario una contraseña cada vez que quiera utilizar la llave privada. ssh-agent(1) puede evitar la molestia de introducir repetidamente frases largas. esto se explica má adelante, en la ssh-agent y ssh-add.

ssh-agent(1) y ssh-add(1) ofrecen métodos para que las llaves SSH se puedan cargar en memoria, permitiendo eliminar la necesidad de teclear la contraseña cada vez que haga falta.

ssh-agent(1) gestionará la validación utilizando la llave (o llaves) privada que le cargue. 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 usar ssh-agent(1) en una shell necesitará primero ser invocado como argumento por una shell. Segundo, añada la identidad ejecutando ssh-add(1) y facilitando la contraseña de la llave privada. Completados estos pasos el usuario puede hacer ssh(1) a cualquier equipo que tenga instalada la llave pública correspondiente. Por ejemplo:

Para utilizar ssh-agent(1) en X11 tendrá que incluir una llamada a ssh-agent(1) en ~/.xinitrc. De este modo ofrecerá los servicios de ssh-agent(1) a todos los programas lanzados en X11. Veamos un ejemplo de ~/.xinitrc:

Esto lanzaría ssh-agent(1), que a su vez lanzaría XFCE cada vez que inicie X11. Hecho esto y una vez reiniciado X11 para aplicar los cambios puede ejecutar ssh-add(1) para cargar todas sus llaves SSH.

OpenSSH permite crear un túnel en el que encapsular otro protocolo en una sesión cifrada.

La siguiente orden le dice a ssh(1) que cree un túnel para telnet:

Veamos las opciones que se le han suministrado a ssh:

Un túnel SSH crea un socket que escucha en localhost 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.

En el ejemplo el puerto 5023 en localhost se reenvía al puerto 23 del localhost de la máquina remota. Ya que 23 es telnet, esto crearía una sesión telnet segura a través de un túnel SSH.

Puede usar esto para encapsular cualquier otro protocolo TCP inseguro como SMTP, POP3, FTP, etc.

Limitar qué usuarios pueden entrar y desde dónde suele ser razonable. La opción AllowUsers le permite configurarlo, por ejemplo, para permitir entrar solamente al usuario root desde 192.168.1.32. Puede hacerlo con algo parecido a esto en /etc/ssh/sshd_config:

Para permitir al usuario admin la entrada desde cualquier lugar, solamente introduzca el nombre de usuario:

Puede listar múltiples usuarios en la misma línea:

Después de hacer los cambios a b /etc/ssh/sshd_config debe decirle a sshd(8) que cargue de nuevo sus ficheros de configuración ejecutando:

OpenSSH

ssh(1) scp(1) ssh-keygen(1) ssh-agent(1) ssh-add(1) ssh_config(5)

sshd(8) sftp-server(8) sshd_config(5)

Las ACLs del sistema de ficheros pueden comprobarse con getfacl(1). Por ejemplo, para ver las configuraciones de ACL del fichero test, uno podría usar lo siguiente:

Para cambiar las configuraciones de las ACL en este fichero use setfacl(1). Observe:

La bandera -k eliminará todas las ACLs definidas para un fichero o sistema ficheros. El método preferible sería utilizar -b, ya que deja los campos básicos imprescindibles para que las ACL sigan funcionando.

La opción -m se usa para modificar las entradas por defecto de las ACL. 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 Invalid argument en la salida estándar stdout.

Las advertencias de seguridad de FreeBSD tienen un aspecto similar a la que se muestra aquí. Fué enviada a la lista de correo Lista de correo para anuncios de seguridad que afectan a FreeBSD.

Antes de poder usar la contabilidad de procesos tendrá que habilitarla. Ejecute la siguiente orden:

Una vez habilitada, la contabilidad de procesos empezará a seguir el rastro de estadísticas de la CPU, órdenes, etc. Todos los logs de contabilidad están en un formato ilegible para humanos, pero accesibles para sa(8). Si se ejecuta sin opciones, sa imprimirá información sobre el número de llamadas por usuario, el tiempo total transcurrido expresado en minutos, el tiempo total de CPU y de usuario en minutos, el número medio de operaciones de E/S, etc.

Para ver información acerca de las órdenes que se están ejecutados puede usar la lastcomm(1). lastcomm imprime órdenes ejecutadas por los usuarios en ttys(5) específicas. Veamos un ejemplo:

Imprimiría todas las veces (conocidas) que el usuario trhodes ha usado ls en la terminal ttyp1.

Hay muchas más opciones que pueden serle muy útiles. Si quiere conocerlas consulte las páginas de manual lastcomm(1), acct(5) y sa(8).