Cómo conectarme a un servidor remoto en una red protegida

Para quienes trabajamos en sistemas brindando servicios, muchas veces nos sucede que necesitamos conectarnos a un servidor en la red de nuestros clientes, pero lamentablemente no tienen VPN (Red Privada Virtual)  ni otro mecanismo para conectarnos de forma remota.

Normalmente existen alternativas:

1) Seguir insistiendo en que nos den acceso a la red mediante VPN , o bien ofrecerles configurar una. Con tiempo veré de postear un tutorial del OpenVPN.

2) Poco probable, pero he visto empresas que publican directamente el servidor en Internet, sin filtros. Recuerdo alguna vez las estadísticas de cuantos minutos podía estar un servidor Windows en Internet sin  ser "hackeado" o infectado por algún tipo de virus o gusano de internet. No lo recomiendo ni un poquito

3) Programa de control remoto a alguna PC. Recomiendo TeamViewer. No siempre es posible obtener este tipo de acceso. http://www.teamviewer.com

4) Solicitar que abran el puerto de SSH en su conexión externa (Internet) para poder entrar creando túneles. Esta alternativa es bastante simple de usar, y existen diferentes formas de sacar provecho:
a) Si el acceso lo necesitamos a 1 sólo servidor , podemos redirigir el puerto, usando tuneles "locales". Esto permitirá transferir de forma lógica ese puerto hacia nuestro equipo desde donde nos conectamos.

Ejemplo con PuTTY:

* Configuramos una sesión, apuntando a la IP pública del servidor (si no tiene una IP fija podemos usar NO-IP o DynDNS para localizar su IP cambiante), e indicamos el puerto
* Vamos a la pestaña SSH y al expandirla seleccionamos Tunnels, y configuramos un tunnel de la siguiente manera














Seleccionamos

Source Port:  el puerto a redirigir. En este ejemplo el 23 (TELNET)
Destination: La IP del servidor seguido del puerto. Puede ser el mismo equipo donde apuntamos o a otro que sea visible desde el servidor de SSH
Local: Esto indica que el puerto remoto será transferido al puerto local. Esto permitirá que podamos conectarnos en la direccion 127.0.0.1 (localhost ) al puerto que indicamos en Source Port como si fuera el equipo remoto.
Add : debemos presionar el botón para agregar el puerto. Podemos repetirlo para diferentes puertos de diferentes equipos.

Es importante destacar 2 cosas:

a) No todos los servicios soportan "tunneling". Algunos servicios necesitan ser accedidos por VPN o estando en la red local
b) Si tenemos varios equipos a los cuales acceder en el mismo puerto, podemos elegir diferentes puertos locales en "Source Port). Sólo deberemos cambiar el puerto para acceder a un servidor diferente

En este ejemplo estamos conectándonos al puerto 23 de un servidor remoto que es visible para el servidor que usamos para conectarnos por SSH. En este ejemplo, usamos el 23 local. La forma de conectarnos a él sería:

telnet 127.0.0.1 23

Si fuera un servidor web, pondríamos el puerto 80 y podríamos acceder de la siguiente forma






 b) Si son varios servidores, dependiendo de la cantidad de equipos y puertos,  podemos hacer lo mismo de arriba seleccionando un puerto local diferente para cada servidor como en el ejemplo de la imagen












o podemos crear un "proxy socks" con un único puerto




El SSH permite crear un tunel "dinámico" o proxy socks. Esto permite usar múltiples puertos a través de un único tunel, siempre que el programa lo permita.

Por ejemplo, en Firefox podemos seleccionar el proxy socks en la configuración y estaremos navegando como si nuestro equipo fuera el servidor de SSH. Esto lo haremos en Opciones->Avanzado->Red->Conexión/Configurar :





Lo mismo podemos hacer con programas como PuTTY, Filezilla (FTP), etc, que permiten seleccionar un Proxy Socks para conectarse al servidor remoto.

c) Podemos usar el mismo mecanismo que en b)  , pero si nuestro programa NO soporta Proxy, o no queremos complicarnos la existencia, podemos usar Proxifier (hay un trial en la página del producto).
Proxifier permite hablar con la mayoría de los programas aunque no tengan la opción de configurar el proxy socks, de forma transparente. Permite configurar rangos de direcciones IP asociadas a un determinado proxy (podemos usar más de uno a la vez) sin tener que hacer nada en el programa.

