Category Archives: Internet

Servidores DNS públicos y gratuitos

Introducción

El servicio de DNS (Domain Name System) se encarga de traducir los nombres de los dominios de los requerimientos a sus correspondientes direcciones IP para poder ser físicamente localizados y consultados.  Este procedimiento toma unos cuantos milisegundos los cuales a lo largo del día pueden significar cantidades significativas de tiempo.  En casos como este o de problemas específicos es conveniente algunas veces utilizar el servicio de servidores DNS diferentes a los provistos por el ISP.

A continuación se muestra una lista de los servidores DNS gratuitos y públicos que he recopilado.

Servidores DNS

  1. Google
    8.8.8.8
    8.8.4.4
  2. Google (IPV6)
    2001:4860:4860::8888
    2001:4860:4860::8844
  3. OpenDNS
    208.67.222.222
    208.67.220.220
  4. Norton DNS
    198.153.192.1
    198.153.194.1
  5. OpenNIC
    69.164.208.50
    216.87.84.211
  6. Level3
    209.244.0.3
    209.244.0.4
  7. DNS Advantage
    156.154.70.1
    156.154.71.1
  8. ScrubIT3
    67.138.54.120
    207.225.209.77
  9. Public-Root5
    199.5.157.131
    208.71.35.137
  10. Comodo Secure
    8.26.56.26
    8.20.247.20

Solucionando mis problemas con el modem Huawei HG530

Introducción

En el apartamento UNE me instaló un gateway Huawei HG530 ADSL.  Como es habitual en estos aparatos incluye cuatro puertos LAN para conectar mediante cable a un igual número de equipos, sin embargo los equipos que yo conectaba sólo funcionaban en el puerto #1, los demás obtenían una dirección IP del servicio DHCP pero no conseguían acceder a Internet.

El problema y la solución

Anoche le dí otra oportunidad al problema y estuve revisando las opciones de configuración web del dispositivo y encontré que bajo la opción Advanced > Port Mapping es posible crear una especie de VLANs entre los puertos.  Tal y como me lo entregaron los técnicos de UNE parecía contener la definición de dos VLANs, la primera incluía al puerto LAN #1 y la segunda a los demás siendo esto coherente con los síntomas analizados.

Para solucionar esta situación removí la segunda VLAN y agregué los puertos LAN faltantes a la primera para permitir la comunicación entre ellos, el puerto WAN y el puerto WLAN.  La configuración resultante se muestra a continuación.

También es conveniente verificar bajo la opción Basic > DHCP que este servicio se encuentre activo a través de todos los puertos LAN, de lo contrario los equipos conectados en ellos no obtendrán una dirección IP de manera automática.

Mejorando la seguridad

Con sorpresa encontré que el firewall también venía desactivado, permitiendo establecer conexiones web y telnet para la administración del router desde Internet.  Para impedir esto se activaron las opciones bajo Advanced > Security.


Así como las ubicadas bajo Advanced > Firewall.

Actualizar Empathy a la versión 2.32.1

Introducción.

Empathy es el software de mensajería que incluye por defecto GNU/Linux Ubuntu desde su versión 10.04.  Antes utilizaba Pidgin el cual es está mas maduro debido a su mayor trayectoria, sin embargo después de instalar esta última versión de Ubuntu -10.10- decidí darle una oportunidad a esta nueva aplicación.

Tal y como lo mencioné, a este software aún le faltan varias de las características que considero indispensables para su uso, entre ellas la posibilidad de permitir o negar la posibilidad de los contactos de ver nuestro estado o comunicarse con nosotros (privacidad).

Estado de la sesión en Empathy
Estado de la sesión en Empathy

Otra característica que extrañaba era la posibilidad de estar invisible, es decir, conectado a los diferentes servicios de mensajería pero sin aparecer conectado en las listas de mis contactos.  Esto era parcialmente factible, ya que con protocolos como el de Messenger era posible pero específicamente con el de GTalk (mensajería de Google) no lo era, cuando se tenían cuentas activas de este protocolo el estado era asignado automáticamente como ocupado lo que hacía a mi usuario evidentemente visible.

Pensé que era una limitación del protocolo de Google (basado en XMPP) sin embargo recientemente encontré que era realmente un bug de Telepathy -la librería que da soporte a las conversaciones en Empathy- y que este ya ha sido corregido.

Actualizar Empathy.

