Guía de Seguridad del Administrador de Linux - Sistema X Window

El sistema X Window proporciona un método transparente a red de compartir datos gráficos, o más específicamente de exportar el display de un programa a un host remoto (o local). Utilizándolo se puede ejecutar un potente paquete de renderizado 3D de una SGI origin 2000 y mostrarlos en un 486. En esencia, es el abuelito de todos estos "delgados clientes" que se están haciendo bastante populares hoy en la actualidad. Se creó en el MIT, durante una época en la que la seguridad no era un asunto que preocupase demasiado. Esto, por supuesto, ha llevado a más de un bug desagradable. Peor incluso, el nivel de control que se le ha dado a X (maneja pulsaciones de teclado, movimientos de ratón, dibuja la pantalla, etc.) significa que si se compromete pueden ocurrir cosas muy desagradables. Estos datos, si se envían sobre la red (p. ej., el programa X que se ejecuta se está mostrando en un host remoto) se pueden registrar en logs con facilidad, de modo que la información sensible (como un xterm que esté siendo utilizado para hacer login en otro sistema remoto) es vulnerable. Además de estos problemas, el protocolo de autentificación que utiliza X es relativamente débil (aunque se ha mejorado). Ejecutarlo en una sesión gráfica de xemacs en un servidor situado 3 zonas horarias más lejos puede ser algo bastante útil.

El X es bastante predecible en cuanto al uso de puertos, casi todas las implementaciones

e instalaciones de X utilizan el puerto 6000 para la primera sesión, e incrementan en uno

para otras sesiones, lo cual lo hace bastante sencillo de escanear. Si no se va a utilizar el

X para mostrar un programa ejecutándose en sistemas remotos, sugeriría que se filtrase

el puerto 6000 con el cortafuegos.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 6000:6100

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 6000:6100

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 6000:6100

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 6000:6100

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 6000:6100

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 6000:6100

El control sobre lo que está permitido ejecutar al servidor X se puede hacer de

diferentes formas.



xhost

El xhost te permite especificar a qué máquinas se le permite o no conectar al servidor X,

es un mecanismo de seguridad bastante simplicista, y no es apropiado en cualquier entorno moderno, sin embargo, si se utiliza en conjunción con otros mecanismos, puede ayudar. El comando es bastante simple: "xhost +nombredehost.com" añade nombredehost.com, "xhost –hostname.com" elimina nombredehost.com de la lista, es necesario especificar "xhost –" para activar la lista de control de accesos, o si no por defecto se le dejará entrar a cualquiera.



mkxauth

Definitivamente, el mkxauth es un paso adelante desde xhost. El mkxauth ayuda a crear ficheros ~/.Xauthority, y juntarlos, lo cual se utiliza para especificar nombres de hosts y las magic cookies relativas. Estas cookies se pueden utilizar para conseguir acceso a un host X remoto (en esencia, cada extremo tiene una copia de la cookie) y se transmiten bien en texto plano (inseguro) o cifrado con DES (bastante seguro). Utilizando este método se puede estar relativamente a salvo y seguro. Los ficheros Xauthority también se pueden utilizar en conjunción con Kerberos, eliminando la necesidad de copiar los ficheros Xauthority y manteniéndolos sincronizados. Los hosts se autentifican entre sí a través de un servidor central de llaves Kerberos de forma cifrada, este método es apropiado para la mayoría de grandes instalaciones/etc. El mkxauth tiene una página de manual excelente "man mkxauth" y se pueden obtener detalles generalizados disponibles en la página del manual del Xsecurity (no estoy seguro de lo común que es el nombre de esta página) "man Xsecurity".