Para mayor información, http://www.proxifier.com/

3) Usar un tunel remoto. Si nuestro cliente "no sabe como hacerle" y está perdido, pero sigue necesitando nuestra ayuda, podemos usar un Tunel Remoto. Cabe aclarar que hacer esto sin el consentimiento del cliente nos podría meter en problemas.

Un tunel remoto es similar a un tunel local, sólo que en lugar de mapear un puerto del servidor en nuestra PC/Servidor de la oficina, será el servidor del cliente quien se conectará a la PC/Servidor de la oficina para maperar su propio puerto. El resultado es similar, sólo que no seremos nostros quienes iniciemos la comunicación.

Para mayor claridad: Imaginemos que este cliente no tiene VPN ni está en las soluciones a corto plazo, que no tiene conocimiento de como abrir un puerto en el firewall para publicar el SSH o cualquier otro en Internet (no como Uds :-)  o no quiere complicarse la existencia, pero sigue necesitando nuestro apoyo, podemos hacer que la montaña vaya a Mahoma.

Para esto, necesitamos tener un servidor SSH publicado en Internet, o bien nuestra PC con un servicio de SSH. Me inclino más por el servidor. Lo ideal sería que usarámos un puerto como el 443 en lugar del 22 (default) para evitar los firewalls en nuestro cliente.

Si nuestra IP no es fija, podemos usar un servicio como NO-IP o DynDNS para obtener una direccion dinámica con un nombre permanente. Muchos routers de Internet soportan DYNDNS y NO-IP de forma nativa, pero de no ser así, podemos instalar el cliente en el servidor o cualquier PC de la oficina. http://www.no-ip.com . Sólo deben crear una cuenta de usuario, descargar el cliente y listo.


Volviendo a nuestro tema original, vamos a configurar PuTTY apuntando a nuestro servidor, asumamos:

Nombre de servidor: miempresa.no-ip.biz (no-ip.com dispone de varios dominios gratuitos y otros de paga).
Puerto:  443

Nuestro servidor puede ser Linux o Unix (lo ideal), o  Windows. En Windows debemos instalar OpenSSH para Windows, y es bastante simple de configurar. http://sourceforge.net/projects/sshwindows/

En el servidor del cliente, si es Windows, configuramos la conexión a esa dirección, y creamos un tunel con lo siguiente:



Esto va a crear una conexión desde el servidor del cliente hasta nuestro servidor en la oficina en el puerto 2222, apuntando al OTRO servidor, en este caso el 192.168.1.123 en el puerto 22 (defautl para SSH).

Es decir, si hacemos ssh -p 2222 usuario@127.0.0.1 no va a pedir la clave para llegar al servidor remoto dentro de la red del cliente, que no necesita estar publicado y no necesita ser el servidor que se conecta con nosotros.

Ahora, ya que podemos ver el servidor en nuestra máquina, podemos crear un proxy socks hacia el cliente.

En Windows: Creamos una conexión apuntando a 127.0.0.1 en el puerto 2222 y luego es simplemente crear un tunnel dinámico como antes




Si es en Linux la cosa se pone más simple:

ssh -p 2222 usuario@127.0.0.1 -D 8080

Si conocemos lo suficiente de scripts en Unix/Linux podremos incluso crear un tunel persistente, que se reconecte cada X tiempo.

NOTA: Deben tener acceso a Internet desde el equipo en el cliente que se conecta a sus oficinas.
NOTA2: Deben tener activado el TCP Forwarding en el servidor local (es el default)
NOTA3: Repito, deben obtener el permiso del cliente, o sentirá que se están conectando a sus espaldas.

Linux sirve en la empresa? Cómo podría usarlo?

Aún recuerdo cuando me inscribí en la universidad y las computadoras no tenían disco rígido, sino un diskette con una suerte de cliente delgado que se conectaba a un servidor Linux central para capturar las inscripciones. Linux era un juguete de universitarios nerds que prometía mucho, nada más. Corría el año 1991.

