Social Icons

twitterfacebookgoogle plusemail

lunes, 4 de febrero de 2013

Reporte del RFC del protocolo de conexión del SSH


A partir de la referencia del RFC 4254 que puede ser encontrada en la página de datatracker.ietf.org; en este RFC se describe el protocolo Secure Shell (SSH).


Secure Shell (SSH) es un protocolo para realizar un inicio de sesión de manera segura a un servidor. En el documento se muestran varios tipos de conexiones existentes que se pueden hacer en el tunnel encriptado, desde inicios de sesión interactivos, ejecución de comandos de manera remota, reenvio en conexiones TCP/IP y X11. El protocolo SSH fue diseñado para correr en un la capa de transporte y en protocolos de autenticación de usuario.

Peticiones globables (Global Requests). En el documento se habla de que existen diferentes tipos de peticiones que afectan al estado del extremo remoto global, independientemente del canal en el que se encuentre. Un ejemplo de ello es la petición para iniciar el reenvío de TCP / IP  para un puerto específico; Teniendo en cuenta que el cliente y el servidor pueden enviar peticiones globales en cualquier momento, y el receptor deberá responder apropiadamente. En todas las peticiones se debe manejar el siguiente formato.

            byte       SSH_MSG_GLOBAL_REQUEST
      string     nombre de la petición solo en US-ASCII.
      boolean    quieres respuesta
      ....       petición específica de información

Donde el valor de nombre de la petición es el nombre de la extención DNS. Este respondera con este mensaje SSH_MSG_REQUEST_SUCESS o SSH_MSG_REQUEST_FAILURE sí en si quieres respuesta usaste un TRUE.

            byte      SSH_MSG_GLncluye el número local del canal y el tamaño inicial
      byte      SSH_MSG_CHANNEL_OPEN
      string    nombre de la petición solo en US-ASCII.
      uint32    canal por donde se envia
      uint32    tamaño inicial de la ventana
      uint32    tamaño máximo del paquete
      ....      tipo de canal específico de informacicanal hasta que un mensaje es recibido indicando que el espacio de la ventana esta disponible.

Abriendo un canal (Opening a Channel). Cuando se desea abrir un nuevo canal, se asigna un número local para el canal. A continuación, se envia el siguiente mensaje al receptor, e incluye el número local del canal y el tamaño inicial de la ventana en el mensaje.

         byte      SSH_MSG_CHANNEL_OPEN
      string    nombre de la petición solo en US-ASCII.
      uint32    canal por donde se envia
      uint32    tamaño inicial de la ventana
      uint32    tamaño máximo del paquete
      ....      tipo de canal específico de información

Transferencia de datos (Data Transfer). El tamaño de la ventana específica cuantos bytes el otro participante puede enviar antes de que se deba esperar a que la ventana sea ajustada.

            byte     SSH_MSG_CHANNEL_WINDOW_ADJUST
      uint32    canal usado
      uint32    bytes a agregar

Cerrando un canal (Closing a Channel). Cuando el participante quiere terminar el canal, envía SSH_MSG_CHANNEL_CLOSE, después de enviar este mensaje el participante debe de enviar de regreso el mismo mensaje SSH_MSG_CHANNEL_CLOSE al menos que este ya haya enviado este mensaje por el canal; Los canales son considerados como cerrados por los participantes una vez que ambos hayan enviado y recibido SSH_MSG_CHANNEL_CLOSE, hecho lo anterior el canal puede ser reusado.

        byte      SSH_MSG_CHANNEL_CLOSE

Al enviar el mensaje el otro participante deberá responder con SSH_MSG_CHANNEL_OPEN_CONFIRMATION o SSH_MSG_CHANNEL_OPEN_FAILURE.

Comenzando con shell o un comando (Starting a Shell or a Command). Una vez que la sesión ha sido confirmada, un programa se comienza de manera remota al otro participante, el programa puede ser un shell ó una aplicación. Solamente una de las peticiones pueden pasar de manera satisfactoria por canal. Este mensaje de abajo envia una petición de usuario por default en shell, que típicamente esta definido en /etc/psswd en sistemas de UNIX.

            byte      SSH_MSG_CHANNEL_REQUEST

      uint32    máximo tamaño de paquete

