Sistemas Distribuidos (Laboratorio)

Reporte 12 - Seguridad de la información en el clúster

En esta entrada para laboratorio mencionaré buenas prácticas que se acostumbran hacer en un clúster para mantener la seguridad y confidencialidad.

Sería bueno que la información de nuestro clúster sea conocida y accedida solamente por aquellos que estén debidamente autorizados (confidencialidad).

También la información solo puede ser modificada, creada o eliminada por quienes estén autorizados (integración), para este tipo de seguridad, yo recomendaría las técnicas y procedimientos que se aplican en algunas empresas como Alestra, para administrar equipos de red (routers, switches, etc) ellos primero tienen que autenticarse con user y password.

Hacen esto por medio de  TACACS


TACACS (Terminal Access Controller Access Control System) es un protocolo de autenticación remota, propietario de cisco, que se usa para comunicarse con un servidor de autenticación comúnmente usado en redes Unix. TACACS permite a un servidor de acceso remoto comunicarse con un servidor de autenticación para determinar si el usuario tiene acceso a la red.

Cuando el administrador de la empresa quiere tener acceso a un router, primero se le pide un user y un password, luego estos datos proporcionados por el administrador van y se comparan a este servidor TACACS, luego si tus datos están registrados en el servidor y todo coincide tendrás acceso al equipo, de otra manera es "imposible" entrar a cualquier equipo.

No digo que utilicemos esta herramienta en específico porque es propietario de Cisco, por lo tanto es de paga, pero podemos hacer uso de algo similar, incluso se me hace sencillo programarlo, con algo de Mysql debe quedar rápido.

Por otro lado, los sistemas que albergan datos e información deben garantizar disponibilidad cuando se requiera por quienes tienen los privilegios.


Buenas prácticas en seguridad dentro de la red

• Mantener servicios y sistemas actualizados, en cuanto a parches y bug fixes, en este aspecto yo considero que nosotros estamos bien, porque todos tendremos la misma versión de SO además que es la LTS.
  
  
  
  
  
  
  
  
  
  
• Definir y emplear puntos y procedimientos de acceso (mecanismos de autenticación), aquí considero buena opción realizar un simulador de un servidor TACACS donde cada nodo cuente con su user y password guardados en el master, luego cuando queramos entrar al clúster, que nos pida autenticarnos y nuestros datos se comparen con los guardados en el master, de esta manera una persona no autorizada no podría entrar a nuestro clúster.
  
  
  
  
  
  
  
  
  
  
  
• Normar y controlar el acceso a las instalaciones físicas de los sistemas.
  Para este punto yo creo que es más aplicable a empresas donde si requieren de un nivel de seguridad máximo, donde su información si es muy importante.
  Es bien sabido y he escuchado de muchos expertos que si no tienes una seguridad física de tus equipos, entonces no sirve de nada tu seguridad "virtual", incluso me han platicado de equipos cisco con candado físico, creo yo para proteger puertos.
  
  
  
  
  
  
  
  
  
  
  
  
• Implementar sistemas de respaldo. La mayoría de las empresas de IT cuentan con sistemas de respaldo, donde cada moviemiento de información se va actualizando en un disco duro.
  En este tipo de sistemas, así como en los sistemas de redundancia (equipos secundarios que entran en acción cuando el principal falla), es muy importante que se verifique periódicamente su buen funcionamiento.
  
  Actualmente está de moda el concepto de "la nube", incluso es una opción para respaldar la información del clúster, pero yo no la considero como una buena opción ya que dependes del servicio de alguien que ni siquiera le pagas para que te aloje tus datos, por lo tanto no te garantiza confiabilidad y disponibilidad. Peor aún dependes de una conexión a internet que debe ser muy segura y poco intermitente, a los proveedores de internet si les pagas, pero igual nunca garantizan confiabilidad.
  
  Yo considero mejor opción un servidor de respaldo propio, que funcioné con la conexión local, por si el internet llega a fallar, tomando en cuenta que nuestro clúster estará dentro de un mismo salón.
  
  
  
  
  
  
  
  
  
  