No voy a mentirles, junto a la casa de estudio había una librería que importaba libros y vendían unos sobre Linux que traían un CD con slackware para poder jugar. Los dispositivos soportados estaban en una lista no muy extensa, y hacer funcionar una tarjeta de sonido o de video gráfico era realmente para expertos con mucho tiempo para invertirle y dinero para gastar en componentes para la PC.

Años más tarde, en 1998, trabajando para una casa desarrolladora de software al sur del continente americano, me vi envuelto en un proyecto imposible (de mis favoritos): una aplicación originalmente desarrollada para terminales de texto de IBM y migrada al gráfico Visual Basic con base de datos Oracle tenía que verse (nuevamente) en terminales de tipo texto. 

Durante semanas traté con especialistas en las terminales, con fantásticas ideas que rimaban con "winsock", "APIs", "Mappers" y técnicas de programación realmente complejas.

En una de esas pláticas me mostraron una terminal que aún no llegaba al país y que contaba con un navegador, pero de modo texto. Eso me encendió el foco. Linux + Lynx!!!

Lynx es un navegador de modo texto standard en Linux. La idea era generar las aplicaciones en Visual Basic  en modo web, para luego navegar desde un navegador Lynx dentro de un Linux en una pequeña PC (el "middleware") y que convertiría las páginas en pantallas de texto, a las que haría telnet la terminal (handheld) que necesitabamos para el proyecto.

Suena simple, pero implicó desarrollar toda una técnica para programar esas pantallas y alinear los campos. Sin embargo ... funcionó. Y se replicó la solución en otros clientes.

Cabe señalar que ese cliente ya contaba con su servidor Linux para correos.

En los años siguientes logré ver como varias empresas migraron sus servidores de correo, servidores de base de datos (Oracle y DB2), etc. a Linux. Empezaban con ambientes de desarrollo, como una suerte de laboratorio. Cuando ya veían que era robusto, lo extendían al resto de la empresa.

Al día de hoy tenemos Linux en los celulares (Android), en los servidores web y de correo que nos ofrecen como hosting, en los satélites, en los televisores y decodificadores de cable, etc.

Pero volvamos al tema inicial. Que puedo hacer con Linux dentro de una empresa?

En mi caso personal, uso Linux desde hace años en mi computadora personal (laptop) sin problemas. Mi cambio se debió a una serie de problemas con virus que me hicieron decidirme (dos formateos de mi equipo en un mes). No se lo aconsejo a todos, salvo a personal de sistemas en las áreas de telecomunicaciones y desarrollo en plataformas Java o PHP. Aún es técnicamente complejo para un no-técnico, aunque digan lo contrario.

Con un servidor Linux podremos:

1) Armar nuestro ambiente de virtualización: Linux permite crear máquinas virtuales incluso para correr servidores Windows

2) Crear un webserver: Siempre que no tengamos que correr páginas dependientes de DLLs o aplicaciones basadas en Windows.

3) Crear un servidor de correos: Es de las funciones más usadas. Existe un sinnúmero de aplicaciones de correo tanto gratuitas como de paga (IBM Lotus Dómino)

4) Crear un servidor de Base de Datos: Las bases de datos "SERIAS" soportan Línux. Tanto es así, que incluso Oracle emplea Linux para sus equipos ExaData y Exalogic, donde corren su famosísima base de datos. Hay soluciones gratuitas, como MySQL y PostgreSQL, y los líderes en "big-data" son bases de datos open-source como Hadoop, HBase, Cassandra, MongoDB, etc.

5) Crear un servidor de aplicaciones: WebLogic, WebSphere, Tomcat, corren en Linux con total soltura

6) Montar un Firewall: Los principales firewalls emplean Linux. Hay aplicaciones gratuitas y de paga, según los bolsillos

7) Montar una VPN: Existen muchas soluciones para poder conectarnos a la oficina de forma remota y segura

8) Montar un servidor de archivos: Para resguardar nuestros archivos

9) Montar un servidor de respaldo

10) Navegar de forma segura cuando estemos en la calle conectados desde una cafetería

y la lista sigue...

No por nada los principales fabricantes de equipos tienen alianzas con diferentes empresas relacionadas al mundo Linux.

* Existen distribuciones de Linux que permiten correr en grandes mainframes de millones de dólares.

* Las computadoras más veloces del mundo usan Linux (HPC)