La nueva versión de las librerías que corrige este problema no puede ser instalada automáticamente desde el repositorio, al menos para la versión actual de Ubuntu, aparentemente por un problema de dependencias.  Por este motivo es necesario realizar una actualización manual de los paquetes.

En primera instancia es necesario descargar las nuevas versiones de los siguientes archivos.  Para la versión de 32 bits de Ubuntu:

  1. http://packages.ubuntu.com/natty/i386/telepathy-gabble/download
  2. http://packages.ubuntu.com/natty/i386/libsqlite3-0/download
  3. http://packages.ubuntu.com/natty/i386/libtelepathy-glib0/download

Para la versión de 64 bits de Ubuntu.

  1. http://packages.ubuntu.com/natty/amd64/telepathy-gabble/download
  2. http://packages.ubuntu.com/natty/amd64/libsqlite3-0/download
  3. http://packages.ubuntu.com/natty/amd64/libtelepathy-glib0/download

Posteriormente es necesario instalar los paquetes .deb descargados anteriormente.  Esto se puede hacer de varias maneras, desde haciendo doble clic sobre ellos y dejando que el Ubuntu Software Center se encargue de ellos hasta, como yo lo prefiero, instalarlos desde línea de comando de la siguiente manera.

$ sudo dpkg -i libsqlite3-*.deb telepathy-gabble_*.deb libtelepathy-*.deb

Finalmente es necesario reiniciar Empathy para utilizar la nueva versión recién instalada.

Enlaces.

Permitir el acceso de los nodos del cluster a Internet a través del nodo principal

Introducción.

Es muy común que debido al alto tráfico que se genera entre los nodos trabajadores de un clúster y su nodo principal, estos se separen en una red independiente y el nodo principal, con dos interfaces de red, actúe como puente entre los clientes en la red LAN y los nodos trabajadores en la red finalmente oculta.

La configuración de esto es tan simple como la simple conexión física de los dispositivos y la configuración de direcciones IP estáticas para los nodos trabajadores si es que no se desea instalar un servidor DHCP en el nodo principal para que realice esta tarea a través de la interfaz de red específica.  El problema surge cuando es necesario actualizar los nodos trabajadores o en general, que estos accedan a Internet.  Como estos se encuentran en un red diferente de la LAN, no hay nada que los enrrute hacia la WAN, quedando completamente aislados.

La solución a este problema es muy fácil de implementar gracias a las características intrínsecas de enrrutamiento de Linux (y en general de los sistemas operativos *nix).  Simplemente es necesario indicarle al nodo principal que actúe como enrrutador entre sus interfaces de red: red LAN y red de nodos trabajadores, pudiéndose aplicar los controles que se consideren necesarios a través del uso de iptables.

El panorama.

Estructura general del cluster
Estructura general del cluster

El nodo principal del cluster cuenta con dos interfaces de red: eth0 que se comunica con la red LAN de la organización y eth1 que se conecta con los nodos trabajadores, los cuales sólo cuentan con una única interfaz de red eth0.  Estos últimos se encuentran aislados del exterior ya que no son enrrutados inicialmente hacía la red LAN y eventualmente hacia Internet.

Implementación del enrrutamiento.

Configuración en el nodo principal del cluster.

Este actuará como enrrutador para la información enviada desde los nodos trabajadores y permitirles entonces acceder a las redes exteriores.  Para es necesario implementar en él las siguientes modificaciones de configuración.

Activar el envío de paquetes del kernel.

Esto se puede implementar de manera temporal, es decir, esta modificación no perdurará al reinicio del sistema, mediante la ejecución del siguiente comando.

# echo 1 > /proc/sys/net/ipv4/ip_forward

O puede implementarse de manera permanente mediante la edición de los parámetros del kernel de la siguiente manera.

# vi /etc/sysctl.conf

net.ipv4.ip_forward = 1

Esta último método puede verifcarse mediante la ejecución del siguiente comando en el shell.

# sysctl -p | grep ipv4

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_syncookies = 1

Establecer la regla de filtrado.

# iptables -t nat -A POSTROUTING -o eth0 -s 192.168.56.0/24 -j MASQUERADE

Esta instrucción le indica al nodo principal que permita el paso de los paquetes que vienen desde la red de los nodos trabajadores (192.168.56.0/24) hacía la otra red, en este caso la LAN (192.168.1.0), que se accede a través de la interfaz de red eth0.

Esta modificación desde la línea de comando no es persistente, por lo cual se deberá configurar en alguno de los archivos que se ejecutan al inicio.  Probablemente el mejor sitio sea en /etc/sysconfig/iptables, sin embargo debe tenerse cuidado si se utiliza system-config-securitylevel para administrar el firewall ya que este puede sobreescribir el archivo y olvidar los cambios.