• Cifrar o proteger con contraseñas los datos e información importante del clúster. Para eso nosotros estamos trabajando con SSH, con SSH estamos habilitando el establecimiento de conexiones completamente cifradas.
  
  
  
  
  

 

Esperemos que nos quede tiempo para implementar estas medidas de seguridad que en un futuro serán necesarias, cuando quede listo nuestro clúster.

Saludos a todos! 


 

Sistemas Distribuidos (Clase)

Reporte 12 - Hamachi + SSH

En esta semana estuve trabajando con mi compañero Avendaño en realizar un túnel de VPN para poder hacer el clúster desde nuestras casas (el túnel lo hicimos con Hamachi), hicimos esto para llevar algo que ofrecer o proponer en nuestra junta de clúster (creo que ya habían hecho algo parecido).

Esto de realizar el túnel ya lo habiamos intentado antes pero no resultó debido a problemas con el Firewall de Ubuntu, esta vez mi compañero pudo resolver ese problema, luego tiramos ping cada uno de nosotros a nuestras computadoras y si se respondían.

Después de comprobar que entre nuestras computadoras si había conexión, decidimos entrar de forma remota mediante SSH, logramos entrar cada uno a la computadora remota y además intentamos realizar el clúster pero no funcionó.

En la siguiente liga de la wiki documenté todo el proceso que llevamos a cabo para realizar la conexión:

http://elisa.dyndns-web.com/progra/Hamachi%2BSSH

Como ya mencioné en la publicación de la wiki, quiero dar crédito y nominar a mis compañeros Avendaño y Adriana por haber trabajado y apoyado en este "mini proyecto".

Planeo hacer futuras pruebas de RMI aprovechando las facilidades y ventajas que nos da Hamachi.

También nomino al compañero Jonathan por la explicación de su código: http://elisa.dyndns-web.com/progra/Passing%20Arguments%20to%20Threads

Saludos!

 

Sistemas Distribuidos (Clase y Laboratorio)

Reporte 11 - RMI desde computadoras remotas

Para esta entrada decidimos mi compañero Esteban y yo utilizar el feature de Java RMI, decidimos realizar esta tarea en pareja para aprovechar al máximo las funcionalidades de RMI, ya que anteriormente solo lo hice desde mi propia computadora.


Lo que hicé esta semana fue solamente documentar (bases) las cosas que necesitaremos para relizar nuestro mini "proyecto", luego esperemos para la siguiente semana implementar el código para poder hacer uso de este interesante feature.


Hicimos está documentación con la intención de ampliarla más adelante con los códigos que vayamos implementando y por supuesto los resultados que conseguimos, si  obtenemos buenos resultados les haremos saber (mediante la wiki o una entrada) para así intentar implementarlo con todos los compañeros.


Les dejo la liga del wiki, donde podrán ver la documentación que relicé para poder llevar acabo este proyecto (es solo las ideas, pasos y teoría, luego subiremos nuestras implementaciones de código).


Liga: http://elisa.dyndns-web.com/progra/Documentaci%C3%B3n%20RMI


Saludos!

Sistemas Distribuidos (Clase y Laboratorio)

Reporte 10

Java Remote Method Invocation (RMI)

RMI es un mecanismo ofrecido por Java que nos permite utilizar funciones (métodos) de un programa, desde otro programa que reside en otra computadora, obviamente para poder hacer esto se necesita que las computadoras participantes estén en red, además de otras cosas que mencionaré a continuación. Wikipedia dice:

La arquitectura RMI puede verse como un modelo de 4 capas (esto como las capas del modelo ISO OSI ayudan a hacer el troubleshooting en una red con complicaciones, al separar el proceso en layers que cumplen una función en específico):