* Hay empresas como IBM que lanzaron equipos que exclusívamente corren Linux (IBM PowerLinux)

Si al día de hoy su empresa no usa Linux, posiblemente se esté perdiendo de mucho por muy poco...

Navegar de forma segura y sin filtrado de contenido

Muchas veces estamos trabajando en oficinas de un cliente y nos topamos con la molestia de que tienen filtrado de contenido y no nos permite navegar en las páginas que necesitamos, incluido nuestro correo web.

Esto no sólo nos puede frustrar o molestar a la hora de trabajar, sino que nos plantea dudas sobre que tan seguros son nuestros datos al estar siendo monitoreados por la empresa. Demás está decir que muchas veces se traduce en tener que conectar nuestra preciada tarjeta BAM o celular con 3G/4G para poder navegar de una forma cómoda.

También nos ha pasado que vamos a sitios como Starbucks, Sanborns, VIPs, etc. para conectarnos, exponiendo nuestra conexión a quienes estén conectados en la red.

Aún recuerdo de los tiempos en que Internet no era tan popular que los principales hackers del país (actuales consultores en seguridad) se podían encontrar en los cyber-cafés. No creo que eso haya cambiado mucho, dado que es una excelente forma de conseguir conexiones "anónimas", especialmente en el café de la sirenita, donde todos llevan equipos móviles y hablan de negocios a la vista de todos (y escuchan).

Ante estos retos del día a día mi paranoia me llevó a armar un pequeño mecanismo que desde hace unos años me ha evitado dolores de cabeza: "Proxy usando Tunnel de SSH"

Lo que suena un poco complicado para algunos y conocido para otros se puede configurar en un rato y sin inventar el agua tibia.

Manos a la obra

Que necesitamos:

1) Internet en la casa u oficina y que tenga una IP pública (puede ser dinámica, no necesita ser IP fija)
2) Una computadora, servidor o vieja laptop que tengamos tirada en un rincón y que podamos dejar encendida cuando salgamos de casa.
3) Windows, Linux o Unix instalado en el Servidor/PC/Laptop
4) OpenSSH: Ok, quienes tenga Unix o Linux lo tienen por default y sólo necesitan configurarlo correctamente para evitar intrusos. En el caso de Windows les recomiendo el OpenSSH que se puede descargar de http://bit.ly/Azu4E8

Que debemos hacer en nuestro "Servidor"

1)  En el "Servidor" dejar configurado el OpenSSH, evitando que se puedan firmar como root, administrador o administrator, para evitar que nos hackeen el equipo facilmente.
2) Si tenemos Windows podemos instalarlo usando la siguiente guía http://bit.ly/yV9huA
3) Vamos a la página http://www.no-ip.com y creamos una cuenta gratuita y un nombre de host (en Hosts/Redirections) en alguno de los dominios gratuitos que nos ofrecen. Hay un ejemplo de como hacerlo en :
http://orlandohc-rcht.blogspot.com/2011/09/how-to-servidor-web-casero-2wire.html

4) En el router de nuestro proveedor de Internet debemos configurar un "forward" del puerto de SSH hacia nuestro "Servidor", para abrir el puerto a Internet. Podemos hacerlo desde las reglas del Firewall que traen los routers ADSL sin mucha dificultad. Aquí pueden encontrar una guía para un modem de Infinitum: http://bit.ly/wmOEOG

Que debemos hacer en nuestra Notebook/Laptop

En el caso de nuestra notebook o laptop la cosa está bastante simple:
1) Les recomiendo instalar el navegador Opera, dado que soporta Proxy Socks 5 y puede activarse/desactivarse el firewall facilmente presionando F12.
2) Descargamos el PuTTy COMPLETO con el Plink.exe, que permite ejecutar desde línea de comandos. Mi recomendación es copiar/instalar los archivos en c:\PuTTY
3) Creamos un archivo de texto proxy.bat dentro de c:\PuTTY con el siguiente comando:
plink -C usuario@<nombre_de_servidor> -D 8080
4) Creamos un acceso directo a nuestro escritorio para ese archivo, a fin de que sea cómodo de ejecutar
5) En el Opera configuramos el proxy:

Como Funciona?


