diff --git a/es_ES.ISO8859-1/books/handbook/advanced-networking/chapter.sgml b/es_ES.ISO8859-1/books/handbook/advanced-networking/chapter.sgml index 8cd71b09fb..936b8a99fd 100755 --- a/es_ES.ISO8859-1/books/handbook/advanced-networking/chapter.sgml +++ b/es_ES.ISO8859-1/books/handbook/advanced-networking/chapter.sgml @@ -1,9129 +1,9129 @@ Networking Avanzado Networking Avanzado Resumen Este capítulo cubre algunos de los servicios de red que se usan con más frecuencia en sistemas &unix;. Para ser más concretos este capítulo explica cómo definir, ejecutar, probar y mantener todos los servicios de red que utiliza &os;. Se muestran además ejemplos de ficheros de configuración que podrá utilizar para sus propios quehaceres. Después de leer este capítulo habremos aprendido: Los conceptos básicos de pasarelas y encaminadores (gateways y routers). Cómo poner en funcionamiento dispositivos IEEE 802.11 y &bluetooth;. Cómo configurar &os; para que actúe como un bridge. Cómo poner en funcionamiento un sistema de ficheros en red con NFS. Cómo realizar un arranque del sistema por red en máquinas sin disco duro. Cómo ejecutar un servidor de información en red para compartir cuentas de usuario mediante NIS. Cómo especificar parámetros de configuración automática de red utilizando DHCP. Cómo ejecutar un servidor de nombres de dominio. Cómo sincronizar la hora y la fecha y ejecutar un servidor horario utilizando el protocolo NTP. Cómo ejecutar un servicio de traducción de direcciones de red. Cómo gestionar el dæmon inetd. Cómo conectar dos computadoras a través de PLIP. Cómo habilitar IPv6 en una máquina FreeBSD. Cómo configurar ATM sobre &os; 5.X. Antes de leer este capítulo debería usted: Intentar comprender los conceptos básicos de los scripts de /etc/rc. Familiarizarse con la terminología básica de redes. Coranth Gryphon Escrito por Pasarelas y Encaminadores routing gateway subnet Para que una máquina sea capaz de encontrar otra máquina remota a través de la red debe existir mecanismo que describa cómo llegar del origen al destino. Este mecanismo se demonina routing o encaminamiento. Una ruta es un par definido de direcciones: una dirección de destino y una dirección de pasarela. Éste par indica que para llegar a dicho destino debe efectuarse una comunicación previa con dicha pasarela. Exiten tres tipos distintos de destinos: máquinas individuales, subredes y por defecto. La ruta por defecto se utiliza sólamente cuando no se puede aplicar ninguna de las otras rutas existentes. El tema de las rutas por defecto se tratará más adelante con más detalle. También existen tres tipos de pasarelas distintas: máquinas individuales, interfaces (también llamados enlaces) y direcciones hardware de ethernet (direcciones MAC). Ejemplo Para ilustrar diferentes aspectos del sistema de encaminamiento veamos el siguiente ejemplo obtenido mediante el comando netstat. &prompt.user; netstat -r Routing tables Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 ejemplo.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.ejemplo.com link#1 UC 0 0 224 link#1 UC 0 0 default route Las primeras dos líneas especifican la ruta por defecto (la cual se comenta en la siguiente sección) y la ruta de máquina local. loopback device La interfaz (columna Netif) que especifica esta tabla de rutas para el destino localhost se denomina lo0, y también se conoce como el dispositivo de loopback a de bucle de retorno. Esto viene a decir que el tráfico no debe entregarse a la red puesto que dicho tráfico va destinado a la misma máquina que lo originó. Ethernet MAC address Lo siguiente que podemos observar son las direcciones que comienzan por 0:e0:. Son direcciones hardware de Ethernet, llamadas también se direcciones MAC. FreeBSD identifica automáticamente cualquier máquina (test0 en el ejemplo anterior) que se encuentre en la red local y crea una ruta del estilo que estamos comentando, para entregar el tráfico directamente a través del correspondiente interfaz Ethernet, en este caso ed0. Existe también un contador (Expire) asociado con este tipo de rutas que se usa para borrarlas cuando dicho contador expira. Las rutas para las máquinas de nuestra propia red de de área local se crean dinámicamente utilizando el protocolo ARP (Address Resolution Protocol o Protocolo de Resolución de Direcciones), que se encarga de averiguar la dirección MAC que se corresponde con la dirección IP de la máquina destino. subnet FreeBSD tambíen utiliza rutas de subred para direccionar la subred local (10.20.30.255 es la dirección de broadcast para la subred 10.20.30, y ejemplo.com es el nombre de dominio asociado con dicha subred.) La notación link#1 se refiere a la primera tarjeta Ethernet de la máquina. En este tipo de redes no se especifica ningún interfaz en el campo de Netif. Las rutas de subredes aparecen cuando se asigna una dirección IP a una interfaz, utilizando una máscara de red. También se pueden aprender dinámicamente utilizando demonios de encaminamiento, como routed. Por último estas rutas pueden crearse manualmente de forma explícita; es lo que se conoce con el nombre de rutas estáticas. La línea de host1 se refiere a nuestra máquina, que el sistema identifica por la correspondiente dirección Ethernet de la tarjeta de red. FreeBSD sabe que debe utilizar la interfaz de loopback (lo0) en vez de enviar los paquetes a a través de red. Las dos líneas que comienzan por host2 son ejemplos del uso de alias de &man.ifconfig.8; alias (consultar la sección sobre Ethernet para averiguar por qué nos podría interesar hacer esto.) El símbolo => después de la interfaz lo0 especifica que no sólo estamos utilizando la interfaz de loopback, si no que además especifica que se trata de un alias. Estas rutas sólo aparecen en las máquinas que implementan el alias, el resto de las máquinas de la subred local solamente poseerán una línea link#1 para dichas rutas. La última línea (destino de subred 224) trata sobre encaminamiento multicast, que cubriremos en otra sección. Finalmente, se pueden observar varios atributos relacionados con las rutas en la columna de Flags. A continuación se muestra una pequeña tabla con el significado de algunos de esos de los atributos o flags. U Up: La ruta está activa. H Host: El destino de la ruta es una única máquina. G Gateway: Envía cualquier cosa para éste destino a través de la pasarela especificada, la cual decidirá cómo encaminar el paquete hasta que eventualmente se alcance el destino. S Static: Esta ruta se configuró manualmente, y no se ha generado de forma automática por el sistema. C Clone: Genera una nueva ruta para la máquina a la que nos queremos conectar basándose en la ruta actual. Este tipo de ruta se utiliza normalmente en redes locales. W WasCloned: Indica una ruta que se auto-configuró basándose en una ruta de red de área local con etiqueta Clone. L Link: Esta ruta posée referencias a hardware de Ethernet. Rutas por Defecto default route Cuando el sistema local necesita realizar una conexión con una máquina remota se examina la tabla de rutas para determinar si se conoce algún camino para llegar al destino. Si la máquina remota pertenece a una subred que sabemos cómo alcanzar (rutas clonadas) entonces el sistema comprueba si se puede conectar utilizando dicho camino. Si todos los caminos conocidos fallan al sistema le queda una única opción: la ruta por defecto. Esta ruta está constituída por un tipo especial de pasarela (normalmente el único encaminador presente en la red área local) y siempre posée el flag c en el campo de flags. En una LAN, la pasarela es la máquina que posée conectividad con el resto de las redes (sea a través de un enlace PPP, DSL, cable modem, T1 u otra interfaz de red.) Si se configura la ruta por defecto en una máquina que está actuando como pasarela hacia el mundo exterior la ruta por defecto será el encaminador que se encuentre en posesión del proveedor de servicios de internet (ISP). Vamos a examinar un ejemplo que utiliza rutas por defecto. A continuación se muestra una configuración bastante común: [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] Las máquinas Local1 y Local2 se encuentran en nuestro sitio u organización. Local1 se conecta con un ISP a través de una conexión de modem PPP. El servidor PPP del ISP se conecta a través de una red de área local a otra pasarela utilizando una interfaz externa. Las rutas por defecto para cada una de las máquinas son las siguientes: Host Default Gateway Interface Local2 Local1 Ethernet Local1 T1-GW PPP Una pregunta bastante frecuente es ¿Por qué (o cómo) hacer que la máquina T1-GW sea el encaminador por defecto para Local1 en vez de que sea el servidor del ISP al cual se está conectando?. Recordemos que, como la interfaz PPP está utilizando una dirección de la red local del ISP en nuestro lado de la las rutas para cualquier otra máquina en la red local del proveedor se generarán de forma automática. De este ya sabemos el modo de alcanzar la máquina T1-GW, de tal forma que no se necesita un paso intermedio para enviar tráfico al servidor del ISP. Es frecuente utilizar la dirección X.X.X.1 como la dirección de la pasarela en la red local. Siguiendo con el ejemplo anterior, si nuestro espacio de direccionamiento local fuera la clase C 10.20.30 y nuestro ISP estuviera utilizando 10.9.9 las rutas por defecto serían: Host Default Route Local2 (10.20.30.2) Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) T1-GW (10.9.9.1) Se puede especificar fácilmente la entrada de la ruta por defecto utilizando el fichero /etc/rc.conf. En nuestro ejemplo en la máquina Local2, se añadió la siguiente línea en dicho fichero: defaultrouter="10.20.30.1" También se puede hacer directamente desde la línea de comandos mediante &man.route.8;: &prompt.root; route add default 10.20.30.1 Para obtener más información sobre la manipulación de tablas de rutas se ruega consultar la página de manual &man.route.8;. Máquinas con Doble Pertenencia (Dual Homed Hosts) dual homed hosts Existe otro tipo de configuración que debemos describir y que se produce cuando una máquina se sitúa en dos redes distintas al mismo tiempo. Técnicamente hablando cualquier máquina que actúa como pasarela (en el caso anterior utilizando un enlace de PPP) pertenece al tipo de máquinas con doble pertenencia, pero normalmente el término sólo se aplica para describir máquinas que se encuentran directamente conectadas con dos redes de área local. En un caso la máquina posée dos tarjetas de red Ethernet, cada una de ellas con una dirección de red independiente. En otro caso la máquina puede tener sólo una tarjeta de red, pero utilizar aliasing (&man.ifconfig.8;). El primer caso se utiliza cuando se necesita usar dos redes Ethernet al mismo tiempo mientras que el segundo caso se utiliza cuando se dispone de un único segmento de red físico pero se han definido dos redes lógicas distintas En cualquier caso la tabla de rutas se construye de tal forma que cada subred sepa que la máquina es la pasarela definida definida (inbound route) para la otra subred. Ésta configuración en la que la máquina actúa como encaminador entre las dos subredes se usa a menudo cuando queremos implementar filtrado de paquetes o cortafuegos seguridad en un sentido o en ambos. Si queremos que dicha máquina encamine paquetes entre las dos interfaces es necesario decirle a FreeBSD que active dicha funcionalidad. En la siguiente sección se explica cómo hacerlo. Construcción de un Encaminador router Un encaminador de red, también llamado pasarela o router, es simplemente un sistema que reenvía paquetes desde un interfaz hacia otro interfaz. Los estándares Internet y el sentido común aplicado a la ingeniería de redes impiden que FreeBSD incluya por defecto ésta característica. Se puede activar cambiando a YES el valor de la siguiente variable en el fichero &man.rc.conf.5;: gateway_enable=YES # Set to YES if this host will be a gateway Esta opción modificará la variable de &man.sysctl.8; net.inet.ip.forwarding al valor 1. Si en algún momento se necesita detener el encaminador de forma temporal basta con asignar a dicha variable el valor 0. Consulte &man.sysctl.8; para más detalles. Nuestro recién activado encaminador necesita rutas para saber a dónde debe enviar el tráfico recibido. Si nuestra red es ña se pueden definir rutas estáticas. FreeBSD incluye por defecto el dæmon de encaminamiento BSD, &man.routed.8;, que admite RIP (versión 1 y versión 2) e IRDP. El paquete net/zebra le permitirá usar otros protocolos de encaminamiento dinámico como BGP v4, OSPF v2 y muchos otros. En caso de necesitar características avanzadas de gestión puede usted recurrir a productos comerciales como &gated;. BGP RIP OSPF Incluso cuando FreeBSD se configura del modo descrito no se cumple completamente con los estándares de Internet respecto a los encaminadores de red. Bastará no obstante para poder usarse. Al Hoang Escrito por Configuración de Rutas Estáticas Configuración Manual Vamos a suponer que tenemos la siguiente topología de red: INTERNET | (10.0.0.1/24) Router por defecto para Internet | |Interfaz xl0 |10.0.0.10/24 +------+ | | RouterA | | (pasarela FreeBSD) +------+ | Interfaz xl1 | 192.168.1.1/24 | +--------------------------------+ Red Interna 1 | 192.168.1.2/24 | +------+ | | RouterB | | +------+ | 192.168.2.1/24 | Red Interna 2 En este escenario RouterA es nuestra máquina &os; que actúa como pasarela para acceder al resto de internet. Tiene una ruta por defecto que apunta a 10.0.0.1 que le permite conectarse con el mundo exterior. Vamos a suponer también que RouterB se encuentra configurado de forma adecuada que sabe cómo llegar a cualquier sitio que necesite. Esto es sencillo viendo nuestra topología de red, basta con añadir una ruta por defecto en la máquina RouterB utilizando 192.168.1.1 como encaminador. Si observamos la tabla de rutas de RouterA veremos algo como lo siguiente: &prompt.user; netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGS 0 49378 xl0 127.0.0.1 127.0.0.1 UH 0 6 lo0 10.0.0/24 link#1 UC 0 0 xl0 192.168.1/24 link#2 UC 0 0 xl1 Con la tabla de rutas actual RouterA no es capaz de alcanzar la red interna 2. Esto es así porque no posee ninguna ruta para la red 192.168.2.0/24. Una forma de mitigar esto es añadir de forma manual la ruta que falta. El siguiente comando añade la red interna 2 a la tabla de rutas de la máquina RouterA utilizando 192.168.1.2 como siguiente salto: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 Ahora RouterA puede alcanzar cualquier máquina en la red 192.168.2.0/24. Cómo Hacer la Configuración Persistente El ejemplo anterior es perfecto en tanto que resuelve el problema de encaminamiento entre redes pero existe un problema. La información de encaminamiento desaparecerá si se reinicia la máquina. La forma de evitarlo es añadir las rutas estáticas a /etc/rc.conf: # Añade la red interna 2 como una ruta estática static_routes="redinterna2" route_internalnet2="-net 192.168.2.0/24 192.168.1.2" La variable de configuración static_routes es una lista de cadenas separadas por espacios. Cada cadena identifica un nombre para la ruta que se desea definir. En el ejemplo anterior sólamente se dispone de una cadena dentro de la variable static_routes. Esta cadena es redinterna2. A continuación se añade otra variable de configuración denominada route_redinterna2 donde se escriben todos los parámetros de configuración que normalmente utilizaríamos normalmente utilizaríamos con &man.route.8;. En el ejemplo que estamos comentando se utilizaría el siguiente comando: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 De tal forma que la variable debería contener "-net 192.168.2.0/24 192.168.1.2". Como ya se ha comentado anteriormente podemos especificar más de una cadena en la variable static_routes. Esto nos permite crear varias rutas estáticas. Las siguientes línas muestran un ejemplo donde se añaden rutas estáticas para las redes 192.168.0.0/24 y 192.168.1.0/24 en un routerimaginario: static_routes="red1 red2" route_red1="-net 192.168.0.0/24 192.168.0.1" route_red2="-net 192.168.1.0/24 192.168.1.1" Propagación del Encaminamiento routing propagation Ya hemos comentado cómo se definen las rutas para el mundo exterior pero no hemos comentado nada sobre cómo haremos que el mundo exterior nos encuentre a nosotros. También hemos aprendido que las tablas de rutas se pueden construír de tal forma que un grupo de tráfico (perteneciente a un espacio de direcciones determinado) se reenvíe a una máquina específica de la red, que se encargará de reenviar los paquetes hacia adentro. Cuando se obtiene un espacio de direcciones para la organización el proveedor de servicios modifica sus tablas de rutas para que todo el tráfico para nuestra subred se encamine a través del enlace PPP hasta alcanzarnos. Pero ¿cómo conocen las organizaciones dispersas a través del país que deben enviar los paquetes dirigidos a nosotros hacia nuestro ISP? Existe un sistema (muy similar al sistema de nombres de dominio, DNS) que se encarga de controlar todos los espacios de direcciones que se encuentran actualmente repartidos y que además define sus puntos de conexión con el backbone de internet. El backbone está formado por las principales líneas de de comunicacion que se encargan de transportar el tráfico de internet a través del país y del mundo entero. Cada máquina del backbone dispone de una copia de un conjunto maestro de tablas de rutas gracias a las cuales pueden dirigir el tráfico para una red particular hacia una determinada red de transporte de dicho backbone. Una vez en la red de transporte adecuada el tráfico se encamina a través de un número indeterminado de redes de proveedores de servicio hasta que se alcanza la red de destino final. Una de las tareas que debe realizar el proveedor de servicio servicio consiste en anunciarse a las organizaciones del consiste en anunciarse a las organizaciones del backbone como el punto de conexión principal (y por tanto como el camino de entrada) para alcanzar las redes de sus clientes. Este proceso se denomina propagación de rutas. Depuración de Problemas traceroute En algunas ocasiones surgen problemas con la propagación de las rutas y algunas organizaciones son incapaces de conectarse con nuestra subred. Quizá el comando más útil para averiguar dónde se está interrumpiendo el sistema de encaminamiento sea &man.traceroute.8;. Se puede usar también cuando somos nosotros los que no podemos alcanzar alguna red externa (por ejemplo cuando &man.ping.8; falla). &man.traceroute.8; se ejecuta pasandole como parámetro el nombre de la máquina remota a la que nos queremos conectar. El comando muestra por pantalla lás máquinas que actúan de pasarela a lo largo del camino. El proceso termina bien porque se alcanza el destino o bien porque algún router intermedio no puede conectarse con el siguiente salto, o lo desconoce. Si quiere saber más sobre esto consulte la página man de &man.traceroute.8;. Encaminamiento Multicast multicast options MROUTING FreeBSD soporta tanto aplicaciones multicast como encaminamiento multicast de forma nativa. Las aplicaciones multicast no necesitan ninguna configuración especial en FreeBSD; estas aplicaciones se ejecutan tal cual. El encaminamiento multicast necesita para ser usado que se compile dicho soporte en el núcleo de FreeBSD: options MROUTING Se debe configurar además el dæmon de encaminamiento multicast, &man.mrouted.8;, para establecer túneles y ejecutar DVMRP utilizando /etc/mrouted.conf. Se pueden encontrar más detalles sobre cómo realizar una configuración de multicast en &man.mrouted.8;. Eric Anderson Escrito por Redes sin cables (<quote>wireless</quote>) wireless networking 802.11 Redes sin cables Introducción Puede resultar muy útil el ser capaz de utilizar una computadora sin la molestia de tener un cable de red colgando de la máquina en todo momento. FreeBSD puede utilizarse como un cliente de wireless e incluso como un punto de acceso. Modos de Operación Wireless Existen dos formas diferentes de configurar dispositivos wireless 802.11: BSS e IBSS. Modo BSS El modo BSS es el que se utiliza normalmente. Este modo también se denomina modo infraestructura. En esta configuración se conectan un determinado número de puntos de acceso a una red cableada. Cada red Cada red wireless posée su propio nombre. Este nombre es el SSID de la red. Los clientes wireless se conectan a estos puntos de acceso. El estándar IEEE 802.11 define el protocolo que se utiliza para realizar esta conexión. Un cliente wireless puede asociarse con una determinada red wireless especificando el SSID. Un cliente wireless también puede asociarse a cualquier red que se encuentre disponible; basta con no especificar ningún SSID. Modo IBSS El modo IBSS, también conocido como modo ad-hoc, se ha diseñado para facilitar las conexiones punto a punto. En realidad existen dos tipos distintos de modos ad-hoc. Uno es el modo IBSS, también conocido como modo ad-hoc o modo ad-hoc del IEEE. Este modo se encuentra especificado en el estándar IEEE 802.11. El segundo tipo se denomina modo ad-hoc de demostración o modo ad-hoc de Lucent (y algunas veces, también se le llama simplemente modo ad-hoc, lo cual es bastante confuso). Este es el modo de funcionamiento antíguo, anterior al estándar 802.11, del modo ad-hoc debería utilizarse sólo en instalaciones propietarias. No profundizaremos más sobre estos modos de funcionamiento. Modo Infraestructura Puntos de Acceso Los puntos de acceso son dispositivos de red wireless que funcionan de forma equivalente a los hubs o concentradores, permitiendo que varios clientes wireless se comuniquen entre sí. A menudo se utilizan varios puntos de acceso para cubrir un área determinada como una casa, una oficina u otro tipo de localización delimitada. Los puntos de acceso poseen típicamente varias conexiones de red: la tarjeta wireless y una o más tarjetas Ethernet que se utilizan para comunicarse con el resto de la red. Los puntos de acceso se pueden comprar como tales pero también se puede configurar un sistema FreeBSD para crear nuestro propio punto de acceso wireless utilizando un determinado tipo de tarjetas wireless que poseen tales capacidades de configuración. Existe una gran cantidad de fabricantes de hardware que distribuyen puntos de acceso y tarjetas de red wireless, aunque las capacidades de unos y otras varín. Construcción de un Punto de Acceso basado en FreeBSD wireless networking Punto de Acceso Requisitos Para crear nuestro propio punto de acceso con FreeBSD debemos utilizar un determinado tipo de tarjeta wireless. Por el momento, sólo las tarjetas con el chip Prism nos permiten hacer un punto de acceso. También vamos a necesitar una tarjeta para red cableada que sea soportada por el sistema (esto no es muy complicado dada la ingente cantidad de dispositivos de este tipo que funcionan en FreeBSD). Para este ejemplo vamos a suponer que queremos puentear (&man.bridge.4;) todo el tráfico entre la red cableada y la red inalámbrica. El uso como punto de acceso wireless (también denominado hostap) funciona mejor con determinadas versiones del firmware. Las tarjetas con chip Prism2 deben disponer de la versión 1.3.4 (o superior) del firmware. Los chips Prism2.5 y Prism3 deben disponer de la versión 1.4.9 o superior del firmware. Las versiones más antíguas de estos firmwares pueden no funcionar correctamente. A día de hoy la única forma de actualizar el firmware de las tarjetas es usando las herramientas que proporciona el fabricante para &windows;. Puesta en Marcha del Sistema Primero debemos asegurarnos de que el sistema reconoce la tarjeta wireless: &prompt.root; ifconfig -a wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:09:2d:2d:c9:50 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid "" stationname "nodo Wireless FreeBSD" channel 10 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 No se preocupe si no entiende algo de la configuración anterior, lo importante es asegurarse de que el sistema muestra algo parecido, lo cual nosindicará que la tarjeta wireless ha sido correctamente reconocida por FreeBSD. Si el interfaz inalámbrico no es reconocido correctamente y se está utilizando una tarjeta PC Card consulte &man.pccardc.8; y &man.pccardd.8;, en las que tiene mucha información al respecto. A continuación, para que podamos disponer de un bridge deberá cargar el módulo del kernel &man.bridge.4; por el sencillo procedimiento de ejecutar el siguiente comando: &prompt.root; kldload bridge No debería aparecer mensaje de error alguno al ejecutar dicho comando. Si apareciera alguno quizás deba compilar el kernel del sistema con &man.bridge.4; incluído. La sección Bridging de éste manual incluye información abundante para llevar a buen puerto esa tarea. Una vez que tenemos el soporte de bridging cargado debemos indicar a FreeBSD qué interfaces se desean puentear. Para ello emplearemos &man.sysctl.8;: &prompt.root; sysctl net.link.ether.bridge=1 &prompt.root; sysctl net.link.ether.bridge_cfg="wi0,xl0" &prompt.root; sysctl net.inet.ip.forwarding=1 En &os; 5.2-RELEASE y posteriores se deben emplear las siguientes opciones en lugar de las anteriormente expuestas: &prompt.root; sysctl net.link.ether.bridge.enable=1 &prompt.root; sysctl net.link.ether.bridge.config="wi0,xl0" &prompt.root; sysctl net.inet.ip.forwarding=1 Ahora es el momento de configurar la tarjeta de red inalámbrica. El siguiente comando convierte la tarjeta en un punto de acceso: &prompt.root; ifconfig wi0 ssid mi_red channel 11 media DS/11Mbps mediaopt hostap up stationname "PA FreeBSD" La línea de &man.ifconfig.8; levanta el interfaz wi0, configura el SSID con el valor de mi_red y también el nombre de la estación como FreeBSD. La opción configura la tarjeta a 11Mbps. Ésto es necesario para que cualquier valor que se necesite asignar a surta efecto. La opción sitúa el interfaz en modo punto de acceso. La opción configura la tarjeta para que use el canal de radio número 11. En &man.wicontrol.8; encontraráa rangos de canales válidos para varios dominios regulatorios. Por favor, tenga en cuenta que no todos los canales son legales en todos los países. Despues de esto deberíamos disponer de un punto de acceso completamente funcional y en ejecución. Le animamos a consultar &man.wicontrol.8;, &man.ifconfig.8; y &man.wi.4; para máss información. También le recomemdamos leer la sección sobre cifrado que econtrará más adelante. Información de Estado Una vez que el punto de acceso estáconfigurado resulta interesante poder obtener información acerca de los clientes que estén asociados. La persona encargada de la administración del punto de acceso puede ejecutar cuando estime oportuno lo siguiente: &prompt.root; wicontrol -l 1 station: 00:09:b7:7b:9d:16 asid=04c0, flags=3<ASSOC,AUTH>, caps=1<ESS>, rates=f<1M,2M,5.5M,11M>, sig=38/15 Lo que aquí se muestra indica que hay una única estación asociada y nos suministra sus parámetros. Los valores de señal que se muestran se deben tomar sólo como indicaciones aproximadas de la fuerza de dicha señal. Su traducción a dBm u otras unidades varía según la versión del firmware de la tarjeta que se use. Clientes Un cliente wireless es un sistema que se comunica con un punto de acceso o directamente con otro cliente wireless. Generalmente los clientes wireless sólo poseen un dispositivo de red: la tarjeta de red inalámbrica. Existen varias formas de configurar un cliente wireless basadas en los distintos modos inalámbricos, normalmente reducidos a BSS (o modo infraestructura, que requiere de un punto de acceso) y el modo IBSS (modo ad-hoc, o modo punto a punto). En nuestro ejemplo usaremos el más famoso de ambos, el BSS, para comunicarnos con un punto de acceso. Requisitos Sólamente existe un requisito real para configurar un sistema FreeBSD como cliente inalámbrico: usar una tarjeta de red inalámbrica soportada por el sistema. Ejecución de un cliente inalámbrico FreeBSD Para utilizar una red inalámbrica se necesitan conocer algunos conceptos básicos de redes de redes wireless. En nuestro ejemplo queremos conectarnos a la red inalámbrica mi_red y queremos hacerlo con el soporte de cifrado desactivado. En este ejemplo no se utiliza cifrado, lo cual resulta ser bastante peligroso. En la próxima sección aprenderemos cómo activar el sistema de cifrado común el los dispositivos inalámbricos, por qué resulta importante hacerlo y por qué algunas tecnologías de cifrado no son suficientes para protegernos completamente. Asegúrese de que FreeBSD reconoce su tarjeta de red inalámbrica: &prompt.root; ifconfig -a wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:09:2d:2d:c9:50 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid "" stationname "FreeBSD Wireless node" channel 10 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 A continuación debemos especificar los parámetros correctos para nuestra red: &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid mi_red Sustituya 192.168.0.20 y 255.255.255.0 con una dirección IP y máscara de red que se adecúen con el espacio de direccionamiento de la red cableada. Recordemos que nuestro punto de acceso está puenteando la red inalámbrica y la red de cable, de modo que para el resto de dispositivos de la red el cliente inalábrico se muestra como un elemento más de la red cableada. Llegados a este punto deberíamos poder hacer ping a las máquinas de la red cableada como si estuviéramos compartiendo el mismo enlace físico cableado. Si se presentan problemas con la conexión inalámbrica se puede comprobar si la tarjeta wireless se encuentra correctamente asociada (conectada) con el punto de acceso: &prompt.root; ifconfig wi0 ebería devolver algún tipo de información entre la que deberíamos observar la siguiente línea: status: associated Si no aparece la palabra associated puede ser que nos encontremos fuera de la cobertura proporcionada por el punto de acceso o puede ser que necesitemos activar el cifrado, aunque éstos no son los únicos problemas con los que nos podemos encontrar. Cifrado wireless networking encryption El cifrado, también llamado codificación, de una red inalámbrica es un proceso importante porque, a diferencia de lo que ocurre con las redes cableadas convencionales, las redes inalámbricas no se pueden restringir a un espacio físico determinado. Los datos que viajan a través de ondas de radio se difunden a través de las paredes y alcanzan a los vecinos más cercanos. Aquí es donde entra en en juego el sistema de cifrado. El cifrado se emplea para evitar que cualquiera pueda examinar los datos enviados a través del aire. Los dos métodos más comunes para realizar el cifrado de datos entre el cliente y el punto de acceso son WEP e &man.ipsec.4;. WEP WEP WEP son las siglas de Wired Equivalency Protocol. WEP es un un intento de crear redes inalámbricas al menos tan seguras omo las redes cableadas o al menos de seguridad equivalente a dichas redes. Por desgracia el sistema WEP es débil y resulta bastante sencillo de romper. Esto significa que cuando se transmite información de carácter crítico no se debe confiar únicamente en este sistema de cifrado. No obstante es mejor que no utilizar nada; puede activar WEP en el sistema que hace de punto de acceso mediante: &prompt.root; ifconfig wi0 inet up ssid mi_red wepmode on wepkey 0x1234567890 media DS/11Mbps mediaopt hostap y en un cliente inalámbrico mediante el siguiente comando: &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid mi_red wepmode on wepkey 0x1234567890 Por favor, tenga un poco de sentido común y reemplace la clave 0x1234567890 por otra clave menos obvia. IPsec &man.ipsec.4; es una herramienta más robusta y potente para cifrar datos que se mueven a través de una red. Es el mecanismo más conveniente para asegurar los datos de una red inalámbrica. Tiene más información sobre el protocolo &man.ipsec.4; y cómo utilizarlo en la sección IPsec de este manual. Herramientas No hay muchas herramientas disponibles si se quiere depurar y monitorizar redes inalámbricas pero en el siguiente apartado mostraremos cómo utilizar algunas de ellas. El paquete <application>bsd-airtools</application> El paquete bsd-airtools es un conjunto muy completo de herramientas wireless que se pueden utilizar para multitud de tareas, entre las cuales podemos citar citar el desciframiento de claves WEP, detección de puntos de de acceso, monitorización de la señal de radio, etc. El paquete bsd-airtools se puede instalar como port desde net/bsd-airtools. La información relacionada con los ports puede encontrarse en la sección de este manual. El programa dstumbler es una herramienta que permite descubrir puntos de acceso y entre otras cosas muestra de forma gráfica la relación señal / ruido del enlace. Si se experimentan problemas para acceder a un determinado punto de acceso dstumbler puede ser muy útil. Para probar la seguridad de la red inalámbrica se puede usar dweputils, concretamente los comandos dwepcrack, dwepdump y dwepkeygen. Estos comandos permiten determinar hasta qué punto la seguridad que ofrece WEP es suficiente para nuestras necesidades. Las utilidades <command>wicontrol</command>, <command>ancontrol</command> y <command>raycontrol</command> Mediante estas herramientas se puede controlar el comportamiento de la tarjeta de red inalámbrica. En los ejemplos anteriores se ha utilizado &man.wicontrol.8; debido a que la tarjeta de red del ejemplo utiliza el interfaz wi0. Si se posée una tarjeta wireless de Cisco dicha tarjeta se mostrará en el sistema mediante el interfaz an0 y por lo tanto el comando equivalente que se debe usar será &man.ancontrol.8;. <command>ifconfig</command> ifconfig Con &man.ifconfig.8; se puede utilizar unas cuantas de las opciones que se pueden usar con &man.wicontrol.8;, pero no obstante no posée todas las funcionalidades que proporciona &man.wicontrol.8;. Se recomienda leer &man.ifconfig.8; para conocer los detalles de los parámetros y opciones que admite. Tarjetas de Red Inalámbricas Soportadas Puntos de Acceso Las únicas tarjetas que soportan el modo de funcionamiento funcionamiento BSS (pueden funcionar como puntos de acceso) son los dispositivos basados en el chip Prism 2, 2.5 ó 3. Consulte &man.wi.4; para ver una lista completa de ellos. Clientes FreeBSD soporta casi todas las tarjetas inalámbricas 802.11b 802.11b que se encuentran actualmente en el mercado. La mayoría de las tarjetas basadas en los chips Prism, Spectrum24, Spectrum24, Hermes, Aironet y Raylink tambíen funcionan en modo IBSS (modos ad-hoc, punto a punto y BSS). Pav Lucistnik Escrito por
pav@oook.cz
 Bluetooth Bluetooth Introducción Bluetooth es una tecnología inalámbrica que opera en banda de 2.4 GHz (donde no se necesita licencia). Se trata de una tecnología pensada para la creación de redes de ámbito personal (de cobertura reducida, normalmente de unos 10 metros). Las redes se suelen construir en modo ad-hoc utilizando dispositivos heterogéneos como teléfonos móviles, dispositivos manuales (handhelds) y computadoras portátiles. A diferencia de otras tecnologías inalámbricas como Wi-Fi, Bluetooth ofrece perfiles de servicio más detallados; por ejemplo un perfil para actuar como un servidor de ficheros basado en FTP, para la difusión de ficheros (file pushing), para el transporte de voz, para la emulación de línea serie y muchos más. La pila de Bluetooth en &os; se implementa utilizando el entorno de Netgraph (véase &man.netgraph.4;). La mayoría de los dispositivos USB Bluetooth se pueden utilizar mediante el controlador &man.ng.ubt.4;. Los dispositivos Bluetooth basados en el chip Broadcom BCM2033 están soportados mediante los controladores &man.ubtbcmfw.4; y &man.ng.bt3c.4;. Los dispositivos Bluetooth basados en la interfaz serie o de Rayos Infrarrojos (UART) se controlan mediante &man.sio.4;, &man.ng.h4.4; y &man.hcseriald.8;. Este capítulo describe el uso de dispositivos Bluetooth USB. El soporte para Bluetooth se encuentra en las versiones de &os; 5.0 y posteriores. Instalación del Dispositivo Por defecto los controladores de los dispositivos Bluetooth se encuentran disponibles como módulos del kernel. Antes de enchufar el dispositivo Bluetooth se debe cargar el módulo correspondiente dentro del núcleo. &prompt.root; kldload ng_ubt Si el dispositivo Bluetooth se encuentra conectado cuando el sistema arranca se debe cargar el módulo modificando a tal efecto el fichero /boot/loader.conf. ng_ubt_load="YES" Al conectar el dispositivo Bluetooth aparecerá en la consola (o en syslog) la siguiente información: ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3, wMaxPacketSize=49, nframes=6, buffer size=294 Se debe copiar /usr/share/examples/netgraph/bluetooth/rc.bluetooth a algún lugar más conveniente, por ejemplo /etc/rc.bluetooth. Este script se usa para ejecutar y detener la pila Bluetooth del sistema. Se suele recomendar quitar la pila antes de desenchufar el dispositivo pero si no se hace no debería producirse ningún desastre. Cuando se arranca la pila aparece un mensaje similar a este: &prompt.root; /etc/rc.bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a Features: 0xff 0xff 0xf 00 00 00 00 00 <3-Slot> <5-Slot> <Encryption> <Slot offset> <Timing accuracy> <Switch> <Hold mode> <Sniff mode> <Park mode> <RSSI> <Channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <Paging scheme> <Power control> <Transparent SCO data> Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8 HCI Interfaz de la Controladora de la Máquina (HCI) La interfaz de la Controladora de la Máquina (Host Controller Interface) proporciona una interfaz de comandos para la controladora de banda base y para el gestor de enlace, y permite acceder al estado del hardware y a los registros de control. Esta interfaz proporciona una capa de acceso homogénea para todos los dispositivos Bluetooth de banda base. La capa HCI de la máquina intercambia comandos y datos con el firmware del HCI presente en el dispositivo Bluetooth. El driver de la capa de transporte de la controladora de la máquina (es decir, el driver del bus físico) proporciona ambas capas de HCI la posibilidad de intercambiar información entre ellas. Se crea un nodo Netgraph de tipo HCI para cada dispositivo Bluetooth. El nodo Netgraph HCI se conecta normalmente con el nodo que representa el controlador del dispositivo Bluetooth de la máquina (sentido de bajada) y con el nodo Netgraph L2CAP en el sentido de subida. Todas las operaciones HCI se realizan sobre el nodo Netgraph HCI y no sobre el el nodo que representa al dispositivo. El nombre por defecto para el nodo HCI es devicehci. Para obtener más detalles, por favor consulte la página del manual de &man.ng.hci.4;. Una de las tareas más importantes que se deben realizar es el descubrimiento automático de otros dispositivos Bluetooth que se encuentren dentro del radio de cobertura. Esta operación se denomina en inglés inquiry (consulta). Esta operación o otras operaciones HCI relacionadas se realizan mediante la utilidad &man.hccontrol.8;. El siguiente ejemplo muestra cómo descubrir dispositivos en pocos segundos. Tenga siempre presente que un dispositivo remoto sólo contesta a la consulta si se encuentra configurado en modo descubrimiento (discoverable mode). &prompt.user; hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] BD_ADDR es la dirección identificativa única del dispositivo Bluetooth, similar a las direcciones MAC de las tarjetas Ethernet. Esta dirección se necesita para transmitir otro tipo de información a otros dispositivos. Se puede asignar un nombre más significativo para los humanos en la variable BD_ADDR. El fichero /etc/bluetooth/hosts contiene información relativa a los dispositivos Bluetooth conocidos. El siguiente ejemplo muestra cómo obtener un nombre significativo para los humanos que fué asignado a un dispositivo remoto: &prompt.user; hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav's T39 Si se realiza una consulta (inquiry) sobre el dispositivo Bluetooth remoto, dicho dispositivo identificará nuestro computador como nombre.de.su.sistema (ubt0). El nombre asignado al dispositivo local se puede modificar en cualquier momento. El sistema Bluetooth proporciona una conexión punto a punto (con sólo dos unidades Bluetooth involucradas) o también una conexión punto multipunto. En el último caso, la conexión se comparte entre varios dispositivos Bluetooth. El siguiente ejemplo muestra como obtener una lista de las conexiones de banda base activas en el dispositivo local: &prompt.user; hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN Resulta útil disponer de un manejador de la conexión cuando se necesita terminar la conexión de banda base. Es importante recalcar que normalmente no es necesario realizar esta terminación de forma manual. La pila Bluetooth puede concluír automáticamente las conexiones de banda base que se encuentren inactivas. &prompt.root; hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16] Se ruega consultar la salida del comando hccontrol help para obtener un listado completo de los comandos HCI que se encuentran disponibles. La mayoría de éstos comandos no requiren privilegios de superusuario. L2CAP Protocolo de Adaptación y de Control de Enlace a nivel Lógico (L2CAP) El protocolo L2CAP (Logical Link Control and Adaptation Protocol) proporciona servicios de datos tanto orientados a conexión como no orientados a conexión a los protocolos de las capas superiores, junto con facilidades de multiplexación y de segmentacion y reensamblaje. L2CAP permite que los protocolos de capas superiores puedan transmitir y recibir paquetes de datos L2CAP de hasta 64 kilobytes de longitud. L2CAP se basa en el concepto de canales. Un canal es una conexión lógica que se sitúa sobre la conexión de banda base. Cada canal se asocia a un único protocolo. Cada paquete L2CAP que se recibe a un canal se redirige al protocolo superior correspondiente. Varios canales pueden operar sobre la misma conexión de banda base, pero un canal no puede tener asociados más de un protocolo de alto nivel. Para cada dispositivo Bluetooth se cre un único nodo Netgraph de tipo l2cap. El nodo L2CAP se conecta normalmente conectado al nodo Netgraph HCI (hacia abajo) y con nodos Bluetooth tipo sockets hacia arriba. El nombre por defecto para el nodo Netgraph L2CAP es devicel2cap. Para obtener más detalles se ruega consultar la página del manual &man.ng.l2cap.4;. Un comando muy útil es el &man.l2ping.8;, el cual se puede utilizar para hacer ping a otros dispositivos. Algunas implementaciones de Bluetooth no devuelven todos los datos que se envían, de tal forma que el valor 0 bytes que se observa a continuación es normal: &prompt.root; l2ping -a 00:80:37:29:19:a4 0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0 La herramienta &man.l2control.8; se utiliza para realizar varias operaciones sobre los nodos L2CAP. Este ejemplo muestra cómo obtener la lista de conexiones lógicas (canales) y la lista de conexiones de banda base (física) que mantiene el dispositivo local: &prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State 00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN &prompt.user; l2control -a 00:02:72:00:d4:1a read_connection_list L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN Otra herramienta de diagnóstico interesante es &man.btsockstat.1;. Realiza un trabajo similar al comando &man.netstat.1;, pero en este caso para las estructuras de datos relacionadas con el sistema Bluetooth. A continuación se muestra la información relativa a la misma conexión lógica del ejemplo anterior. &prompt.user; btsockstat Active L2CAP sockets PCB Recv-Q Send-Q Local address/PSM Foreign address CID State c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN Active RFCOMM sessions L2PCB PCB Flag MTU Out-Q DLCs State c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN RFCOMM Protocolo RFCOMM El protocolo RFCOMM proporciona emulación de puertos serie a través del protocolo L2CAP. Este protocolo se basa en el estándar de la ETSI denominado TS 07.10. RFCOMM es un protoclo de transporte sencillo, con soporte para hasta 9 puertos serie RS-232 (EIATIA-232-E). El protocolo RFCOMM permite hasta 60 conexiones simultaneas (canales RFCOMM) entre dos dispositivos Bluetooth. Para los propósitos de RFCOMM, un camino de comunicación involucra siempre a dos aplicaciones que se ejecutan en dos dispositivos distintos (los extremos de la comunicación). Entre ellos existe un segmento que los comunica. RFCOMM pretende cubrir aquellas aplicaciones que utilizan los puertos serie de las máquinas donde se ejecutan. El segmento de comunicación es un enlace Bluetooth desde un dispositivo al otro (conexión directa). RFCOMM trata únicamente con la conexión de dispositivos directamente, y también con conexiones entre el dispositivo y el modem para realizar conexiones de red. RFCOMM puede soportar otras configuraciones, tales como módulos que se comunican via Bluetooth por un lado y que proporcionan una interfaz de red cableada por el otro. En &os; el protocolo RFCOMM se implementa utilizando la capa de sockets de Bluetooth. pairing Enparejamiento de Dispositivos Por defecto, la comunicación Bluetooth no se valida, por lo que cualquier dispositivo puede en principio hablar con cualquier otro. Un dispositivo Bluetooth (por ejemplo un teléfono celular) puede solicitar autenticación para realizar un determinado servicio (por ejemplo para el servicio de marcación por modem). La autenticación de Bluetooth normalmente se realiza utilizando códigos PIN. Un código PIN es una cadena ASCII de hasta 16 caracteres de longitud. Los usuarios deben introducir el mismo código PIN en ambos dispositivos. Una vez que el usuario ha introducido el PIN adecuado ambos dispositivos generan una clave de enlace. Una vez generada, la clave se puede almacenar en el propio dispositivo o en un dispositivo de almacenamiento externo. La siguiente vez que se comuniquen ambos dispositivos se reutilizará la misma clave. El procedimiento descrito hasta este punto se denomina emparejamiento (pairing). Es importante recordar que si la clave de enlace se pierde en alguno de los dispositivos involucrados se debe volver a ejecutar el procedimiento de emparejamiento. El dæmon &man.hcsecd.8; se encarga de gestionar todas las peticiones de autenticación Bluetooth. El archivo de configuración predeterminado se denomina /etc/bluetooth/hcsecd.conf. A continuación se muestra una sección de ejemplo de un teléfono celular con el código PIN arbitrariamente fijado al valor 1234: device { bdaddr 00:80:37:29:19:a4; name "Pav's T39"; key nokey; pin "1234"; } No existe ninguna limitación en los códigos PIN a excepción de su longitud. Algunos dispositivos (por ejemplo los dispositivos de mano Bluetooth) pueden obligar a escribir un número predeterminado de caracteres para el código PIN. La opción fuerza al dæmon &man.hcsecd.8; a permanecer ejecutádose en primer plano, de tal forma que se puede observar fácilmente lo que ocurre. Si se configura el dispositivo Bluetooth remoto para aceptar el procedimiento de emparejamiento y se inicia la conexión con dicho dispositivo, el dispositivo remoto debería decir que el procedimiento de emparejamiento se ha aceptado y debería solicitar el código PIN. Si se introduce el mismo código PIN que se escribió en su momento en el fichero hcsecd.conf el procedimiento de emparejamiento y de generación de la clave de enlace debería terminar satisfactoriamente. Por otra parte el procedimiento de emparejamiento se puede iniciar en el dispositivo remoto. A continuación se muestra un ejemplo de la salida del dæmon hcsecd. hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 SDP Protocolo de Descubrimiento de Servicios (SDP) El Protocolo de Descubrimiento de Servicios (Service Discovery Protocol o SDP) permite a las aplicaciones cliente descubrir la existencia de diversos servicios proporcionados por uno o varios servidores de aplicaciones, junto con los atributos y propiedades de los servicios que se ofrecen. Estos atributos de servicio incluyen el tipo o clase de servicio ofrecido y el mecanismo o la información necesaria para utilizar dichos servicios. SDP se basa en una determinada comunicación entre un servidor SDP y un cliente SDP. El servidor mantiene una lista de registros de servicios, los cuales describen las características de los servicios ofrecidos. Cada registro contiene información sobre un determinado servicio. Un cliente puede recuperar la información de un registro de servicio almacenado en un servidor SDP lanzando una petición SDP. Si el cliente o la aplicación asociada con el cliente decide utilizar un determinado servicio, debe establecer una conexión independiente con el servicio en cuestión. SDP proporciona un mecanismo para el descubrimiento de servicios y sus atributos asociados, pero no proporciona ningún mecanismo ni protocolo para utilizar dichos servicios. Normalmente, un cliente SDP realiza una búsqueda de servicios acotada por determinadas características. No obstante hay momentos en los que resulta deseable descubrir todos los servicios ofrecidos por un servidor SDP sin que pueda existir ningún conocimiento previo sobre los registros que pueda contener. Este proceso de búsqueda de cualquier servicio ofrecido se denomina navegación o browsing. El servidor Bluetooth SDP denominado &man.sdpd.8; y el cliente de línea de comando denominado &man.sdpcontrol.8; se incluyen en la instalación estándar de &os;. El siguiente ejemplo muestra cómo realizar una consulta de navegación una consulta de navegación SDP. &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec browse Record Handle: 00000000 Service Class ID List: Service Discovery Server (0x1000) Protocol Descriptor List: L2CAP (0x0100) Protocol specific parameter #1: u/int/uuid16 1 Protocol specific parameter #2: u/int/uuid16 1 Record Handle: 0x00000001 Service Class ID List: Browse Group Descriptor (0x1001) Record Handle: 0x00000002 Service Class ID List: LAN Access Using PPP (0x1102) Protocol Descriptor List: L2CAP (0x0100) RFCOMM (0x0003) Protocol specific parameter #1: u/int8/bool 1 Bluetooth Profile Descriptor List: LAN Access Using PPP (0x1102) ver. 1.0 ... y así sucesivamente. Resulta importante resaltar una vez más que cada servicio posee una lista de atributos (por ejemplo en el canal RFCOMM). Dependiendo de los servicios que se quieran utilizar puede resultar necesario anotar algunos de los atributos. Algunas implementaciones de Bluetooth no soportan navegación de servicios y pueden devolver una lista vacía. En este caso se puede intentar buscar algún servicio determinado. El ejemplo siguiente muestra cómo buscar el servicio OBEX Object Push (OPUSH): &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH En &os; los servicios a clientes Bluetooth se suministran mediante el servidor &man.sdpd.8;. &prompt.root; sdpd La aplicación local servidora que quiere proporcionar servicio Bluetooth a los clientes remotos puede registrar su servicio con el dæmon SDP local. Un ejemplo de dicha aplicación Un ejemplo de dicha aplicación lo constituye el dæmon &man.rfcomm.pppd.8;. Una vez ejecutado el dæmon registra un servicio LAN de Bluetooth en el dæmon SDP local. Se puede obtener la lista de servicios registrados con el servidor SDP local lanzando una consulta de navegación SDP utilizando el canal de control local. &prompt.root; sdpcontrol -l browse Acceso Telefónico a Redes (DUN) y Acceso a Redes mediante perfiles PPP (LAN) El perfil de Acceso Telefónico a Redes (Dial-Up Networking o DUN) se utiliza mayoritariamente con modems y teléfonos celulares. Los escenarios cubiertos por este perfil se describen a continuación: Utilización de un teléfono celular o un modem por una computadora para simular un modem sin cables que se conecte a un servidor de acceso telefónico a redes o para otros servicios de acceso telefónico relacionados; Utilización de un teléfono celular o un modem por un computador para recibir llamadas de datos. El Acceso a Redes con perfiles PPP (LAN) se puede utilizar en las siguientes situaciones: Acceso LAN para un único dispositivo Bluetooth; Acceso LAN para múltiples dispositivos Bluetooth; Conexión de PC a PC (utilizando emulación de PPP sobre una línea serie). En &os; ambos perfiles se implementan bajo los comandos &man.ppp.8; y &man.rfcomm.pppd.8;, un encapsulador que convierte la conexión RFCOMM de Bluetooth en algo que puede ser utilizado por PPP. Antes de que se puedan utilizar los perfiles se debe definir una nueva etiqueta PPP en el fichero de configuración /etc/ppp/ppp.conf. Consulte &man.rfcomm.pppd.8; para ver algunos ejemplos. En el siguiente ejemplo se va a utilizar &man.rfcomm.pppd.8; para abrir una conexión RFCOMM con un dispositivo remoto con BD_ADDR 00:80:37:29:19:a4 sobre un canal RFCOMM basado en DUN (Dial-Up Networking). El número de canal RFCOMM se obtiene a partir del dispositivo remoto a través de SDP. Es posible especificar el canal RFCOMM a mano, en cuyo caso &man.rfcomm.pppd.8; no realizará ninguna consulta SDP. Se puede utilizar el comando &man.sdpcontrol.8; para descubrir el canal RFCOMM utilizado en el dispositivo remoto. &prompt.root; rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup Para proporcionar el servicio de Acceso a Redes a través de PPP (LAN) se debe ejecutar el servidor &man.sdpd.8;. Se debe crear una nueva entrada en /etc/ppp/ppp.conf. Le rogamos que consulte &man.rfcomm.pppd.8; y observe los ejemplos que se facilitan. Por último se debe ejecutar el servidor PPP RFCOMM sobre un número de canal RFCOMM adecuado. El servidor PPP RFCOMM registrará automáticamente el servicio LAN de Bluetooth con el servidor SDP local. El ejemplo que se muestra a continuación describe cómo ejecutar el servidor PPP RFCOMM. &prompt.root; rfcomm_pppd -s -C 7 -l rfcomm-server OBEX Perfil OBEX Object Push (OPUSH) OBEX es un protocolo muy utilizado para transferencias de ficheros sencillas entre dispositivos móviles. Su uso más importante se produce en comuncaciones por infrarrojos, donde se utiliza para transferencia de ficheros genéricos entre portátiles o dispositivos Palm y para enviar tarjetas de visita o entradas de la agenda entre teléfonos celulares y otros dispositivos con aplicaciones PIM. El cliente y el servidor de OBEX se implementan como un paquete denominado obexapp disponible como port en comms/obexapp. El cliente OBEX se utiliza para introducir y para recuperar recuperar objetos del servidor OBEX. Un objeto puede por ejemplo ser una tarjeta de visita o una cita. El cliente OBEX puede obtener un número de canal RFCOMM del dispositivo remoto utilizando SDP. Esto se hace especificando el nombre del servicio en lugar del número de canal RFCOMM. Los nombres de servicios soportados son: IrMC, FTRN y OPUSH. Es posible especificar el canal RFCOMM como un número. A continuación se muestra un ejemplo de una sesión OBEX donde el objeto que posee la información del dispositivo se recupera del teléfono celular y un nuevo objeto (la tarjeta de visita) se introduce en el directorio de dicho teléfono. &prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get get: remote file> telecom/devinfo.txt get: local file> devinfo-t39.txt Success, response: OK, Success (0x20) obex> put put: local file> new.vcf put: remote file> new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20) Para proporcionar servicio de OBEX el servidor &man.sdpd.8; debe estar en funcionamiento. Además se debe crear un directorio raíz donde todos los objetos van a ser almacenados. La ruta por defecto para el directorio raíz es /var/spool/obex. Por último se debe ejecutar el servidor OBEX en un número de canal RFCOMM válido. El servidor OBEX registra automáticamente el servicio de Object Push con el dæmon SDP local. El ejemplo que se muestra a local. El ejemplo que se muestra a continuación continuación describe cómo ejecutar el servidor OBEX. &prompt.root; obexapp -s -C 10 Perfil de Puerto Serie (SP) El perfil de puerto serie (Serial Port o SP) permite que dispositivos Bluetooth realicen emulación de RS232 (o similar). El escenario cubierto por este perfil trata con con aplicaciones comerciales que utilizan Bluetooth como un sustituto sustituto del cable, utilizando una capa de abstracción que representa un puerto serie virtual. La aplicación &man.rfcomm.sppd.1; implementa el perfil Puerto Serie. Usa una pseudo tty como abstracción de puerto serie virtual. El ejemplo de más abajo muestra cómo conectarse a un servicio de dispositivo remoto de Puerto Serie. Observe que no necesita especificarse el canal RFCOMM: &man.rfcomm.sppd.1; puede obtenerlo del dispotivo remoto via SDP. Si necesita especificarlo por alguna razón hágalo en la propia línea de comandos. &prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6... Una vez conectado el pseudo tty se puede utilizar como un puerto serie. &prompt.root; cu -l ttyp6 Depuración de Problemas Un dispositivo remoto no puede conectarse Algunos dispositivos Bluetooh antiguos no soportan el cambio de cambio de roles. Por defecto, roles. Cuando &os; acepta una nueva conexión por defecto intenta realizar un cambio de rol y convertirse en maestro. Dispositivos que no son capaces de realizar este cambio no pueden conectarse. Es interesante resaltar que el cambio de roles se realiza cuando se está estableciendo una nueva conexión de tal forma que no es posible preguntar al dispositivo si soporta intercambio de roles. Existe una opción HCI para desactivar el intercambio de roles en la parte local. &prompt.root; hccontrol -n ubt0hci write_node_role_switch 0 Algo va mal ¿puedo ver exactamente qué está ocurriendo? Sí, se puede. Utilice el paquete hcidump-1.5, que se puede descargar de aquí. La herramienta hcidump es similar a la herramienta &man.tcpdump.1;. Se puede utilizar para mostrar el contenido de los paquetes Bluetooth sobre el terminal y para volcar los paquetes Bluetooth a un fichero. Steve Peterson Escrito por Puenteado Introducción IP subnet bridge Algunas veces resulta útil dividir una red física (como por ejemplo un segmento Ethernet) en dos segmentos de red separados, sin tener que crear subredes IP y sin utilizar una pasarela para comunicar ambos segmentos. El dispositivo que realiza esta función se denomina bridge. Un sistema FreeBSD con dos interfaces de red puede actuar como un bridge o puente entre ambas. El bridge funciona de tal forma que aprende las direcciones de la capa MAC (direcciones Ethernet) de los nodos que se encuentran conectados a cada interfaz de red de tal forma que sólo se reenvía tráfico entre los segmentos de red cuando las direcciones fuente y destino se encuentran separadas en segmentos distintos. En varios aspectos se puede comparar un bridge con un switch de pocos puertos. Situaciones donde el Puenteado resulta adecuado Existen al menos dos situaciones típicas donde se puede utilizar la funcionalidad proporcionada por los bridges. Tráfico de gran volumen en un segmentos de red La primera situación surge cuando nos encontramos con un segmento de red congestionado pero por las razones que sean no queremos subdividir la red e interconectar las nuevas subredes mediante un encaminador. Vamos a considerar un ejemplo de un periódico donde los departamentos editoriales y de producción utilizan la misma subred. Los usuarios de la editorial utilizan el servidor A como servidor de ficheros y los de producción utilizan el servidor B. Se Se utiliza una red Ethernet para conectar ambos departamentos y se ha detectado que la alta utilización del enlace está ralentizando el funcionamiento de la red. Si los usuarios de la editorial pudieran agregarse en un segmento de red mientras que los usuarios de producción se localizaran en otro se podrían conectar ambos segmentos mediante un bridge. Sólo se utilizará el bridge para encaminar tráfico de red destinado a interfaces que se encuentren en el otro lado del bridge, reduciendo de esta forma la congestión en cada nuevo segmento. Cortafuegos de Filtrado/Conformación de Tráfico firewall network address translation La segunda situación típica se produce cuando se necesita un cortafuegos pero no la Traducción de Direcciones de Red (NAT). A continuación se muestra un ejemplo. Una pequeña compañía se comunica con su ISP utilizando DSL o ISDN. Dicha compañía posee 13 13 direcciones IP globalmente accesibles delegadas por su ISP y tiene 10 ordenadores en funcionamiento. En esta situación un un cortafuegos basado en un router resulta difícil debido a la distribución del espacio de direccionamiento disponible (subnetting). router DSL ISDN Un cortafuegos implementado sobre un bridge se puede utilizar en el camino de bajado desde el ISP hasta las oficinas de la compañía sin necesidad de tener en cuenta ningún aspecto relacionado con la distribución de las direcciones IP. Configuración de un <quote>Bridge</quote> Selección de la interfaz de red Un bridge necesita al menos dos tarjetas de red situadas en dos segmentos de red para su funcionamiento. Por desgracia no todas las interfaces de red pueden usarse para el puenteo. Consulte &man.bridge.4;, ahín encontrará más información sobre qué tarjetas puede usar. Por favor, instale y pruebe las dos tarjetas de red antes de continuar. Cambios en la Configuración del Núcleo kernel options options BRIDGE Para activar el soporte de bridging en el núcleo añada options BRIDGE al fichero de configuración del núcleo y recompile el kernel. Soporte de Cortafuegos firewall Si se desea utilizar el bridge como un cortafuegos, se debe añadir además la opción - IPFIREWALL. Lea para obtener información general sobre - cómo configurar el bridge para que actúe - además como cortafuegos. + IPFIREWALL. Lea el capílo de + firewalls para obtener + información general sobre cómo configurar el + bridge para que actúe además como cortafuegos. Si además queremos que los paquetes que no sean IP (por ejemplo paquetes ARP) puedan atravesar el bridge deberemos añadir la opción IPFIREWALL_DEFAULT_TO_ACCEPT. Tenga en cuenta opción modifica el comportamiento del cortafuegos de tal forma que por defecto aceptará cualquier paquete. Hay que tener cuidado para asegurarse de que el comportamiento esperado del cortafuegos, que reside en el conjunto de reglas que se hayan definido, no se vea afectado por este cambio. Soporte de Conformado de Tráfico Si se quiere utilizar el bridge como un conformador de tráfico, es decir, como un elemento capaz de adaptar los distintos flujos según determinados patrones, se debe añadir la opción DUMMYNET a la configuración del núcleo. Se ruega consultar &man.dummynet.4; para obtener más información al respecto. Cómo Activar el <quote>Bridge</quote> Añadir la línea: net.link.ether.bridge=1 en /etc/sysctl.conf para habilitar el soporte de bridging en tiempo de ejecución y la línea: net.link.ether.bridge_cfg=if1,if2 Para activar el bridging en las interfaces especificadas (sustituya if1 y if2 con los nombres de sus interfaces de red). Si deseamos filtrar los paquetes puenteados utilizando &man.ipfw.8;, debemos añadir también: net.link.ether.bridge_ipfw=1 En &os; 5.2-RELEASE y posteriores, se debe utilizar las siguientes líneas en lugar de las anteriores: net.link.ether.bridge.enable=1 net.link.ether.bridge.config=if1,if2 net.link.ether.bridge.ipfw=1 Información Adicional Si queremos ser capaces de conectarnos al bridge mediante &man.telnet.1; se puede asignar una dirección IP a una de las tarjetas de red del bridge. Por amplio consenso se considera una mala idea asignar más de una dirección IP al bridge. Si poseemos varios bridges en nuestra red sólamente puede existir un único camino entre cualesquiera dos máquinas de nuestra red. Técnicamente hablando esto significa que no existe soporte para gestión de enlace mediante mecanismos basados en árboles de recubrimiento mínimos (spanning tree). Un bridge puede añadir latencia a los tiempos de respuesta del comando &man.ping.8;, especialmente cuando el tráfico tiene que viajar de un segmento de red al otro. Tom Rhodes Reorganizado y ampliado por Bill Swingle Escrito por NFS NFS FreeBSD soporta diversos sistemas de ficheros, uno de los cuales es el Sistema de Ficheros en Red, tambíen conocido por su acrónimo en inglés NFS. NFS permite compartir directorios y ficheros a través de la red. Los usuarios del sistema NFS pueden acceder a ficheros que se encuentran físicamente en máquinas remotas de una forma transparente, como si se tratara de ficheros locales. He aquí algunos los beneficios más destacados que NFS proporciona: Las estaciones de trabajo locales utilizan menos espacio de disco debido a que los datos se encuentran centralizados en un único lugar pero pueden ser accedidos y modificados por varios usuarios, de tal forma que no es necesario replicar la información. Los usuarios no necesitan disponer de un directorio home en cada una de las máquinas de la organización. Los directorios home pueden crearse en el servidor de NFS para posteriormente poder acceder a ellos desde cualquier máquina a través de la infraestrutura de red. También se pueden compartir a través de la red dispositivos de almacenamiento como disqueteras, CDROM y unidades ZIP. Esto puede reducir la inversión en dichos dispositivos y mejorar el aprovechamiento del hardware existente en la organización. Cómo Funciona <acronym>NFS</acronym> El sistema NFS está dividido al menos en dos partes principales: un servidor y uno o más clientes. Los clientes acceden de forma remota a los datos que se encuentran almacenados en el servidor. Para que el sistema funcione correctamente se deben configurar y ejecutar unos cuantos procesos. En &os; 5.X se ha reemplazado portmap por rpcbind. de esta forma para los ejemplos que vamos a comentar a continuación se recuerda que en &os; 5.X se debe reemplazar cualquier instancia de portmap por rpcbind. El servidor de NFS debe ejecutar los siguientes dæmones: NFS server portmap mountd nfsd Dæmon Descripción nfsd El dæmonNFS, que atiende peticiones de clientes NFS. mountd El dæmon de montaje de NFS, que transporta las peticiones que &man.nfsd.8; realiza. portmap El dæmon portmapper permite que los clientes NFS puedan descubrir qué puerto está utilizando el servidor de NFS. El cliente también puede ejecutar un dæmon conocido , como nfsiod. El dæmon nfsiod atiende las peticiones provinientes del servidor NFS. Este dæmon es opcional y sirve para mejorar el rendimiento pero no es necesario para el funcionamiento correcto del sistema. Se recomienda consultar &man.nfsiod.8; para obtener más información. Configuración de <acronym>NFS</acronym> NFS configuration La configuración de NFS es un proceso relativamente sencillo. Para que los procesos anteriormente descritos se ejecuten en tiempo de arranque del sistema, basta con realizar paqueñas modificaciones en /etc/rc.conf. En /etc/rc.conf del servidor de NFS se deben configurar las siguientes opciones: portmap_enable="YES" nfs_server_enable="YES" mountd_flags="-r" mountd se ejecuta automáticamente cuando se activa el servidor NFS. En el cliente debemos asegurarnos de que se encuentra activada la activada la siguiente opción dentro de /etc/rc.conf: nfs_client_enable="YES" El archivo /etc/exports especifica los directorios o sistemas de ficheros que NFS exporta al exterior. Cada línea dentro de /etc/exports/ especifia un sistema de ficheros y qué máquinas tienen derechos de acceso sobre dicho sistema. Además de los derechos de acceso se pueden definir otras opciones de acceso, tales como solo lectura o lectura y escritura. Existen multitud de opciones que pueden definirse sobre un directorio exportable pero en este manual sólo se van a comentar unas pocas. Consulte &man.exports.5; para obtener una descripción más detallada. Aquí se muestran algunos ejemplos de entradas para /etc/exports: NFS export examples El siguiente ejemplo proporciona una idea de cómo exportar sistemas de ficheros, aunque los parámetros pueden diferir dependiendo de su entorno y su configuración de red. En dicho ejemplo, se exporta el directorio /cdromm a tres máquinas que se encuentran en el mismo dominio que el servidor (de ahí que no se especifique ningún nombre de dominio para cada máquina) o que pueden estar dadas de alta en /etc/hosts. En cualquier caso la opción configura el sistema de ficheros de red como sólo lectura (read-only). Con esta opción los sistemas remotos no serán capaces de realizar cambios sobre el sistema de ficheros exportados. /cdrom -ro host1 host2 host3 La siguiente línea exporta el directorio /home a tres máquinas utilizando direcciones IP. Esto resulta útil cuando disponemos de una red privada pero no disponemos de ningún servidor de DNS configurado. También se podría configurar /etc/hosts para que resolviera nombres de máquinas internos; consulte &man.hosts.5; para obtener más información al respecto. La opción permite que los subdirectorios del directorio /home tambíen se puedan utilizar como puntos de montaje. En otras palabras, esto permite que los clientes puedan trabajar sobre los subdirectorios en los que estén realmente interesados. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 La siguiente línea exporta el directorio /a de tal forma que puedan acceder a dicho directorio dos máquinas situadas en distintos dominios. La opción permite que el usuario root de la máquina cliente modifique los datos del sistema de ficheros en red como si fuera el usuario root del servidor. Si no se especifica la opción el usuario root del cliente puede no poseer los permisos necesarios para realizar modificaciones en el sistema de ficheros. /a -maproot=root host.example.com box.example.org Para que un cliente pueda acceder al sistema de ficheros exportado debe poseer permisos para ello. Debemos asegurarnos de que el cliente se encuentra listado en /etc/exports. Dentro de /etc/exports cada línea representa información de exportación de un sistema de ficheros para un determinado conjunto de máquinas. Una máquina sólo puede aparecer una vez dentro de un sistema de ficheros exportable y el archivo sólo puede tener una única entrada por defecto. Por ejemplo, si suponemos que /usr es un único sistema de ficheros la siguiente configuración de /etc/exports sería incorrecta: /usr/src client /usr/ports client Existe un sistema de ficheros, concretamente /usr, que posee dos líneas con reglas de exportación para la misma máquina, client. El formato correcto para esta situación sería el siguiente: /usr/src /usr/ports client Las propiedades de un sistemas de ficheros que se exporta al exterior deben aparecer agrupadas bajo la misma línea. Líneas que no poseen ningún cliente se tratan como si tuvieran una única máquina. Esto limita la forma en que pueden configurarse la exportaciones de sistemas de ficheros pero para la mayoría de la gente no suele ser un problema. El ejemplo que se muestra a continuación es una muestra de una lista de exportación correcta, donde /usr y /exports son sistemas de ficheros locales: # Exportar src y ports a cliente01 y cliente02, pero # solo el cliente01 tiene acceso root /usr/src /usr/ports -maproot=root cliente01 /usr/src /usr/ports cliente02 # Las maquinas cliente tienen acceso root y pueden montar todo lo que aparezca # en /exports. Cualquier sistema puede montar /exports/obj en modo # solo lectura /exports -alldirs -maproot=root cliente01 cliente02 /exports/obj -ro Se debe reiniciar el dæmon mountd siempre que se modifique el contenido del archivo /etc/exports para que los cambios surtan efecto. Esto se realiza enviando la señal HUP al proceso mountd: &prompt.root; kill -HUP `cat /var/run/mountd.pid` También se puede reiniciar FreeBSD para que se cargue la nueva configuración pero este mecanismo no resulta necesario si se ejecutan los siguientes comandos como root, los cuales ponen el servidor de NFS de nuevo en funcionamiento. En el servidor de NFS: &prompt.root; portmap &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r En el cliente de NFS: &prompt.root; nfsiod -n 4 En este punto todo debería estar preparado para poder anclar el sistema de ficheros remoto en la máquina cliente. En los siguientes ejemplos el nombre del servidor es server y el punto de montaje temporal utilizado por el cliente es client. Si se desea montar el sistema de ficheros de forma temporal o simplemente comprobar que la configuración funciona sin problemas se puede ejecutar un comando como el que se muestra a continuación con permisos de root en la máquina cliente: NFS mounting &prompt.root; mount server:/home /mnt Este comando ancla el directorio /home del servidor en el directorio /mnt del cliente. Si todo funciona correctamente debería poder entrar en el directorio /mnt del cliente y ver todos los ficheros que se encuentran en el directorio /home del servidor. Si queremos anclar automáticamente un sistema de ficheros remoto cuando la máquina está arrancando se puede añadir una línea como la siguiente dentro de /etc/fstab: servidor:/home /mnt nfs rw 0 0 &man.fstab.5; comenta todas las opciones disponibles. Usos Prácticos El protocolo NFS tiene múltiples usos prácticos. Los más típicos se enumeran a continuación: NFS uses Compartición de la unidad de CDROM entre varias máquinas. Esto resulta ser más barato y una forma más conveniente para instalar software en varias máquinas. En grandes redes puede ser más adecuado configurar un servidor central de NFS en el cual se almacenen todos los homes de los distintos usuarios. Estos directorios se pueden exportar a través de la red de tal forma que los usuarios pueden trabajar con el mismo directorio independientemente de la máquina que utilicen. Varias máquinas pueden poseer el directorio /usr/ports/distfiles compartido. De este modo cuando necesitemos instalar un port en varias máquinas, se puede acceder rápidamente a las fuentes sin necesidad de bajarlas una vez para cada máquina. Wylie Stilwell Escrito por Chern Lee Reescrito por Anclajes Automáticos usando <application>amd</application> amd automatic mounter daemon El dæmon &man.amd.8; (the automatic mounter daemon, o dæmon de montaje automático) automáticamente ancla un sistema de ficheros remoto cuando se tiene que acceder a un fichero perteneciente a dicho sistema. Los sistemas de ficheros que permanecen inactivos durante un determinado periodo de tiempo son automáticamente desmontados por el mismo dæmon. Este dæmon proporciona una alternativa sencilla a la utilización de los montajes permanentes que normalmente se especifican a través del fichero /etc/fstab. amd trabaja actuando como un servidor servidor de NFS para los directorios /host y /net. Cuando se accede a algún fichero ubicado bajo estos directorios amd busca el punto de montaje remoto y automáticamente lo monta. El directorio /net se utiliza para anclar sistemas de ficheros remotos especificados mediante direcciones IP, mientras que el directorio /host almacena aquellos sistemas de ficheros remotos que han sido especificados mediante un nombre de máquina. amd detecta cualquier intento de acceder a un fichero dentro del directorio /host/foobar/usr y se encarga de montar el sistema de ficheros remoto (/usr) en la máquina, en caso de que no estuviera ya anclado. Anclaje de una Exportación utilizando <application>amd</application> El comando showmount muestra los puntos de montaje que posee una máquina remota. Por ejemplo para conocer los montajes de un máquina llamada foobar, se puede utilizar: &prompt.user; showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/foobar/usr Como se observa en el ejemplo, el comando showmount muestra el directorio /usr como una exportación. Cuando se cambia el directorio actual al directorio /host/foobar/usr el dæmon amd intenta resolver el nombre foobar y automáticamente ancla el sistema de ficheros remoto. El dæmon amd se puede ejecutar a partir de los scripts de inicio, utilizando la siguiente línea del archivo de configuración /etc/rc.conf: amd_enable="YES" Además, amd soporta opciones adicionales que pueden definirse mediante la variable amd_flags. Por defecto, la variable amd_flags posee las siguientes opciones: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" El archivo /etc/amd.map define las opciones por defecto con las cuales se anclan los sistemas de ficheros remotos. El archivo /etc/amd.conf define algunas características avanzadas para el dæmon amd. Se ruega consultar las páginas del manual de &man.amd.8; y de &man.amd.conf.5; para obtener más información. John Lind Escrito por Problemas de Integración con Otras Plataformas Determinados adaptadores Ethernet para sistemas basados en el bus ISA poseen restricciones que pueden producir serios problemas de red, en particular con el protocolo NFS. Estos problemas no son específicos de FreeBSD, pero los sistemas &os; se ven afectados por ellos. El problema surge casi siempre cuando el sistema (&os;) está empotrado dentro de una red compuesta por estaciones de trabajo de alto rendimiento, como por ejemplo estaciones de Silicon Graphics y de Sun Microsystems. El montaje del sistema de ficheros remoto suele funcionar perfectamente y algunas operaciones sobre el el sistema de ficheros pueden tener é,xito pero de repente el el servidor que no responde a las peticiones del cliente, aunque peticiones y respuestas de otros clientes funcionan con normalidad y se continúan procesando. Esto sucede en los sistemas clientes, tanto en sistemas FreeBSD como en otras estaciones de trabajo. En muchos sistemas, lo único que se puede hacer es resetear la máquina de forma abrupta, ya que el bloqueo producido por el protocolo NFS no se puede solucionar. Aunque la solución correcta consiste en obtener un adaptador Ethernet con mayor rendimiento y capacidad, todavía se puede aplicar un parche sencillo que puede llegar a permitir un funcionamiento sin problemas. Si el sistema FreeBSD actúa como servidor de NFS se puede incluír la opción cuando el ejecute una petición de montaje sobre dicho servidor. Si &os; dicho servidor. Si &os; actúa como cliente de NFS, se puede ejecutar &man.mount.8; con el parámetro . Estas opciones se pueden especificar en el /etc/fstab del cliente para que entren en funcionamiento cuando se realicen montajes automáticos y también se puede utilizar el parámetro de &man.mount.8; cuando se realicen montajes manuales. Resulta apropiado resaltar que existe un problema totalmente distinto que algunas veces se confunde con el que acabamos de describir, que aparece cuando el servidor y los clientes se encuentran en redes diferentes. Si nos encontramos en esta situación debemos asegurarnos de que nuestros routers están encaminando correctamente los paquetes UDP que genera el protocolo NFS pues en caso contrario el sistema no funcionará, independientemente de los ajustes que se realicen en el cliente o en el servidor. En los siguientes ejemplos fastws es el nombre de una estación de trabajo de altas prestaciones y freebox es el nombre de un sistema &os; con un adaptador Ethernet de bajas prestaciones. Se pretende además exportar el directorio /sfcompartido (ver &man.exports.5;) y el directorio /projecto. Tenga en cuenta que en cualquier caso puede resultar útil definir opciones adicionales a las que que se muestran en el siguiente ejemplo, como pueden ser , o . Esto dependerá de la aplicación que utilice el sistema de ficheros remoto. Ejemplos de configuración para el sistema &os; (freebox) que actúa como cliente. Configuración del archivo /etc/fstab de freebox: fastws:/sfcompartido /projecto nfs rw,-r=1024 0 0 Comando de ejecución manual para freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sfcompartido /projecto Ejemplos de configuración para el sistema &os; que actúa como servidor. Configuración de /etc/fstab de fastws: freebox:/sfcompartido /projecto nfs rw,-w=1024 0 0 Comando de ejecución manual para fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sfcompartido /projecto Casi cualquier adaptador Ethernet de 16 bits permite operar sin operar sin las restricciones anteriores sobre el tamaño de lectura o escritura especificado por defecto. Por si alguien estuviera interesado a continuación se muestra el error que aparece en estos casos, lo cual explica por qué decimos que el error resulta irrecuperable. NFS trabaja típicamente con un tamaño de bloque de 8 K (aunque se pueden producir fragmentos de menor tamaño). Debido a que el máximo tamaño de los paquetes Ethernet se encuentra alrededor de los 1500 bytes el bloque de NFS se trocea en varios paquetes Ethernet aunque desde el punto de vista del protocolo NFS se trata como si fuese un único paquete. Los trozos deben reensamblarse en el destino y se debe enviar una confirmación para el bloque recibido. Las estaciones de trabajo de altas prestaciones pueden soltar paquetes NFS de forma contínua uno después de otro, lo más juntos posible. Por otro lado en las tarjetas de red más pequeñas y de menor capacidad puede ocurrir que un paquete recien llegado a la tarjeta sobreescriba información perteneciente a un paquete anterior antes de que llegue a ser transmitido completamente, de tal forma que al recibirse el bloque NFS no puede ser ni reconstruido ni ni reconocido. Como resultado de este proceso la máquina tratará de enviar el mismo paquete transcurridos unos instantes de espera, pero se tratarán de enviar de nuevo los 8 K que constituyen un bloque NFS, y de esta forma se repetirá el el proceso, así hasta el infinito. Si se mantiene el tamaño del bloque por debajo del tamaño de paquete máximo de Ethernet, podemos asegurar que cualquier paquete Ethernet transporta un bloque NFS, el cual puede asentirse individualmente, evitando así la explosión de paquetes y el eventual bloqueo del sistema. Desbordamientos circulares del buffer ( overruns) pueden producirse si nos encontramos con una estación de trabajo de altas prestaciones que envía contínuamente mucho tráfico a un sistema convencional, pero con tarjetas Ethernet de buena calidad, estos desbordamientos resultan altamente improbables para el caso de los tamaños de bloque por defecto generados por el sistema NFS. Cuando se produce un desbordamiento, las unidades afectadas se retransmiten, y existe una gran probabilidad de que se reciban, se reensamblen y se confirmen. Jean-François Dockès Actualizado por Alex Dupre Reorganizado y ampliado por Ejecución sin Disco Duro diskless workstation diskless operation Una máquina &os; se puede arrancar a través de la red y operar sin que necesite poseer ningún disco, utilizando sistemas de ficheros de un servidor de NFS. No se necesita realizar ninguna modificación al sistema, salvo configurar determinados ficheros. Este tipo de sistemas se pueden configurar fácilmente puesto que &os; dispone de todos los elementos necesarios: Existen al menos dos formas de cargar el núcleo del sistema operativo a través de la red: PXE: El sistema de &intel; conocido como Preboot Execution Environment. Se trata de una especie de arranque inteligente a partir de una memoria de sólo lectura (ROM) que se encuentra en algunas placas bases y tarjetas de red. Se puede obtener más información en &man.pxeboot.8;. El port etherboot (net/etherboot) genera código de sólo lectura (código ROM) que se puede utilizar para arrancar máquinas a través de la red. Dicho código se puede instalar en una memoria de arranque tipo PROM en algunas tarjetas de red o se puede cargar en una disquetera (o disco duro), y también en un sistema de ficheros &ms-dos; que esté en ejecución. Varias tarjetas de red soportan este mecanismo. Existe un script de ejemplo (/usr/share/examples/diskless/clone_root) que facilita la creación y el mantenimiento del sistema de ficheros raíz de la estación de trabajo en el servidor. La configuración de este script se debe retocar ligeramente pero sirve como punto de partida para comenzar rápidamente. Existen ficheros estándar de arranque bajo /etc que dan soporte al arranque de máquinas sin disco. El swapping, en caso de ser necesario, se puede realizar usando NFS y tambíen usando un disco duro local. Existen varias formas de ejecutar una estación de trabajo sin discos. En el proceso se involucran distintos elementos y la mayoría se pueden adaptar a las necesidades del usuario. A continuación se describen variaciones sobre la configuración de un sistema sin discos, haciendo incapié en la simplicidad y compatibilidad con los scripts de arranque de &os;. El sistema que vamos a describir tiene las siguientes características. Las estaciones de trabajo sin disco utilizan un sistema de ficheros raíz de sólo lectura y un sistema de ficheros compartido, también de sólo lectura, bajo /usr. El sistema de ficheros raíz es una copia del sistema raíz estandar de &os; (normalmente del sistema raíz del servidor), donde se sobreescriben algunos archivos de configuración necesarios para la ejecución sin discos y para la configuración local específica de la máquina objetivo. Las partes del sistema de ficheros raíz que tiene que tener permisos de lectura y escritura se superponen con los sistemas de ficheros &man.mfs.8; (&os; 4.X) o &man.md.4;. Cualquier cambio que se produzca en dichas partes se perderá cuando se reinicie el sistema. El núcleo se transmite y se carga utilizando etherboot o bien PXE, dependiendo del hardware y los mecanismos que se soporten. Como se ha comentado con anterioridad estos sistemas son inseguros. Se debe confinar dentro de una red protegida y el resto de las máquinas por defecto no deben confiar en estos métodos. Toda la información que se presenta en esta sección se ha probado utilizando &os; 4.9-RELEASE y 5.2.1-RELEASE. El texto se encuentra estructurado principalmente para utilización en sistemas 4.X. Se insertan notas para indicar cambios producidos en las versiones 5.X. Conocimientos Previos Configurar estaciones de trabajo sin discos es una operación relativamente sencilla pero en la que pueden cometerse errores. Estos errores resultan algunas veces difíciles de diagnosticar debido a razones que vamos a exponer a continuación. Por ejemplo: Diferentes opciones de tiempo de compilación pueden determinar comportamientos distintos en tiempo de ejecución. Los mensajes de error a menudo resultan crípticos o incluso no existen. Se se quieren resolver los posibles problemas que puedan surgir resulta muy útil conocer el funcionamiento conceptual del mecanismo. Para que el arranque se produzca exitosamente se deben realizar varias operaciones: La máquina necesita obtener algunos parámetros iniciales, tales como su dirección IP, el fichero ejecutable, el nombre del servidor y la ruta raíz. Esto se realiza utilizando los protocolos DHCP o BOOTP. DHCP es una extensión compatible del protocolo BOOTP y utiliza los mismos números de puertos y los mismos formatos de paquete básicos. Es posible configurar un sistema de tal forma que utilice sólamente BOOTP. En el sistema base de &os; se incluye el programa servidor &man.bootpd.8;. No obstante DHCP posee varias ventajas sobre BOOTP (archivos de configuración más limpios, posibilidad de ejecutar PXE, junto con otras características que no se relacionan directamente con el tema que estamos tratando tratando) por lo que principalmente se va a describir la configuración de DHCP, proporcionando ejemplos equivalentes en &man.bootpd.8; siempre que sea posible. La configuración de ejemplo se basa en el paquete software de ISC DHCP (en el servidor de prueba se instaló la versión 3.0.1.r12). La máquina sin disco necesita transferir uno o varios programas a la memoria local. Para ello se usa TFTP o bien NFS. La elección entre ambos se produce mediante la configuración de la compilación que se produce en varios lugares. Una fuente de error típica aparece cuando se especifican ficheros con el protocolo incorrecto: TFTP normalmente transfiere todos los ficheros desde un único directorio del servidor, de modo que espera nombres de ficheros relativos a dicho directorio. Por otro lado NFS necesita recibir rutas de fichero absolutas. El kernel y los programas de arranque intermedios deben ser inicializados y ejecutados. Existen diferencias importantes en este área: PXE carga &man.pxeboot.8;, una versión modificada de la tercera fase del cargador de arranque de &os;. &man.loader.8; obtiene la mayoría de los parámetros necesarios para arrancar el sistema y los deposita en variables de entorno del kernel antes de tranferir el control. En este caso es posible utilizar un un núcleo GENERIC . etherboot carga directamente el directamente el núcleo con menos trabajo previo que el método anterior. Para ello se debe compilar un núcleo con ciertas opciones. PXE y etherboot funcionan muy bien en los sistemas 4.X. Dado que los núcleos de los sistemas 5.X permiten que el &man.loader.8; realice más tareas, se prefiere usar PXE. Si su BIOS y su tarjeta de red soportan PXE lo normal es utilizarlo. No obstante se puede arrancar un sistema 5.X utilizando etherboot. Para acabar la tarea la máquina necesita acceder al sistema de ficheros. En todos los casos se utiliza NFS. No olvide consultar &man.diskless.8;. Instrucciones de Configuración Configuración Utilizando <application>ISC DHCP</application> DHCP diskless operation El servidor ISC DHCP puede responder tanto a peticiones de BOOTP como a peticiones de DHCP. ISC DHCP no forma parte de la versión 4.9 de &os; por lo que se debe instalar el port net/isc-dhcp3-server o el paquete correspondiente. Por favor, consulte para obtener más información sobre los ports y los paquetes. Una vez que ISC DHCP se encuentra instalado necesita un fichero de configuración para poder ejecutarse /usr/local/etc/dhcpd.conf). A continuación se muestra un ejemplo comentado, donde la máquina margaux utiliza etherboot y la máquina corbieres utiliza PXE: default-lease-time 600; max-lease-time 7200; authoritative; option domain-name "example.com"; option domain-name-servers 192.168.4.1; option routers 192.168.4.1; subnet 192.168.4.0 netmask 255.255.255.0 { use-host-decl-names on; option subnet-mask 255.255.255.0; option broadcast-address 192.168.4.255; host margaux { hardware ethernet 01:23:45:67:89:ab; fixed-address margaux.example.com; next-server 192.168.4.4; filename "/data/misc/kernel.diskless"; option root-path "192.168.4.4:/data/misc/diskless"; } host corbieres { hardware ethernet 00:02:b3:27:62:df; fixed-address corbieres.example.com; next-server 192.168.4.4; filename "pxeboot"; option root-path "192.168.4.4:/data/misc/diskless"; } } Esta opción indica a dhcpd que envíe el valor que se encuentra en las declaraciones de host como el nombre de máquina para la máquina sin disco. Otra forma de hacer esto sería añadiendo una opción option host-name margaux dentro de las declaraciones de máquina. La directiva next-server selecciona el servidor de TFTP o de NFS que se debe utilizar para cargar el núcleo o el fichero cargador del núcleo (por defecto se utiliza la misma máquina que actúa como servidor de DHCP). La directiva filename define el archivo que etherboot o PXE cargará en el siguiente paso de ejecución. Debe especificarse de acuerdo con el método de transferencia seleccionado. Etherboot se puede compilar para que use NFS o TFTP. El sistema &os; se configura por defecto para NFS. PXE utiliza TFTP por lo que se utiliza una ruta relativa para especificar el nombre del fichero (esto puede depender de la configuración del servidor de TFTP pero suele ser lo normal). Además PXE no carga el núcleo, lo hace pxeboot. Existen otras posibilidades interesantes, como cargar pxeboot desde el directorio /boot de una unidad de CD-ROM de &os; (ya que &man.pxeboot.8; puede cargar un núcleo GENERIC surge la posibilidad de utilizar PXE para arrancar desde una unidad de CD-ROM remota). La opción root-path define la ruta para el sistema de ficheros raíz utilizando la notación típica de NFS. Cuando se utiliza PXE, es posible dejar la dirección IP siempre y cuando no se active la opción del núcleo de BOOTP. El servidor NFS será en este caso el mismo que el servidor de TFTP. Configuración utilizando BOOTP BOOTP diskless operation A continuación se muestra la configuración equivalente utilizando bootpd (reducida a un único cliente). Esta configuración se debe situar en /etc/bootptab. Por favor, recuerde que etherboot se debe compilar con la opción específica de NO_DHCP_SUPPORT para que pueda utilizar BOOTP y que PXE requiere DHCP. La única ventaja obvia de bootpd es que se encuentra disponible en el sistema base. .def100:\ :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ :sm=255.255.255.0:\ :ds=192.168.4.1:\ :gw=192.168.4.1:\ :hd="/tftpboot":\ :bf="/kernel.diskless":\ :rp="192.168.4.4:/data/misc/diskless": margaux:ha=0123456789ab:tc=.def100 Preparación de un Programa de Arranque con <application>Etherboot</application> Etherboot La página web de Etherboot contiene una amplia documentación enfocada principalmente a los sistemas Linux pero en cualquier caso contiene información que puede resultar útil. En los siguientes párrafos se describe brevemente como se puede utilizar etherboot en un sistema &os;. Lo primero es instalar el port o paquete net/etherboot. El port de etherboot está en /usr/ports/net/etherboot. Si el árbol de ports está instalado en el sistema basta con ejecutar make en dicho directorio. Por favor, lea para saber más sobre los ports y los paquetes. Se puede modificar la configuración de etherboot (por ejemplo, para que use TFTP en lugar de NFS) editando el fichero Config que se encuentra en el directorio fuente de etherboot. Para nuestros propósitos se utilizará un disquete de arranque. Para utilizar otros métodos (PROM o un programa &ms-dos;) por favor consulte la documentación de etherboot. Para crear un disco de arranque se debe insertar un disco en la unidad de disquetes de la máquina donde se ha instalado etherboot, cambiar al directorio src dentro del árbol de directorios de etherboot y teclear: &prompt.root; gmake bin32/tipo_de_dispositivo.fd0 tipo_de_dispositivo depende del tipo de tarjeta Ethernet que se encuentre instalada en la estación de trabajo sin disco. Consulte el fichero NIC en el mismo directorio para determinar cúal es el tipo_de_dispositivo que debe usted usar. Arrancar con <acronym>PXE</acronym> Por defecto el cargador &man.pxeboot.8; carga, valga la redundancia, el kernel vía NFS. El El cargador se puede compilar para que utilice TFTP en lugar de NFS especificando la opción LOADER_TFTP_SUPPORT dentro de /etc/make.conf. Observe los comentarios de /etc/defaults/make.conf (o de /usr/share/examples/etc/make.conf para sistemas 5.X) para saber más detalles. Existen otras dos opciones de make.conf no documentadas que pueden ser útiles para arrancar una máquina sin disco a través del puerto serie: BOOT_PXELDR_PROBE_KEYBOARD y BOOT_PXELDR_ALWAYS_SERIAL (esta última sólo existe en &os; 5.X). Para utilizar PXE cuando arranca la máquina normalmente el usuario tiene que seleccionar la opción Boot from network dentro del menú de opciones de la BIOS o pulsar un tecla de función cuando la máquina se está inicializando. Configuración de Servidores de <acronym>TFTP</acronym> y de <acronym>NFS</acronym> TFTP diskless operation NFS diskless operation Si PXE o etherboot se encuentran configurados para utilizar TFTP se necesita activar tftpd en el servidor de ficheros: Crear un directorio desde el cual el dæmon tftpd servirá los ficheros, por ejemplo /tftpboot. Añadir la siguiente línea a /etc/inetd.conf: tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot Parece que al menos algunas versiones de PXE utilizan la versión TCP de TFTP. En este caso se puede añadir una segunda línea, donde se reemplace dgram udp por stream tcp. Indicar a inetd que vuelva a leer su fichero de configuración: &prompt.root; kill -HUP `cat /var/run/inetd.pid` Se puede situar el directorio tftpboot en cualquier parte del servidor. Debe asegurarse de que la localización se encuentra correctamente configurada tanto en inetd.conf como en dhcpd.conf. En todos los casos también resulta necesario activar el sistema de NFS y exportar los sistemas de ficheros adecuados, todo ello en el servidor de NFS. Añadir lo siguiente a /etc/rc.conf: nfs_server_enable="YES" Exportar el sistema de ficheros donde el directorio raíz sin disco se encuentra localizado añadiendo lo siguiente a /etc/exports (ajuste el punto de montaje de la unidad y sustituya margaux corbieres por el nombre de las estaciones de trabajo sin disco, según corresponda): /data/misc -alldirs -ro margaux corbieres Indicar a mountd que vuelva a leer su archivo de configuración. Si en un primer paso se ha configurado la activación automática del sistema de NFS en /etc/rc.conf lo mejor es reiniciar para que los cambios surtan efecto. &prompt.root; kill -HUP `cat /var/run/mountd.pid` Construcción de un Núcleo Sin Disco diskless operation kernel configuration Si se utiliza etherboot, se necesita crear un archivo de configuración para el kernel de la máquina sin disco que posea las siguientes opciones (además de las opciones del núcleo habituales): options BOOTP # Use BOOTP to obtain IP address/hostname options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info Puede resultar interesante utilizar además BOOTP_NFSV3, BOOT_COMPAT y BOOTP_WIRED_TO (consultar LINT en 4.X o NOTES en sistemas 5.X). Los nombres de estas opciones son nombres históricos y ligeramente confusos ya que permiten un uso indistinto tanto de DHCP como de BOOTP dentro del núcleo (también resulta posible forzar la utilización única de o bien BOOTP o bien de DHCP). Contruir el núcleo (vea ) y copiarlo al lugar especificado en el archivo dhcpd.conf. Cuando se utiliza PXE, la construcción del núcleo con las opciones anteriores no resulta ser algo estrictamente necesario (aunque se recomienda). Activar dichas opciones provoca un mayor tráfico de peticiones de DHCP durante el arranque del núcleo, lo que puede dar lugar a pequeñas inconsistencias entre los nuevos valores y los los valores recuperados por &man.pxeboot.8; en casos muy específicos. La ventaja de utilizarlas consiste en que como un efecto colateral se configurará el nombre de la máquina. De otro modo tendríamos que configurar dicho nombre mediante otro método por ejemplo mediante la configuración específica de la máquina cliente a través del archivo rc.conf. Para que el núcleo se pueda cargar sin problemas con etherboot en sistemas 5.X dicho núcleo tiene que tener compilado el soporte para device hints. Para ello normalmente se especifica la siguiente opción dentro del fichero de configuración del núcleo (consulte los comentarios del fichero NOTES): hints "GENERIC.hints" Preparación del Sistema de Ficheros Raíz root file system diskless operation Se debe crear un sistema de ficheros raíz en las estaciones de trabajo sin disco, concretamente en la localización especificada por root-path dentro de dhcpd.conf. Las siguientes secciones describen dos formas de hacer esto. Utilización del <quote>script</quote> <filename>clone_root</filename> Este es el modo más rápido de crear un sistema de ficheros raíz, pero actulamente sólo se encuentra soportado en &os; 4.X. El script de shell se encuentra en /usr/share/examples/diskless/clone_root y debe ser configurado al menos para ajustar el lugar donde se construirá el sistema de ficheros (concretamente la variable DEST). Consulte los comentarios que se encuentran al comienzo del script para conocer cuales son las instrucciones que debe seguir. Allí se explica cómo se construye el sistema de ficheros base y como determinados ficheros se pueden sobreescribir de manera selectiva por versiones específicas para funcionar sin discos, para toda una subred o para una máquina individual. También allí se muestran ejemplos de los ficheros /etc/fstab y /etc/rc.conf para máquinas sin disco. Los archivos README que se encuentran dentro de /usr/share/examples/diskless contienen mucha información de base, que junto con el resto de ejemplos dentro del directorio diskless sirven para documentar un método de configuración distinto del que se utiliza en clone_root y en los scripts del sistema de /etc, que resultan ser un tanto confusos. No obstante se pueden utilizar a modo de referencia, excepto si se prefiere utilizar el método que se describe en ellos, en cuyo caso se necesitará modificar y adaptar los scripts de forma adecuada. Utilización del Procedimiento Estándar de <command>make world</command> Este método se puede utilizar tanto en &os; 4.X o 5.X y se instalará un sistema completamente nuevo (no sólo el sistema de ficheros raíz) dentro de DESTDIR. Basta con ejecutar el siguiente script: #!/bin/sh export DESTDIR=/data/misc/diskless mkdir -p ${DESTDIR} cd /usr/src; make world && make kernel cd /usr/src/etc; make distribution Una vez ejecutado puede ser necesario ajustar los ficheros /etc/rc.conf y /etc/fstab que se encuentran en DESTDIR de acuerdo con nuestras necesidades. Configuración de la Partición de Intercambio En caso de ser necesario se puede acceder a un fichero de intercambio (swap) a través del sistema NFS. Uno de los métodos típicamente utilizados para realizar esta tarea ha sido retirado de la distribución 5.X. <acronym>NFS</acronym> Swap en sistemas &os; 4.X La ubicación del fichero de intercambio y su tamaño se puede especificar con las opciones &os;-specific 128 y 129 de BOOTP/DHCP. A continuación se muestran varios ejemplos de ficheros de de configuración para ISC DHCP 3.0 o bootpd: Añadir las siguientes líneas al fichero dhcpd.conf: # Global section option swap-path code 128 = string; option swap-size code 129 = integer 32; host margaux { ... # Standard lines, see above option swap-path "192.168.4.4:/netswapvolume/netswap"; option swap-size 64000; } swap-path es la ruta al directorio donde se instalarán los archivos de intercambio. Cada Cada fichero se denomina swap.direccion-ip-del-cliente. Versiones más antiguas de dhcpd usaban una sintáxis del estilo de option option-128 "..., lo cual ya no está soportado. /etc/bootptab normalmente utiliza la siguiente sintaxis: T128="192.168.4.4:/netswapvolume/netswap":T129=0000fa00 El tamaño del fichero dedicado a intercambio se debe expresar en /etc/bootptab en formato hexadecimal. En el servidor de ficheros NFS donde va a residir el fichero de swap se debe(n) crear dicho(s) fichero(s) &prompt.root; mkdir /volumenintercambiored/intercambiored &prompt.root; cd /volumenintercambiored/intercambiored &prompt.root; dd if=/dev/zero bs=1024 count=64000 of=swap.192.168.4.6 &prompt.root; chmod 0600 swap.192.168.4.6 192.168.4.6 es la dirección IP del cliente sin disco. En el servidor NFS añadir a /etc/exports la siguiente línea: /volumenintercambiored -maproot=0:10 -alldirs margaux corbieres A continuación indicar a mountd que vuelva a leer el fichero /etc/exports como se ha indicado anteriormente. <acronym>NFS</acronym> Swap en &os 5.X El núcleo no soporta la activación del intercambio a través de NFS en tiempo de arranque. De esta forma la swap se debe activar mediante los scripts montando un sistema de ficheros de lectura-escritura y creando y activando el fichero de intercambio. Para crear un fichero de intercambio de un determinado tamaño se puede ejecutar lo siguiente: &prompt.root; dd if=/dev/zero of=/ruta/al/fichero/de/intercambio bs=1k count=1 oseek=100000 Para activar el intercambio se tiene que añadir la siguiente línea al fichero de configuración rc.conf: swapfile=/ruta/al/fichero/de/intercambio Cuestiones Variadas Ejecución con un <filename>/usr</filename> de sólo lectura diskless operation /usr read-only Si la estación de trabajo sin disco se configura para utilizar el sistema X-Window se tiene que ajustar el fichero de configuración de xdm debido a que dicho fichero sitúa por defecto el fichero de logs de errores en el directorio /usr. Utilización de un Servidor No-&os; Cuando el servidor del sistema de ficheros raíz no ejecuta &os; se tiene que crear un sistema de ficheros raíz sobre una máquina &os; para después copiarlo al servidor original mediante los comandos tar o cpio. En esta situación algunas veces surgen varios problemas relacionados con los dispositivos especiales que se encuentran en el directorio /dev debido a los diferentes tamaños de los enteros mayor/menor. Una solución para este problema consiste en exportar un directorio del servidor no-&os;, montar este directorio en la máquina &os; anterior y ejecutar MAKEDEV en dicha máquina para crear las entradas de dispositivo correctas (&os; 5.0 y posteriores utilizan &man.devfs.5; para ubicar nodos de dispositivos de forma transparente para el usuario de tal modo que la ejecución de MAKEDEV en estos sistemas no sirve para nada). RDSI RDSI la página de RDSI de Dan Kegel constituye un recurso de información bastante bueno sobre la tecnología RDSI (ISDN en inglés) y sobre el hardware relacionado. A continuación se comenta un esquema rápido sobre RDSI: Si usted vive en Europa le puede resultar útil leer la sección sobre tarjetas RDSI. Si se prevee utilizar RDSI principalmente para conectarse a Internet a través de un Proveedor de Servicios utilizando un mecanismo de marcación automática no dedicado (dial-up), se puede echar un vistazo a los Adaptadores de Terminal. Dichos adaptadores proporciona la mayor flexibilidad y garantiza los mínimos problemas en caso de cambio de cambio de proveedor. Si estamos conectados a dos LAN o conectando a Internet con una conexión RDSI dedicada puede ser interesante considerar la opción de usar un router/bridge único. El coste es un factor importante a la hora de determinar qué solución se debe escoger. Las siguientes opciones se encuentran ordenadas desde las más baratas hasta las más caras. Hellmuth Michaelis Escrito por Tarjetas RDSI ISDN cards La implementación de RDSI que posee &os; soporta sólamente el estandar DSS1/Q.931 (también conocido como Euro-RDSI) utilizando tarjetas pasivas. A partir de &os; 4.4 se soportan también algunas tarjetas activas usando firmware que además soporta otros protocolos de señalización; esto también sucede con la primera tarjeta RDSI de acceso primario (PRI) soportada. El software isdn4bsd permite conectar con otras pasarelas RDSI utilizando IP sobre HDLC o bien PPP PPP síncrono: ambos mediante el uso del PPP del núcleo con isppp, una versión modificada del controlador &man.sppp.4; o mediante la utilización del PPP de entorno de usuario, &man.ppp.8;. Si se utiliza &man.ppp.8; de entorno de usuario se pueden agrupar dos o mas canales B de RDSI (channel bonding). Existe también software que permite a una máquina responder a llamadas de teléfono y algunas cosas más como un modem de 300 baudios. Cada vez se soportan más tarjetas RDSI bajo &os; y los informes existentes muestra que &os; se utiliza con dichas tarjetas de forma satisfactoria en toda Europa y también en otras partes del mundo. Las tarjetas RDSI pasivas soportadas en &os; son principalmente las que poseen el chip Infineon (antiguamente Siemens) ISAC/HSCX/IPAC. También las tarjetas RDSI con los chips de Cologne (en bus ISA exclusivamente), tarjetas PCI con el chip Winbond W6692, algunas tarjetas con combinaciones de los chips Tiger 300/320/ISAC y también algunas tarjetas basadas en chips propietarios como las AVM Fritz! PCI V.1.0 y AVM Fritz! PnP. Actualmente las tarjetas RDSI activas soportadas son las AVM B1 (ISA y PCI) BRI, y las AVM T1 PCI PRI. Se puede consultar /usr/share/examples/isdn/ para obtener documentación sobre isdn4bsd y también en la página principal de isdn4bsd, donde hay enlaces de ayuda, erratas y mucha más información útil, como por ejemplo el manual de isdn4bsd. Si se quiere añadir soporte para un protoclo RDSI distinto para una tarjeta RDSI que no se encuentra soportada o para mejorar isdn4bsd en algún aspecto por favor póngase en contacto con &a.hm;. Para realizar consultas referentes a la instalación, configuración y depuración de problemas relacionados con isdn4bsd le recomendamos recurrir a la lista de correo &a.isdn.name;. Adaptadores de Terminal RDSI Los Adaptadores de Terminal (TA), son para RDSI lo que los modems son para las líneas de teléfono convencionales. modem La mayor parte de los TAs utilizan el conjunto de instrucciones AT de los modem Hayes y se pueden utilizar en lugar del modem. Un TA opera básicamente de igual forma que un modem, diferenciándose en que las velocidades de conexión y throughput son mucho más grandes. La configuración de PPP se realiza exactamente igual que para una configuración de modem convencional. PPP La ventaja principal de utilizar un TA para conectarse a un proveedor de servicios de internet consiste en que se puede usar PPP dinámico. Ya que el espacio de direcciones de IP se está direcciones de IP se está convirtiendo cada vez convirtiendo en un recurso cada dí más limitado y escaso los proveedores ya no desean proporcionar direcciones IP estáticas a sus clientes. No obstante la mayoría de los routers standalone no son capaces de adquirir direcciones IP dinámicas. Los TAs confían completamente en el dæmon de PPP que se está ejecutando para proporcionar fiabilidad y estabilidad en la conexión. De esta forma si se tiene configurado PPP se puede migrar fácilmente de la utilización de modems analógicos al uso de RDSI. No obstante si existía algún problema con PPP antes de efectuar la migración dichos problemas persistirán en RDSI. Si se desea máxima estabilidad se puede utilizar la opción PPP, no el PPP a nivel de usuario. Se sabe que los siguientes TAs funcionan con &os;: Motorola BitSurfer y Bitsurfer Pro Adtran La mayoría de los demás TAs probablemente también funcionen puesto que los fabricantes siempre tratan de que sus productos puedan aceptar la mayoría de los comandos AT. El problema que existe con los TAs es que, como sucede con los modems, se necesita tener una buena tarjeta serie instalada en el sistema. Se recomienda consultar el tutorial FreeBSD Serial Hardware para obtener una comprensión detallada del funcionamiento de los dispositivos serie en &os; y para comprender las diferencias entre puertos serie síncronos y asíncronos. Un TA que se ejecuta a través de un puerto serie (asíncrono) está limitado a 115.2 Kbs, aunque la conexión RDSI sea de 128 Kbs. Para utilizar completamente el ancho de banda que RDSI proporciona, se debe conectar el TA a una tarjeta serie síncrona. No se engañe creyendo que comprando un TA interno hará desaparecer los problemas síncronos/asíncronos. Los TA internos simplemente disponen de un chip de puerto serie instalado de fábrica. Lo único que se consigue con estos dispositivos es no tener que enchufarlos a la red elétrica ahorrando así un enchufe y no tener que comprar un cable serie, pero los problemas dichos anteriormente permanecen. Una tarjeta asíncrona con un TA resulta ser al menos tan rápida como un router standalone y si &os; controla dicha tarjeta se puede adaptar más fácilmente. La elección de una tarjeta síncrona/TA versus un router standalone se trata en la mayoría de los casos de una cuestión cuasi-religiosa. Han existido diversas discusiones sobre este tema en varias listas de correo. Nosotros recomendamos que busque información en los históricos para para poder sopesar los pros y los contras que se han esgrimido en tales discusiones. <quote>Bridges/Routers</quote> RDSI <quote>Stand-alone</quote> ISDN stand-alone bridges/routers Los bridges o routers RDSI no son específicos de &os; o de cualquier otro sistema operativo. Para una descripción completa de la tecnología de bridge y de pasarela de red por favor consulte cualquier libro sobre redes. En el contexto de esta sección los términos router, pasarela y bridge se utilizarán indistintamente. Según va bajando el coste de los routers/bridges RDSI su utilización entre el público en general va en aumento. Un router RDSI es una pequeña caja que se conecta directamente a la red Ethernet local y que gestiona sus propias conexiones con el bridge/router remoto. Posee un software preconfigurado para comunicarse vía PPP y tambíen utilizando otros protocolos de uso común. Un router sopota una mayor tasa de paquetes (throughput) que un standalone TA, ya que utiliza una conexión RDSI síncrona de forma completa. El problema principal que surge con los routers y los bridges RDSI es que la interoperatibilidad entre fabricantes muchas veces causa problemas. Si se está planificando conectarse a un proveedor de servicios resulta conveniente discutir previamente con ellos las necesidades y requisitos. Si se tiene en mente conectar dos segmentos LAN tales como su LAN de casa y la LAN de su oficina RDSI proporciona la solución más simple y menos costosa de gestionar. Esto es así porque al comprar usted mismo el equipamiento necesario para ambos extremos de la conexión tiene usted el control sobre el enlace y puede asegurar su correcto funcionamiento. Por ejemplo, si queremos conecar una computadora casera o una sucursal de la red de oficinas con la oficinal central, se puede utilizar una configuración como la que se muestra a continuación. Sucursal o Red Hogar 10 base 2 La red utiliza una topología basada en bus con Ethernet tipo 10 base 2 (thinnet). Se conecta, en caso de ser necesario, el router a la red cableada mediante un transceiver AUI/10BT. ---Estacion Sun | ---Sistema FreeBSD | ---Windows 95 | Router Stand-alone | ISDN BRI line 10 Base 2 Ethernet Si nuestra sucursal o red hogar está compuesta únicamente por una computadora se puede utilizar un cable cruzado de par trenzado para conectar con el router standalone de forma directa. Oficina Central u Otra LAN 10 base T La red utiliza una topología en estrella basada en Ethernet de 10 base T (Par Trenzado). -------Novell Server | H | | ---Sun | | | U ---FreeBSD | | | ---Windows 95 | B | |___---Stand-alone router | ISDN BRI line ISDN Network Diagram Una gran ventaja que poseen la mayoría de los routers/bridges es que pueden gestionar al mismo tiempo dos conexiones PPP independientes destinadas a dos organizaciones distintas. Esta funcionalidad no se proporciona en la mayoría de los TAs, excepto para determinados modelos (normalmente más caros) que se fabrican con dos puertos serie. No confunda esto con la agrupación de canales, MPP, etc. Esta característica puede resultar muy útil si, por ejemplo, se dispone de una conexión RDSI dedicada con la oficina y queremos introducirnos en ella pero no queremos utilizar otra línea RDSI en el trabajo. Un router situado en las instalaciones de la oficina puede gestionar una conexión de canal B dedicada (64 Kpbs) hacia internet y utilizar el otro canal B como una conexión de datos independiente. El segundo canal B se puede utilizar para marcación remota (dial-in y dial-out) o para agrupación dinámica de canales (MPP, etc) en conjunción con el primer canal B con el objetivo de obtener un mayor ancho de banda. IPX/SPX Un bridge Ethernet permite transmitir más tráfico aparte del tráfico IP. Se puede transmitir IPX/SPX o cualquier otro protocolo que se esté utilizando. Bill Swingle Escrito por Eric Ogren Ampliado por Udo Erdelhoff NIS/YP ¿Qué es esto? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD NIS, siglas de Network Information Services (Servicios de Información de Red), fué un servicio desarrollado por Sun Microsystems para centralizar la administración de sistemas &unix; (originalmente &sunos;). Actualmente se considera como un estándar de la industria; los principales sistemas tipo &unix; (&solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, &os;, etc) implementan NIS. yellow pagesNIS NIS también se conocía como el servicio de páginas amarillas pero debido a problemas legales debidos a la propiedad de marcas comerciales, Sun tuvo que cambiar el nombre. El antíguo término (Yellow Pages o yp) todavía se ve y se utiliza con frecuencia. NIS domains Se trata de un sistema cliente servidor basado en llamadas RPC que permite a un grupo de máquinas que se encuentran definidas dentro de un dominio administrativo NIS compartir un conjunto de ficheros de configuración. Esto permite al administrador de sistemas por un lado configurar clientes NIS de forma minimalista y por otro lado centralizar la gestión de los ficheros de configuración en una única ubicación (una sola máquina). Windows NT Se trata de algo similar al sistema de dominio de &windowsnt; aunque la implementación interna no se puede comparar, la funcionalidad y el servicio obtenido son similares. Términos/Procesos que Usted Debe Conocer Existen varios conceptos y varios procesos de usuario que el usuario no versado en estos temas suele encontrarse la primera vez que se intenta implantar un servicio de NIS en &os;, tanto si se intenta configurar un servidor como si se intenta configurar un cliente: portmap Term Description NIS domainname Un servidor maestro de NIS y todos sus clientes (incluyendo a sus servidores esclavos) poseen el mismo nombre dominio NIS. Al igual que ocurre con el nombre de dominio de &windowsnt;, el nombre de dominio de NIS no tiene nada que ver con el nombre de dominio de DNS. portmap Debe ejecutarse para que se activen las llamadas a procedimientos remotos (Remote Procedure Call o RPC) que son utilizadas por NIS. Si portmap no se está ejecutando no se podrá ejecutar ni clientes ni servidores de NIS. ypbind Asocia un cliente con un servidor NIS. Primeramente se lee el nombre de dominio NIS del sistema y utilizando RPC se conecta con el servidor. ypbind es la parte central de la comunicación cliente servidor del sistema NIS; si ypbind muere en una máquina cliente, dicha máquina no podrá acceder al servidor NIS. ypserv Debe ejecutarse sólamente en los servidores NIS; se trata del proceso servidor de NIS. Si &man.ypserv.8; muere, el servidor no será capaz de responder a peticiones NIS (no obstante, si se definen servidores NIS esclavos la situación puede recuperarse). Existen algunas implementaciones de NIS (no es el caso de &os;) que no intentan conectarse con otro servidor si el servidor con otro servidor si el servidor que se estaba que se estaba utilizando muere. A menudo lo único que se puede hacer en estos casos es reiniciar el servidor (el proceso o la propia máquina) o el proceso ypbind del cliente. rpc.yppasswdd Otro proceso que sólo debe ejecutarse en el servidor maestro de NIS; se trata de un dæmon que permite a los clientes de NIS modificar las contraseñas de los usuarios. Si no se ejecuta este dæmon los usuarios tendrán que entrar en el servidor maestro de NIS para cambiar sus contraseñas allí. ¿Cómo Funciona? Existen tres tipos de máquinas dentro del entorno NIS: los servidores maestros, los servidores esclavos y los clientes de NIS. Los servidores actúan como repositorios centrales para almacenamiento de información de configuración. Los servidores maestros mantienen una copia maestra de dicha información, mientras que los servidores esclavos mantienen copias de la información maestra por motivos de redundancia. Los servidores se encargan de transmitir la información necesaria a los clientes a petición de estos últimos. De esta forma se pueden compatir mucha información contenida en varios archivos. Los ficheros master.passwd, group y hosts normalmente se comparten a través de NIS. Siempre que un proceso en un cliente necesita información que, en caso de no utilizar NIS, se podría recuperar de ficheros locales, en este caso se envía una solicitud al servidor NIS con el que nos encontramos asociados. Clases de Máquinas NIS master server Servidor de NIS maestro. Este servidor, semejante a un controlador de dominio primario de &windowsnt; mantiene todos los archivos que utilizan los clientes. Los ficheros passwd, group y algunos otros se encuentran ubicados en el servidor maestro. Resulta posible configurar una máquina para que actúe como servidor NIS maestro para más de un dominio NIS. No obstante esta configuración no se va a tratar en esta introducción, en la cual asumimos un entorno NIS de tamaño relativamente pequeño. NIS slave server Servidores de NIS esclavos. Semejantes a los controladores de backup de &windowsnt;, los servidores NIS esclavos se utilizan para proporcionar redundancia en entornos de trabajo donde la disponibilidad del servicio resulta muy importante. Además se utilizan para distribuir la carga que normalmente soporta un servidor maestro: los clientes de NIS siempre se asocian con el servidor de NIS que posee mejor tiempo de respuesta, y esto y esto también incluye a los servidores de NIS esclavos. NIS client Clientes NIS. Los clientes NIS, de forma semejante a las estaciones de trabajo de &windowsnt;, se validan contra un servidor NIS (en el caso de &windowsnt; se validan contra un controlador de dominio) para acceder al sistema. Utilización de NIS/YP Esta sección trata sobre cómo configurar y poner en funcionamiento un entorno de NIS sencillo. Esta sección supone que se está utilizando utilizando &os; 3.3 o posteriores. Las instrucciones dadas aquí probablemente funcionen también en cualquier versión de &os; superior a la 3.0 pero no podemos garantizar que esto sea así. Planificación Vamos a suponer que somos el administrador de un pequeño laboratorio de una universidad. En este laboratorio, compuesto por 15 máquinas &os;, actualmente no existe ningún punto de administración centralizada; cada máquina posee sus sus propios /etc/passwd y /etc/master.passwd. Estos ficheros se encuentran sincronizados el uno con el otro mediante intervención manual; por tanto, cuando queramos añadir un usuario a nuestro laboratorio tendremos que ejecutar adduser en todas las máquinas. Claramente esta situación tiene que cambiar, de tal forma que hemos decidido crear un dominio NIS en el laboratorio usando dos máquinas como servidores NIS. La configuración de nuestro laboratorio debería ser algo parecido a lo siguiente: Nombre de máquina Dirección IP Papel ellington 10.0.0.2 servidor NIS maestro coltrane 10.0.0.3 Servidor NIS esclavo basie 10.0.0.4 Estación de trabajo del profesorado bird 10.0.0.5 máquina cliente cli[1-11] 10.0.0.[6-17] Resto de máquinas clientes Si se está configurando un esquema de NIS por primera vez es una buena idea detenerse a pensar cómo queremos implantar el sistema. Existen varias decisiones que se deben tomar independientemente del tamaño de nuestra red. Elección del nombre de dominio NIS NIS domainname Este nombre puede no ser el nombre de dominio al que estamos acostumbrados. Resulta más preciso llamarlo nombre de dominio NIS. Cuando un cliente genera peticiones de NIS que llegan a todas las máquinas (broadcast) solicitando información se incluye el nombre de dominio NIS que tiene configurado. De esta forma, varios servidores de dominios distintos situados en la misma red pueden discriminar las peticiones recibidas. Se puede pensar en el nombre de dominio NIS como un identificador de grupos de máquinas que se encuentran relacionados administrativamente de alguna forma. Algunas organizaciones eligen utilizar su nombre de dominio de Internet como nombre de dominio NIS. Esto no se recomienda ya que puede causar confusión cuando se intentan depurar problemas de red. El nombre de dominio NIS debería ser un nombre único dentro de nuestra red y resulta más útil aún si el nombre elegido puede describir de alguna forma al conjunto de máquinas que representa. Por ejemplo el departamento de arte de la empresa Acme puede utilizar como nombre de dominio acme-art. En nuestro ejemplo hemos utilizado el nombre test-domain. SunOS No obstante algunos sistemas operativos (de forma notable &sunos;) utilizan como nombres de dominio nombres de Internet. Si se poseen máquinas con esta restricción no queda más remedio que utilizar los nombres de dominio de Internet como nombres de dominio NIS. Requisitos Físicos de los Servidores Existen varias cosas que debemos tener en cuenta cuando se selecciona una máquina para actuar como servidor NIS. Una de las características desafortunadas del servicio de páginas amarillas es el alto nivel de dependencia que llegan a tener los clientes respecto del servidor de NIS. Si el cliente no puede contactar con el servidor NIS normalmente la máquina se queda en un estado totalmente inutilizable. La carencia de información de usuarios y grupos provoca que las máquinas se bloqueen. Con esto en mente debemos debemos asegurarnos de escoger un servidor de NIS que no se reinicie de forma habitual o uno que no se utilice para para desarrollar. Si se dispone de una red con poca carga puede resultar aceptable colocar el servidor de NIS en una máquina donde se ejecuten otros servicios pero en todo momento se debe tener presente que si por cualquier motivo el servidor de NIS quedara inutilizable afectaría a todas las máquinas de forma negativa. Servidores NIS Las copias canónicas de toda la información que mantiene el sistema de páginas amarillas se almacenan en una única máquina denominada servidor maestro de NIS. Las bases de datos utilizadas para almacenar la información se denominan mapeos NIS. En &os; estas asociaciones o mapeos se almacenan en el directorio /var/yp/[nombrededominio] donde [nombrededominio] es el nombre del dominio de NIS que el servidor gestiona. Un único servidor NIS puede gestionar varios dominios al mismo tiempo de forma que resulta posible tener varios directorios como el anterior, uno por cada dominio soportado. Cada dominio posee su conjunto de mapeos independiente y propio. Los servidores maestro y esclavos manejan todas las peticiones de a través del dæmon ypserv. El comando ypserv se responsabiliza de recibir peticiones de los clientes NIS. Estas peticiones se traducen a una ruta dentro del servidor. Esta ruta localiza un fichero de base de datos determinado del servidor de NIS, y finalmente ypserv se encarga de transmitir la información de dicha base de datos de vuelta al cliente que la solicitó. Configuración de un Servidor de NIS Maestro NIS server configuration La configuración de un servidor de NIS maestro puede resultar relativamente sencilla dependiendo de las necesidades que se tengan. &os; viene preconfigurado por defecto con un servicio NIS. Todo lo que necesitamos es añadir la siguiente línea en /etc/rc.conf y &os; se encarga del resto. nisdomainname="test-domain" Esta línea establece el nombre de dominio NIS como test-domain, cuando se realiza la configuración de la red (por ejemplo, después de un reinicio). nis_server_enable="YES" Esta variable indica a &os; que ejecute los procesos necesarios para actuar como un servidor de NIS la próxima vez que se configure el subsistema de red. nis_yppasswdd_enable="YES" Esto permite activar el dæmon rpc.yppasswdd el cual, como se ha mencionado anteriormente, permite a los usuarios realizar cambios de contraseña desde las máquinas clientes de NIS. Dependiendo de la configuración de NIS podemos necesitar añadir algunas entradas más. Consulte la sección sobre servidores NIS que también actúan como clientes, más adelante en el texto, para saber más sobre esto. Una vez hecho esto todo lo que tenemos que hacer es ejecutar el comando /etc/netstart como superusuario. Este comando realiza los pasos de configuración necesarios utilizando los valores de las variables definidas en /etc/rc.conf. Inicialización de los mapeos de NIS NIS maps Las asociaciones o mapeos de NIS no son más que ficheros de base de datos. Estos ficheros se generan a partir de los ficheros de configuración contenidos en el directorio etc/ excepto para el caso del fichero etc/master.passwd. Esto es así por una buena razón ya que no suele ser buena idea propagar las contraseñas de root y de otras cuentas de administración a todos los servidores NIS del dominio. servidores NIS del dominio. Así, antes de inicializar los mapeos se debe ejecutar: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd Se deben borrar todas las entradas que hagan referencia a cuentas del sistema (bin, tty, kmem, games, etc), junto con cualquier cuenta que no deseemos que se transmita a los clientes NIS (por ejemplo la cuenta de root y cualquier otra cuenta con UID 0 (el del superusuario)). Asegúrese de que /var/yp/master.passwd no se puede leer ni por grupos ni por el resto de usuarios (modo 600). Utilice el comando chmod en caso de necesidad. Tru64 UNIX Una vez hecho esto es hora de inicializar las asociaciones de NIS. &os; incluye un script denominado ypinit para realizar esta tarea (consulte su página del manual para obtener más información). Recuerde que este script se encuentra disponible en la mayoría de los sistemas &unix;, pero no en todos. En sistemas Digital UNIX/Compaq Tru64 UNIX se denomina ypsetup. Debido a que se pretende generar asociaciones para un servidor NIS maestro vamos a ejecutar ypinit con la opción . A modo de ejemplo, suponiendo que todos los pasos comentados anteriormente se han realizado con éxito, ejecute: ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..salida de la generacion de mapeos..] NIS Map update completed. ellington has been setup as an YP master server without any errors. ypinit debería haber creado el fichero /var/yp/Makefile a partir de /var/yp/Makefile.dist. Una vez creado este archivo presupone que se está usando un entorno NIS con un único servidor utilizando sólamente máquinas &os;. Debido a que test-domain posee también un servidor NIS esclavo se debe editar el fichero var/yp/Makefile: ellington&prompt.root; vi /var/yp/Makefile Se debe comentar la línea que dice: NOPUSH = "True" (si es que no se encuentra ya comentada). Configuración de un Servidor NIS Esclavo NIS slave server La configuración de un servidor NIS esclavo resulta ser incluso más sencilla que la del maestro. Basta con entrar en el servidor esclavo y editar /etc/rc.conf de foma semejante a como se realizó en el apartado anterior. La única diferencia consiste en que ahora debemos utilizar la opción cuando ejecutemos ejecutemos ypinit. A continuación del parámetro se debe especificar el nombre del servidor maestro de modo que el comando tendría que ser algo parecido a esto: coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. En estos momentos debemos tener un nuevo directorio llamado /var/yp/test-domain. Las copias de los mapeos del servidor maestro se almacenan en dicho directorio. Es nuestra responsabilidad como administradores asegurar que dichas copias permanecen actualizadas en todo momento. La siguiente entrada en el archivo /etc/crontab del servidor esclavo se encarga de realizar esta tarea: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Estas dos líneas obligan al servidor esclavo a sincronizar los mapeos con el servidor maestro. Estas entradas no son obligatorias ya que el servidor maestro siempre intenta comunicar cualquier cambio que se produzca en sus asociaciones a todos los servidores esclavos ya que la información de, esclavos, ya que la información de, por ejemplo, contraseñas es de vital importancia para el funcionamiento de los sistemas que dependen del servidor. No obstante es una buena idea obligar a que se realicen estos cambios mediante las entradas anteriores. Esto resulta ser incluso más importante en redes de sobrecargadas donde las actualizaciones de asociaciones pueden algunas veces no llegar a realizarse de forma completa. A continuación se ejecuta el comando /etc/netstart en el servidor esclavo de igual de igual forma que se hizo con el servidor maestro; esto relanza de nuevo el servidor de NIS. Clientes NIS Un cliente de NIS establece lo que se conoce con el nombre de asociación (bind en inglés) con un servidor NIS NIS determinado utilizando el dæmon ypbind. ypbind comprueba el dominio por defecto del sistema (especificado mediante el comando domainname) y comienza a enviar peticiones RPC a todos los elementos de la red local (broadcast). Estas peticiones especifican el nombre del dominio con el que se quiere establecer la asociación. Si esta petición alcanza una petición alcanza un servidor NIS configurado para servir dicho dominio el servidor responde a la petición e ypbind almacenará la dirección de dicho servidor. Si existen varios servidores disponibles (un maestro y varios esclavos, por ejemplo), ypbind utilizará la dirección del primero en responder. A partir de este punto el cliente dirigirá el resto de sus peticiones NIS directamente a la dirección IP almacenada. Ocasionalmente ypbind envía un ping sobre el servidor para comprobar que en efecto se encuentra funcionando. Si no se recibe contestación al ping dentro de un espacio de tiempo determinado ypbind marca el dominio como sin asociar y comienza de nuevo a inundar la red con la esperanza de localizar algún otro servidor NIS. Configuración de un cliente NIS NIS client configuration La configuración de un cliente &os; de NIS resulta ser una operación extremadamente sencilla. Editar el fichero /etc/rc.conf y añadir las siguientes líneas para establecer el nombre de dominio NIS y para que se ejecute ypbind al arranque de la red: nisdomainname="test-domain" nis_client_enable="YES" Para importar todas las entradas de contraseñas del servidor de NIS hay que eliminar todas las cuentas de usuario de /etc/master.passwd y utilizar vipw para añadir la siguiente línea al final de dicho fichero: +::::::::: Esta línea permite que cualquiera abra una cuenta en local, siempre que dicha cuenta se encuentre definida en las asociaciones de cuentas y contraseñas del servidor NIS. Existen varias formas de configurar los clientes NIS modificando esta línea. Consulte la sección sobre netgroups que se encuentra más adelante en este mismo texto. Si quiere saber más puede consultar el libro de O'Reilly Managing NFS and NIS. Se debe mantener al menos una cuenta local (por ejemplo, una cuenta que no se importe a través de NIS) en el fichero /etc/master.passwd y además dicha cuenta debería ser miembro del grupo wheel. Si algo va mal con el procedimiento descrito esta cuenta se puede utilizar para entrar en la máquina cliente de forma remota para posteriormente convertirse en superusuario e intentar solucionar el problema. Para importar todas las entradas de grupo posibles del servidor NIS se debe añadir la siguiente línea al fichero /etc/group: +:*:: Después de completar estos pasos deberímos ser capaces de ejecutar ypcat passwd y ver la asociación de contraseñas que se encuentra en el servidor de NIS Seguridad en NIS En general cualquier usuario remoto puede realizar peticiones de RPC a &man.ypserv.8; y recuperar los contenidos de las asociaciones de NIS siempre y cuando el usuario remoto conozca el nombre de dominio de NIS. Para evitar este tipo de transacciones no autorizadas, &man.ypserv.8; soporta una característica denominada securenets la cual se puede utilizar para limitar el acceso a un determinado conjunto de máquinas. En el arranque &man.ypserv.8; intenta cargar la información de securenets a partir de un fichero denominado /var/yp/securenets. Esta ruta de fichero varía dependiendo del camino especificado con la opción . Dicho fichero contiene entradas compuestas de, por un lado, un rango de red y por otro una máscara de red, separados por espacios en blanco. Las líneas que comienzan por # se consideran comentarios. A continuación se muestra un ejemplo de un fichero securenet: # admitir conexiones desde localhost -- obligatorio 127.0.0.1 255.255.255.255 # admitir conexiones desde cualquier host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # admitir conexiones desde cualquier host # between 10.0.0.0 to 10.0.15.255 # esto incluye las maquinas en el 'testlab' 10.0.0.0 255.255.240.0 Si &man.ypserv.8; recibe una petición de una dirección que coincide con alguna de las reglas especificadas en el fichero se procesa la petición. Si no existe ninguna coincidencia la petición se rechaza y se graba un mensaje de aviso. Si el archivo /var/yp/securnets no existe ypserv acepta conexiones de cualquier máquina. El programa ypserv también posee soporte para el paquete de Wietse Venema denominado tcpwrapper. Este paquete permite utilizar los ficheros de configuración de tcpwrapper para realizar control de acceso en lugar de utilizar var/yp/securenets. Aunque ambos mecanismos de control de acceso proporcionan un grado de seguridad mayor que no utilizar nada resultan vulnerables a ataques de falsificación de IPs. El cortafuegos de la red donde se implanta el servicio de NIS debería encargarse de bloquear el tráfico específico de dicho servicio. Los servidores que utilizan /var/yp/securenets pueden no prestar servicio a clientes NIS legítimos cuando se trabaja con implementaciones arcaicas de TCP/IP. Algunas de estas implementaciones ponen a cero todos los bits de máquina cuando se realizan broadcast y/o pueden fallar al especificar la máscara de red en el mismo caso, por citar algunos ejemplos. Mientras que algunos de estos problemas se pueden solucionar variando la configuración del cliente en otros casos podemos vernos obligados a prescindir del cliente en cuestión o a prescindir del fichero var/yp/securenets. Se desaconseja la utilización de var/yp/securenets en un sistema con una implementación arcaica de TCP/IP y puede suponer una pérdida de funcionalidad para grandes zonas de la red. tcpwrapper La utilización del paquete tcpwrapper incrementa la latencia del servidor NIS. El retardo adicional introducido puede ser lo suficientemente grande como para causar la expiración de ciertos temporizadores de los programas clientes, especialmente en redes muy cargadas o con servidores de NIS lentos. Si se experimentan estos síntomas en varias máquinas clientes, puede ser conveniente convertir dichas máquinas en servidores NIS esclavos y obligarlas a asociarse con ellas mismas. Prohibir el Acceso a Determinados Usuarios En nuestro laboratorio de ejemplo existe una máquina denominada basie que actúa sólo como una estación de trabajo para el profesorado. No queremos sacar a esta máquina del dominio NIS pero nos damos cuenta de que el fichero passwd que se encuentra en el servidor de NIS posee cuentas tanto para profesores como para alumnos. ¿Qué podemos hacer?. Existe una forma de prohibir el acceso a determinados usuarios sobre una determinada máquina incluso aunque se encuentren dados de alta en la base de datos de NIS. Para realizar esto todo lo que debemos hacer es añadir -nombredeusuario al final del fichero /etc/master.passwd en la máquina cliente donde nombredeusuario es el nombre de usuario del usuario al que queremos prohibirle el acceso. Esto se debe realizar a poder ser mediante el comando vipw ya que vipw realiza comprobaciones de seguridad sobre los cambios realizados y además se encarga de reconstruir la base de datos de contraseñas cuando se termina la edición. Por ejemplo, si quisiéramos prohibir el acceso al usuario bill a la máquina basie haríamos: basie&prompt.root; vipw [añadimos -bill al final y salimos] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Udo Erdelhoff Escrito por Utilización de Netgroups netgroups El método descrito en la sección anterior funciona razonablemente bien si las reglas especiales se definen para un conjunto pequeño de usuarios y/o máquinas. En dominios admnistrativos grandes puede que se nos olvide prohibir el acceso a algún usuario en determinadas máquinas perdiendo de esta forma el principal beneficio de utilizar el servicio de páginas amarillas: administración centralizada. La solución creada por los desarrolladores de NIS se denomina netgroups. Su propósito se asemeja al concepto de grupos utilizado por los sistemas &unix;. La diferencia principal es la carencia de un identificador numérico y la habilidad para definir un netgroup que incluye tanto a cuentas de usuario como a otros netgroups. Los netgroups se desarrollaron para gestionar redes grandes y y complejas con cientos de usuarios y máquinas. Por un lado esto es una Cosa Buena si nos encontramos en tal situación pero por otro lado esta complejidad añadida hace que sea casi imposible de explicar a través de ejemplos sencillos. El ejemplo que va a utilizar en lo que queda de sección ilustrará este hecho. Vamos a suponer que la exitosa introducción del servicio de páginas amarillas en nuestro laboratorio ha llamado la atención de nuestros jefes. Nuestra siguiente tarea consiste en extender el dominio de NIS para que cubra otras máquinas del campus. Las tablas que se muestran a continuación contienen los nombres de los nuevos usuarios y máquinas junto con una breve descripción de ellas. Nombre del Usuario/usuarios Descripción alpha, beta Empleados normales del departamento de IT charlie, delta Los nuevos aprendices del departamento de IT echo, foxtrott, golf, ... Empleados normales able, baker, ... Los actuales internos Nombre de la Máquina(s) Descripción guerra, muerte, hambre, peste Los servidores más importantes. Sólo los empleados de IT pueden entrar en estas máquinas orgullo, avaricia, envidia, ira, lujuria, pereza Servidores de menor importancia. Todos los miembros del departamento de IT pueden entrar en ellos. uno, dos, tres, cuatro, ... Estaciones de trabajo ordinarias. Sólo los empleados actuales pueden utilizar estas máquinas. trashcan Una máquina muy vieja sin ningún dato dato crítico. Incluso los internos pueden utilizar esta máquina. Si se trata de implementar estas restricciones a nivel de usuario particular tendríamos que añadir una línea -usuario a cada fichero passwd del sistema para cada usuario que tuviera prohibido el acceso a dicho sistema. Si nos olvidamos de una sola entrada podrímos tener serios problemas. Puede ser factible realizar esta configuración cuando se instala el servicio pero no obstante el riesgo que corremos al mantener este sistema de restricciones en el día día es muy alto. Después de todo Murphy era un optimista. La gestión de esta situación mediante netgroups ofrece varias ventajas. Cada usuario no tiene que tratarse de una forma individualizada; basta con añadir un usuario a uno o más netgroups y posteriormente permitir o prohibir el acceso para todos los usuarios del netgroup. Si se añade una nueva máquina al servicio de NIS simplemente tendremos que definir restricciones de acceso para los netgroups definidos en la red. Si se añade un nuevo usuario bastará con añadir dicho usuario a un netgroup existente. Estos cambios son independientes unos de otros: se acabó la necesidad de aplicar la frase por cada combinación de usuario y máquina haga esto y esto. Si hemos planificado nuestro servicio de NIS cuidadosamente, sólo tendremos que modificar un fichero de configuración en un determinado servidor para permitir o denegar estos accesos. El primer paso consiste en la inicialización de la asociación o mapeo del netgroup. El comando de &os; &man.ypinit.8; no crea este mapeo por defecto pero una vez creado será tenido en cuenta por la implementación de NIS. Para crear una asociación vacía simplemente escriba: ellington&prompt.root; vi /var/yp/netgroup y comienze a añadir contenido. En nuestro ejemplo necesitamos al menos cuatro netgroups: empleados de IT, aprendices de IT, empleados normales e internos. IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) IT_EMP, IT_APP etc. son los nombres de los netgroups. Cada conjunto delimitado por paréntesis define una o más cuentas como pertenecientes al netgroup. Existen tres campos definidos dentro de dichos de dichos grupos: El nombre de las máquinas donde los siguientes items son aplicables. Si no se especifica un nombre de máquina la entrada se aplica a todas las máquinas existentes. Si se especifica una máquina determinada entraremos en un mundo lleno de horrores y confusiones así que mejor no hacerlo. El nombre de la cuenta que pertenece al netgroup que estamos definiendo. El dominio NIS donde reside la cuenta. Se pueden importar cuentas de otros dominios NIS (en caso de que usted pertenezca al extraño grupo de personas que gestionan más de un dominio NIS. Cada uno de estos campos puede contener comodines. Consulte &man.netgroup.5; para obtener más detalles. netgroups No se deben utilizar nombres de los netgroups superiores a ocho caracteres, especialmente si las máquinas de nuestro dominio utilizan sistemas operativos variados. Los nombres son sensibles a las mayúsculas/minúsculas: se recomienda utilizar nombres en mayúsculas para distinguirlos de los usuarios o máquinas. Algunos clientes de NIS (distintos de los clientes &os;) no pueden gestionar netgroups con un gran número de entradas. Por ejemplo algunas versiones antiguas de &sunos; comienzan a presentar problemas si un netgroup contiene más de quince entradas. Se puede solventar este problema creando varios sub-netgroups de como mucho quince usuarios y finalmente creando el verdadero netgroup compuesto por los sub-netgroups: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 Se puede repetir este proceso si se tienen que definir más de 225 usuarios dentro de un único netgroup. La activación y distribución de nuestro nuevo mapeo NIS resulta sencillo: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Esto genera las tres asociaciones NIS netgroup, netgroup.byhost y netgroup.byuser. Utilice &man.ypcat.1; para comprobar si el nuevo mapeo NIS se encuentra disponible: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser La salida del primer comando debería parecerse a los contenidos del fichero /var/yp/netgroup. El segundo comando no mostrará ninguna salida salvo que se hayan especificado netgroups específicos para máquinas. El tercer comando se puede utilizar para obtener la lista de los netgroups a los que petenece un determinado usuario. La configuración del cliente es bastante simple. Para configurar el servidor guerra se debe ejecutar &man.vipw.8; y sustituír la línea +::::::::: por +@IT_EMP::::::::: Ahora sólo se importan los datos para los usuarios que se encuentren definidos en el netgroup IT_EMP; dichos datos se importan en la base de datos de contraseñas de guerra y sólo se permite el acceso a estos usuarios. Por desgraciaesta información también se aplica a la función ~ del shell y a todas las rutinas que traducen nombres de usuarios con los correspondientes identificadores númericos de usuario (uid). En otras palabras, el comando cd ~ no va a funcionar, el comando ls -l muestra el identificador numérico en lugar del nombre de usuario y el comando find . -user joe -print produce un error de No such user (Usuario desconocido). Para solucionar esto debemos importar todas las entradas de usuario en la máquina cliente NIS pero sin permitirles el acceso. Esto se puede realizar añadiendo otra línea al fichero /etc/master.passwd. Esta línea debería contener lo siguiente: +:::::::::/sbin/nologin, lo que significa que se importen todas las entradas pero que se reemplace el shell por /sbin/nologin. Se puede sustituir cualquier campo de la entrada de contraseñas especificando un valor concreto para dicho campo en el fichero local local /etc/master.passwd. Asegúrese de que la línea +:::::::::/sbin/nologin se sitúa después de +@IT_EMP:::::::::. Si esto no se cumple todas las cuentas de usuario importadas del servidor NIS poseerán /sbin/nologin como shell de acceso. Después de este cambio si se introduce un nuevo empleado en el departamento de IT basta con cambiar una asociación de NIS. Se podría aplicar una aproximación similar para los servidores menos importantes sustituyendo la cadena +::::::::: en las versiones locales del fichero /etc/master.passwd por algo parecido a esto: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin Las líneas correspondientes para las estaciones de trabajo normales podrían ser: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin Y parece que todos nuestros problemas de gestión han desaparecido; hasta que unas semanas más tarde se produce un cambio en la política de gestión: el depatamento de IT comienza a alquilar interinos. Los interinos de IT pueden utilizar las estaciones de trabajo normales y los servidores menos importantes y los aprendices de IT pueden acceder a los servidores principales. No nos queda más remedio que añadir un nuevo netgroup denominado IT_INTERN y añadir los nuevos interinos de IT a este nuevo grupo y comenzar a cambiar la la configuración de cada máquina, una por una... Como dice el antiguo proverbio: Errores en la planificación centralizada conllevan grandes quebraderos de de cabeza globales. La habilidad que posee NIS para crear netgroups a partir de otros netgroups se puede utilizar para evitar la situación anterior. Una posibilidad consiste en la creación de netgroups basados en roles. Por ejemplo, se podría crear un netgroup denominado BIGSRV para definir las restricciones de acceso para los servidores importantes, otro grupo denominado USERBOX para las estaciones de trabajo... Cada uno de estos netgroups podría contener los netgroups que pueden acceder a dichas máquinas. Las nuevas entradas para nuestro mapeo NIS de netgroups sería algo así: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS Este método de definir restricciones de acceso funciona razonablemente bien si podemos definir grupos de máquinas que posean restricciones semejantes. Por desgracia lo normal es que este caso resulta ser una excepción más que una regla. En la mayor parte de las ocasiones necesitaremos definir restricciones de acceso en función de máquinas individuales. Las definiciones de netgroups específicos para determinadas máquinas constituyen el segundo método que se puede utilizar para gestionar el cambio de política del ejemplo que estamos explicando. En nuestro caso el fichero /etc/master.passwd de cada máquina contiene dos líneas que comienzan por +. La primera de ellas añade un netgroup con las cuentas que pueden acceder a esa máquina, mientras que la segunda añade el resto de cuentas con shell el resto de cuentas con shell /sbin/nologin. Es una buena idea utilizar la versión todo en mayúsculas del nombre de máquina como el nombre del netgroup. En otras palabras, las líneas deberían ser como la siguiente: +@BOXNAME::::::::: +:::::::::/sbin/nologin Una vez que hemos completado esta tarea para todas las máquinas nunca más resultará necesario modificar las versiones locales de /etc/master.passwd. Los futuros cambios se pueden gestionar simplemente modificando el mapeo o asociación de NIS. A continuación se muestra un mapeo de netgroups para el escenario que se está explicando junto con algunas buenas ideas: # Definimos antes que nada los grupos de usuarios IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Ahora definimos unos pocos grupos basados en roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # Y un grupo para tareas especiales # Permitimos a echo y golf acceso a nuestra maquina-anti-virus SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # netgroups basados en maquinas # Nuestros servidores principales GUERRA BIGSRV HAMBRE BIGSRV # El usuario india necesita acceso a este servidor PESTE BIGSRV (,india,test-domain) # # Este es realmente importante y necesita mas restricciones de # acceso MUERTE IT_EMP # # La maquina-anti-virus que mencionabamos mas arriba ONE SECURITY # # Restringimos una maquina a un solo usuario TWO (,hotel,test-domain) # [...otros grupos] Si estamos utilizando algun tipo de base de datos para gestionar cuentas de usuario debemos ser capaces de crear la primera parte del mapeo utilizando las herramientas proporcionadas por dicho sistema de base de datos. De este modo los nuevos usuarios tendrán automáticamente derechos de acceso sobre las máquinas. Una última, por precaución: puede no ser siempre aconsejable utilizar netgroups basados en máquinas. Si se están desplegando, por ejemplo, un par de docenas o incluso cientos de máquinas idénticas en laboratorios de estudiantes, es mejor utilizar netgroups basados en roles en lugar de netgroups basados en máquinas individuales para mantener el tamaño de la asociación NIS dentro de unos límites razonables. Cosas Importantes para Recordar Todavía quedan un par de cosas que tendremos que hacer de forma distinta a lo comentado hasta ahora en caso de encontrarnos dentro de un entorno de NIS. Cada vez que deseemos añadir un usuario a nuestro laboratorio debemos añadirlo al servidor NIS maestro únicamente y es tarea fundamental del administrador acordarse de reconstruir los mapeos NIS. Si nos olvidamos de esto el nuevo usuario será incapaz de acceder a ninguna máquina excepto al servidor NIS. Por ejemplo, si necesitáramos añadir el nuevo usuario jsmith al laboratorio tendríamos que ejecutar lo siguiente: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain Se puede ejecutar también adduser jsmith en lugar de pw useradd jsmith. No introduzca las cuentas de administración dentro de los mapeos de NIS. No es buena idea propagar cuentas y contraseñas de administración a máquinas donde residen usuarios que normalmente no deberían poder acceder a dichas cuentas. Mantenga el servidor maestro y esclavo de NIS seguros y minimize el tiempo de interrupción del servicio. Si alguien fuera capaz de comprometer la integridad de estas máquinas o de apagarlas los usuarios del dominio no podrían acceder a sus cuentas en ningún sistema. Esto es la debilidad principal de cualquier sistema de administración centralizada. Si no se protegen los servidores NIS tendremos frente a nosotros a una horda de usuarios bastante enfadados. Compatibilidad con NIS v1 El servicio ypserv de &os; puede servir también a clientes NIS v1. La implementación de NIS de &os; sólo utiliza el protocolo NIS v2 aunque otras implementaciones incluyen soporte para el protocolo v1 por razones de compatibilidad con sistemas antiguos. Los dæmones ypbind suministrados con estos sistemas tratan de establecer una asociación con un servidor NIS versión 1 aunque puede que nunca la lleguen a utilizar (y pueden continuar realizando búsquedas mediante broadcast incluso cuando reciben una respuesta de un servidor versión 2). Tenga muy presente que mientras se soportan las llamadas normales de clientes v1, la versión de ypserv actualmente suministrada no gestiona peticiones de transferencia de mapeos a través de la versión 1; en consecuencia no se puede utilizar como maestro o esclavo junto con servidores de NIS antiguos que sólo soporten el protocolo v1. Por suerte quedan muy pocos servidores de este estilo en funcionamiento hoy en día. Servidores NIS que Actúan También Como Clientes NIS Se debe tener cuidado cuando se ejecuta ypserv en un entorno multi-servidor donde las máquinas servidoras actúan también como máquinas clientes de NIS. Normalmente es una buena idea obligar a los servidores a que se asocien con ellos mismos mejor que permitirles emitir peticiones de asociación en broadcast, lo que posiblemente terminará con los servidores asociados entre sí. Se pueden producir extraños fallos si un servidor del que dependen otros deja de funcionar. Puede darse que los contadores de todos los clientes expiren e intenten asociarse a otro servidor, pero el retardo puede ser considerable y los fallos todavía podrín persistir debido a que los servidores se asocian contínuamente los unos a los otros. Se puede obligar a una máquina a asociarse con un servidor en particular ejecutando ypbind con la opción . Si no se quiere ejecutar esto manualmente cada vez que se reinice el servidor NIS se puede puede añadir la siguiente línea al fichero /etc/rc.conf: nis_client_enable="YES" # ejecuta tambien el soft cliente nis_client_flags="-S NIS domain,server" Consulte &man.ypbind.8; para obtener más información. Formatos de Contraseñas NIS password formats Uno de los problemas más comunes que se encuentra la gente a la hora de implantar un servicio de NIS es la compatibilidad del formato de las contraseñas. Si nuestro servidor de NIS utiliza contraseñas cifradas mediante DES sólo podrá aceptar clientes que utilicen DES. Por ejemplo, si poseemos clientes de NIS &solaris; en nuestra red casi seguro que necesitaremos utilizar contraseñas cifradas mediante DES. Para comprobar qué formato utilizan los servidores y los clientes, se puede mirar en /etc/login.conf. Si la máquina se configura para utilizar cifrado de contraseñas mediante DES, entonces la clase por defecto debe poseer una entrada como la siguiente: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Se han omitido otras entradas] Otros posibles valores para característica de passwd_format pueden ser blf y md5 (para utilizar los algoritmos Blowfish y MD5 respectivamente). Se debe reconstruir la base de datos de acceso siempre que se modifique el fichero /etc/login.conf mediante la ejecución del siguiente comando como root: &prompt.root; cap_mkdb /etc/login.conf El formato de las contraseñas que ya se encuentran definidas en /etc/master.passwd no se actualizará hasta que el usuario cambie su contraseña, después de que se haya reconstruido la base de datos de tipos de acceso. A continuación para asegurarse de que las contraseñas se cifran con el formato seleccionado también debemos comprobar que la variable crypt_default dentro del fichero /etc/auth.conf da preferencia al formato de contraseña elegido. Por ejemplo cuando se utilizan contraseñas cifradas con DES la entrada debe ser: crypt_default = des blf md5 Si se realizan los pasos anteriores en cada una de las máquinas clientes y servidoras de nuestro entorno NIS podemos asegurar que todas utilizan el mismo formato de contraseña dentro de nuestra red. Si se presentan problemas de validación con determinados usuarios en una determinada máquina cliente se puede empezar a investigar sobre el asunto. Recuerde: si se quiere desplegar un servicio de páginas amarillas sobre un entorno de red heterogéneo probablemente se deba utilizar DES en todos los sistemas puesto que DES es el mínimo común denominador. Greg Sutter Escrito por DHCP ¿Qué es DHCP? Dynamic Host Configuration Protocol DHCP Internet Software Consortium (ISC) DHCP, el Protocolo de Configuración Dinamica de Máquinas (Dynamic Host Configuration Protocol), especifica un método para configurar dinámicamente los parámetros de red necesarios para que un sistema pueda comunicarse efectivamente. &os; utiliza la implementación de DHCP proporcionada por el Internet Software Consortium (ISC) de tal forma que toda la información relativa a la configuración de DHCP se basa en la distribución proporcionada por el ISC. Qué Temas Trata Esta Seccións Esta sección describe tanto los componentes de la parte servidora como los componentes de la parte cliente del sistema DHCP del ISC. El programa cliente, denominado forma parte por defecto de los sistemas &os; y el programa servidor se puede instalar a partir del port net/isc-dhcp3-server. Las principales fuentes de información son las páginas de manual &man.dhclient.8;, &man.dhcp-options.5; y &man.dhclient.conf.5; junto con las referencias que se muestran a continuación en esta misma sección. Cómo Funciona UDP Cuando el cliente de DHCP, dhclient, se ejecuta en una máquina cliente, valga la redundancia, comienza a enviar peticiones broadcast solicitando información de configuración. Por defecto estas peticiones se realizan contra el puerto UDP 68. El servidor responde a través del puerto UDP 67 proporcionando al cliente una dirección IP junto con otros parámetros relevantes para el correcto funcionamiento del sistema en la red, tales como la máscara de red, el router por defecto y los servidores de DNS. Toda esta información se presta y es válida sólo durante un determinado período de tiempo (configurado por el administrador del servidor de DHCP). De esta forma direcciones IP asignadas a clientes que ya no se encuentran conectados a la red pueden ser reutilizadas al pasar determinado periodo de tiempo. Los clientes de DHCP pueden obtener una gran cantidad de información del servidor. Se puede encontrar una lista completa en &man.dhcp-options.5;. Integración dentro de los Sistemas &os; &os; se integra totalmente con el cliente DHCP del ISC, dhclient. Este soporte se proporciona tanto en el proceso de instalación como en la instalación por defecto del sistema base obviando la necesidad de poseer un conocimiento detallado de aspectos relacionados con la configuración de redes siempre y cuando se disponga de servicio de DHCP en la red dada. El comando dhclient se incluye en todas las distribuciones de &os; desde la versión 3.2. sysinstall sysinstall soporta DHCP. Cuando se configura la interfaz de red la primera pregunta es: ¿Quiere intentar configurar el interfaz mediante DHCP?. Si se responde afirmativamente se ejecutará el comando dhclient y si tiene éxito se procede con los siguientes pasos de configuración rellenandose automáticamente las variables de arranque necesarias para completar la configuración de la red. Existen dos cosas que se deben realizar de tal forma que nuestro sistema utilice la configuración de red mediante DHCP al arrancar: DHCP requirements Asegurarse de que el dispositivo bpf se encuentra compilado en el kernel. Para ello basta añadir device bpf (pseudo-device bpf en los sistemas &os; 4.X) al fichero de configuración del kernel y recompilarlo e instalarlo. Para más información sobre la construcción de núcleos consulte . El dispositivo bpf se encuentra activado por defecto dentro del fichero de configuración del núcleo (GENERIC que encontrará en su sistema &os; de forma que si no se está utilizando un fichero de configuración del núcleo específico (hecho a medida y/o por usted) no es necesario crear uno nuevo y se puede utilizar directamente GENERIC. Para aquellas personas especialmente preocupadas por la seguridad debemos advertir de que el dispositivo bpf es el dispositivo que las aplicaciones de captura de paquetes utilizan para acceder a los mismos (aunque dichas aplicaciones deben ser ejecutadas como root). DHCP requiere la presencia de bpf pero si la seguridad del sistema es más importante que la configuración automática de la red no se recomienda instalar bpf en el núcleo. Editar el fichero /etc/rc.conf para para incluir lo siguiente: ifconfig_fxp0="DHCP" Asegúrese de sustituir fxp0 con el nombre de interfaz que desea que se configure dinámicamente, como se describe en . Si se utiliza una ubicación distinta para el comando dhclient o si se desea añadir opciones adicionales al comando dhclient se puede incluir, adaptándolo a las condiciones particulares de cada usuario, lo siguiente: dhcp_program="/sbin/dhclient" dhcp_flags="" DHCP server El servidor de DHCP (dhcpd) forma parte del port net/isc-dhcp3-server. Este port también contiene la documentación de ISC DHCP. Ficheros DHCP configuration files /etc/dhclient.conf dhclient necesita un fichero de configuración denominado /etc/dhclient.conf. Normalmente este fichero sólo contiene comentarios de forma que las opciones que se definen por defecto son razonablemente inocuas. Este fichero de configuración se describe en la página de manual de &man.dhclient.conf.5;. /sbin/dhclient dhclient se encuentra enlazado de forma estática y reside en /sbin. La página de manual de &man.dhclient.8; proporciona más información sobre el comando dhclient. /sbin/dhclient-script dhclient-script es el script de configuración del cliente de DHCP específico de &os;. Tiene todos los detalles en &man.dhclient-script.8; pero no necesita hacer ninguna modificación en él para que todo funcione correctamente. /var/db/dhclient.leases El cliente de DHCP mantiene una base de datos de préstamos en este fichero que se escribe de forma semejante a un log. En &man.dhclient.leases.5; puede consultar una explicación ligeramente más detallada. Lecturas Recomendadas El protocolo DHCP se describe completamente en RFC 2131. También tiene más información en dhcp.org. Instalación y Configuración de un Servidor de DHCP Qué Temas se Tratan en Esta Sección Esta sección proporciona información sobre cómo configurar un sistema &os; de forma que actúe como un servidor de DHCP utilizando la implementación proporcionada por el Internet Software Consortium (ISC). La parte servidora del paquete proporcionado por el ISC no se instala por defecto en los sistemas &os; pero se puede intalar como port desde net/isc-dhcp3-server. Consulte si necesita saber más sobre la Colección de ports. Instalación del Servidor DHCP DHCP installation Para configurar un sistema &os; como servidor de DHCP debe asegurarse de que el dispositivo &man.bpf.4; está compilado dentro del núcleo. Para ello basta añadir device bpf ( pseudo-device bpf en &os; 4.X) al fichero de configuración del núcleo y reconstruir el mismo. Si necesita saber más sobre el proceso de compilar e instalar el núcleo consulte . El dispositivo bpf ya se encuentra activado en el fichero de configuración GENERIC del núcleo que se facilita con &os; de tal forma que no resulta imprescindible crear un núcleo a medida para ejecutar DHCP. Para aquellas personas especialmente preocupadas por la seguridad debemos advertir de que el dispositivo bpf es el dispositivo que las aplicaciones de captura de paquetes utilizan para acceder a los mismos (aunque dichas aplicaciones deben ser ejecutadas como root). DHCP requiere la presencia de bpf pero si la seguridad del sistema es más importante que la configuración automática de la red no se recomienda instalar bpf en el núcleo. El siguiente paso consiste en editar el fichero de ejemplo dhcpd.conf que se crea al instalar el port net/isc-dhcp3-server. Por defecto el fichero se llama /usr/local/etc/dhcpd.conf.sample, así que se debe copiar este fichero a /usr/local/etc/dhcpd.conf y a continuación realizar todos los cambios sobre este último. Configuración del Servidor de DHCP DHCP dhcpd.conf El fichero dhcpd.conf se compone de un conjunto de declaraciones que hacen referencia a máquinas y a subredes. Esto se entenderá mejor mediante el siguiente ejemplo: option domain-name "ejemplo.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address mailhost.ejemplo.com; } Esta opción especifica el dominio que se proporciona a los clientes y que dichos clientes utilizan como dominio de búsqueda por defecto. Consulte &man.resolv.conf.5; si necesita más información sobre qué significa el dominio de búsqueda. Esta opción especifica la lista de servidores de DNS (seperados por comas) que deben utilizar los clientes. La máscara de red que se proporciona a los clientes. Un cliente puede solicitar un determinado tiempo de vida para el préstamo. En caso contrario el servidor asigna un tiempo de vida por defecto mediante este valor (expresado en segundos). Este es el máximo tiempo que el servidor puede utilizar para realizar préstamos a los clientes. Si un cliente solicita un tiempo mayor como máximo se responderá con el valor aquí configurado, ignorándose la petición de tiempo del cliente. Esta opción especifica si el servidor de DHCP debe intentar actualizar el servidor de DNS cuando se acepta o se libera un préstamo. En la implementación proporcionada por el ISC esta opción es obligatoria. Esto indica qué direcciones IP se pueden utilizar para ser prestadas a los clientes que las soliciten. Las direcciones IP pertenecientes a este rango, incluyendo los extremos, se pueden entregar a los clientes. Declara cúal es la pasarela por defecto que se proporcionará a los clientes. Especifica la dirección MAC de una máquina, de tal forma que el servidor de DHCP pueda identificar a la máquina cuando realice una petición. Especifica que la máquina cliente debería obtener siempre la misma dirección IP. Recuerde que se puede utilizar un nombre de máquina para esto ya que el servidor de DHCP resolverá el nombre por sí mismo antes de devolver la información al cliente. Una vez que se ha acabado de configurar el fichero dhcpd.conf se puede proceder con la ejecución del servidor mediante el siguiente comando: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start Si posteriormente se necesitan realizar cambios en la configuración anterior tenga en cuenta que el envío de la señál SIGHUP a la aplicación dhcpd no provoca que se lea de nuevo la configuración como suele ocurrir en la mayoría de los dæmones. Tendrá que enviar la señal SIGTERM para parar el proceso y posteriormente relanzar el dæmon utilizando el comando anterior. Ficheros DHCP configuration files /usr/local/sbin/dhcpd dhcpd se encuentra enlazado de forma estática y reside en el directorio /usr/local/sbin. La página de manual &man.dhcpd.8; que se instala con el port le proporcionará más información sobre dhcpd. /usr/local/etc/dhcpd.conf dhcpd necesita un fichero de configuración, /usr/local/etc/dhcpd.conf. Este fichero contiene toda la información relevante que se quiere proporcionar a los clientes que la soliciten, junto con información relacionada con el funcionamiento del servidor. Este fichero de configuración se describe en la página del manual &man.dhcpd.conf.5; que instala el port. /var/db/dhcpd.leases El servidor de DHCP mantiene una base de datos de préstamos o alquileres dentro de este fichero, que presenta un formato de fichero de log. La página del manual &man.dhcpd.leases.5; que se instala con el port proporciona una descripción ligeramente más larga. /usr/local/sbin/dhcrelay dhcrelay se utiliza en entornos de red avanzados donde un servidor de DHCP reenvía una petición de un cliente hacia otro servidor de DHCP que se encuentra localizado en otra subred. Si se necesita esta funcionalidad se debe instalar el port net/isc-dhcp3-server. La página del manual &man.dhcrelay.8; proporcionada por el port contiene más detalles sobre esto. Chern Lee Enviado por DNS Resumen BIND FreeBSD utiliza por defecto una versión de BIND (Berkeley Internet Name Domain) que proporciona la implementación más común del protocolo de DNS. DNS es el protocolo a través del cual los nombres de máquinas se asocian con direcciones IP y viceversa. Por ejemplo una consulta preguntando por www.FreeBSD.org recibe una respuesta con la dirección IP del servidor web del Proyecto FreeBSD, mientras que una pregunta sobre ftp.FreeBSD.org recibe como respuesta la dirección IP correspondiente al servidor de FTP. El proceso inverso sucede de una forma similar. Una pregunta relativa a una determinada dirección IP se resuelve al nombre de la máquina que la posee. No se necesita ejecutar un servidor de DNS para poder realizar consultas y búsquedas de DNS. DNS El DNS se coordina de forma distribuida a través de Internet utilizando un sistema en cierta forma complejo de servidores de nombres raíz autorizados y mediante otros servidores de nombres de menor escala que se encargan de replicar la información de dominios individuales con el objetivo de mejorar los tiempos de respuesta de búsquedas reiteradas de la misma información. Este documento hace referencia a la versión estable BIND 8.X. BIND 9.X se puede instalar a través del port net/bind9. El protocolo de DNS se encuentra definido en la RFC1034 y la RFC1035. El Internet Software Consortium (www.isc.org) se encarga de de mantener el software de BIND. Terminología Para comprender este documento se deben definir los siguientes términos: Término Definición DNS directo (Forward DNS) Asociación de nombres de máquinas con direcciones IP Origen Se refiere al dominio cubierto por un determinado fichero de zona named, BIND, servidor de nombres (name server) Nombres típicos que hacen referencia al paquete servidor de nombres de BIND de &os; resolver Resolver Un proceso del sistema que utilizan las aplicaciones para hacer preguntas al servidor de nombres. reverse DNS DNS inverso (Reverse DNS) Lo contrario de lo que realiza el DNS directo; asocia direcciones IP con nombres de máquinas root zone Zona Raíz El comienzo de la jerarquía de zonas de Internet. Todas las zonas surgen a partir de una zona raíz de forma similar a como todos los directorios de un sistema de ficheros se encuentran a partir de un directorio raíz inicial. Zona Un dominio individual, subdominio o porción del DNS que se encuentra administrado por la misma autoridad. zones examples Ejemplos de zonas: . es la zona raíz org. es una zona localizada bajo la zona raíz ejemplo.org es una zona localizada bajo la zona org. foo.ejemplo.org. es un subdominio o una zona ubicada bajo la zona ejemplo.org. 1.2.3.in-addr.arpa es una zona que referencia a a todas las direcciones IP que se encuentran dentro del espacio de direcciones de 3.2.1.*. Como se puede observar la parte más específica de una máquina aparece más a la izquierda. Por ejemplo ejemplo.org es más específico que org. y del mismo modo org. es más específico que la zona raíz. El formato de cada parte del nombre de la máquina es muy similar al formato de un sistema de ficheros: el directorio /dev se encuentra dentro del directorio raíz, y así sucesivamente. Razones para Ejecutar un Servidor de Nombres Los servidores de nombres normalmente son de dos tipos: autoritarios y de cache. Se necesita un servidor de nombres autoritario cuando: uno quiere proporcionar información de DNS al resto del mundo respondiendo con información autoritaria a las consultas recibidas. un dominio, por ejemplo ejemplo.org, está registrado y se necesita añadir nombres de máquinas bajo dicho dominio. un bloque de direcciones IP necesita entradas de DNS inversas (de IP a nombre de máquina). un servidor de nombres de backup, llamado esclavo, debe responder a consultas cuando el servidor primario se encuentre caído o inaccesible. Se necesita un servidor caché cuando: un servidor de DNS local puede responder más rápidamente de lo que se haría si se tuviera que preguntar al servidor de nombres externo. se desea reducir el tráfico global de red (se ha llegado a comprobar que el tráfico de DNS supone un 5% o más del total del tráfico que circula por Internet). Cuando se pregunta por www.FreeBSD.org el resolver normalmente pregunta al servidor de nombres del ISP de nivel superior y se encarga de recibir la respuesta. Si se utiliza un servidor de DNS caché local la pregunta sólo se dirige una única vez hacia el exterior. Dicha pregunta la realiza el servidor caché. Posteriores consultas sobre el mismo nombres son respondidas directamente por este servidor. Cómo Funciona En &os; el dæmon de BIND se denomina named por razones obvias. Fichero Descripción named El dæmon de BIND ndc El programa de control del dæmon /etc/namedb El directorio donde se almacena la información de las zonas de BIND /etc/namedb/named.conf El archivo de configuración del dæmon Los ficheros de zonas se encuentran normalmente bajo el directorio /etc/namedb y contienen la información que proporciona el servidor de nombres al resto de máquinas de Internet. Ejecución de BIND BIND starting Debido a que BIND se instala por defecto la configuración resulta ser bastante sencilla. Para asegurarnos de que el dæmon se ejecuta al inicio del sistema se deben añadir las siguientes modificaciones en /etc/rc.conf: named_enable="YES" Para arrancar el dæmon de forma manual (una vez configurado) &prompt.root; ndc start Ficheros de Configuración BIND configuration files Uso de <command>make-localhost</command> Asegúrese de hacer los siguiente &prompt.root; cd /etc/namedb &prompt.root; sh make-localhost para que se cree el archivo de zona inversa /etc/namedb/localhost.rev de forma apropiada. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Consulte la pĂ¡gina man de named(8) para mĂ¡s detalles. tiene // alguna vez la necesidad de configurar un servidor primario // asegĂºree de que entiende a la perfecciĂ³n los detalles peliagudos // del funcionamiento del DNS. Si hay errores, incluso triviales, // puede sufrir pĂ©rdidas de conectividad ogenerar cantidades ingentes // de trĂ¡fico inĂºtil hacia o desde Interne options { directory "/etc/namedb"; // AdemĂ¡s de con la lĂ¡usula "forwarders" puedeobligar a su servidor // de nombres a que nunca lance bĂºsquedas por su cuenta sino que // se las pida a sus "forwarders". Esto se hace del siguiente modo: // // forward only; // Si su proveedor de acceso tiene a su alcance un servidor DNS // escriba aquĂ­ su direcciĂ³n IP y descomente la lĂ­neaPodrĂ¡ usar // su cachĂ© y por lo tanto reducir el trĂ¡fico DNS de Internet. // /* forwarders { 127.0.0.1; }; */ Tal y como se dice en los comentarios del ejemplo para beneficiarnos de la caché se puede activar forwarders. En circunstancias normales un servidor de nombres busca de forma recursiva a través de Internet tratando de localizar un servidor de nombres que sea capaz de responder una determinada pregunta. Si se activa esta opción por defecto se pasa a preguntar primero al servidor de nombres especificado (servidor o servidores) pudiendo aprovecharse de la información de caché que dicho servidor tuviera disponible. Si el servidor de nivel superior al nuestro se encuentra congestionado puede merecer la pena la activación de esta característica de redirección ya que se puede disminuir la carga de tráfico que dicho servidor tiene que soportar. La dirección IP 127.0.0.1 no funciona aí. Se debe cambiar esta dirección IP por un servidor de nombres válido. /* * Si hay un cortafuegos entre usted y los servidores de * nombres que quiere consultar tendrĂ¡ que descoentar la * siguiente directiva, "query-source". Las versiones * anteriores de BIND siempre hacĂ­an sus consultas a travĂ©s * del puerto 53 pero BIND 8.1 utiliza por defecto un puerto no * privilegiado. */ // query-source address * port 53; /* * Si lo va a ejecutar en un "cajĂ³n de arena" (o "sandbox") * tendrĂ¡ que declarar una uicaciĂ³n diferente para el * fichero de volcado de named. */ // dump-file "s/named_dump.db"; }; // Nota: lo siguiente serĂ¡ incluĂ­do en futuras versiones. /* host { any; } { topology { 127.0.0.0/8; }; }; */ // La configuraciĂ³n de secundarios se explica de modo secillo a // partir de aquĂ­. // // Si activa un servidor de nombres local no olvide incluĂ­r // 127.0.0.1 en su /etc/resolv.conf para que sea ese servidor el // primero al que se consulte. // AsegĂºrese tambiĂ©n de activarlo en /etc/rc.con zone "." { type hint; file "named.root"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "localhost.rev"; }; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" { type master; file "localhost.rev"; }; // Nota: No use las direcciones IP que se muestran aquĂ­, son falsas // y sĂ³lo se usancomo demostraciĂ³n y para una mejor comprensiĂ³n. // // Ejemplo de entradas en la configuraciĂ³n de secundarios. Puede ser // conveniente convertirse en secundario al menos del dominio en cuya // zona estĂ¡ su dominio. Cnsulte con su administrador de red para // que le facilite la direcciĂ³n IP del servidor primario. // // No olvide incluĂ­r la zona del bucle inverso (IN-ADDR.ARPA). (Son // los primeros bytes de la direcciĂ³n IP correspondiente, en orden // inverso, con ".IN-ADDR.ARPA" al final.) // // Antes de configurar una zona primara asegĂºresede haber comprendido // completamente cĂ³mo funcionan DNS y BIND. Hay errores que no son // visibles fĂ¡cilmente. La configuraciĂ³n de un secundario es, por // el contrario, muchĂ­simo mĂ¡s sencilla. // // Nota: No se limite a copiar los ejemplos de mĂ¡s arriba. :-) // Utilice nombres y direcciones reales. // // ADVERTENCIA: FreeBSD ejecuta bind en un sandbok (observe los // parĂ¡meros de named (named_flags) en rc.conf). El directorio que // contiene las zonas secundarias debe tener permisos de escritura // para bind. Le sugerimos la siguiente secuencia de comandos: // // mkdir /etc/namedb/s // chown bind:bind /etc/namedb/s // chmod 750 /etc/namedb/s Si quiere más información sobre cómo ejecutar BIND en un sandbox consulte Ejecución de named en un sandbox. /* zone "ejemplo.com" { type slave; file "s/ejemplo.com.bak"; masters { 192.168.1.1; }; }; zone "0.168.192.in-addr.arpa" { type slave; file "s/0.168.192.in-addr.arpa.bak"; masters { 192.168.1.1; }; }; */ Dentro del fichero named.conf se muestran ejemplos de entradas de esclavo tanto para las zonas directas como para las inversas. Para cada nueva zona administrada se debe crear una entrada de zona dentro del fichero named.conf Por ejemplo la entrada de zona más simple para el dominio ejemplo.org puede ser algo como esto: zone "ejemplo.org" { type master; file "ejemplo.org"; }; Esta zona es una zona maestra ( observe la línea de , y mantiene la información de la zona en /etc/namedb/ejemplo.org tal como se indica en la línea de . zone "ejemplo.org" { type slave; file "ejemplo.org"; }; En el caso del esclavo la información de la zona se transmite desde el servidor de nombres maestro y se almacena en el fichero especificado. Cuando el servidor maestro muere o no puede ser alcanzado el servidor de nombres esclavo puede responder a las peticiones debido a que posee la información de la zona. Ficheros de Zona A continuación se muestra un fichero de una zona maestra para el dominio ejemplo.org, que se encuentra ubicado en /etc/namedb/ejemplo.org: $TTL 3600 example.org. IN SOA ns1.ejemplo.org. admin.ejemplo.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ) ; Minimum TTL ; DNS Servers @ IN NS ns1.ejemplo.org. @ IN NS ns2.ejemplo.org. ; Machine Names localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30 ; Aliases www IN CNAME @ ; MX Record @ IN MX 10 mail.ejemplo.org. Tenga muy en cuenta que todo nombre de máquina que termina en . es tratado como si fuera un nombre de máquina completo mientras que cualquier otro nombre sin el . final se trata como una referencia relativa al dominio de origen de la zona. Por ejemplo www se traduce a www + origen. En nuestro fichero de zona ficticio nuestro origen es ejemplo.org de forma que www se convierte en www.ejemplo.org El formato de un fichero de zona es el siguiente: nombrederegistro IN tipodeentrada valor DNS records Los registros de DNS que más se utilizan son: SOA Comienzo de Zona con Autoridad (Start Of zone Authority) NS Un servidor de nombres con autoridad para una una determinada zona A Una dirección IP de una máquina CNAME El nombre canónico de una máquina para definir un alias MX mail exchanger PTR Un puntero a un nombre de dominio (utilizados para definir el DNS inverso) ejemplo.org. IN SOA ns1.ejemplo.org. admin.ejemplo.org. ( 5 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day ejemplo.org. el nomre de dominio, también el origen para el fichero de zona ns1.ejemplo.org. el servidor de nombres primario/autoritario para esta zona admin.ejemplo.org. la persona responsable de esta zona; observe que la dirección de correo electrónico aparece con la @ sustituida por un punto. (admin@ejemplo.org se escribe admin.ejemplo.org) 5 el número de serie del fichero. Este número se debe incrementar cada vez que se modifique el fichero de zona. Muchos administradores prefieren un formato expresado del siguiente modo aaaammddss. 2001041002 significa (según dicho formato) que el fichero se modificó por última vez el 04/10/2001 y se indica con los dos últimos dígitos (02) que es la segunda vez en el día que se ha modificado el fichero. El número de serie es importante ya que para avisar a los servidores de nombres esclavos de que se ha actualizado la zona. @ IN NS ns1.ejemplo.org. Esta es una entrada de tipo NS. Cada servidor de nombres que contesta de forma autoritaria a las consultas de un determinado dominio debe tener una de estas entradas. El caracter @ se sustituye por ejemplo.org., es decir, se sustituye por el origen. localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30 El registro de tipo A hace referencia a nombres de máquinas . Como puede verse más arriba ns1.ejemplo.org se resuelve a 3.2.1.2. Vemos que se utiliza otra vez el origen @, que significa que ejemplo.org se resuelve a 3.2.1.30. www IN CNAME @ Los registros de nombres canónicos se utilizan normalmente como alias de máquinas. En el ejemplo www es un alias de ejemplo.org (3.2.1.30). CNAMEs se puede utilizar para proporcionar alias de nombres de máquinas, o también para proporcionar un mecanismo de vuelta cíclica (round robin) de un nombre de máquina mapeado a un determinado conjunto de máquinas intercambiables. MX record @ IN MX 10 mail.ejemplo.org. El registro MX indica qué servidores de correo se encargan de recibir correos para esta zona. mail.example.org es el nombre del servidor de correo y 10 significa la prioridad de dicho servidor. Se pueden especificar varios servidores de correo con prioridades de, por ejemplo,3, 2 y 1. Un servidor de correo que intenta entregar correo para el dominio ejemplo.org primero intentará contactar con el servidor especificado en el registro MX de mayor prioridad, después con el siguiente y así sucesivamente hasta que lo logre entregar. Para los ficheros de zona de in-addr.arpa (DNS inverso) se utiliza el mismo formato excepto que se especifican registros PTR en lugar de registros A o CNAME. $TTL 3600 1.2.3.in-addr.arpa. IN SOA ns1.ejemplo.org. admin.ejemplo.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 3600 ) ; Minimum @ IN NS ns1.ejemplo.org. @ IN NS ns2.ejemplo.org. 2 IN PTR ns1.ejemplo.org. 3 IN PTR ns2.ejemplo.org. 10 IN PTR mail.ejemplo.org. 30 IN PTR ejemplo.org. Este fichero proporciona las asociaciones de direcciones IP con nombres de máquinas adecuadas para nuestro dominio ficticio. Servidor de Nombres de Cache BIND caching name server Un servidor de nombres de tipo caché es un servidor de nombres que no es autoritario para ninguna zona. Simplemente realiza consultas por sí mismo y recuerda las respuestas para futuros usos. Para configura uno de estos servidores se configura el servidor de la forma habitual pero se omite la inclusión de zonas. Ejecución de <application>named</application> en un <quote> Sandbox</quote> BIND running in a sandbox chroot Para obtener una mayor seguridad se puede ejecutar &man.named.8; como un usuario sin privilegios y configurarlo mediante &man.chroot.8; dentro del directorio especificado como el directorio del sandbox. Esto hace que cualquier cosa que se encuentre fuera de dicho directorio resulte inaccesible para el dæmon named. En caso de que se comprometiera la seguridad de named esta restricción puede ayudar a limitar el daño sufrido. &os; dispone por defecto de un usuario y un grupo destinado a este uso: bind. Hay quien recomienda que en lugar de configurar named con chroot es mejor configurarlo dentro de &man.jail.8;. En esta sección no se va a explicar esa alternativa. Debido a que named no va a poder acceder a nada que se encuentre fuera del directorio sandbox (y esto incluye cosas tales como bibliotecas compartidas, sockets de log, etc) se debe efectuar una serie de cambios para que named pueda funcionar con normalidad. En la siguiente lista se supone que la ruta del sandbox es /etc/namedb y que no se ha modificado anteriormente dicho directorio. Por favor, ejecute los pasos que se muestran a continuación: Cree todos los directorios que named espera tener a su disposición: &prompt.root; cd /etc/namedb &prompt.root; mkdir -p bin dev etc var/tmp var/run master slave &prompt.root; chown bind:bind slave var/* named sólamente necesita escribir en estos directorios así que eso es todo lo que debemos crear. Reorganizar y crear los archivos de configuración de zona básicos: &prompt.root; cp /etc/localtime etc &prompt.root; mv named.conf etc && ln -sf etc/named.conf &prompt.root; mv named.root master &prompt.root; sh make-localhost && mv localhost.rev localhost-v6.rev master &prompt.root; cat > master/named.localhost $ORIGIN localhost. $TTL 6h @ IN SOA localhost. postmaster.localhost. ( 1 ; serial 3600 ; refresh 1800 ; retry 604800 ; expiration 3600 ) ; minimum IN NS localhost. IN A 127.0.0.1 ^D Esto permite que named pueda escribir al archivo de log la hora correcta a través del &man.syslogd.8; Si está usando una versión de &os; anterior a 4.9-RELEASE se debe construir una copia estáticamente enlazada de named-xfer y copiarla dentro del directorio del sandbox: &prompt.root; cd /usr/src/lib/libisc &prompt.root; make cleandir && make cleandir && make depend && make all &prompt.root; cd /usr/src/lib/libbind &prompt.root; make cleandir && make cleandir && make depend && make all &prompt.root; cd /usr/src/libexec/named-xfer &prompt.root; make cleandir && make cleandir && make depend && make NOSHARED=yes all &prompt.root; cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer Despueés de instalar la versión estática de named-xfer se deben realizar algunas tareas de limpieza para evitar dejar copias de bibliotecas o de programas en nuestros ficheros de fuentes: &prompt.root; cd /usr/src/lib/libisc &prompt.root; make cleandir &prompt.root; cd /usr/src/lib/libbind &prompt.root; make cleandir &prompt.root; cd /usr/src/libexec/named-xfer &prompt.root; make cleandir En algunas ocasiones este paso puede fallar. Si es su caso ejecute lo siguiente: &prompt.root; cd /usr/src && make cleandir && make cleandir y borre su directorio /usr/obj: &prompt.root; rm -fr /usr/obj && mkdir /usr/obj Esto limpia cualquier impureza del árbol de fuentes y si se repiten los pasos anteriores todo debería funcionar. Si se está usando &os; version 4.9-RELEASE o posterior el ejecutable de named-xfer del directorio /usr/libexec ya se encuentra enlazado estáticamente y se puede utilizar &man.cp.1; para copiarlo directamente en nuestro sandbox. Cree el fichero dev/null de tal forma que named pueda verlo y pueda escribir sobre él: &prompt.root; cd /etc/namedb/dev && mknod null c 2 2 &prompt.root; chmod 666 null Enlace simbólicamente /var/run/ndc con /etc/namedb/var/run/ndc: &prompt.root; ln -sf /etc/namedb/var/run/ndc /var/run/ndc Esto simplemente evita el tener que especificar la opción de &man.ndc.8; cada vez que se ejecute. Dado que los contenidos de /var/run se borran al inicio del sistema, si se piensa que esto puede resultar útil, se puede añadir este comando al crontab del usuario root utilizando la opción . Consulte &man.crontab.5; para saber más información sobre esto. Configure &man.syslogd.8; para que cree un socket de log adicional de tal forma que named pueda escribir sobre él. Añada -l /etc/namedb/dev/log a la variable syslogd_flags dentro del fichero /etc/rc.conf. Reorganice la ejecución de las aplicaciones named y chroot para que se ejecuten dentro del sandbox añadiendo lo siguiente al fichero/etc/rc.conf: named_enable="YES" named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf" Recuerde que el fichero de configuración /etc/named.conf tiene una ruta completa que comienza en el directorio del sandbox; por ejemplo, en la línea superior el fichero que aparece es en realidad /etc/namedb/etc/named.conf. El siguiente paso consiste en editar el fichero /etc/namedb/etc/named.conf de tal forma que named pueda conocer qué zonas cargar y donde encontrarlas en disco. A continuación se muestra un ejemplo comentado (cualquier cosa que no se comenta en el ejemplo es porque resulta igual que la configuración del servidor de DNS del caso normal): options { directory "/"; named-xfer "/bin/named-xfer"; version ""; // No muestra la versiĂn de BIND query-source address * port 53; }; // ndc control socket controls { unix "/var/run/ndc" perm 0600 owner 0 group 0; }; // A partir de aquĂ­van las zonas: zone "localhost" IN { type master; file "master/named.localhost"; allow-transfer { localhost; }; notify no; }; zone "0.0.127.in-addr.arpa" IN { type master; file "master/localhost.rev"; allow-transfer { localhost; }; notify no; }; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" { type master; file "master/localhost-v6.rev"; allow-transfer { localhost; }; notify no; }; zone "." IN { type hint; file "master/named.root"; }; zone "private.example.net" in { type master; file "master/private.example.net.db"; allow-transfer { 192.168.10.0/24; }; }; zone "10.168.192.in-addr.arpa" in { type slave; masters { 192.168.10.2; }; file "slave/192.168.10.db"; }; La línea que contiene directory se especifica como /, ya que todos los ficheros que named necesita se encuentran dentro de este directorio (recuerde que esto es equivalente al fichero /etc/namedb de un usuario normal. Especifica la ruta completa para el binario named-xfer binary (desde el marco de referencia de named). Esto resulta necesario ya que por defecto named se compila de tal forma que trata de localizar el comando named-xfer dentro de /usr/libexec. Especifica el nombre del fichero (relativo a la línea (relativo a la línea ) directory anterior) donde named puede encontrar el fichero de zona para esta zona. Especifica el nombre del fichero (relativo a la líena directory anterior) donde named debería escribir una copia del archivo de zona para esta zona después de recuperarla exitosamente desde el servidor maestro. Este es el motivo por el que en las etapas de configuración anteriores necesitábamos cambiar la propiedad del directorio slave al grupo bind. Después de completar los pasos anteriores reinicie el servidor o reinicie &man.syslogd.8; y ejecute &man.named.8; asegurándose de que se utilicen las nuevas opciones especificadas en syslogd_flags y named_flags. En estos momentos deberíamos estar ejecutando una copia de named dentro de un sandbox. Seguridad Aunque BIND es la implementación de DNS más utilizada existe siempre el asunto relacionado con la seguridad. De vez en cuando se encuentran agujeros de seguridad y vulnerabilidades. Es una buena idea suscribirse a CERT y a freebsd-security-notifications para estar al día de los problemas de seguridad relacionados con named. Si surge un problema nunca está de más actualizar los fuentes y recompilar los ejecutables desde dichas fuentes. Lecturas Recomendadas Las páginas del manual de BIND/named: &man.ndc.8; &man.named.8; &man.named.conf.5; Página oficial de ISC Bind Preguntas más frecuentes sobre BIND Libro de O'Reilly "DNS and BIND", cuarta edición RFC1034 - Nombre de Dominio - Conceptos y Características RFC1035 - Nombres de Domninio - Implementación y Especificación Tom Hukins Escrito por NTP NTP Resumen Según pasa el tiempo el reloj de un computador está expuesto a ligeros desplazamientos. NTP (Protocolo de Hora en Red, en inglés Network Time Protocol) es un protocolo que permite asegurar la exactitud de nuestro reloj. Existen varios servicios de internet que confían y se pueden beneficiar de relojes de computadores precisos. Por ejemplo un servidor web puede recibir peticiones de un determinado fichero si ha sido modificado posteriormente a una determinada fecha u hora. Servicios como &man.cron.8; ejecutan comandos en determinados instantes. Si el reloj no se encuentra ajustado estos comandos pueden ejecutarse fuera de la hora prevista. NTP ntpd &os; viene con el servidor NTP &man.ntpd.8; que se puede utilizar para preguntar a otros servidores NTP, de tal forma que podemos ajustar nuestro reloj según la hora de otros servidores e incluso proporcionar servicio de hora nosotros mismos. Elección de los Servidores de Hora Adecuados NTP choosing servers Para sincronizar nuestro reloj necesitamos comunicarnos con uno o más servidores NTP. El administrador de nuestra red o nuestro proveedor de servicios de Internet muy posiblemente hayan configurado algún servidor NTP para estos propósitos. Consulte la documentación de que disponga. Existe una lista de servidores NTP públicamente accesibles que se pueden utilizar para buscar un servidor NTP que se encuentre geográficamente próximo. Asegúrese de que conoce la política de uso de estos servidores públicos ya que en algunos casos es necesario pedir permiso al administrador antes de de poder utilizarlos, principalmente por motivos estadísticos. Le recomendamos seleccionar servidores NTP que no se encuentren conectados entre sí por si alguno de los servidores que use sea inaccesible o su reloj se averíe. &man.ntpd.8; utiliza las respuestas que recibe de otros servidores de una forma inteligente. servidores de una forma inteligente (Tiene a hacer más caso a los más fiables. Configuración de la Máquina NTP configuration Configuración Básica ntpdate Si sólamente deseamos sincronizar nuestro reloj cuando se arranca la máquina se puede utilizar &man.ntpdate.8;. Esto puede ser adecuado en algunas máquinas de escritorio que se reinician frecuentemente y donde la sincronización no suele ser un objetivo prioritario pero normalmente la mayoría de las máquinas deberían ejecutar &man.ntpd.8;. La utilización de &man.ntpdate.8; en tiempo de arranque es también una buena idea incluso para las máquinas que ejecutan &man.ntpd.8;. El programa &man.ntpd.8; modifica el reloj de forma gradual, mientras que &man.ntpdate.8; ajusta directamente el reloj sin importar que tamaño tenga la diferencia de tiempo existente entre la máquina y el servidor de tiempo de referencia. Para activar &man.ntpdate.8; en tiempo de arranque, añada ntpdate_enable="YES" al fichero /etc/rc.conf. También es necesario especificar todos los servidores que deseamos utilizar para realizar el proceso de sincronización y cualquier parámetro que deseemos pasar al comando &man.ntpdate.8; utilizando la variable ntpdate_flags. NTP ntp.conf Configuración General NTP se configura mediante el archivo /etc/ntp.conf utilizando el formato descrito en &man.ntp.conf.5;. A continuación se muestra un sencillo ejemplo: server ntplocal.ejemplo.com prefer server timeserver.ejemplo.org server ntp2a.ejemplo.net driftfile /var/db/ntp.drift La opción server especifica qué servidores se van a utilizar, especificando un servidor por línea. Si se especifica un servidor con el argumento prefer, como en ntplocal.ejemplo.com dicho servidor se prefiere sobre los demás. No obstante la respuesta de su servidor preferido se descartará si difiere sustancialmente de la respuesta recibida por parte del resto de los servidores especificados; en caso contrario sólo se tendrá en cuenta la respuesta del servidor preferido sin importar la información suministrada por el resto. El argumento prefer se utiliza normalmente en servidores NTP altamente precisos, como aquellos que poseen hardware de tiempo específico. La opción driftfile especifica qué fichero se utiliza para almacenar el desplazamiento de la fracuencia de reloj de la máquina. El programa &man.ntpd.8; utiliza este valor para automáticamente compensar el desvío que experimenta de forma natural el reloj de la máquina, permitiendo mantener una precisión acotada incluso cuando se pierde la comunicación con el resto de referencias externas. La opción driftfile especifica qué fichero se utiliza para almacenar la información sobre espuestas anteriores de servidores NTP. Este fichero contiene información útil para la implementación de NTP. No debería ser modificada por ningún otro proceso. Control de Acceso al Servidor NTP Por defecto nuestro servidor de NTP puede ser accedido por cualquier máquina de Internet. La opción restrict se puede utilizar para controlar controlar qué máquinas pueden acceder al servicio. Si queremos denegar el acceso a todas las máquinas existentes basta con añadir la siguiente línea a /etc/ntp.conf: restrict default ignore Si sólo queremos permitir el acceso al servicio de hora a las máquinas de nuestra red y al menos tiempo nos queremos asegurar de que dichos clientes no pueden a su vez configurar la hora del servidor o utilizarse ellos mismos como nuevos servidores de hora basta con añadir lo siguiente en lugar de lo anterior: restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap donde 192.168.1.0 es la dirección IP de nuestra red y 255.255.255.0 es la máscara de red. /etc/ntp.conf puede contener varias opciones de tipo restrict. Para más detalles consulte la sección Soporte de Control de Acceso de &man.ntp.conf.5;. Ejecución del Servidor de NTP Para asegurarnos de que el servidor de NTP se ejecuta en tiempo de arranque se debe añadir la línea xntpd_enable="YES" al fichero /etc/rc.conf. Si deseamos pasar opciones adicionales a &man.ntpd.8; se puede modificar la variable xntpd_flags del fichero /etc/rc.conf. Para ejecutar el servidor sin reiniciar la máquina ejecute ntpd junto con todos aquellos parámetros que haya especificado en la variable de arranque xntpd_flags del fichero /etc/rc.conf. Por ejemplo: &prompt.root; ntpd -p /var/run/ntpd.pid Bajo &os; 5.X se han renombrado algunas opciones del fichero /etc/rc.conf. Se debe reemplazar cualquier aparición xntpd por por ntpd. Utilización de ntpd junto con una Conexión Temporal a Internet El programa &man.ntpd.8; no necesita una conexión permanente a Internet para poder funcionar correctamente. No obstante si la conexión a Internet se encuentra configurada con marcación bajo demanda es una buena idea impedir que el tráfico de NTP lance una marcación automática o que mantenga la conexión viva. Si se utiliza el PPP de entorno de usuario se pueden utilizar las directivas filter dentro del fichero /etc/ppp/ppp.conf para evitar esto. Por ejemplo: set filter dial 0 deny udp src eq 123 # Evita que el trĂ¡fico NTP inice una llamada saliente set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 Evita que el trĂ¡ficoNTP entrante mantenga abierta la conexiĂ³n set filter alive 1 deny udp dst eq 123 Evita que el trĂ¡fico NTP saliente mantenga abierta la conexiĂ³n set filter alive 2 permit 0/0 0/0 Para ás detalles consulte la sección PACKET FILTERING de &man.ppp.8; y los ejemplos que se encuentran en /usr/share/examples/ppp/. Algunos proveedores de acceso a Internet bloquean paquetes que utilizan números de puertos bajos impidiendo que los paquetes de vuelta alcancen nuestra máquina. Información Adicional Hay documentación sobre el servidor NTP en formato HTML en /usr/share/doc/ntp/. Chern Lee Escrito por Traducción de Direcciones de Red Overview natd El dæmon de &os; que se encarga de traducir direcciones de red, más conocido como &man.natd.8;, es un dæmon que acepta paquetes IP, modifica la dirección IP fuente de dichos paquetes y los reinyecta en el flujo de paquetes IP de salida. &man.natd.8; ejecuta este proceso modificando la dirección de origen y el puerto de tal forma que cuando se reciben paquetes de contestación &man.natd.8; es capaz de determinar el destino real y reenviar el paquete a dicho destino. Internet connection sharing IP masquerading El uso más común de NAT es para Compartir la Conexión a Internet. Configuración Debido al pequeño espacio de direccionamiento que se encuentra actualmente disponible en IPv4 y debido también al gran aumento que se está produciendo en cuanto a número de usuarios de líneas de conexión a Internet de alta velocidad como cable o DSL la gente necesita utilizar cada vez más la salida de Compartición de Conexión a Internet. La característica de poder conectar varios computadores a través de una única conexión y una única dirección IP hacen de &man.natd.8; una elección razonable. Cada vez con más frecuencia un usuario típico dispone de una máquina conectada mediante cable o DSL pero desearía utilizar dicha máquina como un router de acceso para el resto de los ordenadores de su red de área local. Para poder hacerlo la máquina (&os; por supuesto) debe configurarse para actuar como pasarela. Debe tener al menos dos tarjetas de red, una para conectarse a la red de área local y la otra para conectarse con el router de acceso a Internet. Todas las máquinas de la LAN se conectan entre sí mediante un hub o un switch. _______ __________ ________ | | | | | | | Hub |-----| Client B |-----| Router |----- Internet |_______| |__________| |________| | ____|______ | | | Cliente A | |___________| Topología de la Red Una configuración como esta se utiliza frecuentemente para compartir el acceso a Internet. Una de las máquinas de la LAN está realmente conectada a Internet. El resto de las máquinas acceden a Internet utilizando como pasarela la máquina inicial. kernel configuration Configuración Se deben añadir las siguientes opciones al fichero de configuración del núcleo: options IPFIREWALL options IPDIVERT Además, según se prefiera, se pueden añadir también las siguientes: options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE Lo que viene a continuación se tiene que definir en /etc/rc.conf: gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="fxp0" natd_flags="" gateway_enable="YES" Configura la máquina para que actúe como router o pasarela de red. Se puede conseguir lo mismo ejecutando sysctl net.inet.ip.forwarding=1. firewall_enable="YES" Activa las reglas de cortafuegos que se encuentran definidas por defecto en /etc/rc.firewall y que entran en funcionamiento en el arranque del sistema. firewall_type="OPEN" Especifica un conjunto de reglas de cortafuegos que permite el acceso a todos los paquetes que se reciban. Consulte /etc/rc.firewall para obtener información sobre el resto de tipos de reglas que se pueden configurar. natd_interface="fxp0" Indica qué interfaz se utiliza para reenviar paquetes (la interfaz que se conecta a Internet). natd_flags="" Define cualesquiera otras opciones que se deseen proporcionar a &man.natd.8; en tiempo de arranque. Si se definen las opciones anteriores, en el arranque del sistema el fichero /etc/rc.conf configurará las variables de tal forma que se ejecutaría el comando natd -interface fxp0. Evidentemente este comando también se puede ejecutar de forma manual. También es posible utilizar un fichero de configuración para &man.natd.8; en caso de que deseemos especificar muchos parámetros de arranque. Tendremos que declarar la ubicación del fichero de configuración mediante la inclusión de lo siguiente en /etc/rc.conf: natd_flags="-f /etc/natd.conf" El fichero /etc/natd.conf debe contener una lista de opciones de configuración una opción por línea. Por ejemplo, en el caso que se comenta en la siguiente sección se utilizaría un fichero de configuración con la siguiente información: redirect_port tcp 192.168.0.2:6667 6667 redirect_port tcp 192.168.0.3:80 80 Para obtener más información sobre el fichero de configuración se puede consultar la opción que se describe en la página del manual de &man.natd.8;. Cada máquina (y cada interfaz) que se encuentra conectada a la LAN debe poseer una dirección IP perteneciente al espacio de direcciones IP privado tal y como se define en RFC 1918 y debe poseer como pasarela por defecto la dirección IP de la interfaz interna (la interfaz que se conecta a la LAN) de la máquina que ejecuta natd. Por ejemplo los clientes A y B se encuentran en la LAN utilizando las direcciones IP Â192.168.0.2 y 192.168.0.3, respectivamente. La máquina que ejecuta natd posee la dirección IP 192.168.0.1 en la interfaz que se conecta a la LAN. El router por defecto tanto de A omo de B se establece al valor 192.168.0.1. La interfaz externa de la máquina que ejecuta natd, la interfaz que se conecta con Internet, no necesita de ninguna especial en relación con el tema que estamos tratando en esta sección. Redirección de Puertos El incoveniente que se presenta con la utilización de &man.natd.8; es que los clientes de la LAN no son accesibles desde Internet. Dichos clientes pueden establecer conexiones con el exterior pero no pueden recibir intentos de conexión desde pueden recibir intentos de conexion desde Internet. Esto supone un gran problema cuando se quieren ejecutar servicios de acceso global en una o varias máquinas de la red LAN. Una forma sencilla de solucionar parcialmente este problemma consiste en redirigir determinados puertos en el servidor natd hacia determinadas máquinas de la LAN. Supongamos por ejemplo que en A se ejecuta un servidor de IRC y que en B se ejecuta un servidor web. Para que funcione lo que hemos comentado anteriormente se tienen que redirigir las conexiones recibidas en los puertos 6667 (IRC) y 80 (web) a dichas máquinas, respectivamente. Se debe pasar la opción a &man.natd.8; con los valores apropiados. La sintaxis es como sigue: -redirect_port proto IPdestino:PUERTOdestino[-PUERTOdestino] [aliasIP:]aliasPUERTO[-aliasPUERTO] [IPremota[:PUERTOremoto[-PUERTOremoto]]] Continuando con el ejemplo anterior los valores serían: -redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80 Esto redirigirá los puertos tcp adecuados a las máquinas situadas en la LAN. La opción se puede utilizar para indicar rangos de puertos en vez de puertos individuales. Por ejemplo, tcp 192.168.0.2:2000-3000 2000-3000 redirige todas las conexiones recibidas desde los puertos 2000 al 3000 a los puertos puertos 2000 a 3000 de la máquina A. Estas opciones se pueden utilizar cuando se ejecute directamente el comando &man.natd.8; se pueden situar en la variable natd_flags="" en /etc/rc.conf y también se pueden pasar mediante un archivo de configuración. Para obtener más información sobre opciones de configuración por favor consulte &man.natd.8; Redirección de Direcciones address redirection La redirección de direcciones es una característica útil si se dispone de varias direcciones IP pero todas ellas se ubican en una única máquina. Gracias a esto &man.natd.8; puede asignar a cada cliente de la red LAN su propia dirección IP externa. &man.natd.8; reescribe los paquetes que salen de la red LAN con la dirección IP externa adecuada y redirige todo el tráfico recibido de vuelta al cliente en función de la dirección IP de destino: esto se conoce como NAT estático. Por ejemplo las direcciones IP 128.1.1.1, 128.1.1.2 y 128.1.1.3 pertenecen al router natd. 128.1.1.1 se puede utilizar como la dirección IP externa del natd, mientras que 128.1.1.2 y 128.1.1.3 se redirigen a los clientes A y B, respectivamente. La sintaxis de la opción es la siguiente: -redirect_address IPlocal IPpública IPlocal La dirección IP interna del cliente de la LAN. IPpública La dirección IP externa que se corresponde con un determinado cliente de la LAN. En nuestro ejemplo esta opción se especificaría de la siguiente forma: -redirect_address 192.168.0.2 128.1.1.2 -redirect_address 192.168.0.3 128.1.1.3 De forma semejante a la opción estos argumentos se pueden especificar directamente sobre la variable natd_flags="" del fichero /etc/rc.conf o también se pueden pasar vía archivo de configuración de natd. Si se utiliza redirección de direcciones ya no es necesario utilizar redirección de puertos ya que todos los paquetes que se reciben en una determinada dirección IP son redirigidos a la máquina especificada. Las direcciones IP externas de la máquina que ejecuta natd se deben activar y deben formar parte de un alias configurado sobre la interfaz externa que se conecta a Internet. Consulte &man.rc.conf.5; para aprender a hacerlo. Chern Lee Escrito por El <quote>Super Servidor</quote> <application> inetd</application> Resumen &man.inetd.8; se conoce como el Super Servidor de Internet debido a que gestiona las conexiones de varios dæmones. Los dæmones son programas que proporcionan servicios de red. inetd actúa como un servidor de servidor de gestión de otros dæmones. Cuando &man.inetd.8; recibe una conexión se determina qué dæmon debería responder a dicha conexión, se lanza un proceso que ejecuta dicho dæmon y se le entrega el socket. La ejecución de una única instancia de inetd reduce la carga del sistema en comparación con lo que significaría ejecutar cada uno de los dæmones que gestiona de forma individual. inetd se utiliza principalmente para lanzar procesos que albergan a otros dæmones pero inetd también se utiliza para gestionar determinados protocolos triviales como chargen, auth y daytime. Esta sección trata la configuración básica de inetd a través de sus opciones de línea de comandos y utilizando su fichero de configuración, denominado /etc/inetd.conf. Configuraciones inetd se inicializa a través del fichero /etc/rc.conf en tiempo de arranque. La opción inetd_enable posee el valor NO por defecto, pero a menudo la aplicación sysinstall la activa cuando se utiliza la configuración de perfil de seguridad medio. Estableciendo inetd_enable="YES" o inetd_enable="NO" dentro de /etc/rc.conf se puede activar o desactivar la la ejecución de inetd en el arranque del sistema. Se pueden además aplicar distintas opciones de línea de comandos mediante la opción inetd_flags. Opciones de Línea de Comandos sinopsis de inetd: -d Activa la depuración. -l Activa el logging de las conexiones efectuadas con écute. -w Activa el recubrimiento de TCP para servicios externos (activado por defecto). -W Activa el recubrimiento de TCP para los servicios internos, ejecutados directamente por el dæmon inetd (activado por defecto). -c máximo Especifica el máximo número de invocaciones simultáneas de cada servicio; el valor por defecto es ilimitado. Se puede sobreescribir para cada servicio utilizando la opción . -C tasa Especifica el máximo número de veces que se puede llamar a un servicio desde un dirección IP determinada por minuto; el valor por defecto es ilimitado. Se puede redefinir para cada servicio utilizando la opción . -R tasa Especifica el máximo número de veces que se puede invocar un servicio en un minuto; el valor por defecto es 256. Un valor de 0 permite un número ilimitado de llamadas. -a Especifica una dirección IP a la cual se asocia y sobre la cual se queda esperando recibir conexiones. Puede declararse también un nombre de máquina, en cuyo caso se utilizará la dirección (o direcciones si hay más de una) IPv4 o IPv6 que estén tras dicho nombre. Normalmente se usa un nombre de máquina cuando inetd se ejecuta dentro de un &man.jail.8;, en cuyo caso el nombre de máquina se corresponde con el entorno &man.jail.8;. Cuando se desea asociarse tanto a direcciones IPv4 como a direcciones IPv6 y se utiliza un nombre de máquina se necesita una entrada para cada protocolo (IPv4 o IPv6) para cada servicio que se active a través de /etc/inetd.conf. Por ejemplo un servicio basado en TCP necesitaría dos entradas, una utilizando tcp4 para el protocolo IPv4 y otra con tcp6 para las conexiones a través del procolo de red IPv6. -p Especifica un fichero alternativo en el cual se guarda el ID del proceso. Estas opciones se pueden declarar dentro de las variables inetd_flags del fichero /etc/rc.conf. Por defecto inetd_flags tiene el valor -wW, lo que activa el recubrimiento de TCP para los servicios internos y externos de inetd. Los usuarios inexpertos no suelen introducir estos parámetros y por ello ni siquiera necesitan especificarse dentro de /etc/rc.conf. Un servicio externo es un dæmon que se ejecuta fuera de inetd y que se lanza cuando se recibe un intento de conexión. Un servicio interno es un servicio que inetd puede servir directamente sin necesidad de lanzar nuevos procesos. <filename>inetd.conf</filename> La configuración de inetd se realiza a través del ficherode configuración /etc/inetd.conf. Cuando se realiza una modificación en el fichero /etc/inetd.conf se debe obligar a inetd a releer dicho fichero de configuración, lo cual se realiza enviando una señal HANGUP al proceso inetd como se muestra a continuación: Envío de una señal de tipo HANGUP a <application>inetd</application> &prompt.root; kill -HUP `cat /var/run/inetd.pid` Cada línea del fichero de configuración especifica un dæmon individual. Los comentarios se preceden por el caracter #. El formato del fichero de configuración /etc/inetd.conf es el siguiente: service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] user[:group][/login-class] server-program server-program-arguments A continuación se muestra una entrada de ejemplo para el dæmon ftpd para IPv4: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l service-name Este es el nombre del servicio que proporciona un determinado dæmon. Se debe corresponder con el nombre del nombre de servicio que se declara en el fichero /etc/services. Este fichero determina sobre qué puerto debe ponerse a escuchar inetd. Si se crea un nuevo servicio se debe especificar primero en /etc/services. socket-type Puede ser stream, dgram, raw o seqpacket. stream se debe utilizar obligatoriamente para dæmones orientados a conexión (dæmones TCP) mientras que dgram se utiliza en dæmones basados en el protocolo de transporte UDP. protocol Uno de los siguientes: Protocolo Explicación tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 TCP IPv4 e IPv6 al mismo tiempo udp46 UDP IPv4 e IPv6 al mismo tiempo {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] indica si el dæmon puede gestionar su propio socket o no. Los sockets de tipo deben utilizar obigatoriamente la opción mientras que los dæmones basados en sockets de tipo stream, los cuales se implementan normalmente mediante hilos, debería utilizar la opción . La opción normalmente entrega varios sockets a un único dæmon, mientras que la opción lanza un dæmon hijo por cada nuevo socket. El número máximo de dæmones hijo que puede lanzar inetd se puede especificar mediante la opción . Si se necesita por ejemplo un límite de diez instancias para un dæmon en particular se puede especificar el valor 10 justo después de la opción . Además de se puede activar otra opción para limitar en número máximo de conexiones que se aceptan desde un determinado lugar mediante la opción . Esta opción hace justo lo que su nombre indica. Un valor de, por ejemplo, diez en esta opción limitaría cualquier máquina remota a un máximo de diez intentos de conexión por minuto. Esto resulta útil para prevenir un consumo incontrolado de recursos y ataques de Denegación de Servicio (Denial of Service o DoS) sobre nuestra máquina. Cuando se especifica este campo las opciones o son obligatorias y son opcionales. Un dæmon de tipo stream sin la opción y sin la opción simplemente especificaría la opción nowait. El mismo dæmon con el límite máximo de diez dæmones hijos sería: nowait/10. La misma configuración con un límite de veinte conexiones por dirección IP por minuto y un máximo total de diez dæmones hijos sería: nowait/10/20. Todas estas opciones son utilizadas por el dæmon fingerd que se muestra a continuación a modo de ejemplo: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s user Este es el nombre de usuario con el que debería ejecutarse un determinado dæmon. Normalmente los dæmones se suelen ejectar con permisos de root. Por motivos de seguridad, resulta bastante común encontrarse con algunos servidores que se ejecutan bajo el usuario daemon o incluso por el usuario menos privilegiado de todos que es el usuario nobody. server-program La ruta completa de la localización del dæmon que se quiere ejecutar cuando se recibe un intento de conexión. Si el dæmon es un servicio proporcionado por el propio inetd se debe utilizar la opcion en su lugar. server-program-arguments Esto funciona en conjunción con , ya que especifica los argumentos, comenzando por argv[0], que se pasan al dæmon cuando se le invoca. Si la línea de comandos es mydaemon -d, midæmon -d debería ser el valor de la opción . Si el dæmon es un servicio interno se debe utilizar la utilizar la opción en lugar de la que estamos comentando. Security Dependiendo del perfil de seguridad establecido cuando se instaló el sistema &os; varios dæmones de inetd pueden estar desactivados o activados. Si no se necesita un dæmon determinado, no lo active. Especifique un # al comienzo de la línea del dæmon que quiere desactivar y envíe una señal hangup a inetd. No se aconseja ejecutar algunos dæmones determinados (un caso típico es fingerd) porque pueden proporcionar información valiosa para un atacante. Algunos dæmones no presentan ninguna característica de seguridad y poseen grandes o incluso no poseen tiempos de expiración para los intentos de conexión. Esto permite que un atacante sature los recursos de nuestra máquina realizando intentos de conexión a una tasa relativamente baja contra uno de estos ingenuos dæmones. Pueder ser una buena idea protegerse de esto utilizando las opciones y para este tipo de dæmones. El recubrimiento de TCP está activado por defecto tal y como ya se ha comentado anteriormente. Consulte la página del manual de &man.hosts.access.5; para obtener más información sobre cómo aplicar restricciones relacionadas con TCP a los dæmones invocados por inetd. Varios daytime, time, echo, discard, chargen y auth son servicios que inetd proporciona de forma interna y propia. El servicio auth proporciona servicios de identificación a través de la red (ident, identd) y se puede configurar hasta en cierto grado. Consulte la página del manual de &man.inetd.8; si quiere conocer todos los detalles. Línea IP Paralela (PLIP) PLIP Parallel Line IP PLIP nos permite configurar TCP/IP a través del puerto paralelo. Es útil para conectar máquinas que no poseen tarjetas de red, o para instalar &os; en ciertos viejos modelos de portátiles. En esta sección se explica lo siguiente: Construcción de un cable paralelo (laplink). Conexión de dos computadores utilizando PLIP. Construcción de un Cable Paralelo Se puede comprar un cable paralelo en cualquier tienda de componentes informáticos. No obstante si no es posible comprarlo o simplemente queremos saber cómo hacerlo nosotros mismos, en la siguiente tabla mostramos como hacer un cable de impresora paralelo. Cableado de una Conexión de Cable Paralelo para Redes Nombre-A Extremo-A Extremo-B Descr. Post/Bit DATA0 -ERROR 2 15 15 2 Data 0/0x01 1/0x08 DATA1 +SLCT 3 13 13 3 Data 0/0x02 1/0x10 DATA2 +PE 4 12 12 4 Data 0/0x04 1/0x20 DATA3 -ACK 5 10 10 5 Strobe 0/0x08 1/0x40 DATA4 BUSY 6 11 11 6 Data 0/0x10 1/0x80 GND 18-25 18-25 GND -
Configuración de PLIP En primer lugar debemos tener en nuesras manos un cable laplink. A continuación se debe comprobar que ambos sistemas poseen núcleos con soporte para el controlador &man.lpt.4;: &prompt.root; grep lp /var/run/dmesg.boot lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port El puerto paralelo debe ser un puerto controlado por alguna irq. En &os; 4.X se debería tener un línea como la siguiente en el fichero de configuración del kernel: device ppc0 at isa? irq 7 En &os; 5.X el fichero /boot/device.hints debe contener las siguientes líneas: hint.ppc.0.at="isa" hint.ppc.0.irq="7" A continuación se debe comprobar que el fichero de configuración del núcleo posee una línea con device plip o también puede comprobar si se ha cargado el módulo del núcleo plip.ko. Tanto en un caso como en el otro, cuando se ejecute &man.ifconfig.8; debería aparecer el interfaz de red paralelo. En &os; 4.X se muestra algo parecido a lo siguiente: &prompt.root; ifconfig lp0 lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 y en &os; 5.X: &prompt.root; ifconfig plip0 plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 El nombre del dispositivo utilizado para la interfaz paralela es distinto en &os; 4.X (lpX) y en &os; 5.X (plipX). Enchufe el cable laplink en los interfaces de ambos computadores. Configure los parámetros de la interfaz de red en ambas máquinas como root. Por ejemplo, si queremos conectar la máquina host1 ejecutando &os; 4.X con la máquina host2 que ejecuta &os; 5.X: host1 <-----> host2 Dirección IP 10.0.0.1 10.0.0.2 Configure la interfaz de host1 así: &prompt.root; ifconfig lp0 10.0.0.1 10.0.0.2 Configure la interfaz de host2 por medio de: &prompt.root; ifconfig plip0 10.0.0.2 10.0.0.1 Tras esto debería disponerse de una conexión totalmente funcional. Por favor, consulte &man.lp.4; y &man.lpt.4; si quiere saber más. Además se debe añadir ambas máquinas al fichero /etc/hosts: 127.0.0.1 localhost.mi.dominio localhost 10.0.0.1 host1.mi.dominio host1 10.0.0.2 host2.mi.dominio Para comprobar que efectivamente la conexión funciona se puede probar a hacer un ping desde cada máquina. Por ejemplo en la máquina host1: &prompt.root; ifconfig lp0 lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 &prompt.root; netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire host2 host1 UH 0 0 lp0 &prompt.root; ping -c 4 host2 PING host2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms --- host2 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms Aaron Kaplan Texto original de Tom Rhodes Reestructurado y ampliado por IPv6 IPv6 (también conocido como IPng o IP de nueva generación) es la nueva versión del conocido protocolo de red IP, tambíen llamado IPv4. Como sucede con el resto de los sistemas *BSD &os; proporciona una implementación de referencia que desarrolla el proyecto japonés KAME. &os; dispone de todo lo necesario para experimentar con el nuevo protocolo de red. Esta sección se centra en conseguir configurar y ejecutar correctamente el protocolo IPv6. Al comienzo de los años 90 la gente comenzó a preocuparse por el rápido consumo del espacio de direcciones de IPv4. Dada la expansión actual de Internet existen dos preocupaciones principales: Agotamiento de las direcciones disponibles. Actualmente no se trata del principal problema debido al uso generalizado del del espacio de direccionamiento privado (10.0.0.0/8, 192.168.0.0/24, etc.) junto con NAT. El número de entradas de las tablas de rutas comenzaba a ser imposible de manejar. Esto todavia es un problema prioritario. IPv6 trata de resolver estos problemas y algunos más de la siguiente forma: IPv6 posee un espacio de direccionamiento de 128 bits. En otras palabras, en teoría existen 340,282,366,920,938,463,463,374,607,431,768,211,456 direcciones disponibles. Esto significa que existen aproximadamente 6.67 * 10^27 direcciones IPv6 por metro cuadrado disponibles para todo el planeta Tierra. Los routers sólo almacenan direcciones de red agregadas así que se reduce el número de entradas para cada tabla de rutas a un promedio de 8192. Existen además muchas otras caracterísiticas interesantes que IPv6 proporciona, como: Autoconfiguración de direcciones (RFC2462) Direcciones anycast (una-de-varias) Soporte de direcciones multicast predefinido IPsec (Seguridad en IP) Estructura de la cabecera simplificada IP móvil Mecanismos de traducción de IPv6 a IPv4 (y viceversa) Si quiere saber más sobre IPv6 le recomendamos que consulte: Resumen de IPv6 en playground.sun.com KAME.net 6bone.net Conceptos Básicos sobre las Direcciones IPv6 Existen varios tipos distintos de direcciones IPv6: Unicast, Anycast y Multicast. Las direcciones unicast son direcciones bien conocidas. Un paquete que se envía a una dirección unicast deberín llega a la interfaz identificada por dicha dirección. Las direcciones anycast son sintácticamente indistinguibles de las direcciones unicast pero sirven para identificar a un conjunto de interfaces. Un paquete destinado a una dirección anycast llega a la interfaz más cercana (en términos de métrica de routers). Las direcciones anycast sólo se pueden utilizar en routers. Las direcciones multicast identifican un grupo de interfaces. Un paquete destinado a una dirección multicast llega a todos los los interfaces que se encuentran agrupados bajo dicha dirección. Las direcciones IPv4 de tipo broadcast (normalmente xxx.xxx.xxx.255) se expresan en IPv6 mediante direcciones multicast. Direcciones IPv6 Reservadas Dirección IPv6 Longitud del Prefijo (Bits) Descripción Notas :: 128 bits sin especificar como 0.0.0.0 en Pv4 ::1 128 bits dirección de bucle local (loopback) como las 127.0.0.1 en IPv4 ::00:xx:xx:xx:xx 96 bits direcciónes IPv6 compatibles con IPv4 Los 32 bits más bajos contienen una dirección IPv4. También se denominan direcciones empotradas. ::ff:xx:xx:xx:xx 96 bits direcciones IPv6 mapeadas a IPv4 Los 32 bits más bajos contienen una dirección IPv4. Se usan para representar direcciones IPv4 mediante direcciones IPv6. fe80:: - feb:: 10 bits direcciones link-local equivalentes a la dirección de loopback de IPv4 fec0:: - fef:: 10 bits direcciones site-local Equivalentes al direccionamiento privado de IPv4 ff:: 8 bits multicast   001 (base 2) 3 bits direcciones unicast globales Todas las direcciones IPv6 globales se asignan a partir de este espacio. Los primeros tres bits siempre son 001.
Lectura de las Direcciones IPv6 La forma canónica que se utiliza para representar direcciones IPv6 es: x:x:x:x:x:x:x:x, donde cada x se considera un valor hexadecimal de 16 Bit. Por ejemplo FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 A menudo una dirección posee alguna subcadena de varios ceros consecutivos de forma que se puede abreviar dicha cadena (sólo una vez, para evitar ambigúedades) mediante ::. También se pueden omitir los ceros a la ceros a la izquierda dentro de un valor x. Por ejemplo fe80::1 se corresponde con la forma canónica fe80:0000:0000:0000:0000:0000:0000:0001. Una tercera forma de escribir direciones IPv6 es utilizando la ya tradicional notación decimal de IPv4 pero sólamente para los 32 bits más bajos de la dirección IPv6. Por ejemplo 2002::10.0.0.1 se correspondería con la representation hexadecimal canónica 2002:0000:0000:0000:0000:0000:0a00:0001 la cual es equivalente también a escribir 2002::a00:1. A estas alturas el lector debería ser capaz de comprender lo siguiente: &prompt.root; ifconfig rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1 ether 00:00:21:03:08:e1 media: Ethernet autoselect (100baseTX ) status: active fe80::200:21ff:fe03:8e1%rl0 es una dirección link-local autoconfigurada. Se construye a partir de la dirección MAC de la tarjeta de red. Si quiere saber más sobre la estructura de las direcciones IPv6 puede consultar RFC3513. Establecimiento de Conectividad Actualmente existen cuatro formas distintas de conectarse con otras máquinas y redes IPv6: Unirse a la red experimental denominada 6bone Obtener una red IPv6 a través de nuestro proveedor de acceso a Internet. Consulte a su proveedor de servicios para para más información. Encapsulación de IPv6 sobre IPv4 (RFC3068) Utilización del port net/freenet6 si se dispone de una de una conexión de marcación por modem. Vamos a explicar cómo conectarse al 6bone ya que parece ser la forma más utilizada en la actualidad. En primer lugar se recomienda consultar el sitio web de 6bone para saber cuál es la conexión del 6bone (físicamente) más próxima. Se debe escribir a la persona responsable de ese nodo y con un poco de suerte dicha persona responderá con con un conjunto de instrucciones y pasos a seguir para establecer la la conexión con ellos y a través de ellos con el resto de los nodos IPv6 que forman parte del 6bone. Normalmente esta conexión se establece usando túneles GRE (gif). Veamos un ejemplo típico de configuración de un de un túnel &man.gif.4;: &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 &prompt.root; ifconfig gif0 tunnel MI_DIRECCIÓn_IPV4 SU_DIRECCIÓn_IPV4 &prompt.root; ifconfig gif0 inet6 alias DIRECCIÓn_DE-SALIDA_IPv6_DEL_TÚNEL_ASIGNADO Sustituya las palabras en mayúsculas por la información recibida del nodo 6bone al que nos queremos conectar. El comando anterior establece el túnel. Compruebe que el túnel funciona correctamente mediante &man.ping.8;. Haga un &man.ping6.8; a ff02::1%gif0. Deberíamos recibir recibir dos respuestas. Para que el lector no se quede pensando en el significado significado de la dirección ff02:1%gif0 le podemos decir que se trata de de una dirección IPv6 multicast de tipo link-local. %gif0 no forma parte del protocolo IPv6 como tal sino que se trata de un detalle de implementación relacionado con las direcciones link-local y se añade para especificar la interfaz de salida que se debe utilizar para enviar los paquetes de &man.ping6.8;. Como estamos haciendo ping a una dirección multicast a la que se unen todos los interfaces pertenecientes al mismo enlace debería responder al ping tanto nuestro propio interfaz como el interfaz remoto. A continuación se configura la ruta por defecto hacia nuestro enlace 6bone; observe que es muy semejante a lo que hay que hacer en IPv4: &prompt.root; route add -inet6 default -interface gif0 &prompt.root; ping6 -n MI_UPLINK &prompt.root; traceroute6 www.jp.FreeBSD.org (3ffe:505:2008:1:2a0:24ff:fe57:e561) from 3ffe:8060:100::40:2, 30 hops max, 12 byte packets 1 atnet-meta6 14.147 ms 15.499 ms 24.319 ms 2 6bone-gw2-ATNET-NT.ipv6.tilab.com 103.408 ms 95.072 ms * 3 3ffe:1831:0:ffff::4 138.645 ms 134.437 ms 144.257 ms 4 3ffe:1810:0:6:290:27ff:fe79:7677 282.975 ms 278.666 ms 292.811 ms 5 3ffe:1800:0:ff00::4 400.131 ms 396.324 ms 394.769 ms 6 3ffe:1800:0:3:290:27ff:fe14:cdee 394.712 ms 397.19 ms 394.102 ms Esta captura de pantalla variará dependiendo de la localización de la máquina. Tras seguir estos pasos deberíamos poder alcanzar el sitio IPv6 de www.kame.net y ver la tortuga bailarina, que es una imagen animada que sólo se muestra cuando se accede al servidor web utilizando el protocolo IPv6 (para ellos se encesita utilizar un navegador web que soporte IPv6, IPv6, por ejemplo www/mozilla o Konqueror, que forma parte de x11/kdebase3, o también con www/epiphany. DNS en el Mundo IPv6 Existen dos tipos de registros de DNS para IPv6. No obstante el IETF ha declarado los registros A6 y CNAME como registros para uso experimental. Los registros de tipo AAAA son los únicos estandar a día de hoy. La utilización de registros de tipo AAAA es muy sencilla. Se asocia el nombre de la máquina con la dirección IPv6 de la siguiente forma: NOMBREDEMIMÁQUINA AAAA MIDIRECCIÓNIPv6 De igual forma que en IPv4 se utilizan los registros de tipo A. En caso de no poder administrar su propia zona de DNS se puede pedir esta configuración a su proveedor de servicios. Las versiones actuales de bind (versiones 8.3 y 9) y el port dns/djbdns (con el parche de IPv6 correspondiente) soportan los registros de tipo AAAA. Harti Brandt Escrito por ATM en &os; 5.X Configuración de IP clásico sobre ATM (PVCs) IP clásico sobre ATM (CLIP) es el método más sencillo de utilizar ATM con IP. Se puede utilizar con conexiones conmutadas (SVC) y con conexiones permanentes (PVCs). En esta sección se describe cómo configurar una red basada en PVCs. Configuraciones en Red Mallada Completa El primer método para configurar CLIP con PVCs consiste en conectar unas máquinas con otras mediante circuitos PVC dedicados. Aunque la configuración parece sencilla llega a resultar imposible de manejar cuando se posee un número grande de máquinas. El ejemplo que se muestra a continuación supone que nuestra red posee cuatro máquinas y que cada una se conecta a la red ATM mediante una tarjeta de red ATM. El primer paso consiste en planificar las direcciones IP y las conexiones ATM que se van a configurar en las máquinas. Máquina Dirección IP hostA 192.168.173.1 hostB 192.168.173.2 hostC 192.168.173.3 hostD 192.168.173.4 Para construir una red completamente mallada necesitamos una conexión ATM entre cada par de máquinas: Máquinas Pareja VPI.VCI hostA - hostB 0.100 hostA - hostC 0.101 hostA - hostD 0.102 hostB - hostC 0.103 hostB - hostD 0.104 hostC - hostD 0.105 Los valores VPI y VCI en cada extremo de la conexión pueden ser diferentes pero por simplicidad suponemos que son iguales. A continuación necesitamos configurar las interfaces ATM en cada máquina: hostA&prompt.root; ifconfig hatm0 192.168.173.1 up hostB&prompt.root; ifconfig hatm0 192.168.173.2 up hostC&prompt.root; ifconfig hatm0 192.168.173.3 up hostD&prompt.root; ifconfig hatm0 192.168.173.4 up Suponiendo que la interfaz ATM es hatm0 en todas las máquinas. Ahora necesitamos configurar los PVCs en las máquinas (suponemos que ya se han configurado de forma correcta en el switch ATM, para lo cual puede ser necesario consultar el manual del switch). hostA&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 100 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 101 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 102 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 100 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 103 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 104 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 101 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 103 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 105 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 102 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 104 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 105 llc/snap ubr Por supuesto que se pueden utilizar otras especificaciones de tráfico siempre y cuando las tarjetas de red las soporten. En este caso la especificación del tipo de tráfico se completa con los parámetros del tráfico. Puede acceder a la ayuda de &man.atmconfig.8; así: &prompt.root; atmconfig help natm add y por supuesto en la página de manual de &man.atmconfig.8;. Se puede crear la misma configuración utilizando el fichero /etc/rc.conf. Para la máquina hostA sería algo así: network_interfaces="lo0 hatm0" ifconfig_hatm0="inet 192.168.173.1 up" natm_static_routes="hostB hostC hostD" route_hostB="192.168.173.2 hatm0 0 100 llc/snap ubr" route_hostC="192.168.173.3 hatm0 0 101 llc/snap ubr" route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr" El estado de todas las rutas CLIP se puede obtener en todo momento con: hostA&prompt.root; atmconfig natm show diff --git a/es_ES.ISO8859-1/books/handbook/security/chapter.sgml b/es_ES.ISO8859-1/books/handbook/security/chapter.sgml index ce65008d95..6449c90059 100755 --- a/es_ES.ISO8859-1/books/handbook/security/chapter.sgml +++ b/es_ES.ISO8859-1/books/handbook/security/chapter.sgml @@ -1,351 +1,5511 @@ Matthew Dillon Gran parte de este capítulo ha sido - tomado del manual de security(7) por + tomado del manual de security(7) por - + Seguridad seguridad - Sinópsis - - Este capítulo proveera una introducción básica - a los conceptos de seguridad de sistema y algunos temas avanzados en - &os;. Muchos de los temas se pueden aplicar a la seguridad del sistema - asi como también a la de Internet en general. Internet ya no es - un lugar amistoso en el cual cada quién desea ser - un buen vecino. Asegurar su sistema es imprecindible para proteger sus - datos, característica intelectual, tiempo, y mucho mas de las + Sinopsis + + Este capítulo brindará una introducción + básica a los conceptos de seguridad de sistema y algunos temas + avanzados en &os;. Muchos de los temas cubiertos aquí + pueden aplicarse a la seguridad del sistema asi como también + a la de Internet en general. Internet ya no es un lugar + amistoso en el cual cada quién desea ser un + buen vecino. Asegurar su sistema es imperativo para proteger sus + datos, propiedad intelectual, tiempo, y mucho más de las manos de hackers y similares. - FreeBSD proporciona un arcenal de utilidades y mecanisimos para + FreeBSD proporciona un arsenal de utilidades y mecanismos para asegurar la integridad y la seguridad de su sistema y red. Después de leer este capítulo, usted sabrá: - Conceptos básicos de seguridad, con respecto a &os;. + Conceptos básicos de seguridad, con respecto a &os;. - Sobre algunos mecanisimos de encriptación disponibles en - &os;, como DES y MD5. + Acerca de varios mecanismos de encriptación disponibles + en &os;, como DES y MD5. + - Como instalar KerberosIV en versiones - anteriores a 5.0. + Como configurar autentificación de contraseñas + para usar solo-una-vez. - Como instalar Kerberos5 en versiones - posteriores a 5.0. + Como configurar TCP Wrappers para usar + con inetd. - Como crear cortafuegos usando IPFW. + Como instalar KerberosIV en &os; + con versiones anteriores a 5.0. - Como configurar IPsec y crear un VPN entre - computadoras &os;/&windows;. + Como instalar Kerberos5 en &os; con + versiones posteriores a 5.0. - Como configurar y usar OpenSSH, - implementación de SSH en &os;. + Como configurar IPsec y crean una VPN entre + máquinas &os;/&windows;. + + + + Como configurar y utilizar OpenSSH, + la implementación SSH de &os;. - Como configurar y cargar los modulos de extensión de - control de acceso usando TrustedBSD MAC - Framework. + Que son ACLs del sistema de archivos y como + utilizarlas. - Que sistema de archivos ACLs son y como - usarlos. + Como usar la utilidad Portaudit + para auditar paquetes de software de terceros instalados + desde la colección de ports. - Como utilizar las publicaciones de advertencias de seguridad en - &os;. + Como utilizar las publicaciones de advertencias de seguridad en + &os;. + + Tener una idea de lo que es contabilidad de + procesos y como habilitarla en &os;. + - Antes de leer este capítulo, usted debe saber: + Antes de leer este capítulo, usted debe: - Conceptos básicos de &os; y el Internet. + Entender Conceptos básicos de &os; y el Internet. - + + Tópicos de seguridad adicionales son cubiertos a lo + largo de este libro. Por ejemplo, controles de acceso + obligatorio (Mandatory Access Control) son discutidos en y firewalls de internet son discutidos en el + capítulo de firewalls. + . Introducción - La seguridad es una función que comienza y termina con el + La seguridad es una función que comienza y termina con el administrador de sistema. Mientras que los sistemas multi-usuario - BSD &unix; tienen una inherente seguridad, el trabajo de construir y - mantener mecanismos de seguridad adicionales para mantener a los - usuarios de manera honesta es probablemente una de las - unicas tareas del administrador del sistema. Los sistemas son tan - seguros como uno los haga, los problemas de seguridad compiten con la - necesidad humana de conveniencia. Los sistemas &unix; en general, son - capaces de correr una gran cantidad de procesos simultáneos, - de los cuales muchos de estos son servidores – lo que significa - que entidades externas pueden conectarse y hablar con - ellos. Asi como las mini-computadoras del ayer se convirtieron en los - ahora escritorios de trabajo, y las computadoras se interconectaron, - la seguridad cada ves se hace un problema mas grande. + BSD &unix; tienen una seguridad inherente, el trabajo de construir y + mantener mecanismos de seguridad adicionales para hacer que los + usuarios sean honestos es probablemente una de las + tareas más grandes del administrador del sistema. Los sistemas + son tan seguros como uno los haga, los problemas de seguridad compiten + con la necesidad humana de conveniencia. Los sistemas &unix; en + general, son capaces de correr una gran cantidad de procesos + simultáneos, de los cuales muchos de estos son servidores + – lo que significa que entidades externas pueden conectarse y + hablar con ellos. Asi como las mini-computadoras del + ayer se convirtieron en los ahora escritorios de trabajo, y las + computadoras se interconectaron, la seguridad cada vez se hace un + problema más grande. La seguridad es mejor implementada como cebolla en capas. Basicamente, lo que se quiere hacer es crear la mayor cantidad - posible de convenientes capas de seguridad para luego cuidadosamente - monitorear el sistema para detectar intrusos. No es conveniente - sobreconstruir la seguridad, ya que esta interferira con el aspecto - de detección, y la detección es uno de los mas importantes - aspectos de cualquier mecanismo de seguridad. Por ejemplo, no tiene - mucho sentido usar los flags de schg (ver - &man.chflags.1;) en cada sistema binario, ya que mientras este puede - protejer los binarios temporalmente, hace que el algun cambio hecho - por un atacante sea difícil de detectar y puede resultar que - el mecanismo de seguridad no detecte al atacante en lo absoluto. + posible de capas de seguridad como sea conveniente para luego + cuidadosamente monitorear el sistema para detectar intrusos. No es + conveniente sobreconstruir la seguridad, ya que esta interferirá + con el aspecto de detección, y la detección es uno de + los más importantes aspectos de cualquier mecanismo de + seguridad. Por ejemplo, no tiene mucho sentido activar la bandera + schg (ver &man.chflags.1;) en cada binario del + sistema, ya que mientras este puede protejer los binarios + temporalmente, hace que algún cambio hecho por un atacante, + que ha entrado al sistema,sea difícil de detectar y puede + resultar que el mecanismo de seguridad no detecte al atacante en + lo absoluto. La seguridad del sistema depende también de estar preparado - para diferentes formas de ataque, incluyendo intentos de quebrar el + para diferentes formas de ataque, incluyendo intentos de quebrar el sistema, o hacer un sistema inservible, pero no intentos de comprometer al usuario root (quebrar root). Los problemas de seguridad estan separados en diferentes categorias: - Ataques de Negación de servicio (DoS). + Ataques de Negación de servicio (DoS). - Compromisos en cuentas de usuarios. + Comprometer cuentas de usuarios. - Compromisos de root por medio de servidores accesibles. + Comprometer root a través de servidores accesibles. + - Compromisos de root por medio de cuentas de usuarios. + Comprometer root via cuentas de usuarios. - Creación de puertas de entrada. + Creación de puertas traseras (Backdoors). - Ataques DoS - Negación de servicio (DoS) + DoS attacks + Denial of Service (DoS) - security + seguridad Ataques DoS - Negación de servicio (DoS) + Negación de servicios (DoS) + + Negacion de servicio (DoS) + + Un ataque de negación de servicio es una acción que + priva al sistema de los recursos requeridos. Generalmente, los ataques + DoS son mecanismos de fuerza bruta que intentan quebrar el sistema + o hacerlo inutilizable sobrepasando la capacidad de sus servidores + o del stack de red. + Algunos ataques DoS intentan aprovecharse de + errores en el stack de red para quebrar el sistema con un solo paquete. + Lo último solo puede ser solucionado aplicando en el kernel + una actualización que arregle el error. + Los ataques en servidores muchas veces pueden ser + solucionados especificando opciones apropiadas para limitar la carga del + sistema en condiciones adversas. Los ataques de fuerza bruta en redes + son mas complicados. Los ataques con paquetes enmascarados, por + ejemplo, son casi imposible de detener, a menos que desconecte el + sistema de Internet. Puede ser que no tiren el sistema, pero + saturarán la conexión a Internet. + + + seguridad + comprometer cuentas + + + Comprometer una cuenta de usuario es mucho más común + que un ataque DoS. Muchos administradores de sistemas + todavía corren servidores estándar + telnetd, rlogind, + rshd y ftpd en + sus máquinas. + Estos servidores, por omisión, no + operan sobre conexiones encriptadas. El resultado es que si se + tiene una base de usuarios de tamaño moderado, uno o + más de sus usuarios entrando al sistema desde una localidad + remota (que es la forma más común y conveniente de + entrar a un sistema) provocará que su contraseña + sea descubierta. + El atento administrador de sistemas analizará sus logs de + acceso remoto buscando por direcciones fuente sospechosas + incluso para entradas exitosas al sistema. + + Se debe asumir siempre que una vez que un atacante tiene acceso + a una cuenta de usuario, el atacante puede comprometer + root. De todas formas, la realidad es que en + un sistema bien mantenido y asegurado, el acceso a una cuenta de + usuario no necesariamente da al atacante acceso a + root. La distinción es importante + porque sin acceso a root el atacante + generalmente no puede esconder sus huellas y puede, a lo mucho, + meterse con los archivos de usuarios, o estrellar la máquina. + Comprometer cuentas de usuario es muy común porque los + usuarios tienden a no tomar las precauciones que el administrador + toma. + + + seguridad + backdoors - Negación de servicio (DoS) - - Un ataque de negación de servicio es una acción que - priva al sistema de los recursos requeridos. Generalmente, los ataques - DoS son mecanismos de fuerza bruta que intentan quebrar el sistema - forzando sus servidores. Algunos ataques DoS intentan aprovecharse de - bugs en la red para quebrar el sistema con un solo paquete. Esto puede - ser solucionado aplicando en el kernel una actualización que - arregle el bug. Los ataques en servidores muchas veces pueden ser - solucionados aplicando opciones apropiadas para limitar la carga del - sistema en condiciones adversas. Los ataques de fuerza bruta en redes - son mas complicados. Los ataques con paquetes enmascarados, por - ejemplo, son casi imposible de detener, el cual puede desconectar el - sistema de Internet. Pueden no quebrar el sistema, pero saturaran la - conexión a Internet. + Los administradores de sistema deben tener en mente que + existen muchas maneras potenciales de comprometer a + root en una máquina. El atacante puede + conocer la contraseña de root, el u + atacante puede encontrar un error en un servidor ejecutándose + como root y ser capaz de comprometer root a + través de una conexión de red a ese servidor, o el + atacante puede conocer un error en programa suid-root que le permita + comprometer root una vez que ha entrado + a una cuenta de usuario. Si un atacante ha encontrado una manera + de comprometer a root en una máquina, + entonces puede no necesitar instalar una puerta trasera. Muchos de + los agujeros root encontrados y cerrados hasta + la fecha significan una cantidad considerable de trabajo por parte del + atacante para limpiar todo despues del ataque, así que + la mayoría de los atacantes instalan puertas traseras. + Una puerta trasera brinda al atacante una forma sencilla de + retomar acceso de root en el sistema, + pero también le proporciona al administrador de sistemas + inteligente una manera conveniente de detectar la intrusión. + Haciendole imposible a un atacante instalar una puerta trasera + puede en realidad ser en detrimento de su seguridad, porque + no cerrará el agujero que el atacante encontró + para entrar en primer lugar. + + Los remedios de seguridad deben ser implementados + siempre con una aproximación multicapa tipo + cebolla y puede ser categorizado + como sigue: + + + + Aseguramiento de root y cuentas de staff. + + + + Aseguramiento de servidores que se ejecutan como root + y binarios suid/sgid. + + + + Aseguramiento de cuentas de usuarios. + + + + Aseguramiento del archivo de contraseñas. + + + + Aseguramiento del Kernel, dispositivos crudos y + sistema de archivos. + + + + Detección rápida de cambios inapropiados + hechos al sistema. + + + + Paranoia. + + + + La siguiente secci6oacute;n de este capítulo cubrirá + los puntos de arriba con mayor profundidad. - Asegurando FreeBSD + Asegurando &os; seguridad - asegurando FreeBSD + asegurando &os; - Comando vs. Protocolo - A través de este documento usaremos el texto en - negrita para referirnos a un comando o - aplicación. Esto se utiliza para casos tales como ssh, puesto - que es tanto un protocolo como un comando. + Comando vs. protocolo + A través de este documento usaremos el texto en + negrita para referirnos a un comando o + aplicación, y una fuente espaciada para + referirnos a comandos espcíficos. Los protocolos usarán + una fuente normal. Esta distinción tipográfica es + útil para instancias como ssh, ya + que es tanto un protocolo como un comando. - Las siguientes secciones cubrirán los métodos para - asegurar su sistema FreeBSD que fueron mencionados en la - sección anterior a este + Las siguientes secciones cubrirán los métodos para + asegurar su sistema &os; que fueron mencionados en la + sección anterior a este capítulo. - - Encapsulado SSH - - OpenSSH - encapsulado - - - - - - Cortafuegos - - Firewalls - - - + + Asegurando la cuenta <username>root</username> y cuentas de staff + + su + - - IPsec - - IPsec - - + En primer lugar, no se moleste en asegurar las cuentas de + staff si no ha asegurado la cuenta root. + La mayoría de los sistemas tienen una contraseña + asignada a la cuenta root. Lo primero que + se hace es asumir que la contraseña está + siempre comprometida. + Esto no significa que debe eliminar la contraseña. La + contraseña es casi siempre necesaria para acceso de + consola a la máquina. Lo que esto significa es que no se + debe hacer posible el uso de la contraseña fuera de la + consola o incluso posiblemente con el comando &man.su.1;. + Por ejemplo, asegúrese que sus ptys estaán + especificadas como inseguras en el archivo + /etc/ttys para que las entradas directas + de root vía + telnet o rlogin no estén + permitidas. + Si utiliza otros servicios de entrada como + sshd, asegúrese que entradas directas + de root estén también deshabilitadas. + Puede hacer esto editando su archivo + /etc/ssh/sshd_config, y asegurándose + que PermitRootLogin esté puesto a + NO. Considere cada método de acceso — + servicios como FTP frecuentemente caen en las grietas. + Entradas directas de root solo deben + ser permitidas vía consola. + + wheel + + + Por supuesto, como administrador de sistema usted debe + ser capaz de accesar a root, asi que + abrimos algunos agujeros. Pero asegúrese que estos + agujeros necesiten contraseñas adicionales de + verificación para operar. Una forma de hacer a root + accesible es agregar cuentas de staff apropiadas al + grupo wheel (en + /etc/group). Los miembros del staff colocados + en el grupo wheel tienen permitido + hacer su a root. + Nunca debe de proporcionar a miembros del staff acceso + nativo a wheel poniéndolos + en el grupo wheel en su entrada de + contraseña. Las cuentas de staff deben ser colocadas + en un grupo staff, y entonces + agregadas al grupo wheel en el + archivo /etc/group. Solo aquellos + miembros del staff que en realidad necesiten tener acceso + de root deben ser colocados en el + grupo wheel. también es posible + al utilizar un método de autentificación como + Kerberos, usar el archivo .k5login en + la cuenta root para permitir un + &man.ksu.1; a root sin tener que + colocar a nadie en el grupo + wheel. Esta puede ser una mejor solución + ya que el mecanismo wheel todavía + permite a un atacante comprometer root + si el intruso ha conseguido el archivo de contraseñas + y puede comprometer una cuenta de staff. Teniendo el + mecanismo wheel es mejor que no tener + nada del todo, aunque 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 login alternativo y hacer lo que se conoce como + estrellado de las contraseñas encriptadas + para las cuentas de staff. Usando el comando &man.vipw.8; + se puede reemplazar cada instancia de una contraseña + encriptada con un solo caracter *. + Este comando actualizará el archivo + /etc/master.passwd y la base de datos + usuario/contraseña para deshabilitar logins + autenticados por contraseñas. + + Una entrada de una cuenta de estaff como: + + foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + + Debe ser cambiada a esto: + + foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + + Este cambio prevendrá que ocurran logins normales, + ya que la contraseña encriptada nunca corresponderá + con *. Hecho esto, + los miembros de staff deben usar otro mecanismo + para autentificarse tal como &man.kerberos.1; o + &man.ssh.1; utilizando un par de llave pública/privada. + Cuando se usa algo como Kerberos, generalmente se debe + asegurar la máquina que corre los servidores Kerberos + y su estación de trabajo de escritorio. Cuando se + usa un par de llave pública/privada con ssh, + generalmente se debe asegurar la máquina desde + donde se hace el login (típicamente nuestra estación + de trabajo). Una capa adicional de protección puede + ser añadida al par de llaves protegiendo con contraseña + la llave par al crearla con &man.ssh-keygen.1;. + La posibilidad de estrellado de las + contraseñas de las cuentas de staff también + garantiza que los miembros del staff solo puedan entrar + a través de métodos de acceso que usted haya + configurado. Esto obliga a todos los miembros del staff + a utilizar conexiones seguras, encriptadas, para todas + sus sesiones, lo que cierra un importante agujero usado + por muchos intrusos: hacer un olfateo (sniffing) de la + red desde una máquina no relacionada y menos + segura. + + Los mecanismos de seguridad más indirectos también + asumen que se esta firmando desde un servidor más restrictivo + a un servidor menos restrictivo. + Por ejemplo, si su máquina principal está corriendo + toda clase de servidores, su estación de trabajo no debe + de estar corriendo ninguno. Para que su estación de trabajo + sea razonablemente segura debe correr los servidores mínimos + posibles, hasta incluso ningún servidor, y debe correr + un blanqueador de pantalla portegido por contraseña. + Por supuesto, dado un acceso físico a una estación + de trabajo un atacante puede romper cualquier clase de seguridad + que se ponga. Esto es definitivamente un problema que debe + considerar, pero también debe considerar el hecho de que la + mayoría de las intrusiones ocurren remotamente, a través + de la red, de gente que no tiene acceso físico a su + estación de trabajo o servidores. + KerberosIV + + Usar algo como Kerberos también le brinda la habilidad + de deshabilitar o cambiar la contraseña para una cuenta + de staff en un lugar, y que tenga un efecto inmediato en todas + las máquinas en las cuales el miembro de staff puede + tener una cuenta. Si la cuenta de un miembro de staff es + comprometida, la habilidad para cambiar instantaneamente su + contraseña en todas las máquinas no debe ser + desestimada. Con contraseñas discretas, 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 solo se puede hacer un + ticket de Kerberos para expirar despues de un tiempo, también + el sistema Kerberos puede requerir que el usuario escoja una + nueva contraseña despues de cierto periodo de tiempo + (digamos, una vez al mes). - - Asegurando la cuenta <username>root</username> y las cuentas de - staff + + Asegurando servidores que se ejecutan como <username>root</username> + y binarios SUID/SGID + + + ntalk + + + comsat + + + finger + + + sandboxes + + + sshd + + + telnetd + + + rshd + - su + rlogind - Antés que nada, no se preocupe en asegurar las cuentas - del staff si aun no ha asegurado la cuenta root. - La mayor parte de los sistemas tienen asignada una clave de acceso - a la cuenta root. Lo primero que usted debe - asumir es que la contraseña siempre - está comprometida. Esto no significa que tenga que - eliminar la contraseña. La contraseña es casi siempre - necesaria para el acceso a la cónsola de la computadora. Esto - significa que usted no debe permitir utilizar la contraseña - fuera de la cónsola o usarla posiblemente con el comando - &man.su.1;. Por ejemplo, cerciorese de que sus ptys sean - correctamente especificados como inseguros en el archivo - /etc/ttys para rechazar conexiones directas a - root vía telnet o - rlogin. Si se usan otros servicios tales como - sshd, asegurese de que las conexiones - directas a root estén deshabilitadas. Es - posible hacer esto editando el fichero - /etc/ssh/sshd_config, asegurando que - PermitRootLogin esté fijado como - NO. Considere cada método de acceso - - Servicios como FTP puedes tener problemas de seguridad. Las - conexiones directas a root deben ser sólo - permitidas físicamente en la cónsola de sistema. + El administrador de sistemas prudente solo ejecuta los + servidores que necesita, no más, no menos. Dese cuenta + que los servidores de terceros son los más propensos + a contener errores. Por ejemplo, ejecutando una versión + antigua de + imapd o + popper es como dar un boleto 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 daemons + 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 + todavía prevalece: Si alguien es capaz de penetrar a + través de un servidor ejecutándose en una caja + de arena, todavía tendría que salirse de la caja de + arena. Mientras más capas tenga que romper el atacante + es menor la posibilidad de su éxito. Los agujeros de + root han sido hallados historicamente en virtualmente + cualquier servidor que se ha ejecutado como root, + incluyendo servidores básicos del sistema. + Si está ejecutando una máquina a través de + la cual la gente solo entra por + sshd y nunca entra por + telnetd o + rshd o + rlogind, entonces ¡apague esos + servicios! + + &os; ahora por omisión ejecuta + ntalkd, + comsat y + finger en una caja de arena. + Otro programa que puede ser candidato para correr en una + caja de arena es &man.named.8;. + /etc/defaults/rc.conf incluye los + argumentos necesarios para correr named + en una caja de arena de una forma comentada. Dependiendo de si + está instalando un nuevo sistema o actualizando un sistema + existente, las cuentas especiales de usuario utilizadas por + 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. - wheel + sendmail - Por supuesto, como administrador de sistema usted debe poder - acceder como root, y nosotros tenemos algunas - formas de conseguirlo. Nos aseguraremos de que éstas formas - tengan autenticación adicional. Una de las formas de hacer - root accesible es agregar cuentas apropiadas del - staff al grupo wheel (en - /etc/group). Se permite a los miembros del - staff puestos en el grupo wheel usar el - comando su para acceder root. - Nunca debe dar a miembros del staff acceso nativo a - wheel cuando se crea la cuenta. Las cuentas - del staff deben estar colocadas en grupos de - staff, para después agregar a aquellos - deseados al grupo wheel en el fichero - /etc/group. Solamente a aquellos que realmente - se necesiten en este grupo deben ser agregados. Es también - posible usar un método de autentificación tal como - Kerberos, utilizar el fichero .k5login en la - cuenta root para permitir a &man.ksu.1; que - root no necesite a nadie en el grupo - wheel. Esta puede ser una mejor - solución puesto que el mecanismo de - wheel todavía permite al intruso romper - root, si el intruso ha conseguido quebrar el - archivo de contraseñas y el grupo del staff. Mientrás - que usar el mecanismo de wheel es mejor que no - tener nada en lo absoluto, no es necesariamente la opción mas - segura. - - Una manera indirecta de asegurar las cuentas del staff y usar el - acceso a root de ultima instancia es usar un - método de acceso alternativo conocido como - starring. Este método marca las - contraseñas cifradas con un solo - *. Este comando actualizará - fichero de /etc/master.passwd y la base de datos - de usuario/contraseña para desabilitar los logins con - autentificación de contraseña. - - Una cuenta del staff como esta: + Existen un número de otros servidores que tipicamente + no se ejecutan en cajas de arena: + sendmail, + imapd, ftpd, + y otros. Existen alternativas para algunos de estos, pero + instalarlas puede requerir más trabajo del que tal vez + esté dispuesto a realizar (el factor conveniencia + ataca de nuevo). Tal vez tenga que correr estos servidores como + root y depender de otros mecanismos para + detectar intrusiones que puedan ocurrir a través de + ellos. - foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + Los otros grandes agujeros de root + potenciales en un sistema son los binarios + suid y sgid root instalados en el sistema. La mayoría + de estos binarios, como rlogin, + residen en /bin, /sbin, + /usr/bin o /usr/sbin. + Aunque nada es 100% seguro, los binarios suid y sgid del + sistema por omisión pueden ser considerados razonablemente + seguros. Pero aún así, + agujeros root son encontrados + ocasionalmente en estos binarios. Un agujero root + fué entontrado en Xlib en + 1998 que hizo a xterm + (que es tipicamente suid) vulnerable. Es mejor prevenir que + lamentar y el administrador de sistemas prudente restringirá + los binarios suid, que solo el staff debe de ejecutar, a un + grupo especial que solo el staff pueda accesar, y deshacerse + de cualquier binario suid (chmod 000) + que nadie utilice. Un servidor sin pantalla generalmente + no necesita un binario xterm. + Binarios sgid pueden ser igual de peligrosos. Si un + intruso puede comprometer un binario sgid-kmem, el intruso + podría ser capaz de leer /dev/kmem + y así leer el archivo encriptado de contraseñas, + comprometiendo potencialmente cualquier cuenta con + contraseña. Alternativamente, un intruso que compromete + el grupo kmem puede monitorear teclazos + mandados a través de ptys, incluyendo ptys utilizados + por usuarios que accesan por métodos seguros. + Un intruso que compromete el grupo tty + puede escribir a casi cualquier pty de usuarios. + Si un usuario está corriendo un programa de terminal o + emulador con una propiedad de simulación de teclado, el + intruso puede potencialmente generar un flujo de datos que + provoque que la terminal del usuario haga eco de un comando, + el cual es entonces ejecutado como ese usuario. + - Debe ser cambiada a: - - foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/home/local/bin/tcsh - - Este cambio evitará que las conexiones normales ocurran, - ya que la contraseña cifrada nunca coincidirá con - *. Habiendo hecho esto, los - miembros del staff deberán usar otros métodos de - autentificación como &man.kerberos.1; o &man.ssh.1;, usando - pares de claves públicas/privadas. Al usar algo como - Kereberos, uno debe asegurar generalmente las máquinas que - corran los servidores Kereberos, asi como también su - estación de trabajo. Al usar pares de claves - públicas/privadas con ssh, uno debe asegurar generalmente la - máquina usada para hacer el login (generalmente una - estación de trabajo). Una capa adicional de protección - se puede agregar a los pares de claves - públicas/privadas protegiendolas con contraseña en el - momento de crearlas con &man.ssh-keygen.1;. Pudiendo - marcar las contraseñas de las cuentas del staff - también garantiza que los miembros del staff solamente pueden - acceder al sistema por medio de un método seguro. Esto fuerza - a los miembros del staff a acceder al sistema usando solamente formas - seguras y conexiones cifradas para todas sus sesiones, lo que - protege de una de las vulnerabilidades más usadas por - los intrusos. + + Asegurando cuentas de usuarios - + Las cuentas de usuario son usualmente las más + difíciles de asegurar. Aunque puede imponer restricciones + de acceso draconianas en su staff y estrellar + sus contraseñas, tal vez no pueda hacerlo con cualquier + cuenta general de usuario que tenga. Si tiene suficiente control, + tal vez triunfe y sea capaz de asegurar las cuentas de + usuarios con propiedad. Si no, simplemente tiene que ser más + vigilante en el monitoreo de esas cuentas. El uso de ssh y + Kerberos para cuentas de usuario es más problemático + debido a la administración adicional y soporte técnico + requerido, pero es todavía una buena solución + comparada a un archivo de contraseñas encriptadas. + + + + Asegurando el archivo de contraseñas + + La única manera segura es ponerle * + a tantas contraseñas como sea posible y utilizar ssh o + Kerberos para accesar esas cuentas. Aunque el archivo + encriptado de contraseñas (/etc/spwd.db) + solo puede ser leído por root, puede + ser posible para un intruso obtener acceso de lectura a ese + archivo incluso si el etacante no puede obtener + acceso de escritura como root. + + Sus scripts de seguridad deben revisar siempre por + cambios en el archivo de contraseñas + (ver Revisando integridad de archivos abajo) + y reportarlos. + + + + Asegurando del Kernel, dispositivos crudos y + sistema de archivos + + Si un atacante compromete root puede + hacer cualquier cosa, + pero existen ciertas conveniencias. Por ejemplo, la mayoría + de los Kernels modernos tienen un dispositivo olfateador de + paquetes integrado. Bajo &os; es llamado dispositivo + bpf. Un intruso tratará + comunmente de ejecutar un olfateador de paquetes en una + máquina comprometida. No necesita darle a un intruso + la capacidad y la mayoría de los sistemas no necesitan + que se compile el dispositivo bpf. + + + sysctl + + Pero incluso si apaga el dispositivo bpf, + todavía tiene que preocuparse por + /dev/mem y + /dev/kmem. + Para eso, el intruso puede todavía escribir a + dispositivos de disco crudos. También, existe otra + 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 + bpf, u otro dispositivo de + olfateo 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. + El securelevel puede ser activado con sysctl + en la variable kern.securelevel. + Una vez que ha activado securelevel a 1, los accesos de + escritura a dispositivos crudos serán denegados y + las banderas especiales schg serán + impuestas. + También debe asegurar que la bandera + schg esté habilitada en archivos + binarios críticos para el arranque, directorios y + scripts — todo lo que se ejecuta hasta el punto en que + se activa el securelevel. Esto puede ser una acción + exagerada, y actualizar el sistema es mucho más + complicado cuando se opera en un nivel de seguridad superior. + Puede comprometer y ejecutar el sistema a un nivel de seguridad + superior pero no activar la bandera schg + para cada archivo y directorio del sistema bajo el sol. + Otra posibilidad es simplemente montar / y + /usr de solo lectura. + Se debe notar que siendo demasiado draconiano en lo que trata + de proteger puede prevenir toda la detección importante + de una intrusión. + + + + Revisando integridad de archivos: binarios, archivos de + configuración, etc. + + Cuando se trata de protección, solo se puede proteger + la configuración central del sistema y archivos de + control hasta un punto antes de que el factor conveniencia + levante su fea cabeza. Por ejemplo, usando + chflags para activar el bit schg + en la mayoría de los archivos en / + y /usr es probablemente contraproducente, + debido a que puede proteger los archivos, pero también + cierra una ventana de detección. + La última capa de su seguridad tipo cebolla es quizás + la más importante — detección. El resto de + su seguridad es inutil (o, peor, darle un falso sentido de + seguridad) si no puede detectar incursiones potenciales. + 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 en el acto. + + La mejor manera de detectar una incursión es buscar + archivos modificados, perdidos o inesperados. La mejor manera + de buscar archivos modificados es desde otro (muchas veces + centralizado) sistema con acceso limitado. + Escribiendo sus scripts de seguridad en un sistema extra-seguro + con acceso limitado los hace casi invisibles a atacantes + potenciales, y esto es importante. Para tomar máxima + ventaja generalmente tiene que proporcionar a la máquina + con acceso limitado acceso significativo a las otras máquinas + en el negocio, usualmente ya sea haciendo una importación + NFS de solo lectura de las otras máquinas a la máquina + de acceso limitado o configurando pares de llaves ssh para + permitir a la máquina de acceso limitado hacer ssh a + las otras máquinas. A excepción de su tráfico + de red, NFS es el método menos visible — permitiendo + monitorear los sistemas de archivos en cada máquina cliente + virtualmente indetectado. Si su servidor de acceso limitado + está conectado a las máquinas cliente a través + de un concentrador o a través de varias capas de ruteo, + el método NFS puede ser muy inseguro (network-wise) + y utilizar ssh puede ser la mejor opción incluso + con las huellas de auditoría que ssh presenta. + + Una vez que le da a una maáquina de acceso limitado al + menos acceso de lectura a los sistemas cliente que se supone va + a monitorear, debe escribir scripts para hacer el monitoreo. + Dado un montaje NFS, puede escribir scripts con utilidades + simples como &man.find.1; y &man.md5.1;. Es mejor ejecutar + md5 fisicamente en los archivos de las máquinas cliente + al menos una vez al día, y probar archivos de control + como los encontrados en /etc y + /usr/local/etc incluso más seguido. + Cuando se encuentren discrepancias, relativas a la información + base md5 que la máquina de acceso limitado conoce como + válida, esto debe gritarle a un administrador de sistemas + que vaya a verificarlo. Un buen script de seguridad también + debe revisar por binarios suid inapropiados y por archivos nuevos + o borrados en particiones del sistema como / + y /usr. + + Al utilizar ssh en lugar de NFS, + escribir el script de seguridad es mucho más complicado. + Esencialmente tiene que pasar por scp los + scripts a la máquina cliente para poder ejecutarlos, + haciéndolos visibles, y para seguridad también + necesita pasar por scp los binarios + (como find) que utilizan esos scripts. El cliente + ssh en la máquina cliente + puede estar ya comprometida. Con todo, utilizar ssh + puede ser necesario al trabajar sobre enlaces + inseguros, pero también es mucho más dificil + de manejar. + + Un buen script de seguridad revisará también + por cambios a la configuración de los archivos de acceso + de usuarios y miembros del staff: + .rhosts, .shosts, + .ssh/authorized_keys y demás; + archivos que caigan fuera del rango de revisión + MD5. + + Si tiene una cantidad enorme de espacio en disco para usuarios, + puede tomar mucho tiempo recorrer cada archivo en esas + particiones. En este caso, configurando banderas de montaje + para deshabilitar binarios y dispositivos suid en esas particiones + es una buena idea. Las opciones nodev y + nosuid (vea &man.mount.8;) son lo que + necesita revisar. Probablemente debe escanearlos de todas + maneras, al menos una vez a la semana, ya que el objeto de esta + capa es detectar intrusiones ya sea que la instrusión + haya sido efectiva o no. + + La contabilidad de procesos (vea &man.accton.8;) es una + opción relativamente con una carga ligera del sistema + operativo la cual puede ayudar como un mecanismo de + evaluación post-intrusión. Es especialmente + útil para rastrear como un intruso en realidad + penetró en un sistema, asumiendo que el archivo + esté todavía intacto despues de que la + intrusión ocurrió. + + Finalmente, los scripts de seguridad deben procesar los + archivos de log, y los mismo logs deben ser generados de una + manera lo más segura posible — un syslog remoto + puede ser muy útil. Un intruso trata de cubrir sus + huellas, y los archivos de log son críticos para el + administrador de sistema tratando de rastrear la hora y el + método de la intrusión inicial. Una manera de + mantener un registro permanente de los archivos de log es + ejecutar la consola del sistema en un puerto serial y + recolectar la información en una base continua + mediante una máquina segura monitoreando las consolas. + + + + Paranoia + + Un poco de paranoia nunca lastima. Como una regla, un + administrador de sistema puede agregar cualquier número + de mecanismos de seguridad, siempre que estos no afecten + la conveniencia, y puede agregar mecanismos de seguridad + que si afecten la conveniencia con + un buen razonamiento. Incluso más importante, un + administrador de seguridad debe mezclarlos un poco — + si utiliza recomendaciones como las dadas en este documento + exactamente, está dando su metodología al + posible atacante que también tenga acceso a este + documento. + + + + Ataques de negación de servicios + Ataques de negación de servicios (DoS) + + Esta sección cubre ataques de negación de servicios. + Un ataque DoS es tipicamente un ataque de paquetes. Aunque no hay + mucho que pueda hacer acerca de ataques con paquetes imitados + (spoofed) que saturen su red, generalmente puede limitar el daño + asegurándose que los ataques no tiren sus servidores. + + + + Limitando forks en el servidor. + + + + Limitando ataques springboard (ataques de respuesta ICMP, + ping broadcast, etc.). + + + + Caché de ruteo del Kernel. + + + + Un ataque común DoS es contra un servidor con instancias + (forking) que trata de provocar que el servidor consuma procesos, descriptores + de archivos y memoria, hasta que la máquina muere. + inetd (vea &man.inetd.8;) tiene + varias opciones para limitar este tipo de ataque. + Se debe notar que mientras es posible prevenir que una máquina + se caiga, generalmente no es posible prevenir que un servicio sea + interrumpido por el ataque. Lea la página de manual + de inetd con cuidado y ponga atención + especialmente las opciones , , + y . Note que los ataques con direcciones IP imitadas + rodearán la opción de + inetd, así que una + combinación de opciones debe ser utilizada. Algunos + servidores que se ejecutan en solitario cuentan con + parámetros de autolimitación de instancias. + + Sendmail tiene su opción + , la cual tiende a trabajar + mucho mejor que tratando de usar las opciones de límite + de carga de sendmail debido al retraso que provoca la carga. + Debe especificar un parámetro + MaxDaemonChildren, cuando inicia + sendmail, lo suficientemente alto + para manejar su carga esperada, pero no tan alto que la + computadora no pueda manejar ese número de + sendmails sin caerse de boca. + También es prudente ejecutar sendmail en modo de cola + () y correr el daemon + (sendmail -bd) + de manera separada de las ejecuciones de cola + (sendmail -q15m). Si todavía desea + entregas en tiempo real puede ejecutar la cola a un intervalo + menor, como , pero asegúrese de + especificar una opción MaxDaemonChildren + razonable para ese sendmail y así + prevenir fallas en cascada. + + Syslogd puede ser atacado directamente + y se recomienda fuertemente que utilice la opción + siempre que sea posible, y la opción + de otra manera. + + También debe ser extremadamente cuidadoso con servicios + de conexión inversa como ident inverso de + TCP Wrapper, que puede ser atacado + directamente. Generalmente no va a querer utilizar la + propiedad de ident inverso de + TCP Wrapper por esta razón. + + Es una muy buena idea proteger los servicios internos + de acceso externo protegiéndolos vía firewall + en los ruteadores de los bordes. + La idea aquí es prevenir ataques de saturación + desde el exterior de la LAN, no tanto para proteger servicios + internos de comprometimientos root basados + en red. Siempre configure un firewall exclusivo, ej., + restringir todo menos los puertos + A, B, C, D y M-Z. De esta manera puede restringir + todos sus puertos bajos exceptuando ciertos servicios específicos + como named (si es el primario para + una zona), ntalkd, + sendmail y otros servicios accesibles + desde Internet. Si trata de configurar el firewall de la otra + manera — como un firewall inclusivo o permisivo, existe + una gran posibilidad de que olvide cerrar un + par de servicios, o de que agregue un nuevo servicio interno y + olvide actualizar el firewall. Puede incluso abrir el rango + de números de puerto altos en el firewall para permitir + operaciones de tipo permisivas, sin comprometer sus puertos + bajos. También tome nota que &os; le permite controlar + el rango de números de puerto utilizados para asignación + dinámica, a través de sysctl + con net.inet.ip.portrange + (sysctl -a | fgrep portrange), lo cual + también facilita la complejidad de la configuración + de su firewall. Por ejemplo, puede utilizar un rango normal + primero/último de 4000 o 5000, y un rango de puerto + alto de 49152 a 65535, entonces bloquée todo debajo de + 4000 en su firewall (excepto para ciertos puertos específicos + accesibles desde Internet, por supuesto). + + ICMP_BANDLIM + + Otro ataque DoS común es llamado ataque springboard + — atacar un servidor de una manera que provoca que el + servidor genere respuestas que sobrecarguen al servidor, la + red local o alguna otra máquina. Los ataques más + comunes de este tipo es el ataque ICMP ping broadcast. + El atacante imita paquetes ping enviados a la dirección + broadcast de su LAN con la dirección IP fuente puesta + a la de la máquina que desean atacar. Si sus ruteadores + de borde no están configurados para atrapar pings a + direcciones de broadcast, su LAN termina generando suficientes + respuestas a la dirección fuente imitada 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. Ataques de + broadcast de más de ciento veinte megabits han sido + medidos. Un segundo ataque común springboard es contra + el sistema de reporte de error de ICMP. Mediante la construcción + de paquetes que generan respuestas de error ICMP, un atacante + puede saturar la conexión entrante de red de un servidor + y provocar que el servidor sature su conexión saliente + de red con respuestas ICMP. Este tipo de ataque también + puede estrellar el servidor agotando sus mbufs, especialmente + si el servidor no puede drenar las respuestas ICMP que + genera lo suficientemente rápido. El kernel de &os; + tiene una nueva opción de compilación de + kernel llamada que limita la + efectividad de este tipo de ataques. La última gran + clase de ataques springboard está relacionada a + ciertos servicios de inetd como + el servicio de eco udp. Un atacante simplemente imita un paquete + UDP con la dirección fuente siendo el puerto de eco del + servidor A, y la dirección destino siendo el puerto de + eco del servidor B, donde servidor A y B están ambos + en su LAN. Los dos servidores entonces rebotan este paquete + de ida y vuelta entre ellos. El atacante puede sobrecargar + ambos servidores y la LAN simplemente inyectando un par de + paquetes de esta manera. Problemas similares existen con el + puerto chargen. Un administrador + de sistema competente apagará todos estos servicios + de inetd internos de verificación. + + Los ataques de paquetes imitados pueden ser también + utilizados para sobrecargar el caché de ruteo del kernel. + Refiérase a los parámetros de sysctl + net.inet.ip.rtexpire, + rtminexpire, y + rtmaxcache. + Un ataques de paquetes imitados que utiliza una dirección + IP fuente aleatoria provocará que el kernel genere una + ruta temporal en caché en la tabla de ruteo, visible con + netstat -rna | fgrep W3. Estas rutas + tipicamente expiran en 1600 segundos más o menos. Si el + kernel detecta que la tabla de ruteo en caché ya está + demasiado grande reducirá dinamicamente rtexpire + pero nunca la decrementará a menos del valor de + rtminexpire. Existen dos problemas: + + + + El kernel no reacciona con suficiente rapidez cuando + un servidor ligeramente cargado es atacado. + + + + El rtminexpire no es lo suficientemente + bajo para que el kernel sobreviva a un ataque sostenido. + + + + Si sus servidores están conectados al Internet + mediante un T3 o mejor, puede ser prudente corregir manualmente + rtexpire y rtminexpire + 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 debe ser + suficiente para proteger la tabla de ruteo de ataques. + + + + Detalles de acceso con Kerberos y SSH + ssh + KerberosIV + + Existen un par de detalles con respecto a + Kerberos y ssh que necesitan ser analizados si + pretende utilizarlos. Kerberos V es un excelente + protocolo de autentificación, pero existen + errores en la versión kerberizada de + telnet y + rlogin que las hacen + inapropiadas para manejar flujos binarios. + También, por omisión Kerberos no encripta una + sesión a menos que utilice la opción + . ssh + encripta todo por omisión. + + ssh funciona bastante bien en + cada caso excepto que reenvía llaves de encriptación + por omisión. Lo que esto significa es que si usted tiene + una estación de trabajo segura manteniendo llaves que + le dan acceso al resto del sistema, y hace ssh a una + máquina insegura, sus llaves son usables. Las llaves en + sí no son expuestas, pero ssh instala un puerto de + reenvío durante la duración de su login, y si + un atacante ha comprometido a root + en la máquina insegura puede utilizar ese puerto + para usar sus llaves y ganar acceso a cualquier otra + máquina que sus llaves abran. + + Recomendamos que utilice ssh en + combinación con Kerberos siempre que sea posible + para logins de staff. + ssh puede ser compilado con + soporte de Kerberos. Esto reduce su dependencia en + llaves ssh expuestas mientras al mismo tiempo + protegen las contraseñas vía Kerberos. + Las llaves ssh deben ser utilizadas solamente 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 haga uso de la + opción from=IP/DOMAIN que + ssh permite en su archivo + authorized_keys para hacer la llave + usable solamente a entidades que se firmen desde máquinas + específicas. + + + + + + + + Bill + Swingle + Partes reescritas y actualizadas por + + + + + + DES, MD5 y Crypt + + seguridad + crypt + + + crypt + DES + MD5 + + Cada usuario en un sistema &unix; tiene una contraseña + asociada con su cuenta. Parece obvio que estas contraseñas + necesiten ser conocidas solamente por el usuario y por el sistema + operativo. Para mantener estas contraseñas secretas, son + encriptadas con lo que se conoce como un hash de una pasada, + esto es, solo pueden ser facilmente encriptadas pero no + desencriptadas. En otras palabras, lo que acabamos de decir fué + tan obvio que ni siquiera es verdad: el sistema operativo mismo no + conoce realmente la contraseña. + Solamente conoce la forma encriptada de + la contraseña. La única manera de obtener la + contraseña en texto plano es por medio + de una búsqueda de fuerza bruta en el espacio de + contraseñas posibles. + + Desafortunadamente la única manera segura de encriptar + contraseñas cuando &unix; empezó a hacerlo estaba + basada en DES, la encriptación de datos estándar. + Esto no era tanto problema para usuarios residentes en EU, &os; + tuvo que buscar una manera de cumplir con las leyes de EU y + retener compatibilidad con todos las otras variantes de &unix; + que todavía utilizaban DES. + + La solución fué dividir las librerías + de encriptación para que los usuarios de EU pudieran + instalar las librerías DES y utilizar DES pero los + usuarios internacionales todavía tenían un + método de encriptación que podía ser + exportado. Así es como &os; llegó a usar + MD5 como su método de encriptación por + omisión. Se cree que MD5 es más seguro que + DES, así que la instalación de DES es ofrecida primordialmente + por razones de compatibilidad. + + + Reconociendo su mecanismo de encriptación + + Antes de &os; 4.4 libcrypt.a era + un enlace simbólico apuntando a la librería que era + utilizada para encriptación. &os; 4.4 cambió + libcrypt.a para brindar una librería + configurable de autentificación hash de contraseñas. + Actualmente la librería soporta funciones hash DES, MD5 y + Blowfish. Por omisión &os; utiliza MD5 para encriptar + contraseñas. + + Es muy sencillo identificar que método de + encriptación &os; tiene configurado para usar. + Examinando las contraseñas encriptadas en el archivo + /etc/master.passwd en una manera. + Contraseñas encriptadas con el hash MD5 son más + largas que aquellas encriptadas con el hash DES y también + inician con los caracteres + $1$. Las contraseñas + que inician con $2a$ están + encriptadas con la función hash de Blowfish. Las + cadenas de contraseñas DES no tienen ninguna + característica particular, pero son más + cortas que las contraseñas MD5, y están + codificadas con un alfabeto de 64 caracteres el cual no + incluye el caracter $, por eso + una cadena relativamente corta que inicie con un signo de + dólar es muy probable que sea una contraseña + DES. + + El formato de contraseña utilizado para nuevas + contraseñas está controlado por la capacidad + passwd_format en + /etc/login.conf, la cual toma valores + de des, md5 o + blf. Vea la página de manual + &man.login.conf.5; para mayor información acerca de + las capacidades de login. + + + + + + Contraseñas de una sola vez + Contraseñas de una sola vez + + seguridad + Contraseñas de una sola vez + + + S/Key es un esquema de contraseña de una sola vez + en una función de hash de una pasada. &os; utiliza el + hash MD4 para compatibilidad pero otros sistemas han usado + MD5 y DES-MAC. S/Key ha sido parte del sistema base de &os; + desde la versión 1.1.5 y es usado también en + un número creciente de otros sistemas operativos. S/Key + es una marca registrada de Bell Communications Research, Inc. + + Desde la versión 5.0 de &os;, S/Key ha sido + reemplazado con la funcionalidad equivalente OPIE + (One-time Passwords In Everything). OPIE usa hash MD5 + por omisión. + + Existen tres tipos de contraseñas las cuales serán + discutidas abajo. La primera es la contraseña usual estilo + &unix; o Kerberos; llamaremos a esta una contraseña &unix;. + El segundo tipo es la contraseña de una sola vez la cual es + generada por el programa key de S/Key o por + el programa &man.opiekey.1; de OPIE, y aceptada por los programas + keyinit u &man.opiepasswd.1; y el prompt de + login; llamaremos a esta una contraseña de una sola vez. + El último tipo de contraseña es la contraseña + secreta que le da a los programas key/opiekey + (y a veces + keyinit/opiepasswd) la cual + es utilizada para generar contraseñas de una sola vez; + llamaremos a esta una contraseña secreta + o solamente contraseña no calificada. + + La contraseña secreta no tiene nada que ver con su + contraseña &unix;; pueden ser la misma pero esto no es + recomendable. Las contraseñas secretas S/Key y OPIE no + están limitadas a 8 caracteres como las contraseñas + &unix; antiguasBajo &os; la contraseña del + login estándar puede ser de hasta 128 caracteres de + longitud., pueden ser tan largas como quiera. + Contraseñas con frases de seis o siete palabras muy largas + son bastante comunes. En la mayor parte, el sistema S/Key o el + OPIE opera completamente independiente del sistema de contraseñas + &unix;. + + Además de la contraseña, existen dos piezas más + de datos que son importante para S/Key y OPIE. Una es la que es + conocida como la semilla o llave, + consistente de dos letras y cinco dígitos. La otra es la + que es llamada la cuenta iterativa, un número + entre 1 y 100. S/Key genera la contraseña de una sola vez + concatenando la semilla y la contraseña secreta, + entonces aplica el hash MD4/MD5 tantas veces como especifique + la cuenta iterativa y convirtiendo el resultado en seis palabras + cortas en inglés. Estas seis palabras en inglés + son su contraseña de una sola vez. El sistema de autentificación + (principalmente PAM) mantiene un registro del uso de contraseñas + de una sola vez, y el usuario es autentificado si el hash de la + contraseña brindada por el usuario es igual a la + contraseña previa. Como se utiliza un hash de una pasada + es imposible generar contraseñas de una sola vez futuras + si una contraseña usada con éxito es capturada; + la cuenta iterativa es decrementada despues de cada login exitoso + para mantener al usuario y al programa login en sincronía. + Cuanto la cuenta iterativa llega a 1, S/Key y OPIE deben ser + reinicializados. + + Hay tres programas involucrados en cada sistema los + cuales discutiremos abajo. Los programas key + y opiekey aceptan una cuenta iterativa, + una semilla y una contraseña secreta, y generan + una contraseña de una sola vez o una lista consecutiva + de contraseñas de una sola vez. Los programas + keyinit y opiepasswd + son utilizados para inicializar S/Key y OPIE respectivamente, + y para cambiar contraseñas, cuentas iterativas o + semillas; toman ya sea una frase secreta, o una cuenta + iterativa y una contraseña de una sola vez. Los programas + keyinfo y opieinfo + examinan los archivos de credenciales relevantes + (/etc/skeykeys o + /etc/opiekeys) e imprime la cuenta + iterativa y semilla actual del usuario invocante. + + Existen cuatro tipos de operaciones diferentes que cubriremos. + La primera es usando keyinit o + opiepasswd a través de una conexión + segura para configurar contraseñas de una sola vez por + primera vez, o para cambiar su contraseña o semilla. + La segunda operación es utilizando keyinit + o opiepasswd sobre una conexión insegura, + en conjunto con key u opiekey + sobre una conexión segura, para hacer lo mismo. La tercera + es usando key/opiekey para + conectarse a través de una conexión insegura. + La cuarta es usando opiekey o key + para generar un número de llaves las cuales pueden ser escritas + o impresas para llevárselas con usted al ir a algún + lugar que no cuente con conexiones seguras a ningún lado. + + + Inicialización de conexiones seguras + + Para inicializar S/Key por primera vez, cambie su contraseña, + o cambie su semilla mientras esta conectado a través de + una conexión segura (ej., en la consola de una máquina + o vía ssh), use el comando + keyinit sin ningún parámetro + mientras está conectado con su cuenta: + + &prompt.user; keyinit +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 + + Para OPIE, es utilizado opiepasswd: + + &prompt.user; opiepasswd -c +[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 + + + En Enter new secret pass phrase: o + Enter secret password:, debe ingresar + una contraseña o frase. Recuerde, que esta no es la + contraseña que utilizará para entrar, esta es + usada para generar sus llaves de una sola vez. La línea + ID da los parámetros de su instancia + en particular: su nombre de login, la cuenta iterativa y + semilla. Al hacer login el sistema recordará estos + parámetros y los presentará de nuevo para que + no tenga que recordarlos. La última línea da + las contraseéas de una sola vez en particular que + corresponden a esos parámetros y su contraseña + secreta; si fuera a hacer nuevamente login de manera inmediata, + esta contraseña de una sola vez es la que debería + usar. + + + + Inicialización de conexiones inseguras + + 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 correr key u opiekey; + esto podría ser en la forma de un accesorio de escritorio + en una &macintosh;, o un prompt de shell en una máquina + en la cual confíe. También necesitará hacer + una cuenta iterativa (100 es probablemente un buen valor), y puede + realizar su propia semilla o utilizar una generada de manera + aleatoria. A través de una conexión insegura + (hacia la máquina que está inicializando), utilice + el comando keyinit -s: + + &prompt.user; keyinit -s +Updating unfurl: +Old key: to17758 +Reminder you need the 6 English words from the key command. +Enter sequence count from 1 to 9999: 100 +Enter new key [default to17759]: +s/key 100 to 17759 +s/key access password: +s/key access password:CURE MIKE BANE HIM RACY GORE + + + Para OPIE, necesita usar opiepasswd: + + &prompt.user; opiepasswd + +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 + + + Para aceptar la semilla por omisión (la que + el programa keyinit llama de + manera confusa una key), presione + Enter. Entonces antes de proporcionar + una contraseña de acceso, cambiese a su conexión + segura o accesorio de escritorio S/Key, y dele el mismo + parámetro: + + &prompt.user; key 100 to17759 +Reminder - Do not use this program while logged in via telnet or rlogin. +Enter secret password: <secret password> +CURE MIKE BANE HIM RACY GORE + + O para OPIE: + + &prompt.user; opiekey 498 to4268 +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 + + + Ahora regrese a la conexión insegura y copie la + contraseña de una sola vez generada al programa + relevante. + + + + Generando una sola contraseña de una sola vez + + Una vez que ha inicializado S/Key u OPIE, cuando haga login + se le presentará un prompt como este: + +&prompt.user; telnet example.com +Trying 10.0.0.1... +Connected to example.com +Escape character is '^]'. + +FreeBSD/i386 (example.com) (ttypa) + +login: <username> +s/key 97 fw13894 +Password: + + O para OPIE: + +&prompt.user; telnet example.com +Trying 10.0.0.1... +Connected to example.com +Escape character is '^]'. + +FreeBSD/i386 (example.com) (ttypa) + +login: <username> +otp-md5 498 gr4269 ext +Password: + + Como una nota aparte, el prompt de S/Key u OPIE cuentan con una + opción útil (no mostrada aquí): si presiona + Enter en el prompt de contraseña, el + prompt activará el eco, para que pueda ver lo que está + tecleando. Esto puede ser extremadamente útil si está + intentando teclear una contraseña a mano, como desde una + forma impresa. + + MS-DOS + Windows + MacOS + + En este punto necesita generar su contraseña de una + sola vez para responder a este prompt de login. Esto debe hacerse + en un sistema confiable en el que pueda ejecutar key + u opiekey. (Existen versiones de estos para DOS, + &windows; y &macos; también.) Ambos necesitan la cuenta iterativa + y la semilla como opciones de línea de comando. Puede cortar + y pegar estas desde el prompt de login en la máquina a la + que se esta firmando. + + En el sistema confiable: + + &prompt.user; key 97 fw13894 +Reminder - Do not use this program while logged in via telnet or rlogin. +Enter secret password: +WELD LIP ACTS ENDS ME HAAG + + Para OPIE: + + &prompt.user; opiekey 498 to4268 +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 + + Ahora que tiene su contraseña de una sola vez puede + continuar con el login: + + login: <username> +s/key 97 fw13894 +Password: <return to enable echo> +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 ... + + + + + Generando múltiples contraseñas de una sola vez + + A veces usted tiene que ir a lugares donde no hay + acceso a una máquina confiable o a una conexión + segura. En este caso, es posible utilizar los comandos + key y opiekey para + generar un número de contraseñas de una sola + vez con anticipación para imprimirlar y llevárselas + con usted. Por ejemplo: + + &prompt.user; key -n 5 30 zz99999 +Reminder - Do not use this program while logged in via telnet or rlogin. +Enter secret password: <secret password> +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 + + O para OPIE: + + &prompt.user; opiekey -n 5 30 zz99999 +Using the MD5 algorithm to compute response. +Reminder: Don't use opiekey from telnet or dial-in sessions. +Enter secret pass phrase: <secret password> +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 + + El pide cinco llaves en secuencia, la + opción especifica que ese debe ser el + último número de iteración. Note que son + impresas en el orden inverso de uso + eventual. Si es realmente paranoico, tal vez quiera escribir los + resultados a mano; de otra manera puede cortar y pegar hacia lpr. + Note que cada línea muestra la cuenta iterativa y la + contraseña de una sola vez; puede encontrar cómodo + tachar las contraseñas según las vaya utilizando. + + + + Restringiendo el uso de contraseñas &unix; + + S/Key puede colocar restricciones en el uso de contraseñas + &unix; basandose en el nombre de equipo, nombre de usuario, puerto de + terminal o dirección IP de una sesión de login. + Estas restricciones pueden encontrarse en el archivo de configuracio´n + /etc/skey.access. La página de manual + &man.skey.access.5; contiene más información sobre el + formato completo del archivo y detalla también algunas + precauciones de seguridad que hay que tomar en cuenta dependiendo + de este archivo para la seguridad. + + Si no existe un archivo /etc/skey.access + (esto es por omisión en sistemas &os; 4.X), entonces + a todos los usuarios se les permitirá utilizar contraseñas + &unix;. Si el archivo existe, de todas maneras, entonces a todos + los usuarios se les requerirá la utilización de + S/Key a menos que se permita explicitamente otra forma por las + declaraciones de configuración en el archivo + skey.access. En todos los casos, las + contraseñas &unix; son permitidas en la consola. + + Aquí hay una muestra del archivo de configuración + skey.access que ilustra las tres formas más + comunes de declaraciones de configuración: + + permit internet 192.168.0.0 255.255.0.0 +permit user fnord +permit port ttyd0 + + La primera línea (permit internet) + permite a usuarios cuyas direcciones IP fuentes (las cuales son + vulnerables a imitación) concuerden con los valores + y máscara especificados, utilizar contraseñas &unix;. + Esto no debe ser considerado un mecanismo de seguridad, sino un + medio de recordarle a usuarios autorizados que están + usando una red insegura y necesitan utilizar S/Key para + autentificación. + + La segunda línea (permit user) + permite al nombre de usuario especificado, en este caso + fnord, utilizar contraseñas &unix; + en cualquier momento. Generalmente hablando, esto solo debe ser + usado para gente que no puede usar el programa key, + como aquellos con terminales tontas o los que son ineducables. + + La tercera línea (permit port) + permite a todos los usuarios firmados en la línea de + terminal especificada utilizar contraseñas &unix;; + esto puede ser usado para dial-ups. + + OPIE puede restringir el uso de contraseñas &unix; + basándose en la dirección IP de una sesión + de login justo como lo hace S/Key. El archivo relevante es + /etc/opieaccess, el cual está presente + por omisión en sistemas &os; 5.0 o posteriores. Por + favor revise &man.opieaccess.5; para mayor información sobre + este archivo y que consideraciones de seguridad debe tener presente + a la hora de usarlo. + + Aquí hay un archivo opieaccess de muestra: + + permit 192.168.0.0 255.255.0.0 + + Esta línea le permie a usuarios cuya dirección + IP fuente (la cual es vulnerable a imitación) concuerde + con los valores y máscara especificados, utilizar + contraseñas &unix; en cualquier momento. + + Si no concuerda ninguna regla en opieaccess, + por omisión se niegan los logins no-OPIE. + + + + + + + + + Tom + Rhodes + Escrito por: + + + + + TCP Wrappers + + TCP Wrappers + + Cualquiera familiarizado con &man.inetd.8; ha escuchado + probablemente de TCP Wrappers en algún + momento. Pero pocos individuos parecen comprender + completamente su utilidad en un ambiente de red. Parece que + todos quieren instalar un firewall para manejar conexiones + de red. Mientras un firewall tiene una amplia variedad de + usos, hay cosas que un firewall no maneja como el envío + de texto de regreso al originador de la conexión. + El software TCP hace esto y más. + En las siguientes secciones varias de las opciones de + TCP Wrappers serán discutidas, + y, cuando aplique, se brindarán ejemplos de + líneas de configuración. + + El software TCP Wrappers extiende + las habilidades de inetd para brindar + soporte para cada servidor daemon bajo su control. + Utilizando este método es posible proveer soporte de + logs, regresar mensajes a conexiones, permitir a un daemon + aceptar solamente conexiones internas, etc. Mientras algunas + de estas opciones pueden ser provistas implementando un + firewall, esto agregará no solamente una capa extra + de protección sino que irá más allá + del nivel de control que un firewall puede brindar. + + La funcionalidad agregada de TCP Wrappers + no debe ser considerada un reemplazo de un buen firewall. + TCP Wrappers puede ser utilizado en + conjunto con un firewall o otra mejoría de seguridad + aunque solo puede servir como una capa extra de protección + para el sistema. + + Ya que es una extensión a la configuración + de inetd, se espera que el lector haya + leido la sección + configuración de inetd. + + + Mientras programas ejecutados por &man.inetd.8; no son + exactamente daemons, han sido llamados + tradicionalmente daemons. Este es el término que + usaremos en esta sección también. + + + + Configuración inicial + + El único requerimiento para usar + TCP Wrappers en &os; es asegurarse + que el servidor inetd sea iniciado + desde rc.conf con la opción + ; esta es la configuración + por omisión. Por supuesto, se espera que + /etc/hosts.allow esté propiamente + configurado, pero &man.syslogd.8; aventará mensajes + a los logs del sistema en estos casos. + + + A diferencia de otras implementaciones de TCP + Wrappers, el uso de hosts.deny ha sido + descontinuado. Todas las opciones de configuración + deben ser colocadas en /etc/hosts.allow. + + + En la configuración más simple, las + políticas de conexión de daemons están + configuradas ya sea a permitir o bloquear, dependiendo de + las opciones en /etc/hosts.allow. + La configuración por omisión en &os; es + permitir una conexión a cada daemon iniciado con + inetd. Cambiar esta configuración + será discutido solamente despues de cubrir la + configuración básica. + + La configuración básica usualmente + toma la forma de + daemon : dirección : acción. + Donde daemon es el nombre de daemon + el cual inicia inetd. La + dirección puede ser un nombre + de equipo válido, una dirección IP o + IPv6 encerrada en corchetes ([ ]). El campo de + acción puede ser permitir o denegar para el + dar el acceso apropiado. Tenga en mente que la + configuración funciona en base a la primera + concordancia encontrada en la regla de semántica, + esto significa que el archivo de configuración es + explorado en orden ascendente por una regla que + concuerde. Cuando se encuentra una concordancia la + regla es aplicada y el proceso se detendrá. + + Existen muchas otras opciones pero estas serán + explicadas en una sección posterior. Una línea + de configuración simple puede ser facilmente + construida desde esa información solamente. Por + ejemplo para permitir conexiones POP3 + por medio del daemon mail/qpopper, + las siguientes líneas deben ser agregadas a + hosts.allow: + + # This line is required for POP3 connections: +qpopper : ALL : allow + + Despues de añadir esta línea, inetd + necesitará reiniciar. Esto puede lograrse usando el + comando &man.kill.1;, o con el parámetro restart + con /etc/rc.d/inetd. + + + + Configuración avanzada + + TCP Wrappers tiene + opciones avanzadas también; estas permitirán + mayor control sobre la forma en que son manejadas las + conexiones. En algunos casos puede ser una buena idea + regresar un comentario a ciertos equipos o conexiones + de daemons. En otros casos, quizás se deba + registrar un archivo de log o enviar un correo al + administrador. Otras situaciones pueden requerir + el uso de un servicio para conexiones locales + solamente. Todo esto es posible a través del + uso de opciones de configuración conocidas + como comodines, caracteres de expansión + y ejecución de comandos externos. Las diguientes dos + secciones están escritas para cubrir estas + situaciones. + + + Comandos externos + + Suponga que ocurre una situación donde una + conexión debe ser negada pero se debe mandar una razón + al individuo que intentó establecer esa conexión. + ¿Como se puede lograr? Esa acción puede hacerse + posible utilizando la opción . + Cuando un intento de conexión es hecha, se llamará + a para ejecutar un comando de shell + o un script. Existe ya un ejemplo en el archivo + hosts.allow: + + # The rest of the daemons are protected. +ALL : ALL \ + : severity auth.info \ + : twist /bin/echo "No es bienvenido a utilizar %d desde %h." + + Este ejemplo muestra que el mensaje, + No es bienvenido a utilizar daemon + desde nombre de equipo. será + retornado para cualquier daemon no configurado previamente + en el archivo de acceso. + Esto es extremadamente útil para enviar una respuesta + de regreso al iniciador de la conexión justo despues + que la conexión establecida es tirada. Note que + cualquier mensaje regresado debe + ser encerrado entre comillas "; + no existen excepciones a esta regla. + + + Puede ser posible lanzar un ataque de negación + de servicio en el servidor si un atacante o grupo de + atacantes pueden sobrecargar estos daemons con peticiones + de conexión. + + + Otra posibilidad es usar la opción + en estos casos. Al igual que , + niega implicitamente la conexión + y puede ser utilizada para correr comandos de shell externos + o scripts. A diferencia de , + no mandará una respuesta de + regreso al individuo que ha establecido la conexión. + Por ejemplo, considere la siguiente línea de + configuración: + + # No permitimos conexiones desde example.com: +ALL : .example.com \ + : spawn (/bin/echo %a from %h attempted to access %d >> \ + /var/log/connections.log) \ + : deny + + Esto negará todos los intentos de conexión + desde el dominio *.example.com; + simultaneamente haciendo un log del nombre del equipo, + dirección IP y el daemon al + que se intentó accesar en el archivo + /var/log/connections.log. + + Además de la sustitución de caracteres ya + explicada arriba, ej. %a, existen unas cuantas más. + Vea la página de manual &man.hosts.access.5; para + la lista completa. + + + + Opciones comodín + + Hasta el momento el ejemplo ALL ha sido + utilizado continuamente a lo largo de los ejemplos. Existen + otras opciones que extienden un poco más la funcionalidad. + Para ejemplificar, ALL puede ser usado para + concordar con cualquier instancia ya sea de daemon, dominio o + dirección IP. Otro comodín + dsponible es PARANOID el cual puede ser + usado para concordar con cualquier equipo que brinde una + dirección IP que puede estar + falsificada. En otras palabras, paranoid + puede ser usado para definir una acción a tomar + siempre que una conexión sea hecha desde una + dirección IP que difiera de su + nombre de equipo. El siguiente ejemplo puede arrojar más + luz en esta discusión: + + # Bloquear peticiones posiblemente falsificadas a sendmail: +sendmail : PARANOID : deny + + En ese ejemplo todas las peticiones de conexión + a sendmail que tengan una + dirección IP que varíe + de su nombre de equipo seran negadas. + + + Utilizando PARANOID puede invalidar + servidores si el cliente o servidor tiene una configuración + de DNS dañada. Se recomienda + precaución del administrador. + + + Para aprender más acerca de comodines y sus + funcionalidades asociadas, vea la página de + manual &man.hosts.access.5;. + + Antes de que cualquiera de las líneas de + configuración específica de arriba + funcione, la primera línea debe ser comentada + en hosts.allow. Esto fué + especificado al principio de esta sección. + + + + + + + + + Mark + Murray + Contribuido por + + + + + Mark + Dapoz + Basado en una contribución de + + + + + <application>KerberosIV</application> + + Kerberos es un sistema/protocolo agregado para red que le permite + a usuarios autentificarse a través de los servicios de un + servidor seguro. Servicios como login remoto, copia remota, copias + de archivo inter-sistemas seguras y otras tareas de riesgo son + hechas considerablemente seguras y más controlables. + + Las siguientes instrucciones pueden usarse como una guía + para configurar Kerberos como se distribuye para &os;. De todas + maneras, debe referirse a las páginas de manual relevantes + para una descripción completa. + + + Instalando <application>KerberosIV</application> + + MIT + + KerberosIV + instalación + + Kerberos es un componente óptimo de &os;. 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 &os;. Esto + instalará la implementación de Kerberos + eBones (KerberosIV) o + Heimdal (Kerberos5). + Estas implementaciones son incluidas debido a que están + desarrolladas fuera de EU/Canada y estaban así disponibles + para propietarios de sistemas fuera de estos países + durante la era restrictiva de control de exportaciones en código + criptográfico desde EU. + + Alternativamente, la implementación de Kerberos + del MIT está disponible en la colección + de ports como + security/krb5. + + + + Creando la base de datos inicial + + Esto es hecho en el servidor Kerberos solamente. Primero + asegúrese que no tiene bases de datos antiguas de + Kerberos. Debe cambiarse al directorio /etc/kerberosIV + y revisar que solo los siguientes archivos estén + presentes: + + &prompt.root; cd /etc/kerberosIV +&prompt.root; ls +README krb.conf krb.realms + + Si existe cualquier archivo adicional (como principal.* + o master_key), entonces utilice el + comando kdb_destroy para destruir la base + de datos antigua de Kerberos, o si Kerberos no está + corriendo, simplemente borre los archivos adicionales. + + Ahora debe editar los archivos krb.conf + y krb.realms para definir su dominio + Kerberos. En este caso el dominio será EXAMPLE.COM + y el servidor es grunt.example.com. + Editamos o creamos el archivo krb.conf: + + &prompt.root; cat krb.conf +EXAMPLE.COM +EXAMPLE.COM grunt.example.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 + + En este caso, los otros dominios no necesitan estar ahí. + Están aquí como un ejemplo de como puede hacerse a una + máquina consciente de dominios múltiples. Tal vez + no desée incluirlos por simplicidad. + + La primera línea nombra el dominio en el cual el + sistema trabaja. Las otras líneas contienen entradas + dominio/equipo. El primer componente en una línea es un + dominio, y el segundo es un equipo en ese dominio que está + actuando como un centro de distribución de llaves. + Las palabras admin server que siguen al + nombre de equipo significan que ese equipo también + brinda un servidor de base da datos administrativo. Para una + explicación más completa de estos términos, + consulte por favor las páginas de manual de Kerberos. + + Ahora tenemos que agregar grunt.example.com + al dominio EXAMPLE.COM y también agregar + una entrada para poner todos los equipos en el dominio + .example.com + Kerberos EXAMPLE.COM. El archivo + krb.realms puede ser actualizado como + sigue: + + &prompt.root; cat krb.realms +grunt.example.com EXAMPLE.COM +.example.com EXAMPLE.COM +.berkeley.edu CS.BERKELEY.EDU +.MIT.EDU ATHENA.MIT.EDU +.mit.edu ATHENA.MIT.EDU + + De nuevo, los otros dominios no necesitan estar ahí. Están + aquí como un ejemplo de como una máquina puede hacerse consciente + de dominios múltiples. Tal vez desée eliminarlos para + simplificar las cosas. + + a primera línea pone al sistema específico + en el dominio nombrado. El resto de las líneas muestran como + poner por omisión sistemas de un subdominio particular + a un dominio Kerberos. + + Ahora estamos listos para crear la base de datos. Esta solo + necesita correr en el servidor Kerberos (o centro de distribución + de llaves). Ejecute el comando kdb_init para + hacer esto: + + &prompt.root; kdb_init +Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM +You will be prompted for the database Master Password. +It is important that you NOT FORGET this password. + +Enter Kerberos master key: + + Ahora tenemos que salvar la llave para que los servidores en + la máquina local puedan recogerla. Use el comando + kstash para hacer esto: + + &prompt.root; kstash + +Enter Kerberos master key: + +Current Kerberos master key version is 1. + +Master key entered. BEWARE! + + Esto salva la contraseña encriptada + maestra en /etc/kerberosIV/master_key. + + + + Haciendo que corra todo + + + KerberosIV + encendido inicial + + + + Dos datos principales necesitan ser agregados a la base de + datos para cada sistema que estará + asegurado con Kerberos. Sus nombres son kpasswd y + rcmd. Estos dos datos están hechos para + cada sistema, con la instancia siendo el nombre del sistema + individual. + + Estos daemons, kpasswd y + rcmd le permiten a otros sistemas + cambiar contraseñas de Kerberos y ejecutar comandos + como &man.rcp.1;, &man.rlogin.1; y &man.rsh.1;. + + Ahora vamos a añadir estas entradas: + + &prompt.root; kdb_edit +Opening database... + +Enter Kerberos master key: + +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. + +Principal name: passwd +Instance: grunt + +<Not found>, Create [y] ? y + +Principal: passwd, Instance: grunt, kdc_key_ver: 1 +New Password: <---- enter RANDOM here +Verifying password + +New Password: <---- enter RANDOM here + +Random password [y] ? y + +Principal's new key version = 1 +Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? +Max ticket lifetime (*5 minutes) [ 255 ] ? +Attributes [ 0 ] ? +Edit O.K. +Principal name: rcmd +Instance: grunt + +<Not found>, Create [y] ? + +Principal: rcmd, Instance: grunt, kdc_key_ver: 1 +New Password: <---- enter RANDOM here +Verifying password + +New Password: <---- enter RANDOM here + +Random password [y] ? + +Principal's new key version = 1 +Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? +Max ticket lifetime (*5 minutes) [ 255 ] ? +Attributes [ 0 ] ? +Edit O.K. +Principal name: <---- null entry here will cause an exit + + + + Creando el archivo de servidor + + Ahora tenemos que extraer todas las instancias que definen + los servicios en cada máquina. Para esto usamos el + comando ext_srvtab. Esto creará un + archivo que debe ser copiado o movido por medios + seguros a cada cliente de Kerberos + en el directorio /etc/kerberosIV. + Este archivo debe estar presente en cada servidor y cliente, y es + crucial para la operación de Kerberos. + + + &prompt.root; ext_srvtab grunt +Enter Kerberos master key: + +Current Kerberos master key version is 1. + +Master key entered. BEWARE! +Generating 'grunt-new-srvtab'.... + + Ahora, este comando solo genera un archivo temporal el cual + debe ser renombrado a srvtab para que todos + los servidores puedan recogerlo. Utilice el comando + &man.mv.1; para moverlo al lugar correcto en el sistema + original: + + &prompt.root; mv grunt-new-srvtab srvtab + + Si el archivo es para un sistema cliente, y la red no se considera + segura, entonces copie el + client-new-srvtab a un + medio removible y transportelo por medios físicos seguros. + Asegúrese de renombrarlo a srvtab en el + directorio /etc/kerberosIV del cliente, y + asegúrese que tiene modo 600: + + &prompt.root; mv grumble-new-srvtab srvtab +&prompt.root; chmod 600 srvtab + + + + Poblando la base de datos + + Ahora tenemos que agregar algunas entradas de usuarios en la + base de datos. Primero vamos a crear una entrada para el usuario + jane. Utilice el comando + kdb_edit para hacer esto: + + &prompt.root; kdb_edit +Opening database... + +Enter Kerberos master key: + +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. + +Principal name: jane +Instance: + +<Not found>, Create [y] ? y + +Principal: jane, Instance: , kdc_key_ver: 1 +New Password: <---- enter a secure password here +Verifying password + +New Password: <---- re-enter the password here +Principal's new key version = 1 +Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? +Max ticket lifetime (*5 minutes) [ 255 ] ? +Attributes [ 0 ] ? +Edit O.K. +Principal name: <---- null entry here will cause an exit + + + + Probándolo todo + + Primero tenemos que iniciar los daemons de Kerberos. Note que + si tiene correctamente editado su /etc/rc.conf + entonces esto sucederá automaticamente cuando reinicie. + Esto solamente es necesario el el servidor Kerberos. Los clientes + Kerberos tomarán automaticamente lo que necesiten desde + el directorio /etc/kerberosIV. + + &prompt.root; kerberos & +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: EXAMPLE.COM +&prompt.root; kadmind -n & +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! + + Ahora podemos tratar usando el comando kinit + para obtener un boleto para el ID jane + que creamos arriba: + + &prompt.user; kinit jane +MIT Project Athena (grunt.example.com) +Kerberos Initialization for "jane" +Password: + + Trate de listar los tokens usando klist para ver + si realmente los tenemos: + + &prompt.user; klist +Ticket file: /tmp/tkt245 +Principal: jane@EXAMPLE.COM + + Issued Expires Principal +Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM + + Ahora trate de cambiar la contraseña usando + &man.passwd.1; para revisar si el daemon kpasswd + puede obtener autorización para la base de datos + Kerberos: + + &prompt.user; passwd +realm EXAMPLE.COM +Old password for jane: +New Password for jane: +Verifying password +New Password for jane: +Password changed. + + + + Añadiendo privilegios <command>su</command> + + Kerberos nos permite dar a cada + usuario que necesite privilegios de root + su propia contraseña &man.su.1; separada. + Ahora podemos agregar un ID que esté autorizado a + &man.su.1; root. Esto es controlado + teniendo una instancia de root + asociada con una principal. Usando kdb_edit + podemos crear la entrada jane.root en la + base de datos Kerberos: + + &prompt.root; kdb_edit +Opening database... + +Enter Kerberos master key: + +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. + +Principal name: jane +Instance: root + +<Not found>, Create [y] ? y + +Principal: jane, Instance: root, kdc_key_ver: 1 +New Password: <---- enter a SECURE password here +Verifying password + +New Password: <---- re-enter the password here + +Principal's new key version = 1 +Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? +Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short! +Attributes [ 0 ] ? +Edit O.K. +Principal name: <---- null entry here will cause an exit + + Ahora trate de obtener los tokens para asegurarse que funcione: + + &prompt.root; kinit jane.root +MIT Project Athena (grunt.example.com) +Kerberos Initialization for "jane.root" +Password: + + Ahora necesitamos agregar al usuario al archivo de root + .klogin: + + &prompt.root; cat /root/.klogin +jane.root@EXAMPLE.COM + + Ahora trate de hacer &man.su.1;: + + &prompt.user; su +Password: + + y heche un vistazo a que tokens tenemos: + + &prompt.root; klist +Ticket file: /tmp/tkt_root_245 +Principal: jane.root@EXAMPLE.COM + + Issued Expires Principal +May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM + + + + Utilizando otros comandos + + En un ejemplo anterior, creamos creamos un principal + llamado jane con una instancia root. + Esto fué basado en un usuario con el mismo nombre del + principal, y esto es por omisión en Kerberos; que + <principal>.<instancia> de la + forma + <nombre de usuario>.root + permitirá que <nombre de usuario> + haga &man.su.1; a root si las entradas necesarias + están en el archivo .klogin en el + directorio home de root: + + &prompt.root; cat /root/.klogin +jane.root@EXAMPLE.COM + + De la misma manera, si un usuario tiene en su propio directorio home + líneas de la forma: + + &prompt.user; cat ~/.klogin +jane@EXAMPLE.COM +jack@EXAMPLE.COM + + Esto permite a cualquiera en el dominio EXAMPLE.COM + que se ha autentificado como jane o como + jack (vía kinit, ver + arriba) para accesar la cuenta de jane o + archivos en este sistema (grunt) vía + &man.rlogin.1;, &man.rsh.1; o + &man.rcp.1;. + + Por ejemplo, jane se firma ahora en otro sistema + usando Kerberos: + + &prompt.user; kinit +MIT Project Athena (grunt.example.com) +Password: +&prompt.user; rlogin grunt +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 + + O jack se firma a la cuenta de jane en la misma + máquina (jane habiendo + configurado el archivo .klogin + como está arriba, y la persona a cargo de + Kerberos habiendo configurado un principal + jack con una instancia nula): + + &prompt.user; kinit +&prompt.user; rlogin grunt -l jane +MIT Project Athena (grunt.example.com) +Password: +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 + + + + + + + + Tillman + Hodgson + Contribuido por + + + + + Mark + Murray + Basado en una contribución de + + + + + <application>Kerberos5</application> + + Cada release de &os; posterior a &os;-5.1 incluye + soporte solamente para Kerberos5. + Por esta razón Kerberos5 es + la única versión incluída, y su configuración + es similar en muchos aspectos a la de KerberosIV. + La siguiente información solo aplica a + Kerberos5 en releases de + &os;-5.0 o posteriores. Los usuarios que deséen + utilizar KerberosIV pueden + instalar el port + security/krb4. + + Kerberos es un sistema/protocolo + agregado para red que le permite + a usuarios autentificarse a través de los servicios de un + servidor seguro. Servicios como login remoto, copia remota, copias + de archivo inter-sistemas seguras y otras tareas de riesgo son + hechas considerablemente seguras y más controlables. + + Kerberos puede ser descrito como + un sistema proxy identificador-verificador. También + puede ser descrito como un sistema confiable de autentificación + de terceros. + Kerberos brinda solamente + una función — la autenficación segura de + usuarios en la red. No proporciona funciones de autorización + (lo que los usuarios tienen permitido hacer) o funciones de + auditoría (lo que esos usuarios hicieron). + Despues de que un servidor y cliente han usado + Kerberos para probar su identidad, + pueden también encriptar todas sus comunicaciones para + asegurar privacidad e integridad de datos mientras continuan + con sus funciones. + + Por lo tanto es altamente recomendable que + Kerberos sea utilizado con otros + métodos de seguridad que brinden servicios de + autorización y auditoría. + + Las siguientes instrucciones pueden utilizarse como una guía + para configurar Kerberos como se + distribuye en &os;. De todas maneras, se debe dirigir a las páginas + de manual relevantes para una descripción completa. + + Para propósitos de demostrar una instalación + Kerberos, los varios espacios de + nombre serán manejados como sigue: + + + + El dominio DNS (zona) + será example.org. + + + + El dominio Kerberos (realm) + será EXAMPLE.ORG. + + + + + Por favor utilice nombres de dominio reales al + configurar Kerberos incluso si + pretende ejecutarlo internamente. Esto evita problemas + de DNS y asegura la interoperación + con otros dominios Kerberos. + + + + Historia + + Kerberos5 + history + + + Kerberos fué creado + por el 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 + probar su identidad a un servidor (y viceversa) a + través de una conexión de red insegura. + + Kerberos es el nombre de un + protocolo de autentificación de red y un adjetivo + para describir programas que implementan el programa + (Kerberos telnet, por ejemplo). + La versión actual del protocolo es la 5, descrita en + RFC 1510. + + Varias implementaciones libres de este protocolo están + disponibles, cubriendo un amplio rango de sistemas operativos. + El Massachusetts Institute of Technology (MIT), + donde Kerberos fué originalmente + desarrollado, continua desarrollando su paquete + Kerberos. Es comunmente usado en los + EU como un producto criptográfico, y + como tal ha sido historicamente afectado por las regulaciones de + exportación de EU. + El Kerberos del MIT + está disponible como un port + (security/krb5). Heimdal + Kerberos es otra implementación + de la versión 5, y fue desarrollada explicitamente fuera + de los EU para evitar las regulaciones de + exportación (y es por eso incluída en variantes + &unix; no comerciales). La distribución Heimdal + Kerberos está disponible + como un port + (security/heimdal), y una + instalación mínima viene incluída en la + instalación base de &os;. + + Para alcanzar la mayor audiencia, estas instrucciones asumen + el uso de la distribución Heimdal incluída en &os;. + + + + + Configurando un <acronym>KDC</acronym> Heimdal + + Kerberos5 + Dentro de distribución de llaves + + + El centro de distribución de llaves (KDC, + Key Distribution Center) es el servicio centralizado de autentificación + que proporciona Kerberos — es + la computadoras que emite boletos Kerberos. + El KDC está considerado como confiable + por todas las otras computadoras en el dominio Kerberos, + y por eso tiene consideraciones de seguridad más elevados. + + Note que mientras la ejecuación del servidor + Kerberos requiere muy pocos recursos + computacionales, una máquina dedicada actuando solamente + como KDC es recomendada por razones de + seguridad. + + Para empezar a configurar un KDC, asegúrese + que su archivo /etc/rc.conf contiene las + configuraciones correctas para actuar como un KDC + (tal vez necesite ajustar algunas rutas para reflejar su propio + sistema): + + kerberos5_server_enable="YES" +kadmind5_server_enable="YES" +kerberos_stash="YES" + + + está solamente + disponible en &os; 4.X. + + + A continuación configuraremos el archivo de + configuración de Kerberos, + /etc/krb5.conf: + + [libdefaults] + default_realm = EXAMPLE.ORG +[realms] + EXAMPLE.ORG = { + kdc = kerberos.example.org + admin_server = kerberos.example.org + } +[domain_realm] + .example.org = EXAMPLE.ORG + + Note que este archivo /etc/krb5.conf + implica que su KDC tendrá el nombre + de equipo completo calificado de kerberos.example.org. + Necesitará agregar una entrada CNAME (alias) a su archivo + de zona para lograr esto si su KDC tiene un + nombre de equipo diferente. + + + Para redes grandes con un servidor DNS + BIND propiamente configurado, el ejemplo + de arriba puede ser recortado a: + + [libdefaults] + default_realm = EXAMPLE.ORG + + Con las líneas siguientes agregadas al + archivo de zona example.org: + + _kerberos._udp IN SRV 01 00 88 kerberos.example.org. +_kerberos._tcp IN SRV 01 00 88 kerberos.example.org. +_kpasswd._udp IN SRV 01 00 464 kerberos.example.org. +_kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. +_kerberos IN TXT EXAMPLE.ORG + + + Para que los clientes sean capaces de encontrar los + servicios Kerberos, + debe tener ya sea un + /etc/krb5.conf completamente configurado o + un /etc/krb5.conf configurado de forma + mínima y un servidor DNS + configurado correctamente. + + + A continuación crearemos la base de datos + Kerberos. Esta base de datos contiene + las llaves de todos los principales encriptadas con una + contraseña maestra. No se requiere que usted recuerde + esta contraseña, será almacenada en un archivo + (/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 instruye a + kadmin que modifique los archivos de la base + de datos directamente en lugar de ir a través del servicio + de red kadmind. Esto maneja el problema del + huevo y la gallina de tratar de conectar a la base de datos + antes de que ésta sea creada. Una vez que tiene el prompt + de kadmin, utilice el comando init + para crear su base de datos de dominios iniciales. + + Finalmente, mientras está todavía en kadmin, + puede crear su primer principal utilizando el comando add. + Apéguese a las opciones por omisión para los + principales por ahora, puede cambiarlas despues con el comando + modify. Note que puede usar el comando + ? en cualquier prompt para ver las opciones + disponibles. + + Una sesión de ejemplo de creación de una + base de datos es mostrada abajo: + + &prompt.root; kstash +Master key: xxxxxxxx +Verifying password - Master key: xxxxxxxx + +&prompt.root; kadmin -l +kadmin> init EXAMPLE.ORG +Realm max ticket life [unlimited]: +kadmin> add tillman +Max ticket life [unlimited]: +Max renewable life [unlimited]: +Attributes []: +Password: xxxxxxxx +Verifying password - Password: xxxxxxxx + + Ahora es tiempo de iniciar los servicios KDC. + Ejecute /etc/rc.d/kerberos start y + /etc/rc.d/kadmind start para levantar los + servicios. Note que no tendrá ningún daemon + kerberizado corriendo en este punto pero debe ser capaz de confirmar + que el KDC está funcionando obteniendo + y listando un boleto para el principal (usuario) que acaba de crear + desde la línea de comando del mismo KDC: + + &prompt.user; k5init tillman +tillman@EXAMPLE.ORG's Password: + +&prompt.user; k5list +Credentials cache: FILE:/tmp/krb5cc_500 + Principal: tillman@EXAMPLE.ORG + + Issued Expires Principal +Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG + + + + + <application>Kerberos</application> habilitando un servidor con + servicios Heimdal + + + Kerberos5 + habilitando servicios + + + Primero, necesitamos una copia del archivo de configuración + de Kerberos, /etc/krb5.conf. + Para eso, simplemente copielo a la computadora cliente desde el + KDC de una manera segura (utilizando utilidades + de red como &man.scp.1;, o fisicamente con un disco flexible). + + A continuación necesita un archivo /etc/krb5.keytab. + Esta es la diferencia más grande entre un servidor + proporcionando daemons habilitados con Kerberos + y una estación de trabajo — el servidor debe + tener un archivo keytab. Este archivo + contiene las llaves de equipo del servidor, las cuales + le permiten a él y al KDC + verificar la identidad entre ellos. Debe ser transmitidos al + servidor de una manera segura, ya la seguridad en el servidor + puede ser comprometida si la llave es hecha pública. + Esto significa explicitamente que transfiriendola por medio + de un canal de texto claro, como FTP, es + una muy mala idea. + + Tipicamente, transfiere al keytab + al servidor usando el programa kadmin. + Esto es práctico porque también necesita crear + el principal del equipo (el final KDC del archivo + krb5.keytab) usando kadmin. + + Note que debe ya debe haber obtenido un boleto y que este boleto + debe tener permitido utilizar la interface kadmin + en kadmind.acl. Vea la sección titulada + administración remota en la página de + info de Heimdal (info heimdal) para los detalles + de diseño de listas de control de acceso. Si no quiere habilitar + acceso remoto kadmin, puede simplemente conectar + de manera segura al KDC (por medio de consola + local, &man.ssh.1; o &man.telnet.1; Kerberos) + y realizar localmente la administración utilizando + kadmin -l. + + Despues de instalar el archivo /etc/krb5.conf, + puede usar kadmin desde el servidor + Kerberos. el comando + add --random-key le permitirá agregar + el principal del equipo servidor, y el comando ext + le permitirá extraer el principal del equipo servidor a su + propio keytab. Por ejemplo: + + &prompt.root; kadmin +kadmin> add --random-key host/myserver.example.org +Max ticket life [unlimited]: +Max renewable life [unlimited]: +Attributes []: +kadmin> ext host/myserver.example.org +kadmin> exit + + Note que el comando ext (diminutivo + de extract) almacena la llave extraída + en /etc/krb5.keytab por omisión. + + Si no tiene kadmind corriendo en el + KDC (posiblemente por razones de seguridad) + y por lo tanto no tiene acceso a kadmin + remotamente, puede añadir el principal de equipo + (host/myserver.EXAMPLE.ORG) directamente + en el KDC y entonces extraerlo a un archivo + temporal (para evitar sobreescribir /etc/krb5.keytab + en el KDC) usando algo como esto: + + &prompt.root; kadmin +kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org +kadmin> exit + + Puede entonces copiar de manera segura el keytab al + servidor (usando scp o un disco + flexible, por ejemplo). Asegúrese de especificar + un nombre de keytab diferente para evitar sobreescribir + el keytab en el KDC. + + En este punto su servidor puede comunicarse con el + KDC (debido a su archivo + krb5.conf) y puede probar su propia + identidad (debido al archivo krb5.keytab). + Ahora está listo para que usted habilite algunos + servicios Kerberos. + Para este ejemplo habilitaremos el servicio telnet + poniendo una línea como esta en su + /etc/inetd.conf y reiniciando el + servicio &man.inetd.8; con + /etc/rc.d/inetd restart: + + telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user + + La parte crítica es -a + (por autentificación) de tipo usuario. Consulte + la página de manual &man.telnetd.8; para + más detalles. + + + + + <application>Kerberos</application> habilitando un cliente con Heimdal + + + Kerberos5 + configurar clientes + + + Configurar una computadora cliente es trivialmente fácil. + En lo que se refiera a configuración de + Kerberos, solamente necesita el + archivo de configuración de Kerberos, + localizado en /etc/krb5.conf. + Simplemente copielo de manera segura a la computadora cliente + desde el KDC. + + Pruebe su computadora cliente tratando de usar + kinit, klist, y + kdestroy desde el cliente para obtener, + mostrar y entonces borrar un boleto para el principal que + creó arriba. Debe ser capaz de usar aplicaciones + Kerberos para conectar a + servidores habilitados con Kerberos, + aunque si eso no funciona y obtener el boleto hace el problema, + lo más seguro 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 olfateador de paquetes ( como &man.tcpdump.1;) + para confirmar que su contraseña no sea enviada en claro. + Trate de usar telnet con la opción + -x, que encripta el flujo de datos por + entero (similarmente a ssh). + + Las aplicaciones clientes Kerberos + principales (tradicionalmente llamadas kinit, + klist, kdestroy y + kpasswd) están incluidas en + la instalación base de &os;. Note que versiones de &os; + anteriores a 5.0 las renombran a k5init, + k5list, k5destroy, + k5passwd y k5stash + (aunque es tipicamente utilizado solo una vez). + + Varias aplicaciones clientes Kerberos + no principales también están instaladas por + omisión. Aquí es donde la naturaleza + mínima de la instalación base de + Heimdal es sentida: telnet es el único + servicio Kerberos habilitado. + + El port Heimdal agrega algunas de las aplicaciones cliente + faltantes: versiones Kerberos habilitadas + de ftp, rsh, + rcp, rlogin y algunos + otros programas menos comunes. El port de MIT + también contiene una suite completa de aplicaciones + cliente de Kerberos. + + + + + Archivos de configuración de usuario: <filename>.k5login</filename> y <filename>.k5users</filename> + + + .k5login + + + + .k5users + + + Usuarios dentro de un dominio tipicamente + tienen su principal Kerberos + (como tillman@EXAMPLE.ORG) mapeado + a una cuenta de usuario local (como una cuenta local + llamada tillman). aplicaciones cliente + como telnet usualmente no requieren un + nombre de usuario o un principal. + + Ocasionalmente, de todas maneras, tal vez quiera dar acceso + a una cuenta de usuario local a alguien que no tiene un + principal Kerberos que concuerde. + Por ejemplo, tillman@EXAMPLE.ORG puede + necesitar acceso a la cuenta de usuario local webdevelopers. + Otros principales tal vez necesiten acceso a esas + cuentas locales. + + Los archivos .k5login y + .k5users, colocados en el directorio + home del usuario, pueden ser usados de manera similar a + una combinación potente de + .hosts y .rhosts, + resolviendo el problema. Por ejemplo, si un + .k5login con el siguiente + contenido: + + tillman@example.org +jdoe@example.org + + Fuera a ser colocado en el directorio home del usuario + local webdevelopers entonces ambos + principales listados tendrían acceso a esa cuenta + sin requerir una contraseña compartida. + + La lectura de las páginas de manual para estos + comando es recomendado. Note que la página de manual + de ksu cubre + .k5users. + + + + + <application>Kerberos</application> Tips, Trucos y solución de problemas + + + Kerberos5 + solución de problemas + + + + + Al utilizar ya sea los ports de Heimdal o Kerberos + del MIT asegúrese que su + variable de ambiente PATH liste las + versiones de Kerberos de las + aplicaciones clientes antes que las versiones del + sistema. + + + + ¿Todas las computadoras en su dominio Kerberos tienen + la hora sincronizada? Si no, la autentificación + puede fallar. + describe como sincronizar + los relojes utilizando NTP. + + + + MIT y Heimdal interoperan bien. + Excepto por kadmin, el protocola para + el cual no está estandarizado. + + + + Si cambia su nombre de equipo, necesita cambiar también + su equipo/ principal y actualizar su + keytab. Esto también aplica a entradas especiales + en keytab como www/ principal + utilizado para www/mod_auth_kerb + de Apache. + + + + Todos los equipos en su dominio Kerberos deben resolver + (normal y reverso) en el DNS (o en + /etc/hosts como mínimo). + Los CNAMEs funcionarán, pero los registros A y PTR + deben estar correctos y en su lugar. El mensaje de error + no es muy intuitivo: + Kerberos5 refuses authentication because Read req + failed: Key table entry not found. + + + + Algunos sistemas operativos que pueden estar actuando + como clientes de su KDC no activan + los permisos para ksu de manera + setuid root. Esto significa que + ksu no funciona, lo cual es una + buena idea de seguridad pero un tanto molesta. Este no es un + error de KDC. + + + + Con Kerberos del + MIT, si usted desea permitir que un + principal tenga un boleto con una vida más larga + que el valor por omisión de diez horas, debe usar + modify_principal en kadmin + para cambiar maxlife tanto del principal en cuestión + como del principal krbtgt. Entonces + el principal puede utilizar la opción + -l con kinit para + solicitar un boleto con más tiempo de vida. + + + + Si ejecuta un olfateador de paquetes en su + KDC para ayudar con la resolución + de problemas y ejecuta kinit desde una + estación de trabajo, se podrá dar cuenta + que su TGT es enviado inmediatamente + despues de correr kinit — + ¡incluso antes de que escriba su contraseña! La + explicación es que el servidor Kerberos + transmite libremente un TGT (Ticket Granting + Ticket) a cualquier petición no autorizada; de todas + maneras, cada TGT está encriptado + en un llave derivada de la contraseña de usuario. + Por lo tanto, cuando un usuario teclea su contraseña + no está siendo enviada al KDC, + está siendo usada para desencriptar el TGT + que kinit ya obtuvo. Si el proceso de + desencriptación resulta en un boleto válido con + una marca de tiempo válida, el usuario tiene + credenciales Kerberos válidas. + Estas credenciales incluyen una llave de sesión para + establecer comunicaciones seguras con el servidor + Kerberos en el futuro, así + como también el boleto otorgar-boleto (TGT) en sí, + el cual es encriptado con la llave del propio servidor + Kerberos. Esta segunda capa de + encriptación es desconocida para el usuario, pero + es lo que permite al servidor Kerberos + verificar la autenticidad de cada TGT. + + + + Si desea utilizar boletos con tiempo de vida larga (una + semana, por ejemplo) y está utilizando OpenSSH + para conectarse a la máquina donde su boleto está + almacenado, asegúrese que Kerberos + esté puesto a no + en su sshd_config o de lo contrario + sus boletos serán eliminados cuando termine la + sesión. + + + + Recuerde que los principales de equipos pueden tener + un tiempo de vida mas largo también. Si su principal + de usuario tiene un tiempo de vida de una semana pero + el equipo al que se esá conectando tiene un + tiempo de vida de nueve horas, tendrá un principal de + equipo expirado en su caché y el caché de + boleto no funcionará como se espera. + + + + Cuando esté configurando un archivo + krb5.dict para prenevir especificamente + el uso de malas contraseñas (la página de manual + de kadmind cubre esto brevemente), recuerde + que solamente aplica a principales que tienen una política + de contraseñas asignada a ellos. El formato de archivos + krb5.dict es simple: una cadena por + línea. Creando un enlace simbólico a + /usr/share/dict/words puede ser + de utilidad. + + + + + + + Diferencias con el port del <acronym>MIT</acronym> + + Las diferencias más grandes entre las instalaciones + MIT y Heimdal se relacionan al programa + kadmin el cual tiene un conjunto + diferente (pero equivalente) de comandos 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, para ese caso). + + Las aplicaciones cliente pueden también tomar + diferentes opciones de línea de comando para + lograr las mismas tareas. Seguir las instrucciones de + la página web de Kerberos + del MIT + () + se recomienda. Sea cuidadoso con los parches: el port + del MIT se instala en + /usr/local/ por omisión, y las + aplicaciones normales del sistema pueden + ser ejecutadas en lugar de las del MIT + si su variable de ambiente PATH lista los + directorios del sistema primero. + + Con el port del MIT + security/krb5 + proporcionado por &os;, asegúrese de leer el archivo + /usr/local/share/doc/krb5/README.FreeBSD + instalado por el port si quiere entender por qué los + login vía telnetd y + klogind se comportan un tanto + extraño. Más importante, corrigiendo la + conducta de permisos incorrectos en el archivo + caché requiere que el binario + login.krb5 sea usado para autentificación + para que pueda cambiar correctamente los permisos de + propiedad para credenciales reenviadas. + + + + + Mitigando limitaciones encontradas en <application>Kerberos</application> + + + Kerberos5 + limitaciones y deficiencias + + + + <application>Kerberos</application> es un enfoque todo-o-nada + + Cada servicio habilitado en la red debe ser modificado + para funcionar con Kerberos (o de + otra manera ser asegurado contra ataques de red) o de lo + contrario las credenciales de usuario pueden ser robadas y + reutilizadas. Un ejemplo de esto podría ser que + Kerberos habilite todos los shells + remotos ( vía rsh y telnet, + por ejemplo) pero que no cubra el servidor de correo + POP3 el cual manda contraseñas + en texto plano. + + + + + <application>Kerberos</application> está planeado para estaciones de trabajo mono-usuario + + En un ambiente multi-usuario, + Kerberos es menos seguro. + Esto se debe a que almacena los boletos en el + directorio /tmp, el cual puede + ser leído por todos los usuarios. Si un + usuario está compartiendo una computadora con + varias gentes simultaneamente (ej., multi-user), es posible + que los boletos de usuario sean robados (copiados) por otro + usuario. + + Esto puede ser sobrepasado con la opción de línea + de comando -c nombre-de-archivo o + (de preferencia) la variable de ambiente + KRB5CCNAME, pero esto raramente es + hecho. En principal, almacenar los boletos en el + directorio home de los usuarios y utilizar permisos + de archivo simples pueden mitigar este problema. + + + + + El KDC es un punto de falla único + + Por diseño, el KDC debe ser tan + seguro como la base de datos de contraseña maestra que + contiene. El KDC no debe tener ningún + otro servicio corriendo en él y debe ser fisicamente + seguro. El peligro es grande debido a que Kerberos + almacena todas las contraseñas encriptadas con la + misma llave (la llave maestra, la cual a su + vez está almacenada como un archivo en el + KDC). + + Como nota aparte, una llave maestra comprometida no es + tan malo como se podría temer. La llave maestra solo + es utilizada para encriptar la base de datos Kerberos + y como semilla para el generador de números aleatorios. + Mientras el acceso a su KDC sea seguro, + un atacante no puede hacer mucho con la llave maestra. + + Adicionalmente, si el KDC no está + disponible (quizás debido a un ataque de negación + de servicio o problemas de red) los servicios de red son inusables + ya que no se puede efectuar la autentificación, una receta + para un ataque de negación de servicios. Esto puede ser + aliviado con múltiples KDCs (un + maestro único y uno o más esclavos) y con + una implementación cautelosa de secundarios o + autentificación de respaldo (PAM es + excelente para esto). + + + + + Limitaciones de <application>Kerberos</application> + + Kerberos le permite a usuarios, + equipos y servicios autentificarse entre ellos. No tiene un + mecanismo para autentificar el KDC a los + usuarios, equipos o servicios. Esto significa que a + kinit con un troyano (por ejemplo) puede + grabar todos los usuarios y contraseñas. Algo como + security/tripwire o + alguna otra herramienta de revisión de integridad + de sistemas de archivo puede aliviar esto. + + + + + + Recursos y más información + + + Kerberos5 + recursos externos + + + + + + La FAQ de Kerberos + + + + Diseñando + un sistema de autentificación: un dialogo en cuatro escenas + + + + RFC 1510, + The Kerberos Network Authentication Service + (V5) + + + + Página web de MIT + Kerberos + + + + Página web de Heimdal + Kerberos + + + + + + + + + + + Tom + Rhodes + Escrito por: + + + + OpenSSL + + seguridad + OpenSSL + + + Una propiedad que muchos usuarios pasan por alto + es el conjunto de herramientas OpenSSL + incluídas en &os;. OpenSSL + brinda capa de transporte encriptada encima de la capa + de comunicaciones normal; permitiendo así que sea + combinada con muchas aplicaciones y servicios de red. + + Algunos usos de OpenSSL pueden + incluir autentificación encriptada de clientes de + correo, transacciones basadas en web como pagos de tarjetas + de crédito y más. Muchos ports, como + www/apache13-ssl y + mail/sylpheed-claws + ofrecen soporte de compilación para construirse + con OpenSSL. + + + En la mayoría de los casos la colección + de ports tratará de construir el port + security/openssl a menos + que la variable de make WITH_OPENSSL_BASE + sea puesta explicitamente a yes. + + + La versión de OpenSSL + incluída en &os; soporta los protocolos de seguridad + de red Secure Sockets Layer v2/v3 (SSLv2/SSLv3) y + Transport Layer Security v1 (TLSv1) y puede ser utilizada como + una librería criptográfica general. + + + Mientras OpenSSL soporta el + algoritmo IDEA, estáa deshabilitado + por omisión debido a patentes de Estados Unidos. Para + utilizarlo, la licencia debe ser revisada, y si las + restricciones son aceptables, la variable + MAKE_IDEA debe ser activada en + make.conf. + + + Uno de los usos más comunes de + OpenSSL es brindar certificados para + usar con aplicaciones de software. Estos certificados aseguran + que las credenciales de la compañia o individuo son + válidos y no fraudulentos. Si el certificado en + cuestión no ha sido verificado por uno de las varias + autoridades de certificados, + o CAs, usualmente se produce una advertencia. + Una autoridad de certificados es una compañia, como + VeriSign, la cual + firmará certificados para validar credenciales de individuos + o compañias. Este proceso tiene un costo asociado y no es + definitivamente un requisito para usar certificados; de todas + maneras, puede darle un poco de tranquilidad a los usuarios + más paranóicos. + + + Generando certificados + + + OpenSSL + generación de certificados + + + Para generar un certificado, el siguiente comando está + disponible: + + &prompt.root; openssl req -new -nodes -out req.pem -keyout cert.pem +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]:US +State or Province Name (full name) [Some-State]:PA +Locality Name (eg, city) []:Pittsburgh +Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company +Organizational Unit Name (eg, section) []:Systems Administrator +Common Name (eg, YOUR name) []:localhost.example.org +Email Address []:trhodes@FreeBSD.org + +Please enter the following 'extra' attributes +to be sent with your certificate request +A challenge password []:SOME PASSWORD +An optional company name []:Another Name + + Note que la respuesta directamente despues del + prompt Common Name muestra un nombre + de dominio. Este prompt requiere que se introduzca + un nombre de servidor para propósitos de + verificación; colocando cualquier cosa menos + un nombre de dominio producirá un certificado + inválido. Otras opciones, por ejemplo tiempo + de expiración, alternan algoritmos de encriptación, + etc, están disponibles. Una lista completa + puede obtenerse viendo la página de manual + &man.openssl.1;. + + Deben existir ahora dos archivos + en el directorio en el que el comando anterior fué + ejecutado. La petición de certificado, req.pem, + puede ser enviado a una autoridad de certificados que validará + las credenciales que introdujo, firmará la petición y le + regresará el certificado. El segundo archivo creado será + nombrado cert.pem y es la llave privada para + el certificado y debe ser protegida a toda costa; si esta cae en las + manos de otros puede ser utilizada para impersonarlo a usted (o a + sus servidores). + + En los casos donde una firma de una CA + no es requerida, un certificado auto firmado puede ser creado. + Primero, genere la llave RSA: + + &prompt.root; openssl dsaparam -rand -genkey -out myRSA.key 1024 + + A continuación genere la llave CA: + + &prompt.root; openssl gendsa -des3 -out myca.key myRSA.key + + Utilice esta llave para crear el certificado: + + &prompt.root; openssl req -new -x509 -days 365 -key myca.key -out new.crt + + Los dos nuevos archivos deben aparecer en el directorio: + un archivo de firma de autoridad de certificados, + myca.key y el certificado en sí, + new.crt. Estos deben ser colocados en un + directorio, de preferencia bajo + /etc, el cual es + leíble solo por root. Permisos de + 0700 deben ser suficientes para este y pueden ser puestos con + la utilidad chmod. + + + + Usando certificados, un ejemplo + + ¿Entonces que pueden hacer estos archivos? Un buen uso + sería encriptar conexiones al MTA + Sendmail. Esto disolvería + el uso de autentificación de texto claro para usuarios + que mandan correo a través del MTA + local. + + + Este no es el mejor uso en el mundo ya que algunos + MUAs presentarán al usuario + un error si no tienen instalado los certificados + localmente. Refiérase a la documentación + incluída con el software para mayor información + de la instalación de certificados. + + + Las siguientes líneas deben ser colocadas + dentro del archivo local .mc: + + 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 + + Donde /etc/certs/ + es el directorio a ser utilizado para almacenamiento de + los archivos de certificado y llave de manera local. + Los últimos requerimientos son una reconstrucción + del archivo .cf local. Esto es facilmente + logrado tecleando make + install dentro del directorio + /etc/mail. + A continuación ejecute un make + restart que debe reiniciar el + daemon de Sendmail. + + Si todo estuvo bien no habrá mensajes de error + en el archivo /var/log/maillog + y Sendmail aparecerá en + la lista de procesos. + + Para una prueba sencilla, simplemente conecte al + servidor de correo usando la utilidad &man.telnet.1;: + + &prompt.root; telnet example.com 25 +Trying 192.0.34.166... +Connected to example.com. +Escape character is '^]'. +220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) +ehlo example.com +250-example.com Hello example.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 +quit +221 2.0.0 example.com closing connection +Connection closed by foreign host. + + Si la línea STARTTLS aparece en la + salida entonces todo está funcionando correctamente. + + + + + + + + Nik + Clayton + +
nik@FreeBSD.org
+ + Escrito por + + + + + + IPsec + + + VPN sobre IPsec + Creando una VPN entre dos redes, separadas por la Internet + utilizando gateways FreeBSD. + + + + + + Hiten M. + Pandya + +
hmp@FreeBSD.org
+ + Escrito por + + + + + Entendiendo IPsec + + Esta sección le guiará a través del + proceso de configuración de IPsec, y de su uso en un + ambiente que consista en máquinas FreeBSD y + µsoft.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 + (vea ). + + IPsec es un protocolo que se sienta + encima de la capa del protocolo de Internet (IP). Le permite + a dos o mas equipos comunicarse de manera segura (de ahí + el nombre). La pila de red IPsec de FreeBSD está + basada en la implementación + KAME, la cual tiene + soporte para las dos familias de protocolos, IPv4 e IPv6. + + + FreeBSD 5.X contiene una pila IPsec acelerada + por hardware, conocida como Fast + IPsec, que fué obtenida de OpenBSD. + Emplea hardware criptográfico (cuando es posible) + a través del subsistema &man.crypto.4; para + optimizar el desempeño de IPsec. Este subsistema es + nuevo, y no soporta todas las opciones que están + disponibles en la versión KAME de IPsec. De todas + maneras, para habilitar IPsec acelerado por hardware, se + tienen que agregar las siguientes opciones de kernel al + archivo de configuración de kernel: + + + opciones de kernel + FAST_IPSEC + + + +options FAST_IPSEC # new IPsec (cannot define w/ IPSEC) + + + Note que actualmente no es posible utilizar el subsistema + Fast IPsec junto con la implementación + KAME de IPsec. Consulte la página de manual + &man.fast.ipsec.4; para mayor información. + + + + + IPsec + ESP + + + + IPsec + AH + + + IPsec consiste de dos sub-protocolos: + + + + Encapsulated Security Payload + (ESP), protege los datos del paquete IP + de interferencias de terceros, encriptando el contenido + utilizando algoritmos de criptografía simétrica + (como Blowfish, 3DES). + + + Authentication Header (AH), + protege la cabecera del paquete IP de interferencias de + terceros e imitación (spoofing), computando un + checksum criptográfico y aplicando a los campos + de cabecera IP una función hash segura. Esto es + entonces seguido por una cabecera adicional que contiene + el hash, para permitirle a la información en el + paquete ser autentificada. + + + + ESP y AH pueden + ser utilizados de manera conjunta o separada, dependiendo + del ambiente. + + + VPN + + + + Red privada virtual + VPN + + + IPsec puede ser utilizado ya sea para encriptar directamente + el tráfico entre dos equipos (conocido como + modo de transporte); o para construir + túneles virtuales entre dos subredes, + las cuales pueden ser usadas para comunicación segura + entre dos redes corporativas (conocido como modo + de tunel). Este último es comunmente + conocido como una red privada virtual (Virtual + Private Network, VPN). La página de manual + &man.ipsec.4; debe ser consultada para información + detallada sobre el subsistema IPsec en FreeBSD. + + Para agregar soporte de IPsec a su kernel, agregue las + siguientes opciones a su archivo de configuración + de kernel: + + + opciones de kernel + IPSEC + + + + opciones de kernel + IPSEC_ESP + + + +options IPSEC #IP security +options IPSEC_ESP #IP security (crypto; define w/ IPSEC) + + + + opciones de kernel + IPSEC_DEBUG + + + Si se desea soporte para la depuración de + errores, la siguiente opción también debe + ser agregada: + + +options IPSEC_DEBUG #debug for IP security + + + + + El Problema + + No existe un estándar para lo que constituye una VPN. + VPNs pueden ser implementadas utilizando un número de + tecnologías diferentes, cada una de las cuales tiene sus + propias fortalezas y debilidades. Esta sección presenta un + escenario, y las estrategias usadas para implementar una VPN + para este escenario. + + + + El escenario: dos redes, conectadas por Internet, para + comportarse como una sola + + + VPN + creando + + + La premisa es como sigue: + + + + Usted tiene al menos dos sitios + + + Ambos sitios están utilizando IP internamente + + + Ambos sitios están conectados al Internet, a + través de un gateway que esta corriendo FreeBSD. + + + El gateway en cada red tiene al menos una dirección + IP pública. + + + Las direcciones internas de las dos redes pueden ser + direcciones IP públicas o privadas, no importa. + Puede ejecutar NAT en la máquina gateway de ser + necesario. + + + Las direcciones IP internas de las dos redes + no colisionan. Aunque espero + que sea posible teoricamente utilizar una combinación + de tecnología VPN y NAT para hacer funcionar + esto, espero que sea una pesadilla de + configuración. + + + + Si encuentra que está tratando de conectar dos redes, + donde ambas utilizan el mism rango de direcciones IP privadas + (ej., las dos usan 192.168.1.x), entonces una de las dos redes + debe ser renumerada. + + La topología de red puede verse de manera similar + a esto: + + + + + + + +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 ] + + + + Note las dos direcciones IP públicas. Usaré las + letras para referirme a ellas en el resto de este artículo. + El cualquier lugar que vea esas letras en este artículo, + reemplacelas con su propia dirección IP pública. + Note también que internamente, las dos máquinas + gateway 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 en las redes privadas han sido configuradas para + utilizar la máquina .1 + como su gateway por omisión. + + 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 ruteador -- + aunque sea un ruteador 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 + + ping 192.168.2.34 + + y recibir una respuesta, transparentemente. Las máquinas + &windows; deben ser capaces de ver a las máquinas en la + otra red, accesar a archivos compartidos, y demás, + exactamente de la misma manera en que accesan a las + máquinas en la red local. + + Y todo la cosa debe ser segura. Esto significa que el + tráfico entre las dos redes tiene que ser + encriptado. + + Crear una VPN entre estas dos redes es un proceso multi-paso. + Las etapas son las siguientes: + + + + Crear un enlace de red virtual entre las dos + redes, a través de Internet. Probarlo, usando herramientas + como &man.ping.8;, para asegurarse que funcione. + + + + Aplicar políticas de seguridad para asegurarse + que el tráfico entre las dos redes sea transparentemente + encriptado y desencriptado según sea necesario. + Probar esto, usando herramientas como &man.tcpdump.1;, + para asegurarse que el tráfico esté encriptado. + + + + Configurar software adicional en los gateways FreeBSD, + para permitir a las máquinas &windows; verse entre + ellas a través de la VPN. + + + + + Paso 1: Creando y probando un enlace de red <quote>virtual</quote> + + Suponga que usted está en la máquina gateway + en la red #1 (con dirección IP pública A.B.C.D, dirección IP privada + 192.168.1.1), y ejecuta + ping 192.168.2.1, que es la dirección + privada de la máquina con dirección IP + W.X.Y.Z. ¿Que necesita suceder + para que esto funcione? + + + + La máquina gateway necesita saber como alcanzar + a 192.168.2.1. En otras + palabras, necesita tener una ruta a 192.168.2.1. + + + Las direcciones IP privadas, como aquellas en el rango + 192.168.x no se supone + que aparezcan en Internet sueltas. En lugar de eso, cada + paquete que mande a 192.168.2.1 + necesitará ser encerrado dentro de otro paquete. + Este paquete necesitará aparecer como si fuera + enviado desde A.B.C.D, + y tendrá que ser enviado a W.X.Y.Z. Este proceso es llamado + encapsulación. + + + Una vez que este paquete llega a + W.X.Y.Z necesitará + ser desencapsulado, y entregado a + 192.168.2.1. + + + + Puede pensar en ello como si se necesitara un tunel + entre las dos redes. Las dos bocas del tunel son + las direcciones IP A.B.C.D y + W.X.Y.Z, y se debe decir al tunel + las direcciones de las direcciones IP privadas que serán + permitidas que pasen a través de él. El tunel es + usado para transferir tráfico con direcciones IP + privadas a través del Internet público. + + Este tunel es creado utilizando la interfaz genérica, + o dispositivo gif en FreeBSD. Como + puede imaginarse, la interfaz gif + en cada equipo gateway debe ser configurada con cuatro + direcciones IP; dos para las direcciones IP públicas, + y dos para las direcciones IP privadas. + + El soporte para el dispositivo gif debe ser compilado + en el kernel de &os; para ambas máquinas. Puede + hacer esto agregando la línea: + + device gif + + a los archivos de configuración del kernel en + ambas máquinas, y entonces compilarlo, instalarlo + y reiniciar normalmente. + + La configuración del tunel es un proceso de dos + partes. Primero se le debe decir al tunel cuales son las + direcciones IP exteriores (o públicas), utilizando + &man.gifconfig.8;. Luego, las direcciones IP deben ser + configuradas usando &man.ifconfig.8;. + + + En &os; 5.X, la funcionalidad brindada por la + utilidad &man.gifconfig.8; ha sido fusionada a + &man.ifconfig.8;. + + En la máquina gateway de la red #1 debe ejecutar + los siguientes dos comandos para configurar el tunel. + + gifconfig gif0 A.B.C.D W.X.Y.Z +ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff + + + En la otra máquina gateway ejecute los mismos + comandos, pero con el orden las direcciones IP + invertidas. + + gifconfig gif0 W.X.Y.Z A.B.C.D +ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff + + + Entonces puede ejecutar: + + gifconfig gif0 + + para ver la configuración. Por ejemplo, en el + gateway de la red #1, usted vería algo como esto: + + &prompt.root; gifconfig gif0 +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 + + + Como puede ver, se ha creado un tunel entre las direcciones + físicas A.B.C.D y + W.X.Y.Z, y el tráfico + permitido a través del tunel es entre + 192.168.1.1 y + 192.168.2.1. + + Esto también habrá agregado una entrada en + la tabla de ruteo en ambas máquinas, la cual puede + examinar con el comando netstat -rn. + Esta salida es de la máquina gateway en la red #1. + + &prompt.root; netstat -rn +Routing tables + +Internet: +Destination Gateway Flags Refs Use Netif Expire +... +192.168.2.1 192.168.1.1 UH 0 0 gif0 +... + + + Como el valor de Flags lo indica, esta + es una ruta de equipo, lo que significa que cada gateway + conoce como alcalzar al otro gateway, pero no saben como + alcanzar el resto de sus respectivas redes. Ese problema + será solucionado proximamente. + + Es posible que usted esté ejecutando un + firewall en ambas máquinas. Esto necesitará + ser transpasado por el tráfico VPN. Tal vez desée + permitir todo el tráfico entre ambas redes, o tal + vez quiera incluir reglas en el firewall que protejan ambos + extremos de la VPN del otro. + + Las pruebas se simplifican enormemente si configura + el firewall para permitir todo el tráfico a + través de la VPN. Siempre puede apretar las cosas + despues. Si está utilizando &man.ipfw.8; en las + máquinas gateway entonces un comando como + + ipfw add 1 allow ip from any to any via gif0 + + permitirá todo el tráfico entre los dos + extremos de la VPN, sin afectar sus otras reglas del + firewall. Obviamente necesitará ejecutar este comando + en ambos equipos gateway. + + Esto es suficiente para permitir a cada máquina + gateway hacer un ping entre ellas. En 192.168.1.1, + usted debe ser capaz de ejecutar + + ping 192.168.2.1 + + y obtener una respuesta, y debe ser capaz de hacer lo + mismo en la otra máquina gateway. + + De todas maneras, no será capaz de alcanzar + máquinas internas en cada red todavía. Esto + se debe al ruteo -- aunque las máquinas gateway + saben como alcanzarse entre ellas, no saben como alcanzar + la red detrás de cada una. + + Para resolver este problema debe añadir una ruta + estática en cada máquina gateway. El comando + para hacer esto en el primer gateway podría ser: + + route add 192.168.2.0 192.168.2.1 netmask 0xffffff00 + + + Esto significa Para alcanzar los equipos en + la red 192.168.2.0, envía + los paquetes al equipo 192.168.2.1. + Necesitará ejecutar un comando similar en el otro + gateway, pero con las direcciones + 192.168.1.x. + + El tráfico IP de equipos en una red no será + capaz de alcanzar equipos en la otra red. + + Eso ha creado ahora dos tercios de una VPN entre las dos + redes, de la misma manera que es virtual y + es una network. Todavía no es privada. + Puede probar esto utilizando &man.ping.8; y &man.tcpdump.1;. + Abra una sesión en el equipo gateway y ejecute + + tcpdump dst host 192.168.2.1 + + En otra sesión en el mismo equipo ejecute + + ping 192.168.2.1 + + Verá una salida que se parece algo a esta: + + +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 + + + Como puede ver, los mensajes ICMP van y vienen sin + encriptar. Si hubiera usado el parámetro + en &man.tcpdump.1; para tomar más bytes de datos de + estos paquetes, vería más información. + + Obviamente esto es inaceptable. La siguiente sección + discutirá el aseguramiento del enlace entre las dos + redes para que todo el tráfico sea encriptado + automaticamente. + + + Sumario: + + Configure ambos kernels con pseudo-device + gif. + + + Edite /etc/rc.conf en el equipo + gateway #1 y agregue las siguientes líneas + (reemplazando direcciones IP según sea necesario). + 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" + + + + + Edite su script de firewall + (/etc/rc.firewall, o similar) en ambos + equipos, y agregue + + ipfw add 1 allow ip from any to any via gif0 + + + Realice cambios similares a + /etc/rc.conf en el equipo gateway + #2, invirtiendo el orden de las direcciones IP. + + + + + + Paso 2: Asegurando el enlace + + Para asegurar el enlace usaremos IPsec. IPsec brinda un + mecanismo para que dos equipos coincidan en una llave de + encriptación, y entonces usar esta llave para + encriptar los datos entre los dos equipos. + + Existen dos áreas de configuración a considerar + aquí. + + + + Debe existir un mecanismo para que los dos equipos + se pongan de acuerdo en el mecanismo de encriptación + a utilizar. Una vez que los dos equipos se han puesto de + acuerdo en este mecanismo se dice que existe una + asociación de seguridad + entre ellos. + + + Debe existir un mecanismo para especificar que tráfico + debe ser encriptado. Obviamente, usted no desea encriptar + todo su tráfico saliente -- usted solo desea + encriptar el tráfico que es parte de la VPN. Las + reglas que usted pone para determinar que tráfico + será encriptado son llamadas políticas + de seguridad. + + + + Las asociaciones de seguridad y las políticas + son mantenidas por el kernel, y pueden ser modificadas + por programas de usuario. De todas maneras, antes de que usted + pueda hacer esto debe configurar el kernel para soportar IPsec y + el protocolo ESP (Encapsulated Security Payload). Esto es + realizado configurando el kernel con: + + + opciones de kernel + IPSEC + + + options IPSEC +options IPSEC_ESP + + + y recompilando, resintalando y reiniciando. Como se dijo + anteriormente, necesitará hacer esto al kernel de los + dos equipos gateway. + + + IKE + + + Tiene dos opciones cuando se trata de configurar + asociaciones de seguridad. Puede configurarlas a mano entre + los dos equipos, lo que significa elegir el algoritmo de + encriptación, llaves de encriptación, y demás, + o puede utilizar daemons que implementan el protocolo + de intercambio de llaves de Internet (IKE, Internet Key Exchange) + para que lo hagan por usted. + + Yo recomiendo lo último. Aparte de cualquier otra + cosa, es más fácil de configurar. + + + IPsec + políticas de seguridad + + + + setkey + + + Editar y desplegar políticas de seguridad es llevado + a cabo usando &man.setkey.8;. Como una analogía, + setkey es a las tablas de políticas de + seguridad del kernel lo que &man.route.8; es a las tablas de + ruteo del kernel. setkey también puede + desplegar las asociaciones de seguridad actuales, y para + continuar con la analogía, similarmente a + netstat -r es ese aspecto. + + Existen un número de opciones de daemons para + administrar las asociaciones de seguridad en FreeBSD. Este + artículo describirá como usar una de ellas, + racoon — el cual está disponible como + security/racoon en la + colección de ports de &os;. + + + racoon + + + El software security/racoon + debe ser ejecutado en los dos equipos gateway. En cada equipo es + configurado con la dirección IP del otro extremo de la + VPN, y una llave secreta (la cual usted elije, y debe ser la misma + en ambos gateways). + + Los dos daemons entonces se contactan entre ellos, confirman + que son quienes dicen ser (utilizando la llave secreta que usted + configuró). Los daemons entonces generan una nueva llave + secreta, y la utilizan para encriptar el tráfico a + través de la VPN. Periodicamente intercambian este + secreto, para que incluso si un atacante fuera a comprometer una + de las llaves (lo cual es teoricamente cercano a imposible) no + le haría mucho bien -- para cuando haya crackeado la + llave los daemons ya habrán escogido una nueva. + + El archivo de configuración para racoon + está almacenado en ${PREFIX}/etc/racoon. + Debe encontrar un archivo de configuración ahí + el cual no debe necesitar ser cambiado mucho. El otro + componente de la configuración de racoon, la cual + necesitará cambiar, es la llave + precompartida. + + La configuración por omisión de racoon + espera encontrar esto en el archivo ${PREFIX}/etc/racoon/psk.txt. + Es importante notar que la llave precompartida no + es la llave que será utilizada para encriptar su + tráfico a través del enlace VPN, solamente es un + símbolo que permite le a los daemons que administran las + llaves confiar el uno en el otro. + + psk.txt contiene una línea + por cada sitio remoto con el que esté tratando. En + este ejemplo, donde existen dos sitios, cada archivo + psk.txt contendrá una línea + (porque cada extremo de la VPN solo está tratando + con un sitio en el otro extremo). + + En el equipo gateway #1 esta línea debería + parecerse a esta: + + W.X.Y.Z secret + + Esto es, la dirección IP pública + en el extremo remoto, espacio en blanco, y un texto de cadena que + proporcina el secreto. Obviamente, no debe utilizar secret + como su llave -- las reglas normales para escoger una contraseña + aplican. + + En el equipo gateway #2 la línea se parecería + a esta + + A.B.C.D secret + + Esto es, la dirección IP pública del + extremo remoto, y la misma llave secreta. psk.txt + debe tener modo 0600 (ej., solo modo + lectura/escritura para root) antes de + que racoon corra. + + Debe ejecutar racoon en ambas máquinas gateway. + También necesitará agregar algunas reglas de + firewall para permitir el tráfico IKE, el cual es + transportado sobre UDP al puerto ISAKMP (Internet Security + Association Key Management Protocol). De nuevo, esto debe estar + al principio de la lista de reglas del firewall. + + 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 + + + Una vez que racoon este corriendo puede tratar de dar un + ping a un equipo gateway desde el otro. La conexión + todavía no está encriptada, pero entonces racoon + creará las asociaciones de seguridad entre los dos + equipos -- esto puede tomar un momento, y puede que lo vea + como un corto retraso antes de que los comandos ping + empiecen a responder. + + Una vez que se han creado las asociaciones de seguridad + puede verlas utilizando &man.setkey.8;. Ejecute + + setkey -D + + en cualquiera de los equipos para ver la información de + la asociación de seguridad. + + Eso es la mitad del problema. La otra mitad es configurar + sus políticas de seguridad. + + Para crear una política de seguridad sensible, vamos + a revisar lo que se ha configurado hasta el momento. Esta + discusión cuenta para ambos extremos del enlace. + + Cada paquete IP que usted manda tiene una cabecera que + contiene datos acerca del paquete. La cabecera incluye la + dirección IP del destino y de la fuente. Como ya sabemos, + las direcciones IP privadas, como el rango + 192.168.x.y no se supone que + aparezcan en el Internet público. En vez de eso, primero + deben ser encapsulados dentro de otro paquete. Este paquete + debe tener la dirección IP pública de destino y fuente + sustituidas por las direcciones privadas. + + Así que si su paquete saliente empezó luciendo como este: + + + + + + + + + .----------------------. + | Src: 192.168.1.1 | + | Dst: 192.168.2.1 | + | <other header info> | + +----------------------+ + | <packet data> | + `----------------------' + + + + Entonces será encapsulado dentro de otro paquete, + luciendo como este: + + + + + + + + + .--------------------------. + | 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> | | + | `----------------------' | + `--------------------------' + + + + Esta encapsulación es llevada a cabo + por el dispositivo gif. Como puede + ver, el paquete ahora tiene una dirección IP real en + el exterior, y nuestro paquete original ha sido envuelto + como dato dentro del paquete que será puesto en + Internet. + + Obviamente, queremos que todo el tráfico entre + las VPNs esté encriptado. Tal vez pueda tratar + de poner esto en palabras, como: + + Si un paquete sale desde A.B.C.D, y está destinado para + W.X.Y.Z, entonces encríptalo, + utilizando las asociaciones de seguridad necesarias. + + Si un paquete llega desde W.X.Y.Z, y está destinado para + A.B.C.D, entonces desencríptalo, + utilizando las asociaciones de seguridad necesarias. + + Eso es un aproximado, pero no del todo correcto. Si hace esto, + todo el tráfico desde y hacia W.X.Y.Z, + incluso tráfico que no es parte de la VPN, será + encriptado. Eso no es exactamente lo que quiere. La política + correcta es como sigue + + Si un paquete sale desde A.B.C.D, y ese paquete está + encapsulando a otro paquete, y esta destinado para + W.X.Y.Z, entonces encríptalo, + utilizando las asociaciones de seguridad necesarias. + + Si un paquete llega desde W.X.Y.Z, y ese paquete está + encapsulando a otro paquete, y esta destinado para + A.B.C.D, entonces desencríptalo, + utilizando las asociaciones de seguridad necesarias. + + Un cambio sutil, pero necesario. + + Las políticas de seguridad también son + puestas utilizando &man.setkey.8;. &man.setkey.8; proporciona + un lenguaje de configuración para definir la + política. Puede ya sea introducir las instrucciones de + configuración vía stdin, o puede usar la opción + para especificar un nombre de archivo que + contenga las instrucciones de configuración. + + La configuración en el equipo gateway #1 (el cual + tiene la dirección IP pública + A.B.C.D) para forzar que todo + el tráfico saliente hacia W.X.Y.Z + sea encriptado es: + + +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; + + + Ponga estos comando en un archivo (ej., + /etc/ipsec.conf) y entonces ejecute + + &prompt.root; setkey -f /etc/ipsec.conf + + le dice a &man.setkey.8; que + queremos agregar una regla a la base de datos de políticas + segura. El resto de esta línea especifica que paquetes + se ajustarán a esta política. + A.B.C.D/32 y + W.X.Y.Z/32 son las direcciones IP + y máscaras de red que identifican la red o equipos a los + que esta política se aplicará. En este caso, queremos + aplicarla al tráfico entre estos dos equipos. + dice que esta política aplica + a paquetes salientes, e dice que el + paquete será asegurado. + + La segunda línea especifica como este paquete + será encriptado. es el + protocolo que será utilizado, mientras que + indica que el paquete será + despues encapsulado en un paquete IPsec. El uso repetido de + A.B.C.D y + W.X.Y.Z es utilizado para + seleccionar la asociación de seguridad a usar, y + por último exige que los + paquetes deben ser encriptados si concuerdan con esta + regla. + + Esta regla solo concuerda con paquetes salientes. + Necesitará una regla similar para los paquetes + entrantes. + + 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; + + Note el en lugar del + en este caso, y la inversión necesaria de las direcciones + IP. + + El otro equipo gateway (el cual tiene la dirección + IP pública W.X.Y.Z) + necesitará reglas similares. + + 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; + + Finalmente, necesita añadir reglas de firewall + para permitir la circulación de paquetes ESP e IPENCAP + de ida y vuelta. Estas reglas necesitarán ser agregadas + a ambos equipos. + + 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 + + + Debido a que las reglas son simétricas puede utilizar + las mismas reglas en cada equipo gateway. + + Los paquetes salientes se verán ahora como esto: + + + + + + + + + .------------------------------. --------------------------. + | 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> | | | | | | + | | `----------------------' | | -' | | + | `--------------------------' | -------------' | + `------------------------------' --------------------------' + + + + + cuando son recibidos por el extremo más lejano de la + VPN primero serán desencriptados (utilizando las + asociaciones de seguridad que han sido negociadas por racoon). + Entonces entrarán a la interfaz gif, + la cual desenvuelve la segunda capa, hasta que le deja con el + paquete más interno, el cual puede entonces viajar a + la red interna. + + Puede revisar la seguridad utilizando la misma prueba de + &man.ping.8; anterior. Primero, inicie una sesión en + la máquina gateway A.B.C.D, + y ejecute: + + tcpdump dst host 192.168.2.1 + + En otra sesión en la misma máquina ejecute + + ping 192.168.2.1 + + Esta vez debe ver una salida similar a la siguiente: + + XXX tcpdump output + + ahora, como puede ver, &man.tcpdump.1; muestra los paquetes ESP. + Si trata de examinarlos con la opción + verá basura (aparentemente), debido a la encriptación. + + Felicitaciones. Acaba de configurar una VPN entre dos sitios + remotos. + + + Sumario + + Configure ambos kernels con: + + options IPSEC +options IPSEC_ESP + + + + Instale security/racoon. + Edite ${PREFIX}/etc/racoon/psk.txt en ambos + equipos gateway, agregando una entrada para la dirección + IP del equipo remoto y una llave secreta que ambos conozcan. + Asegúrese que este archivo tenga modo 0600. + + + Añada las siguientes líneas a + /etc/rc.conf en cada equipo: + + ipsec_enable="YES" +ipsec_file="/etc/ipsec.conf" + + + + Crée un /etc/ipsec.conf en + cada equipo que contenga las líneas spdadd necesarias. + En el equipo gateway #1 esto sería: + + +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; + + + En el equipo gateway #2 esto sería: + + +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; + + + + Agregue reglas de firewall para permitir el + tráfico IKE, ESP e IPENCAP en ambos equipos: + + +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 + + + + + Los dos pasos previos deben ser suficiente para levantar la + VPN. Las máquinas en cada red seán capaces de + referirse una a otra utilizando direcciones IP, y todo el tráfico + a través del enlace será automatica y seguramente + encriptado. + + + + + + + + + Chern + Lee + Contribuido por + + + + + + OpenSSH + OpenSSH + + seguridad + OpenSSH + + + OpenSSH es un conjunto de herramientas de conectividad + utilizadas para accesar máquinas remotas de manera segura. Puede ser usado + como un reemplzado directo para rlogin, + rsh, rcp y + telnet. Adicionalmente, cualquier otra conexión + TCP/IP puede ser tuneleada/reenviada de manera segura a través + de SSH. OpenSSH encripta todo el tráfico para + eliminar efectivamente el espionaje, secuestro de conexiones, y otros ataques + a nivel de red. + + OpenSSH es mantenido por el proyecto OpenBSD, y está + basado sobre SSH v1.2.12 con todos errores recientes corregidos y actualizaciones. + Es compatible con los protocolos SSH 1 y 2. OpenSSH ha + estado en el sistema base desde FreeBSD 4.0. + + + Ventajas de utilizar OpenSSH + + Normalmente, al utilizar &man.telnet.1; o &man.rlogin.1;, + los datos son enviados a través de la red de una + forma clara, no encriptada. Cualquier olfateador de red + entre el cliente y el servidor puede robar la información + de usuario/contraseña o los datos transferidos en + su sesión. OpenSSH ofrece una + variedad de métodos de autentificación y + encriptación para prevenir que esto suceda. + + + + Habilitando sshd + + OpenSSH + habilitando + + + El daemon sshd está + habilitado por omisión en &os; 4.X y puede + ser habilitado o no durante la instalación por el + usuario en &os; 5.X. Para ver si está habilitado, + revise el archivo rc.conf por: + + sshd_enable="YES" + + Esto cargará &man.sshd.8;, el programa daemon de OpenSSH, + la próxima vez que su sistema inicie. Alternativamente, + puede simplemente correr directamente el daemon sshd + tecleando sshd en la línea de comando. + + + + Cliente SSH + + OpenSSH + cliente + + + La utilidad &man.ssh.1; funciona de manera + similar a &man.rlogin.1;. + + &prompt.root; ssh user@example.com +Host key not found from the list of known hosts. +Are you sure you want to continue connecting (yes/no)? yes +Host 'example.com' added to the list of known hosts. +user@example.com's password: ******* + + El login continuará como si lo haría si fuera + una sesión utilizando rlogin o + telnet. SSH utiliza un sistema de huellas de + llaves para verificar la autenticidad del servidor cuando el + cliente se conecta. Al usuario se le pide que introduzca + yes solamente la primera vez que se + conecta. Todos los intentos futuros de login son verificados + contra la huella de la llave salvada. El cliente SSH le alertará + si la huella guardada difiere de la huella recibida en intentos + de login futuros. Las huellas son almacenadas en + ~/.ssh/known_hosts, o en + ~/.ssh/known_hosts2 para huellas + SSH v2. + + Por omisión, versiones recientes de + los servidores OpenSSH solamente + aceptan conexiones SSH v2. El cliente utilizará la + versión 2 de ser posible y pasará como + respaldo a la versión 1. El cliente puede también + ser forzado a utilizar una u otra pasándole + o para versión 1 o versión 2 + respectivamente. La compatibilidad de versión 1 es + mantenida en el cliente para compatibilidad con versiones + antiguas. + + + + Copia segura + + OpenSSH + copia segura + + scp + + El comando &man.scp.1; funciona de manera + similar a &man.rcp.1;; copia un archivo desde o hacia + una máquina remota, excepto que lo hace de + una forma segura. + + &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT +user@example.com's password: ******* +COPYRIGHT 100% |*****************************| 4735 +00:00 +&prompt.root; + + Ya que la huella fué ya salvada para este equipo en + el ejemplo anterior, es verificada al utilizar &man.scp.1; + aquí. + + Los argumentos pasados a &man.scp.1; son similares + a &man.cp.1;, con el archivo o archivos en el primer + argumento, y el destino en el segundo. Ya que el archivo + es transferido a través de la red, a través de + SSH, uno o más argumentos toman la forma + . + + + + + Configuración + + OpenSSH + configuración + + + Los archivos de configuración del sistema + para el daemon OpenSSH y el + cliente reside dentro del directorio /etc/ssh. + + ssh_config configura las opciones + del cliente, mientras que sshd_config + configura el daemon. + + Adicionalmente, las opciones + (/usr/sbin/sshd por omisión), + y de rc.conf + pueden brindar más niveles de configuración. + + + + ssh-keygen + + En lugar de utilizar contraseñas, &man.ssh-keygen.1; + puede ser utilizado para generar llaves DSA o RSA para + autentificar a un usuario: + + &prompt.user; ssh-keygen -t dsa +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 user@host.example.com + + + &man.ssh-keygen.1; creará un par de llaves + pública y privada para usar en la autentificación. + La llave privada es almacenada en + ~/.ssh/id_dsa o en + ~/.ssh/id_rsa, mientras que la llave + pública es almacenada en ~/.ssh/id_dsa.pub + o en ~/.ssh/id_rsa.pub, respectivamente para + tipos de llave DSA y RSA. La llave pública debe ser + colocada en ~/.ssh/authorized_keys de la + máquina remota para que la configuración funcione. + Similarmente, llaves RSA versión 1 deben ser colocadas en + ~/.ssh/authorized_keys. + + Esto permitirá conexiones a la máquina remota + basándose en llaves SSH en lugar de contraseñas. + + Si una frase es utilizada en &man.ssh-keygen.1;, se le + pedirá al usuario una contraseña cada + vez para poder utilizar la llave privada. &man.ssh-agent.1; + puede aliviar el esfuerzo de introducir repetidamente + frases largas, y esto es explorado en la sección + abajo. + + Las varias opciones y archivos pueden ser + diferentes de acuerdo a la versión de OpenSSH + que tenga en su propio sistema; para evitar problemas debe + consultar la página de manual &man.ssh-keygen.1;. + + + + ssh-agent y ssh-add + + Las utilidades &man.ssh-agent.1; y &man.ssh-add.1; brindan + métodos para que llaves SSH + sean cargadas en memoria para su uso, sin tener que necesitar + el tecleo de la frase cada vez. + + La utilidad &man.ssh-agent.1; manejará la + autentificación utilizando la llave(s) privada que se + le cargó. &man.ssh-agent.1; debe ser utilizado para + lanzar otra aplicación. En el nivel más básico, + puede generar un shell o a un nivel más avanzado, un + manejador de ventanas. + + Para usar &man.ssh-agent.1; en un shell, primero necesitará + ser generado con un shell como argumento. Segundo, la + identidad necesita ser añadida ejecutando &man.ssh-add.1; + y brindando la frase para la llave privada. Una vez que se han + completado estos pasos el usuario será capaz de hacer + &man.ssh.1; a cualquier equipo que tenga instalada la llave + pública correspondiente. Por ejemplo: + + &prompt.user; ssh-agent csh +&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; + + Para utilizar &man.ssh-agent.1; en X11, una + llamada a &man.ssh-agent.1; necesitará ser + colocada en ~/.xinitrc. Esto + brindará los servicios de &man.ssh-agent.1; + a todos los programas lanzados en X11. + Un archivo ~/.xinitrc de ejemplo + podría lucir como este: + + exec ssh-agent startxfce4 + + Esto lanzaría &man.ssh-agent.1;, el cual a su + vez lanzaría XFCE, cada + vez que inicie X11. Entonces una vez que se ha hecho y X11 + ha sido reiniciado para que los cambios tomen efecto, + simplemente ejecute &man.ssh-add.1; para cargar todas sus + llaves SSH. + + + + Túneles SSH + + OpenSSH + túneles + + + OpenSSH tiene la habilidad de crear un tunel para + encapsular otro protocolo en una sesión encriptada. + + El siguiente comando le dice a &man.ssh.1; que realice un + tunel para telnet: + + &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com +&prompt.user; + + El comando ssh es utilizado con + las siguientes opciones: + + + + + + + Obliga a ssh a utilizar la + versión 2 del protocolo. (No utilizar si + está trabajando con servidores SSH antiguos) + + + + + + + + Indica no comando, o solamente tunel. Si se omite, + ssh iniciaría una sesión + normal. + + + + + + + + Obliga a ssh a ejecutarse + en segundo plano. + + + + + + + + Indica un tunel local de la manera + puerto local:equipo remoto:puerto remoto. + + + + + + + + El servidor SSH remoto. + + + + + + Un tunel SSH funciona creando un socket que escucha + en localhost en el puerto especificado. + Entonces 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 está diendo reenviado al + puerto 23 en el localhost + de la máquina remota. Ya que 23 es + telnet, esto crearía una sesión + telnet segura a través de un tunel + SSH. + + Esto puede ser utilizado para envolver cualquier + número de protocolos inseguros TCP como SMTP, + POP3, FTP, etc. + + + Usando SSH para crear un túnel seguro para SMTP + + &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com +user@mailserver.example.com's password: ***** +&prompt.user; telnet localhost 5025 +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. +220 mailserver.example.com ESMTP + + Esto puede utilizarse junto con + &man.ssh-keygen.1; y cuentas de usuario adicional para + crear un ambiente más transparente/libre de problemas. + Las llaves pueden ser usadas en lugar de teclear una + contraseña, y los túneles pueden ser + ejecutados como un usuario separado. + + + + Ejemplos prácticos de túneles SSH + + + Acceso seguro a un servidor POP3 + + 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 corriendo un + servidor POP3. La red, o ruta de red entre su casa y + oficina puede o no ser completamente confiable. Debido + a esto, necesita revisar su correo electrónico + de manera 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. + + &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com +user@ssh-server.example.com's password: ****** + + cuando el túnel esté levantado y funcionando, + puede apuntar su cliente de correo para enviar peticiones + POP3 a localhost en el puerto 2110. + Una conexión será reenviada de manera segura + a traveés del túnel a mail.example.com. + + + + Saltándose un firewall draconiano + + Algunos administradores de red imponen reglas de + firewall extremadamente draconianas, filtrando no + solamente conexiones entrantes, sino también + conexiones salientes. Tal vez solo se le otorgue acceso + para contactar máquinas remotas en los puertos 22 + y 80 para ssh y navegar en web. + + Tal vez quiera accesar otros (quizás no + relacionados al trabajo) servicios, como un servidor + Ogg Vorbis para escuchar música. Si este + servidor Ogg Vorbis está transmitiendo en algún + otro puerto diferente de 22 y 80, no podrá tener + acceso a él. + + La solución es crear una conexión SSH + fuera del firewall de su red, y utilizarla para hacer un + túnel al servidor Ogg Vorbis. + + &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org +user@unfirewalled-system.example.org's password: ******* + + Su cliente de música puede ahora ser + apuntado a localhost puerto 8888, + el cual será reenviado a music.example.com + puerto 8000, evadiendo con éxito el firewall. + + + + + + La opción de usuarios <varname>AllowUsers</varname> + + Es siempre una buena idea limitar que usuarios pueden + entrar y desde donde. La opción AllowUsers + es una buena manera de lograr esto. Por ejemplo, para permitir + solamente entrada al usuario root desde + 192.168.1.32, algo como esto + podría ser apropiado en el archivo + /etc/ssh/sshd_config: + + AllowUsers root@192.168.1.32 + + Para permitir al usuario admin la + entrada desde cualquier lugar, solamente liste el nombre + de usuario: + + AllowUsers admin + + Múltiples usuarios pueden ser listados en la misma + línea, como: + + + AllowUsers root@192.168.1.32 admin + + + Es importante que liste cada usuario que necesite entrar + a esta máquina; de otra forma no podrán entrar. + + + Despues de hacer los cambios a + /etc/ssh/sshd_config debe decirle a + &man.sshd.8; que cargue de nuevo sus archivos de + configuración ejecutando: + + &prompt.root; /etc/rc.d/sshd reload + + + + Más lecturas + OpenSSH + &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; + &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5; + &man.sshd.8; &man.sftp-server.8; &man.sshd.config.5; + + + + + + + + Tom + Rhodes + Contribuido por + + + + + ACL + + Listas de control de acceso a sistemas de archivos + + Junto a mejoramientos del sistema de archivos como instantáneas + (snapshots), FreeBSD 5.0 y posteriores ofrecen la seguridad de + listas de control de acceso a sistemas de archivos + (ACLs, Access Control Lists). + + 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 le permite a un + administrador hacer uso y tomar ventaja de un modelo de + seguridad más sofisticado. + + Para habilitar soporte de ACL para sistemas + de archivos UFS, la siguiente opción: + + options UFS_ACL + + debe ser compilada en el kernel. Si esta opción + no ha sido compilada, un mensaje de advertencia será + desplegado cuando se intente montar un sistema de archivos + soportando ACLs. Esta opción es + incluida en el kernel GENERIC. + ACLs dependen que atributos extendidos sean + habilitados en el sistema de archivos. Los atributos extendidos + están soportados nativamente en la próxima + generación de sistemas de archivos &unix;, UFS2. + + Un nivel mas elevado de carga adminitrativa es requerido + para configurar atributos extendidos en UFS1 + que en UFS2. El desempeño de atributos + extendidos en UFS2 también es substancialmente + más elevado. Como resultado, UFS2 es + generalmente recomendado respecto a UFS1 + en preferencia para su uso con listas de control de acceso. + + ACLs son habilitadas por la bandera administrativa + al momento de montaje, , la cual puede ser añadida + a /etc/fstab. La bandera de montaje puede también + ser automaticamente activada de una manera persistente utilizando + &man.tunefs.8; para modificar una bandera de superbloque ACLs + en la cabecera del sistema de archivos. En general, es preferible utilizar + la bandera de superbloque por varias razones: + + + + La bandera de montaje ACLs no puede ser cambiada + por un remontaje (&man.mount.8; ), solamente con + un completo &man.umount.8; y un &man.mount.8; fresco. Esto significa + que no se pueden habilitar ACLs en el sistema de + archivos raíz despues del arranque. También significa + que no puede cambiar la disposición de un sistema de archivos + una vez que está en uso. + + + + Activando la bandera de superbloque provocará que el sistema + de archivos sea siempre montado con ACLs habilitadas + incluso si no existe una entrada en fstab o si los + dispositivos se reordenan. Esto previene un montado accidental del + sistema de archivos sin tener las ACLs habilitadas, + lo cual puede resultar en que se impongan de manera inadecuada las + ACLs, y por consecuencia un problema de seguridad. + + + + Podemos cambiar el comportamiento de las ACLs para + permitirle a la bandera ser habilitada sin un &man.mount.8; completo, pero + lo consideramos deseable para deshalentar montados accidentales sin + ACLs habilitadas, porque puede disparase a los pies muy + feamente si habilita ACLs, luego las deshabilita, luego las + habilita nuevamente sin borrar los atributos extendidos. En general, una vez que + que se han habilitado ACLs en un sistema de archivos, no deben + ser dehabilitadas, ya que la protección de archivos resultante puede no + ser compatible con aquellas pretendidas por los usuarios del sistema, y rehabilitando + las ACLs pueden re-pegar las ACLs previas + a archivos que han tenido cambios en sus permisos desde eso, resultando en + otra conducta impredecible. + + Los sistemas de archivos con ACLs habilitadas mostrarán + un signo + (más) en sus configuraciones de permisos + al visualizarlos. Por ejemplo: + + drwx------ 2 robert robert 512 Dec 27 11:54 private +drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 +drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 +drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 +drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html + + Aquí vemos que los directorios directory1, + directory2, y directory3 + están todos tomando ventaja de las ACLs. + El directorio public_html no. + + + Haciendo uso de <acronym>ACL</acronym>s + + Las ACLs del sistema de archivo pueden + ser visualizadas por la utilidad &man.getfacl.1;. Por ejemplo, + para ver las configuraciones de ACL en el + archivo test, uno podría + usar el comando: + + &prompt.user; getfacl test + #file:test + #owner:1001 + #group:1001 + user::rw- + group::r-- + other::r-- + + Para cambiar las configuraciones ACL en + este archivo, invoque la utilidad &man.setfacl.1;. Observe: + + &prompt.user; setfacl -k test + + La bandera eliminará todas + las ACLs definidas actualmente de un + archivo o sistema de archivos. El método más + preferible sería utilizar ya que + deja los campos básicos requeridos para que + funcionen las ACLs. + + &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- test + + En el comando antes mencionado, la opción + fué usada para modificar las + entradas ACL por omisión. + Debido a que no hubieron entradas predefinidas, como + fueron removidas por el comando previo, esto restaurará + las opciones por omisión y asignará las + opciones listadas. Tome precauciones para notar que si agrega + un usuario o grupo el cual no existe en el sistema, + un error de Invalid argument será + impreso en stdout. + + + + + + + + Tom + Rhodes + Contribuido por + + + + + + Portaudit + + Monitoreando asuntos de seguridad de terceros + + En años recientes, el mundo de la seguridad ha hecho + muchos mejoramientos en como se maneja la evaluación de + vulnerabilidades. La amenaza de instrusiones al sistema + incrementa cuando utilidades de terceros son instaladas + y configuradas para virtualmente cualquier sistema operativo + disponible hoy en día. + + La evaluación de vulnerabilidades es un factor + clave en la seguridad, y mientras &os; libera advertencias + para el sistema base, hacerlo para cada utilidad de terceros + está mas allá de la capacidad del proyecto + &os;. Existe una manera de mitigar las vulnerabilidades de + terceros y advertir a los administradores de incidentes de + seguridad conocidos. Una utilidad agregada de &os; conocida + como Portaudit existe solamente + con este propósito. + + El port security/portaudit + consulta una base de datos, actualizada y mantenida por el + equipo de seguridad y por los desarrolladores de &os;, por + incidentes de seguridad conocidos. + + Para empezar a usar Portaudit, + primero se debe instalar desde la colección de ports: + + &prompt.root; cd /usr/ports/security/portaudit && make install clean + + Durante el proceso de instalación, los archivos + de configuración para &man.periodic.8; serán + actualizados, permitiendole a Portaudit + aparecer en la ejecución diaria de seguridad. Asegúrese + que el correo de la ejecución diaria de seguridad, el cual + es enviado a la cuenta de correo de root, sea + leído. No se requiere ninguna otra configuración + aquí. + + Despues de la instalación, un administrador debe + actualizar la base de datos almacenada localmente en + /var/db/portaudit invocando + el siguiente comando: + + &prompt.root; portaudit -F + + + La base de datos será automaticamente actualizada + durante la ejecución de &man.periodic.8;; así + que el comando anterior es completamente opcional. Solo es + requerido para los siguientes ejemplos. + + + Para auditar las utilidades de terceros instaladas como + parte de la colección de ports, un administrador solo + necesita correr el siguiente comando: + + &prompt.root; portaudit -a + + Este es un ejemplo de la salida: + + 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. + + Apuntando un navegador de web a la URL + mostrada, un administrador puede obtener más información + acerca de la vulnerabilidad en cuestión. Esto incluirá + versiones afectadas, por versión de port de &os;, junto con + otros sitios web que contengan advertencias de seguridad. + + En corto, Portaudit es una utilidad + poderosa y extremadamente útil cuando se acopla con el + port Portupgrade. + + + + + + + Tom + Rhodes + Contribuido por + + + + + Advertencias de seguridad en FreeBSD + + &os; Security Advisories + + Como muchos sistemas operativos con calidad de producción, + &os; publica advertencias de seguridad. Estas + advertencias son usualmente enviadas por correo a las listas de + seguridad y anotadas en la Errata solamente despues de que la + release apropiada ha sido parchada. Esta sección trabajará + para explicar que es una advertencia de seguridad, como entenderla + y que medidas hay que tomar para parchar el sistema. + + + ¿Como se ve una advertencia? + + Las advertencias de seguridad en &os; se ven de manera + similar a la de abajo, tomada de la lista de correos + &a.security-notifications.name;. + + ============================================================================= +&os;-SA-XX:XX.UTIL Security Advisory + The &os; Project + +Topic: denial of service due to some problem + +Category: core +Module: sys +Announced: 2003-09-23 +Credits: Person@EMAIL-ADDRESS +Affects: All releases of &os; + &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) +&os; only: NO + +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 + + +II. Problem Description + + +III. Impact + + +IV. Workaround + + +V. Solution + + +VI. Correction details + + +VII. References + + + + + El campo Topic indica cual es el problema exaxtamente. + Es basicamente una introducción a la advertencia de seguridad actual + y anota la utilidad con la vulnerabilidad. + + + + Category se refiere a la parte afectada del sistema + la cual puede ser core, contrib o + ports. La categoría core + significa que la vulnerabilidad afecta a un componente central del + sistema operativo &os;. La categoría contrib + significa que la vulnerabilidad afecta a software contribuido al + proyecto &os;, como sendmail. Finalmente + la categoría ports indica que la + vulnerabilidad afecta a software agregado como parte de la + colección de ports. + + + + El campo Module se refiere a la ubicación del + componente, por ejemplo sys. En este ejemplo, vemos que + el módulo, sys, es afectado; por lo tanto, esta + vulnerabilidad afecta a componentes utilizados dentro del kernel. + + + + El campo Announced refleja la fecha en que esa + advertencia de seguridad fué publicada, o anunciada al mundo. + Esto significa que el equipo de seguridad ha verificado que el + problema exista y que un parche ha sido enviado al repositorio + de código fuente de &os;. + + + + El campo Credits le da el crédito al + individuo u organización que descubrió y reportó + la vulnerabilidad. + + + + El campo Affects explica a que releases de &os; + afecta esta vulnerabilidad. Para el kernel, una rápida + revisión a la salida de ident en + los archivos afectados ayudará determinando la + revisión. Para ports, el número de versión + está listado despues del nombre del port en + /var/db/pkg. Si el sistema no se + sincroniza con el repositorio CVS de + &os; y se reconstruye diariamente, existe la posibilidad de + que esté afectado. + + + + El campo Corrected indica la fecha, hora, zona + horaria y release que fué corregido. + + + + El campo &os; only indica si esta vulnerabilidad afecta + solamente a &os;, o si afecta también a otros sistemas operativos. + + + + El campo Background da información acerca de + que es exactamente la utilidad afectada. La mayor parte del + tiempo se refiere a por qué la utilidad existe en &os;, + para que es utilizada, y un poco de información de + como llegó a convertirse en utilidad. + + + + El campo Problem Description explica el agujero + de seguridad en profundiad. Esto puede incluir información de + código fallado, o incluso como la utilidad puede ser + usada maliciosamente para abrir un agujero de seguridad. + + + + El campo Impact describe el tipo de impacto + que el problema puede tener en un sistema. Por ejemplo, + esto puede desde un ataque de negación de servicio, + hasta privilegios extras para usuarios, o incluso brindar + al atacante acceso de superusuario. + + + + El campo Workaround ofrece una solución + temporal posible para administradores de sistemas que tal vez no + puedan actualizar el sistema. Esto puede ser debido a + falta de tiempo, disponibilidad de red, o a muchas otras + razones. Sin importar eso, la seguridad no de debe tomar + a la ligera, y un sistema afectado debe ser parchado o + una solución temporal para el agujero de seguridad + debe ser implementado. + + + + El campo Solution ofrece instrucciones para + parchar el sistema afectado. Este es un método paso a + paso, probado y verificado para parchar un sistema y que + trabaje seguro. + + + + El campo Correction Details despliega + la rama del CVS o el nombre del release + con los puntos cambiados a guiones bajos. También + muestra el número de revisión de los archivos + afectados dentro de cada rama. + + + + El campo References usualmente ofrece fuentes de + información. Esto puede incluir URLs + de web, libros, listas de correos y grupos de noticias. + + + + + + + + + + Tom + Rhodes + Contribuido por + + + + + Contabilidad de procesos + + Contabilidad de procesos + + Contabilidad de procesos es un método de + seguridad en el cual un administrador puede llevar + seguimiento de los recursos del sistema utilizados, + su distribución entre los usuarios, brindar + monitoreo para el sistema y minimamente rastrear + los comandos de los usuarios. + + Esto en realidad tiene sus puntos positivos y negativos. + Uno de los positivos es que una intrusión puede ser + minimizada al punto de entrada. Uno negativo es la cantidad + de logs generados por la contabilidad de procesos, y el + espacio en disco que requieren. Esta sección + llevará a un administrador a través de + las bases de la contabilidad de procesos. + + + Habilitando y utilizando la contabilidad de procesos + + Antes de hacer uso de la contabilidad de procesos, + debe ser habilitada. Para hacer esto, ejecute el + siguiente comando: + + &prompt.root; touch /var/account/acct + +&prompt.root; accton /var/account/acct + +&prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.conf + + Una vez habilitada, la contabilidad de procesos + empezará a seguir el rastro de estadísticas + del CPU, comandos, etc. Todos los logs + de contabilidad están en un formato ilegible + para humanos y pueden ser visualizados usando la utilidad + &man.sa.8;. Si se ejecuta sin opciones, sa + imprimirá información relativa al número + de llamadas por usuario, el tiempo total transcurrido en + minutos, tiempo total de CPU y de usuario + en minutos, número promedio de operaciones de E/S, + etc. + + Para ver información acerca de los comandos + siendo ejecutados, uno podría usar la utilidad + &man.lastcomm.1;. lastcomm puede ser + utilizado para imprimir comandos ejecutados por usuarios + en &man.ttys.5;, específicos, por ejemplo: + + &prompt.root; lastcomm ls + trhodes ttyp1 + + Imprimiría todos los usos conocidos de ls + por el usuario trhodes en la terminal + ttyp1. + + Existen muchas otras opciones útiles y son explicadas + en las páginas de manual &man.lastcomm.1;, &man.acct.5; + y &man.sa.8;. + + + + + -