La implementación del cliente debe rechazar cualquier canal de petición de sesión abierta para que sea más díficil que haya un servidor corrupto que ataque al cliente.

Canales X11 (X11 Channels). X11 son canales abiertos con un canal de petición abierta. Los canales resultantes son independientes de la sesión, y cerrando las sesión, no se cierran los canales transmitidos X11.

            byte      SSH_MSG_CHANNEL_OPEN
      string    "x11"
      uint32    canal de envío
      uint32    tamaño inicial de la ventana
      uint32    máximo tamaño de paquete
      string    dirección de origen
      uint32    puerto de origen

Al enviar el mensaje el otro participante deberá responder con SSH_MSG_CHANNEL_OPEN_CONFIRMATION o SSH_MSG_CHANNEL_OPEN_FAILURE.

Comenzando con shell o un comando (Starting a Shell or a Command). Una vez que la sesión ha sido confirmada, un programa se comienza de manera remota al otro participante, el programa puede ser un shell ó una aplicación. Solamente una de las peticiones pueden pasar de manera satisfactoria por canal. Este mensaje de abajo envia una petición de usuario por default en shell, que típicamente esta definido en /etc/psswd en sistemas de UNIX.

            byte      SSH_MSG_CHANNEL_REQUEST
      uint32    canal usado
      string    "shell"
      boolean   quiero respuesta

El mensaje de abajo envía una petición que el servidor empiece a ejecutar un comando dado.

        byte      SSH_MSG_CHANNEL_REQUEST
      uint32    canal usado
      string    "exec"
      boolean   quiero respuesta
      string    comando

Reenvío de puerto TCP/IP (TCP/IP Port Forwarding)

Solicitud de reenívo de puerto (Requesting Port Forwarding). Un participante no necesita una petición explicita de reenvío desde una dirección a otra. Sí se desea que las conexiones a un puerto desde el otro participante sean enviadas al participante local, este debe ser solicitado de la siguiente manera.

        byte      SSH_MSG_GLOBAL_REQUEST
      string    "tcpip-forward"
      boolean   quiero respuesta
      string    dirección a enlazar (e.g., "0.0.0.0")
      uint32    número de puerto a enlazar

Redirección de canales TCP/IP (TCP/IP Forwarding Channels). Cuando llega una conexión a un puerto por la petición remota de envío, un canal es abierto y reenvía el puerto al otro participante.

            byte      SSH_MSG_CHANNEL_OPEN
      string    "forwarded-tcpip"
      uint32    canal de envío
      uint32    tamaño inicial de la ventana
      uint32    máximo tamaño de paquete
      string    dirección de la cual estaba conectada
      uint32    puerto de la cual estaba conectada
      string    dirección IP original
      uint32    puerto original

Las implementaciones deben rechazar estos mensajes a menos que tengan solicitado previamente un reenvío de puerto TCP/IP con el número de puerto dado.

Conclusión

Este protocolo se me hizo una buena implementación debido a que es muy importante tener cifrada la información para poder evitar alguna fuga de datos. Por el lado de la documentación se me hizo muy completo, ya que contiene todos los aspectos que cubre y todos los posibles casos que ocurren; algunas ocasiones tuve problemas de traducir algunas referencias y es porque a veces es díficil entender algún juego de palabras.

Una cosa que se me haría interesante agregar a este protocolo serían nuevos niveles de encriptado, ya que a como vamos avanzando año con año es mas fácil desencriptar un archivo; hoy en día es posible hacer ataques de cifrado con smarth phones con la misma potencia que una computadora de hace dos años, así que por un lado yo veo que es un area de oportunidad a desarrollar.

Páginas de referencia:

Imagen ilustrativa del protocolo de SSH
http://www.ibm.com/developerworks/aix/library/au-sshsecurity/SSH_Protocol1.gif

Documento RFC del protocolo SSH
http://datatracker.ietf.org/doc/rfc4254/

Imagen ilustrativa del protocolo de SSH
http://www.ibm.com/developerworks/aix/library/au-sshsecurity/SSH_Protocol1.gif

Documento RFC del protocolo SSH
http://datatracker.ietf.org/doc/rfc4254/

1 comentarios:

  1. Le pusiste etiqueta de lab y es de clase. Cuida la ortografía ("extención"). 9 pts.

    ResponderEliminar