Problema con Spark y la zona horaria de Venezuela

Spark es una aplicación Java que funciona como cliente de mensajería instantánea a través de un servidor local de Jabber tal como Openfire.

Este artículo se refiere a un ambiente donde se encontraba instalado Spark 2.5.8 y Openfire 3.6.4


Síntomas:

Existen ocasiones en que los mensajes enviados y recibidos por el cliente Spark pueden aparecer en las ventanas de conversaciones con una hora equivocada, por ejemplo, con 30 minutos de diferencia. Esto puede suceder incluso a pesar de que la zona horaria del sistema operativo esté correctamente configurada tanto en los equipos clientes como en el servidor (en mi caso, Openfire).


Info:

El instalador de Spark 2.5.8 contiene su propio ambiente de tiempo de ejecución de Java (JRE), lo que significa que no es necesario instalar previamente Java en el equipo sino que éste se instala automáticamente con el programa en cuestión. Sin embargo, tal como el sistema operativo, Java también maneja sus propias zonas horarias y el instalador de Spark 2.5.8 no contiene la versión más actualizada de Java, y en particular, la versión del JRE incluida en Spark no contiene la zona horaria de Venezuela.

En Venezuela, actualmente la zona horaria es GMT-04:30, pero a pesar de seleccionar la zona horaria correcta en el sistema operativo, puesto que el JRE de Spark no conoce esta nueva zona horaria, pues no la detecta y le asigna la zona horaria anterior de Caracas, Venezuela, la cual es GMT-04:00, por lo cual todos los mensajes instantáneos se muestran con 30 minutos de diferencia.

Ahora, suponiendo que, aparte de la versión incorporada del JRE, se tiene también instalada la versión más actualizada de Java (en la actualidad JRE6u21), pues, puede suceder que Spark igual sigue usando su versión incorporada de JRE! tal vez esto puede darse por haber instalado Spark ANTES de instalar Java, sin embargo esto aún no lo he confirmado.

El JRE incorporado puede conseguirse en la carpeta C:\Archivos de Programa\Spark\jre\. Entonces, la idea es obligar a Spark a usar una versión de Java diferente a la que trae incorporada.


Solución:

Para solucionar este problema realice lo siguiente:

• Instale la última versión de Java (JRE6u21 en la actualidad)
• Renombre la carpeta C:\Archivos de Programa\Spark\jre\ y coloque un nuevo nombre a la carpeta jre, por ejemplo, jre_OLD
  

Si no es posible actualizar el JRE para disponer de la versión actualizada de las zonas horarias existe una utilidad llamada TZupdater.

Más información:
JAVA y el nuevo TIMEZONE para Venezuela

Mapeo de puertos (Port Forwarding)

Supongamos que tenemos la siguiente topología de red:

Nuestro objetivo es que el servidor interno sea accesible desde Internet, de tal manera que podamos publicar algunos servicios hacia otros usuarios externos que se encuentran fuera de la red.

El primer problema que nos encontraremos para lograr este objetivo es que la red interna pertenece a un segmento de red privado y que por tanto, estas direcciones no pueden ser enrutadas a través de Internet (recordemos que para poder enrutar una dirección en Internet es necesario que la misma sea una dirección IP pública). Entonces, dado que ningún equipo en Internet puede alcanzar directamente al servidor en la red interna, ¿cómo podemos hacer estos servicios accesibles a otras redes fuera de la red interna?

La solución está en utilizar la técnica conocida como Port Forwarding o Mapeo de Puertos, la cual permite la comunicación desde hosts externos hacia los servicios proporcionados dentro de una red privada.

En el diagrama anterior, el único dispositivo de nuestra red que tiene una dirección IP pública es el router/firewall; entonces, el router/firewall podría darnos una mano permitiéndonos usar su dirección IP pública para hacer disponible en Internet alguno(s) de nuestros servicios internos.

Es decir, le diremos al router/firewall, que nos "preste" su dirección IP pública y adicionalmente un (1) puerto (TCP o UDP) para publicar el servicio ofrecido por el servidor. Los usuarios externos únicamente conocen la dirección IP pública del router/firewall, por tanto, el router/firewall "engañará" a los clientes externos haciéndoles creer que es él mismo el que está proporcionando el servicio en cuestión. Sin embargo, al configurar el mapeo de direcciones o puertos en el router/firewall, los intentos de acceso dirigidos a la dirección IP pública del firewall serán redireccionados al servidor interno.

¿Cómo funciona?

NAT permite que una red local use direcciones IP privadas (no enrutables), y aún así comunicarse con Internet. En otras palabras las conexiones pueden ser establecidas desde adentro hacia afuera, pero las conexiones entrantes desde Internet no están permitidas. Al usar el mapeo de puertos, sin embargo, los servicios públicos como un servidor Web o FTP, y otros servicios ejecutándose dentro de la red privada pueden hacerse accesibles desde Internet.