Permitir el acceso al servicio DNS.

Este paso es opcional, pero probablemente si no se lleva a cabo el enrrutamiento sea exitoso si se utilizan direcciones IP directamente mas no si se intenta acceder utilizando nombres FQDN ya que los intentos de acceso al DNS son filtrados por el nodo principal.

Para permitir el acceso al servicio DNS es necesario permitir el paso de paquetes UDP cuyo destino sea el puerto 53 de la siguiente manera.

# iptables -A INPUT -m state –state NEW -m udp -p udp –dport 53 -j ACCEPT

Igual que en el paso anterior, para hacer persistente esta modificación es necesario incluírla en un archivo como /etc/sysconfig/iptables o realizarla con el system-config-securitylevel si se utiliza.

Configuración de los nodos trabajadores.

Es necesario finalmente indicarle a los nodos trabajadores que el nodo principal del cluster será a partir de ahora su nueva puerta de enlace.  Para hacer esto es necesario modificar el siguiente parámetro de su configuración con la dirección IP del servidor principal configurado anteriormente.

GATEWAY = 192.168.56.100

Esta modificación puede realizarse uno de los siguientes puntos de configuración de los nodos trabajadores.

  1. El archivo /etc/sysconfig/network.
  2. El archivo /etc/sysconfig/network-scripts/ifcfg-eth0.

Si el cambio se aplica en el primero de ellos, la modificación tiene un alcance global sobre todas las interfaces de red.  Si se aplica sobre el segundo archivo, la modificación será específica para la interfaz de red eth0.  En el caso de los nodos trabajadores, estos sólo tienen una única interfaz de red así que ambas opciones tienen igual implicación.

Finalmente es necesario reiniciar el servicio de red para garantizar que los cambios realizados tengan efecto.

# /etc/init.d/network restart

echo 1 > /proc/sys/net/ipv4/ip_forward

Construír e instalar Firesheep en GNU/Linux Ubuntu 10.10

Introducción.

Firesheep es un plugin de Firefox que permite fácilmente secuestrar sesiones HTTP en ciertas condiciones y de ciertas aplicaciones web gracias a que estas utilizan el protocolo seguro de transporte HTTPS únicamente durante la autenticación, transmitiendo el resto de la información plana permitiendo que otros usuarios se apoderen de la información de la sesión de usuario y puedan acceder a sitios como Facebook, Twitter y blogs de WordPress entre otros con las credenciales del usuario afectado.  Esto es notoriamente grave en las inalámbricas públicas que pueden ser accedidas sin autenticación alguna.

La solución a esta debilidad de las aplicaciones web será entonces utilizar el protocolo HTTPS durante toda la sesión del usuario, no sólamente durante la autenticación como estas aplicaciones afectadas hacen actualmente.  Como protección desde el lado del usuario es posible utilizar plugins como HTTPS Everywhere que obligan al navegador a utilizar el protocolo HTTPS todo el tiempo que se acceda a determinados sitios web.  De igual manera han aparecido aplicaciones que prometen detectar y combatir el uso de Firesheep en las redes y con las que estaré experimentando próximamente.

Actualmente este plugin puede descargarse para Firefox bajo Windows y OSX, la versión para Linux no se encuentra actualmente disponible, sin embargo como el proyecto es de código abierto es muy fácil obtener el código y compilarlo para esta plataforma tal y como se describe a continuación.

Construír el software.

Instalar git.

El cliente de git es necesario para acceder al código fuente del plugin que se encuentra almacenado en un repositorio de GitHub.

$ sudo aptitude install git-core

Obtener el código fuente.

$ mkdir /tmp/firesheep && cd /tmp/firesheep

$ git clone https://github.com/codebutler/firesheep.git

$ cd firesheep

$ git submodule update --init

Instalar las dependencias.

Estos paquetes son necesarios para la construcción del plugin a partir de su código fuente.

$ sudo apt-get install autoconf libtool libpcap-dev libboost-all-dev libhal-dev xulrunner-1.9.2-dev

Construír el plugin.

$ ./autogen.sh

$ make

Instalar el software.

Desde Firefox elija la opción de abrir un archivo (CTRL+O).

File > Open File…

Y seleccione el archivo /tmp/firesheep/firesheep/build/firesheep.xpi.

Usar el software.