• Primera capa

La primera capa es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicación que quiera que sus métodos estén disponibles para su acceso por clientes remotos debe declarar dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa básicamente para "marcar" un objeto como remotamente accesible. Una vez que los métodos han sido implementados, el objeto debe ser exportado. Esto puede hacerse de forma implícita si el objeto extiende la clase UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de forma explícita con una llamada al método exportObject() del mismo paquete.

• Segunda capa

La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa directamente con la capa de aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y retorno de objetos tienen lugar en esta capa.

• Tercera capa

La capa 3 es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. También es responsable de la gestión de la replicación de objetos y realización de tareas específicas de la implementación con los objetos remotos, como el establecimiento de las persistencias semánticas y estrategias adecuadas para la recuperación de conexiones perdidas. En esta capa se espera una conexión de tipo stream (stream-oriented connection) desde la capa de transporte.

• Cuarta capa

La capa 4 es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una máquina a otra. El protocolo de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que solamente es "comprendido" por programas Java.

Lo primero que se debe implementar para establecer comunicación entre los programas es el servidor. Vamos a crear una interface que enumere las funciones provistas por el objeto a ser exportado por la red osea que queramos invocar de forma remota (solo se declara, no se define). Esta interfaz es compartida entre cliente-servidor. Del lado del servidor vamos a crear una clase que implemente esta interfaz que acabo de mencionar.

Después por el lado del cliente también se accede a esa misma interfaz, pero existe una clase stub que es la que se encarga a establecer el envío del mensaje por red, y recibir una respuesa.

Ejemplo

El programa ejemplo se compone de 2 ventanas, una para el cliente y una para el servidor. El cliente tiene una caja de texto donde se escriben los mensajes a enviar; dichos mensajes se envían utilizando un método remoto(el método se encuentra en la clase RmiServidor.java). Mientras, el servidor posee un area de texto donde se muestran los mensajes que recibe de los posibles clientes.


Para descargar el código vayan a la siguiente liga, también podrán encontrar explicación detallada de cómo funciona RMI, el código no lo hice yo, esta es la página del autor: http://casidiablo.net/rmi-%C2%BFque-es-un-ejemplo-sencillo-con-rmi/

El código se compone de 5 clases:

• RmiServidor.java
• GUIServidor.java
• InterfazReceptorMensajes.java
• RmiCliente.java

En la clase RmiServidor se define el puerto de escucha en 3232 y se despliega la información enviada por el cliente en la GUI del servidor.

La clase GUIServidor solo nos servirá para mostrar los procesos que el servidor realicé, osea mostrar el String escrito que le llega al Servidor desde el Cliente.

La clase InterfazReceptorMensajes es una interfaz que hereda de la clase Remote ( de java.rmi.) aquí es donde anteriormente mencioné que se declara el método recibirMensaje (solo se declara, se definirá en la clase RmiServidor.java)

La clase RmiCliente declara un objeto de la interfaz InterfazReceptorMensajes y dos objetos String en donde colocaremos la dirección IP del servidor a conectarnos y el puerto.

Como pueden ver en el código, la dirección del server es la 127.0.0.1, eso quiere decir que el servidor lo correré en la misma computadora (es la dirección localhost), lo ideal es hacerlo en 2 computadoras, también hacer la prueba con más clientes.

El método enviarMensaje es el que realmente utiliza RMI. Dicho método utiliza la función recibirMensaje del objeto rmiServidor, es decir: utiliza el método remoto del servidor a través de la interfaz.

Explicación más detallada del código pueden encontrarla en la liga antes mencionada (página del autor del código). Para la próxima sesión modificaré el código e intentaré correrlo en más computadoras para aprovechar este feature ofrecido por java.

Yo corrí los códigos con éxito y estos son los pantallazos (para compilarlo pueden hacer como con cualquier otro programa de java, yo hice javac *.java):








Saludos!