Port forwarding o mapeo de puertos se refiere al cambio de la dirección de destino -y posiblemente el puerto- en el paquete inicialmente enviado al router/firewall y que seguidamente es enrutado por el mismo router/firewall para llegar a un host dentro de una red privada protegida por NAT, basado en el número de puerto en el cual fue recibido desde el host orígen.

La configuración necesaria debe ser realizada precisamente en el router/firewall, de esta manera, el router/firewall quedará con un puerto a la escucha (listening) tal como si este dispositivo tuviera el servicio instalado; sin embargo, cada petición o conexión que reciba el router/firewall a este puerto automáticamente será reenviada al puerto correspondiente en el servidor interno, quién verdaderamente será el encargado de responder a las conexiones y procesar las solicitudes del cliente.

La Zona Desmilitarizada (DMZ)

Hace un tiempo, tuve oportunidad de revisar los resultados de una auditoría realizada a una empresa de mediano tamaño, en los mismos observé que se hacía un énfasis en realizar pruebas de penetración al servidor Web -ubicado en la DMZ- y se obviaba casi por completo la realización de pruebas del mismo tipo al servidor de base de datos, puesto que se consideraba que se encontraba en la zona “segura”, a diferencia del servidor Web el cual era accesible desde Internet. El servidor de base de datos estaba en la misma subred que el resto de los equipos de la red interna, a merced de que cualquier empleado malintencionado se hiciera con los datos, lo cual en efecto, llegó a ocurrir al tiempo.

En ciertos casos, he observado que el concepto de Zona Desmilitarizada es entendido erróneamente como la zona que se ha de proteger más, puesto que es la zona que se encuentra accesible y expuesta públicamente a Internet.

Antes que nada, busquemos la definición de la palabra “desmilitarizada”. Según el diccionario de la lengua española, “Desmilitarizar” significa:

1. Suprimir la organización o el carácter militar de una colectividad
2. Reducir o suprimir el sometimiento a la disciplina militar
3. Desguarnecer de tropas e instalaciones militares un territorio, obedeciendo a un acuerdo
   

Por lo cual, se podría inferir que en dicha zona habría poca o nula actividad de fuerzas de seguridad protegiendo la zona, sin embargo, a veces se entiende exactamente a la inversa: proteger la zona a toda costa implementando la mayor cantidad de controles de seguridad posibles.

Creo que esto puede darse por dos razones, primero, al escuchar la palabra “Militar” al oyente descuidado le puede parecer que más bien debe haber un reforzamiento de la seguridad, segundo, comúnmente he observado que se traduce equivocadamente la palabra “Demilitarized” del Inglés a “Demilitarizada” (sin la letra “s”), esto, por insignificante que parezca le quita toda la connotación a la palabra, puesto que el prefijo “des” en el idioma español precisamente denota la negación o la inversión del significado de la palabra que antecede; al utilizar “de” en lugar de “des” más bien puede entenderse que se pretende una “Demarcación militar” y de nuevo un reforzamiento de los controles de seguridad.

Entonces, supongamos que la DMZ es la zona donde debe desplegarse la mayor cantidad de batallones de infantería y cuerpos de la armada, entonces... ¿qué habría de protegerse en esta zona?

En realidad, el propósito de una DMZ es agregar una capa adicional de seguridad a la red interna, no a la DMZ misma. En caso de violar la seguridad inicial, un atacante quedaría limitado y solo tendría acceso a los equipos de la DMZ con poca probabilidad de acceder a la red interna. Los servidores de esta red sin duda recibirán ataques y probablemente algunos tendrán éxito y la zona se verá comprometida, sin embargo, ésta es realmente la función de la zona, contener los ataques y evitar que traspasen el perímetro hacia dentro de la red interna.

Ahora bien, no significa con esto que los servidores que ubiquemos en la zona desmilitarizada estarán totalmente desprotegidos, pero, puesto que esta zona por definición es terreno de nadie, obviamente, los servidores puestos aqui no deben ser servidores críticos para el negocio, por ejemplo, un servidor de base de datos definitivamente no debería encontrarse en esta zona. Los servicios colocados en esta zona han de ser mayormente transaccionales, tales como servidores proxy, servidores Web o servidores de transferencia de correo; idealmente no debe haber depósitos de información tales como bases de datos o el correo privado de los usuarios, por lo cual en esta zona puede encontrarse distintos tipos de servicios intermediarios que inspeccionen el tráfico a nivel de aplicación entre la zona privada (protegida) y la zona pública (Internet), por ejemplo, firewalls de aplicación, antispam, servicios proxy Web y proxy inverso.

La DMZ es como el patio delantero de tu casa, el cual forma parte de tu propiedad y en donde tal vez puedas dejar una que otra cosa que no te importe compartir con el vecino, sin embargo, cualquier objeto de valor estará más seguro dentro de la casa. Y más aún, dentro de la casa, deberás guardarlo en una caja fuerte, protegido con candado y al cuidado de un vigilante a tiempo completo. Ha de recordarse que el objetivo principal es proteger las joyas de la corona, no la fortaleza en sí misma, así, por supuesto que hay que proteger el servidor Web que sirve de interfaz, pero la prioridad es y será proteger la información en la base de datos.