Una vez activado el plugin este puede visualizarse como una barra lateral mediante View > Firesheep o la combinación de teclas CTRL+SHIFT+S.

Firesheep en Ubuntu 10.10
Firesheep en Ubuntu 10.10

Su uso es muy sencillo, simplemente presione el botón Start capturing y espere a que la aplicación capture la información de las sesiones en la red, las cuales aparecerán en la barra lateral situada al lado izquierdo.

Enlaces.

Acceder a un servicio RDP de Windows a través de un túnel SSH

Introducción.

Esta semana fue necesario acceder remotamente a unos servidores para desplegar en ellos un proyecto.  El servidor web es visible a través de Internet y utiliza GNU/Linux, este expone además del http el servicio ssh al exterior utilizando el puerto 45729.  En la red interna (por obvias razones) se encuentra un segundo servidor con Windows XP SP3 sobre el cual se ejecuta la base de datos MSSQL.

Estructura general de la red
Estructura general de la red

Trivialmente el acceso al servidor web es muy sencillo gracias al SSH.  La transmisión de archivos al servidor Windows también puede ser fácilmente implementada gracias al cliente de Samba que permite una interacción transparente con el protocolo SMB de este sistema operativo.  Pero qué pasa si es necesario acceder a la consola grafica de Windows ?  Desafortunadamente en esta etapa de despliegue es necsario hacer verificaciones y algunos cambios en la base de datos MSSQL y no fue posible encontrar herramientas de administración remotas o web que fueran realmente efectivas.  La única opción sería acceder al escritorio a través de Internet.

Para hacer esto, el primer paso es activar el servicio de escritorio remoto (Remote Desktop Protocol) en Windows XP y autorizar su acceso desde la red LAN.

El segundo paso consiste en garantizar el acceso remoto a través de Internet.  Para esto se deberá aprovechar el protocolo SSH del servidor GNU/Linux.

Una primera aproximación es utilizar el ForwardX11 del servicio SSH a través del cual es posible unrrutar el protocolo de la interfaz gráfica de usuario (X11) hacia el cliente a través de la conexión segura.  Después de establecida la conexión se utiliza la aplicación rdesktop, local al servidor web, y su presentación es redirigida hacia el cliente gracias al protocolo SSH.

Esta aproximación fue exitosa, sin embargo los tiempos de respuesta aunque tolerables, fueron muy largos.

Una segunda aproximación consiste en la creación de un túnel SSH entre el servicio de RDP del servidor con Windows XP y el servidor GNU/Linux que pueda ser accedido desde Internet a través de conexiones seguras.  Esta aproximación, que se describe a continuación, nos dió unos mejores tiempos de respuesta a través de una implementación simple pero mas elegante que la anterior.

Procedimiento.

Como se mencionó anteriormente, el primer paso es la activación del servicio de escritorio remoto en la máquina Windows XP SP3 que se encuentra en la red privada, esto se debe realizar localmente.

El siguiente paso consiste en establecer el túnel entre el cliente y el servidor web (GNU/Linux) a través de Internet involucrando al servidor de bases de datos (Windows XP) asociándolo a un puerto específico del primero.  Para hacer esto se debe ejecutar el siguiente comando desde el cliente.

$ ssh -L 33389:192.168.3.1:3389 -l usuario mi.servidor.com -p 45729 -Nf

mi.servidor.com es el nombre FQDN con el que se accede al servidor GNU/Linux que expone a Internet el servicio de SSH a través del cual se ingresa a la red remota.  El puerto que utiliza en este caso el servicio SSH es el 45729.  De manera similar, la dirección del servidor Windows XP es la 192.168.3.1 y el puerto (por defecto) que utiliza el servicio de RPD es el 3389 con el cual se establece un túnel con el puerto local 33389.

El proceso después de autenticado se envía automáticamente a background retornando el control del shell gracias al parámetro -N especificado, sin embargo es posible verificar el establecimiento del túnel de la siguiente manera.

$ ps -fea | grep ssh

jimezam  25009     1  0 14:46 ?        00:00:00 ssh -L 33389:192.168.3.1:3389 -l usuario mi.servidor.com -p 45729 -Nf

Esquema general del túnel SSH
Esquema general del túnel SSH

En términos generales, el túnel SSH le permite al cliente acceder al servicio RDP remoto (192.168.3.1:3389) desde localhost:33389 de manera transparente a través del servicio SSH de mi.servidor.com.

Finalmente en el cliente se accede al escritorio remoto utilizando una aplicación como rdesktop de la siguiente manera.

