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/
Suscribirse a:
Enviar comentarios (Atom)
Le pusiste etiqueta de lab y es de clase. Cuida la ortografía ("extención"). 9 pts.
ResponderEliminar