Cuando estemos fuera de casa simplemente nos conectaremos a la red donde estemos y ejecutaremos el programa que dejamos en el escritorio. Nos abrirá una ventana y pedirá una clave de usuario (la que indicamos en el servicio de SSH) que pondremos para conectarnos a nuestros servidor y ya podremos minimizar la ventana.

Abriremos Opera y podremos navegar de forma segura, así de sencillo. Todo el tráfico viajará hasta nuestra casa u oficina y navegaremos desde ahí, sin mayor dificultad.

NOTA:Si queremos usar Opera sin emplear el Proxy podemos presionar F12 y desmarcar la casilla de Proxy.

Re-escribir o no re-escribir, esa es la cuestión - Modernización de aplicaciones y pantallas

A menudo nos topamos con problemas que nos hacen pensar en que debemos tomar entre las manos nuestro trabajo, hacer una bola y aventarlo al cesto de la basura.

Muchas de nuestras aplicaciones (o las de nuestros clientes) tienen años, y por lo general han sido modificadas por decenas y hasta cientos de programadores a lo largo de su ciclo de vida, sufriendo extrañas mutaciones, agregando interfaces crípticas o que no cumplen con los estándares de seguridad o de funcionalidad, con módulos desarrollados en diversos lenguajes de programación e interactuando entre distintos equipos de múltiples marcas y tecnologías.

Podemos pensar que esto es propio de las empresas que desarrollan sus propios sistemas, pero no es del todo cierto. Existen productos que han sido tan modificados que ni su propio creador podría reconocerlo.

Como muestra:

* Bancos y aseguradoras: Cuentan con aplicaciones de hasta 30 años corriendo en entornos monolíticos (mainframes, mini-computadoras, sistemas propietarios). Necesitan estrictos sistemas de seguridad por reglamentos del sector y las corporaciones que los administran.
* Empresas de distribución de mercancía: Cuentan con sistemas de hasta 10 años, por lo general son desarrollos internos, pero también existen sistemas comerciales que han sido modificados de forma radical.
* Industria: Suelen contar con sistemas bastante antiguos, de hasta 15 o 20 años, y dependiendo de su dependencia de estos la capacidad de inversión.
* Gobierno y empresas de servicio: Sus aplicaciones vienen de gestiones anteriores. Por lo general tienen reglas de negocio muy particulares y eso hace que se vuelvan enormes rompecabezas. Hay sistemas realmente antiguos corriendo en estas empresas.

Cada giro de negocio tiene una problemática particular, pero lo que es común a todos es que los tiempos cambian, las necesidades avanzan, y muchas veces necesitamos que nuestras aplicaciones hagan algo para lo cual no fueron pensadas: conectarse mediante Internet usando tecnologías como WebServices, funcionar desde una tablet, poder funcionar desde "la nube" o simplemente funcionar en web.

Cuando nos enfrentamos a esto nos invaden palabras como: Middleware, Web-Enable, Application Modernization, ESB, Message Queues, Screen Scrapping, Rehosting, o simplemente pensamos en un reemplazo de las aplicaciones, siempre que sea posible.

Pero no existe una forma de transición entre un ambiente y otro?

Los números dicen que muchas veces es más económico comprar un sistema nuevo que reparar uno existente. Pero la realidad dice que eso es en costos de adquisición, nuestros negocios no siempre están preparados para soportar un cambio tan radical.

Si pensamos en hacer convivir lo antiguo con lo nuevo existen alternativas:

Normalmente el middleware permite interconectar nuestro sistema "legacy" con nuevos módulos, pero hay que tener cuidado porque el middleware se puede convertir en un sistema por si mismo, de acuerdo al tamaño de la infraestructura.

Desde un punto de web-enable y application modernization podemos encontrar soluciones que pueden publicar sistemas de pantallas de texto como páginas web. Claro, no podemos considerar esto como una  solución definitiva, dado que conforme los usuarios van usando las aplicaciones en versión web van solicitando mejoras y modificaciones que requieren soluciones diseñadas especialmente para este ambiente, pero puede ser un primer paso. Ejemplos: Webfacing, IBM Rational HATS, Attachmate.