$ rdesktop -z localhost:33389

La ejecución de este comando mostrará localmente la consola gráfica de la máquina Windows XP.

Escritorio remoto del servidor Windows XP
Escritorio remoto del servidor Windows XP

Una nota acerca de clientes en Windows.

Este procedimiento puede adaptarse para el uso de clientes Windows utilizando herramientas adicionales como el caso de Putty para el establecimiento del túnel SSH y la aplicación para conexión a escritorios remotos de Windows.

El primero de ellos es software libre y puede obtenerse en la página web de Putty mientras que el segundo hace parte de las herramientas incluídas en Windows XP y se accede a través de los siguientes menúes.

Inicio > Accesorios > Conexión a escritorio remoto.

Conexión al escritorio remoto de Windows XP
Conexión al escritorio remoto de Windows XP

Enlaces.

Problemas de conexión a las cuentas de Messenger desde Empathy 2.32.0

Introducción.

Desde hace un par de días las conexiones con el servicio de Microsoft Messenger Live han dejado de funcionar desde la aplicación de mensajería Empathy de Gnome mientras que los demás protocolos funcionan normalmente.

Conexión fallida a una cuenta de Messenger desde Empathy
Conexión fallida a una cuenta de Messenger desde Empathy

Todo parece indicar que se trata de un problema introducido en una actualización de la librería papyon la cual es la responsable de realizar las conexiones con el protocolo de Microsoft para esta aplicación (telepathy-butterfly) y otras similares basadas en Python.

Solución.

Mientas se publica el paquete con la versión actualizada de esta librería en los repositorios oficiales es posible manipularla para introducir manualmente el parche necesario para superar este impase.  Para hacerlo, simplemente siga los pasos descritos a continuación.

Desactive las cuentas de Messenger en el Empathy.

Abra una terminal y ejecute los siguientes comandos.

$ cd /usr/lib/pymodules/python2.6/papyon/service/description/SingleSignOn

$ sudo vi RequestMultipleSecurityTokens.py

(busque la siguiente línea)
CONTACTS = (“contacts.msn.com”, “?fs=1&id=24000&kv=7&rn=93S9SWWw&tw=0&ver=2.1.6000.1″)

(reemplácela con la siguiente línea)
CONTACTS = (“contacts.msn.com”, “MBI”)

Active nuevamente las cuentas de Messenger en el Empathy.

Deberán conectar exitosamente otra vez!

Enlaces.

Acceder al escritorio remoto de GNU/Linux Ubuntu 10.04 utilizando FreeNX

Introducción.

Después de experimentar el acceso al escritorio remoto de GNU/Linux a través de XDMCP (con Xephyr y como una terminal) encontré que los resultados fueron satisfactorios pero con algunas desventajas: la seguridad y la velocidad.  En pocas palabras no es prudente utilizar XDMCP en un ambiente diferente a LAN ya que su tráfico no está encriptado y el puerto abierto puede convertirse en un problema de seguridad.

Por esta razón decidí probar un software muy conocido pero que nunca utilizado.  FreeNX es la versión libre del NXServer de NoMachine, el cual es descrito de la siguiente manera en su sitio de Launchpad.

NX technology is a computer program that handles remote X Window System connections, and attempts to greatly improve on the performance of the native X11 protocol to the point that it can be usable over a slow link such as a dial-up modem … The open source alternative to NoMachines’s commercial NX Server.

En términos generales me gustaron mucho los resultados, es rápido y aparentemente seguro (su tráfico se envía a través de SSH). El servidor inclusive puede servir de proxy para acceder a servidores RDP (Windows), VNC o de impresoras mediante los paquetes freenx-rdp, freenx-vnc y freenx-smb respectivamente.

En la instalación, a pesar de no ser compleja, encontré un par de bugs para Ubuntu 10.04 que fueron resueltos.  Este procedimiento se describe a continuación.

Instalar el servidor.

Instalar los paquetes.

$ sudo aptitude install python-software-properties

$ sudo add-apt-repository ppa:freenx-team

$ sudo aptitude update

$ sudo aptitude install freenx-server

Crear las llaves de acceso (opcional).

Como mencioné inicialmente, FreeNX utiliza el protocolo SSH para su transporte, por este motivo puede aprovechar la riqueza de opciones de autenticación que provee este servicio.  Por defecto el servidor instala una pareja de llaves por defecto, utilizarlas constituye un riesgo de seguridad.  Por este motivo se sugiere que se creen y popularicen las llaves propias.  Si la seguridad no es una preocupación, puede obviar este paso y continuar con la instalación del cliente.

Si recibe un mensaje de error al ejecutar nxsetup indicándole que el comando no fue encontrado, realice primero los pasos descritos en la sección de solución de problemas.

$ sudo sudo /usr/lib/nx/nxsetup –install

——> It is recommended that you use the NoMachine key for
easier setup. If you answer “y”, FreeNX creates a custom
KeyPair and expects you to setup your clients manually.
“N” is default and uses the NoMachine key for installation.

Do you want to use your own custom KeyPair? [y/N] y
Setting up /etc/nxserver …done
Generating public/private dsa key pair.
Your identification has been saved in /etc/nxserver/users.id_dsa.
Your public key has been saved in /etc/nxserver/users.id_dsa.pub.
The key fingerprint is:
90:d2:6b:93:58:35:09:7b:e4:cd:43:db:83:9b:e2:bf root@jimezam-notebook
The key’s randomart image is:
+–[ DSA 1024]—-+
|      ..+..      |
|     . *.= +     |
|    . * o * o    |
|     + =   + .   |
|    . = S o      |
|     . o .       |
|        .        |
|         .       |
|          E.     |
+—————–+
Setting up /var/lib/nxserver/db …done
Setting up /var/log/nxserver.log …done
Adding user “nx” to group “utmp” …done
Setting up known_hosts and authorized_keys2 …Unique key generated; your users must install

/var/lib/nxserver/home/.ssh/client.id_dsa.key

on their computers.
done
Setting up permissions …done
Setting up cups nxipp backend …
cp: `/usr/lib/cups/backend/ipp’ and `/usr/lib/cups/backend/ipp’ are the same file

Copie la llave a los equipos cliente, la cual posteriormente podrá ser importada desde el cliente de NX.

$ sudo scp /var/lib/nxserver/home/.ssh/client.id_dsa.key usuario@mi-cliente:~/client.id_dsa.key

Después de importada la llave en el cliente de NX de mi-cliente, se recomienda que remueva el archivo ~/client.id_dsa.key.

Crear nuevas llaves (Servidor)

Es posible que por motivos de seguridad posteriormente desee crear nuevas llaves para reemplazar las existentes después de una cierta cantidad de tiempo.  Para hacer esto ejecute el siguiente comando.

$ sudo dpkg-reconfigure freenx-server

Seleccione el tipo de llaves a utilizarse, utilice la opción Create new custom keys para crear un nuevo par.

Selección del tipo de llaves
Selección del tipo de llaves

Seleccione el tipo de autenticación a utilizarse, en este caso se utilizará el servicio SSH.

Selección del tipo de autenticación
Selección del tipo de autenticación

Finalmente transmita la nueva llave a los clientes para permitirles acceder nuevamente al servidor.

Instalar el cliente.

Instalar el paquete.

Descargue el paquete correspondiente a su sistema operativo de la siguiente dirección.

http://www.nomachine.com/select-package-client.php

Para este caso, Ubuntu 10.04 de 64 bits, se descargo el paquete NX Client DEB for Linux – x86_64.  A continuación se instala el paquete recién descargado.

$ sudo dpkg -i nxclient_3.4.0-7_x86_64.deb

CUPS Printing Backend

The NX Client set-up procedure detected that your “IPP CUPS” printing
backend doesn’t allow printing from the NX session. In order to have
printing support in your NX system, you need to set proper permissions
on the IPP backend. Please execute:

chmod 755 /usr/lib/cups/backend/ipp

$ sudo chmod 755 /usr/lib/cups/backend/ipp

Ejecutar el cliente.

$ /usr/NX/bin/nxclient &

Crear una nueva cuenta de conexión con el asistente (cliente).

Presione el botón Next para iniciar el asistente de creación de cuentas.

Iniciar el asistente de creación de cuentas
Iniciar el asistente de creación de cuentas

Especifique la siguiente información relacionada con la conexión al servidor.

  • Session: nombre de la sesión (a gusto del usuario).
  • Host: dirección IP o nombre del servidor FreeNX.
  • Port: puerto donde se está ejecutando el servicio SSH.
  • Connection Type: tipo de acceso a la red, en este caso es una red LAN.
Información de conexión al sevidor
Información de conexión al sevidor

Especifique la siguiente información relacionada con el administrador de ventanas a ejecutarse en el servidor.

  • Tipo: en este caso será una conexión nativa (Unix) y se ejecutará GNOME.
  • Size: se permite utilizar el máximo tamaño disponible.