Algunas empresas tienen diseños en sus aplicaciones que permiten crear mecanismos de múltiples capas para separar las reglas de negocio de la capa de presentación. Un ejemplo de esto son aplicaciones de modo "batch" o stored procedures en un lenguaje nativo y un desarrollo visual en .NET o Java para la interacción con los usuarios.

Lo importante es comprender que los negocios ya necesitan de este tipo de cambios y mejoras en sus aplicaciones, que los directores y gerentes necesitan acceder a las aplicaciones todo el tiempo, y sin importar el mecanismo, sea un iPad o un celular.

Seguridad en las empresas de hoy

Cuando nos mencionan el tema de seguridad viene a nuestras mentes las imágenes de candados, firewall, policías, cajas fuertes, etc. Obviamente que los vendedores de soluciones de seguridad han acudido a estas imágenes tan simples para hablarnos de sus productos.
Pero la seguridad en nuestras áreas de TI es mucho más compleja y requiere de nuestra comprensión para poder tomar acción.

Nuestras infraestructuras de cómputo actuales se han vuelto realmente muy complejas y eso impacta en la administración de su seguridad. Si imaginamos a nuestra infraestructura como una casa, podemos decir que últimamente hemos abierto muchas puertas, a las cuales debimos poner complejos sistemas de alarmas y cerraduras para evitar que entren intrusos.

Las grandes consultoras señalan que la inversión en seguridad aumentará en el orden del 25% anual durante los próximos 3 años. Los empleos en el sector de seguridad han aumentado y existe una gran demanda de puestos gerenciales en estas áreas.

Para permitir que nuestras empresas puedan contar con páginas web, VPNs, intercambio de datos con otras empresas, etc, hubo que abrir esas "puertas" y agregar firewalls para asegurar el perímetro.
Si la cantidad de accesos y firewalls es importante generaremos una gran cantidad de logs, para lo cual necesitaremos un IPS con correlación de eventos, para que analice comportamientos sospechosos y descarte eventos inocuos.

La mayoría de las consultoras internacionales señalan que los ataques suelen venir desde dentro (estiman que en un 60% a 70% de los casos), por lo que adquirimos productos de monitoreo de aplicaciones (BPM y BAM) para asegurar los flujos de trabajo y productos de monitoreo y auditoría de bases de datos (DAM) para evitar que alguien altere la información en su beneficio.

Esto plantea 3 grandes dilemas:

1) Que sucede si se comete un fraude usando el sistema de forma adecuada, dentro de los horarios establecidos de trabajo, en equipos que tienen permitido hacerlo, pero valiéndose de errores en las políticas o en las aplicaciones?

2) Que sucede cuando el volumen de información es tan grande que un humano no puede analizarlo?

3) Que sucede cuando la falla de seguridad es la suma de eventos en diferentes niveles. Ejemplo: Si una persona se conecta desde una determinada terminal con un usuario específico, dentro de un horario permitido y ejecuta una acción.

He hecho pruebas simples en diversas aplicaciones publicadas en la web y puedo decirles que es alarmante el que se puedan ver datos de clientes sin tener que esforzarse demasiado.
Los buscadores como Google son también herramientas de búsqueda de errores en aplicaciones y de huecos de seguridad en nuestra infraestructura.

Recordemos que normalmente la seguridad se basa en el desconocimiento, desconocimiento de claves, desconocimiento de mecanismos, desconocimiento de direcciones, etc.

Pero este desconocimiento cuenta para gente externa a la organización, o no? Que sucede en la época del outsourcing y el desarrollo en empresas en otros continentes? Que ocurre con los ex-empleados? Y las aplicaciones que tenemos corriendo en  esquema de cloud computing?
Las preguntas son muchas y los desafíos aumentan cada año.

Pero no todo es malas noticias, si hay forma de resolver estos problemas, y se llama correlación de eventos y control de accesos. Existen productos que permiten consolidar los logs de los servidores, firewalls, herramientas de seguridad, etc. y rearmar la historia de lo ocurrido.
Podemos configurar estos productos para que nos envíen alertas, generen reportes y respalden la información para futuras consultas.
También existen productos que permiten revisar y auditar el código de los programas para ayudarnos a encontrar posibles fallas de seguridad.

La clave en todo esto es nuestro conocimento del negocio, nuestro enfoque en la seguridad, y el ser realmente concientes del riesgo que significa el no estar preparados.