Información del escritorio
Información del escritorio

Presione el botón Finish para terminar el asistente.

Finalizar la instalación
Finalizar la instalación

Realizar una conexión con el servidor.

Registro de usuarios
Registro de usuarios

Seleccione el tipo de sesión (Session) que se creó anteriormente a través del asistente y especifique su información de autenticación (Login y Password) para acceder al servidor.  Presione el botón Login para iniciar la sesión.

Si el servidor cuenta con sus propias llaves personalizadas (ver proceso de instalación) será necesario importarlas en el cliente para poder registrarse exitosamente (ver siguiente apartado).

Importar las llaves del servidor en el cliente.

Si el servidor cuenta con sus propias llaves personalizadas (que es lo mas conveniente) es necesario importarlas en el cliente para que se realice exitosamente la conexión al mismo.  Para esto es necesario transferir la llave (client.id_dsa.key) de manera segura desde el servidor hasta el cliente (ver comando scp en la instalación del servidor).

Para importar el archivo de llave seleccione editar la configuración de la sesión presionando el botón Configure del diálogo de registro (ver anterior).

Configuración de sesión
Configuración de sesión

Presione el botón Key… e importe o pegue la llave proveniente del archivo client.id_dsa.key traído desde el servidor.  Después de importado se recomienda que remueva de manera segura este archivo.

Importar llave
Importar llave

Solución de problemas.

No existe la aplicación nxsetup.

Si obtiene el siguiente mensaje de error, el paquete de freenx-server no incluyó erróneamente la aplicación nxsetup la cual es necesaria para realizar su instalación completa.

nxsetup: command not found

Para corregir este problema realice los pasos descritos a continuación.

$ cd /usr/lib/nx

$ sudo wget “https://help.ubuntu.com/community/FreeNX?action=AttachFile&do=get&target=nxsetup.tar.gz”

$ sudo mv “FreeNX?action=AttachFile&do=get&target=nxsetup.tar.gz” nxsetup.tar.gz

$ sudo tar zxvf nxsetup.tar.gz

$ sudo rm nxsetup.tar.gz

Enlaces.

Realizar un tar local y almacenarlo remotamente a través de SSH

Introducción.

Esta es la versión mas simple y menos elaborada que se me ocurre para hacer copias de seguridad esporádicas de archivos locales y almacenarlos en un servidor de archivos remoto.  No permite la facilidad de autenticación con llaves de propósito único como en los artículos anteriores (1 y 2), pero es posible utilizarlo con la autenticación basada en llaves (de propósito general) y la autenticación basada en contraseñas.

En funcionalmente es un tar y scp resumidos en una única ejecución de comandos.

Procedimiento.

Se desea realizar la copia de seguridad de los archivos locales almacenados bajo el directorio /archivos/importantes y almacenarlos en el servidor mis.backups.com bajo la ubicación /u/backups.  El procedimiento es tan sencillo como la única línea que se muestra a continuación.

$ tar zcvf – /archivos/importantes | ssh usuario@mis.backups.com “cat > /u/backups/miArchivoBackup.tgz”

Realizar copias de seguridad remotas con llaves SSH de propósito único (2 – el camino inverso)

Introducción.

Después de encontrar una forma muy interesante de hacer las copias de seguridad mediante el uso de llaves de propósito único mi mente inquieta se ha quedado pensando acerca de la factibilidad de hacer lo mismo pero en sentido contrario y de la posible utilidad para el mismo problema: el método mas simple, seguro y fácil de implementar para hacer las copias de seguridad.

En el artículo anterior se configuró al servidor para que confiara en el cliente que portara el par de llaves adecuado, esta confianza le permitiría al servidor ejecutar un único comando y retornar la información resultante al cliente el cual podría tomar el flujo binario de bytes y crear con él un archivo.  En este caso, cualquiera que tuviera posesión de los archivos de la llave y la passphrase (si las llaves se crearon con ella) podrían ejecutar el comando único, en otras palabras, obtener la copia de seguridad del servidor.  En términos generales esto no debe suceder, no debe ser un riesgo ya que supuestamente las llaves se encuentran bien resguardadas, sin embargo estamos analizando el peor escenario.

Ahora, cómo sería el caso contrario en el que el antes cliente (quien almacena las copias de seguridad) confiara en el servidor (a quien se le va a hacer la copia de seguridad) y recibiera todos los archivos que este le envía y los almacenara en el sistema de archivos.  Es posible implementarlo ?  En caso de comprometerse la pareja de llaves, cuál sería el peor escenario ?

Como lo veo hasta el momento, el atacante estaría posibilitado a subir todos los archivos que quisiera llenando la partición del sistema de archivos (ataque por denegación de servicio – DOS) e interfiriendo con el uso normal del sistema.  Podría además sobreescribir (dependiendo de como se cree el script local) los archivos sobre los cuales cuenta con suficientes permisos.  Estos efectos se minimizarían con el uso de un usuario específico para las copias de seguridad, la asignación de una cuota de disco, la implementación de un buen script en el cliente y un contínuo seguimiento al éxito de las copias de seguridad.  En términos generales es aún mas promisorio que la primera versión (directa).  Vale la pena explorar esta aproximación.

Desde el punto de vista funcional hay una diferencia que debe tenerse en cuenta, la primera aproximación es útil inclusive para realizar las copias de seguridad desde equipos que no siempre están activos o en línea, ya que puede realizarse por demanda; mientras que la segunda aproximación analizada a continuación, requiere que ambos equipos estén en línea al mismo tiempo ya que el procedimiento probablemente se inicie por un proceso cron en el servidor.

Crear la llave de propósito único.

Para la creación de la llave de propósito único se siguen los mismos pasos realizados durante la experimentación con la versión directa, con la diferencia que ahora el servidor es el equipo donde se almacenan las copias de seguridad y el cliente es el equipo que contiene la información a la cual se le desea hacer copia de seguridad.  De esta manera, las llaves (demokey y demokey.pub en el ejemplo) se crearían en el servidor web (por ejemplo) y se crearía el archivo ~/.ssh/authorized_keys2 con el contenido apropiado en el servidor de copias de seguridad.

Crear el script para recibir las copias de seguridad.

Del lado del servidor de copias de seguridad (donde se almacenarán) se crea a manera de ejemplo la siguiente configuración.

Una ruta donde se almacenarán las copias de seguridad.

$ mkdir -p /u/backups/datos

$ chown -R bkpuser /u/backups

$ chmod -R 700 /u/backups

Se crea un script para recibir los archivos con las copias de seguridad y almacenarlos en la ubicación creada anteriormente.

$ vi /u/backups/recibir.sh

# Fecha de creación de la copia de seguridad.
FECHA=`date +%Y%m%d`
# Hora de creación de la copia de seguridad.
HORA=`date +%H%M%S`
# Ubicación donde se almacenan las copias de seguridad.
DIRECTORIO=/u/backups/datos
# Nombre del archivo donde se almacenará la copia de seguridad.
ARCHIVO=”backup-${DATE}-${TIME}.data”

# Almacenar la información de la copia de seguridad.
cat > $DIRECTORIO/$ARCHIVO

# Reportar al cliente el nombre del archivo utilizado.
echo $ARCHIVO

$ chmod +x /u/backups/recibir.sh

Finalmente se configura la llave (authorized_keys2) para que invoque a recibir.sh como su propósito único.

$ vi ~/.ssh/authorized_keys2

(modificar la llave específica)
from=”*.jorgeivanmeza.com,10.20.*” command=”/u/backups/recibir.sh“,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3Nza…(mas caracteres)… jimezam@mi-cliente

El modificador from permite limitar desde cuales ubicaciones es posible utilizar la llave privada para acceder a la funcionalidad de las copias de seguridad.  En este caso sólo es posible acceder a través de SSH utilizando esta llave de propósito único desde cualquier equipo del dominio jorgeivanmeza.com o desde cualquier equipo de la subred 10.20.xxx.xxx.

Realizar una copia de seguridad.

Para iniciar una copia de seguridad desde el servidor de aplicaciones (servidor web por ejemplo) sólo es necesario ejecutar el siguiente comando.

$ tar zcvf – /ruta/a/resguardar 2> /dev/null | ssh bkpuser@mi-servidor


backup-20100927-205847.data

En el ejemplo anterior se realizó la copia de seguridad de los directorios bajo /ruta/a/resguardar y se guardó en mi-servidor en un archivo llamado backup-20100927-205847.data.  Esta última información puede resultar útil para guardar el registro de los archivos de copias de seguridad generados.  Otra alternativa mas elegante sería utilizar llaves de propósito único para cada servidor al cual se le va a hacer copia de seguridad de forma que se pueda especificar claramente que archivo corresponde a que servidor.