Tropospheric scatter

Diffraction
Line of sight
PROTOCOLO SSH
Franklin Lapo

8
vo
Ciclo Titulacin Electrnica y Telecomunicaciones

El protocolo de conexin gestiona las sesiones
interactivas para la ejecucin remota de comandos,
mandando los datos de entrada de cliente a servidor y
los de salida en sentido inverso. Tambien se encarga de
la redireccin de puerto TPC

LA CAPA DE TRANSPORTE SSH:
El protocolo de conexin
LA CAPA DE TRANSPORTE SSH:
El protocolo de conexin

Ejemplo: Con la redireccin TCP es posible lograr que las conexiones que se realicen
a un determinado puerto PC del cliente sean redirigidas a un puerto PB de un
ordenador B desde el servidor, o que las conexiones que se realicen a un
determinado puerto PS del servidor sean redirigidas a un puerto PD de un ordenador
D desde el cliente. De esta forma la conexin SSH se puede utilizar, por ejemplo,
como tnel de otras conexiones a travs de un cortafuegos que est situado entre el
cliente y el servidor SSH.
LA CAPA DE TRANSPORTE SSH:
El protocolo de conexin

SSH contempla a posibilidad de utilizar lo que se conoce como agente de
autenticacin. Este aggente es un proceso que permite automatizar la
autenticacin del usuario basada en claves publicas cuando es necesario
realizara desde un ordenador remoto.


LA CAPA DE TRANSPORTE SSH:
El protocolo de conexin

Ejemplo: El usuario del ordenador A utiliza un cliente SSH para conectarse al
ordenador B y trabajar con una sesin interactiva. El ordenador A puede ser, por
ejemplo un PC porttil en el que el usuario tiene guardada su clave privada y
del que no desea que salga nunca esta clave. Entonces resulta necesario
establecer una conecion SSH desde el ordenador B al ordenador C y se tiene
que autenticar con su clave personal. El cliente del ordenador B, en lugar de
realizar directamente la autenticacin para lo que necesitara la clae privada del
usuario, pide al agente del ordenador A que firme el mensaje adecuado para
demostrar que posee la clave privada.

LA CAPA DE TRANSPORTE SSH:
El protocolo de conexin

Cada sesin interactiva, conexin TCP redirigida o conexin a un agente es un
canal.
Pueden existir distintos canales abiertos en una misma conexin SSh cada uno
identificado con un numero en cada extremo.
SSH2 prev catorce tipos de mensajes que se pueden enviar durante la fase de conexin.
stas son algunas de las funciones que permiten realizar los mensajes:
Abrir un canal. Se pueden abrir canales de distintos tipos: sesin interactiva, canal de ventanas X,
conexin TCP redirigida o conexin con un agente de autenticacin
Congurar parmetros del canal. Antes de empezar una sesin interactiva el cliente puede
especicar si necesita que se le asigne un pseudoterminal en el servidor, como hace el
programarloginde Unix (en cambio, el programa rsh no lo necesita) y, si es as, con qu
parmetros (tipo de terminal, dimensiones, caracteres de control, etc.). Existen otros mensaje para
indicar si se quiere conexin con el agente de autenticacin o redireccin de conexiones de
ventanas X.

Enviar datos. En SSH2 existen dos tipos de mensaje con este n: uno para enviar datos normales
en cualquier sentido y para cualquier canal (incluyendo las sesiones interactivas), y otro para
enviar datos especiales (por ejemplo, los de la salida de error stderr). Adems de los datos de la
sesin, el cliente tambin puede enviar un mensaje para indicar que ha recibido una seal o que
se ha producido un cambio en las dimensiones del terminal.
LA CAPA DE TRANSPORTE SSH:
El protocolo de conexin

Funciones que permiten realizar los mensajes:
Cerrar canal. Cuando termina la ejecucin normal del proceso o intrprete de comandos, el
servidor enva un mensaje indicando el cdigo de salida (el valor numrico que devuelve el
proceso). Si ha terminado a causa de una seal, en SSH2 enva un mensaje con el nmero de
seal. Existen otros mensajes que sirven para indicar que ya no hay ms datos de entrada, para
solicitar el cierre de un canal desde un extremo, y para conrmar el cierre desde el otro extremo.

Ataques contra el protocolo SSH

Muchas de las consideraciones sobre la proteccin que proporciona
SSL/TLS son aplicables tambin al protocolo SSH. Este protocolo est
diseado para que un atacante no pueda leer el contenido de los
mensajes ni alterarlos, y tampoco cambiar la secuencia de los mismos.

La confidencialidad queda garantizada con el mtodo de intercambio de
claves basado en criptografa de clave pblica, que protege contra los
ataques "del hombre en el medio".

Adems, este mtodo permite que el cliente se asegure de que se est
conectando al servidor autntico. Para comprobar que la clave pblica
que enva el servidor es realmente la suya, se pueden usar certificados,
o bien una base de datos local del cliente en la que estn guardadas las
claves de los servidores reconocidos. Y para autenticar al usuario
mediante una clave pblica (la suya o la del cliente desde el cual se
conecta, dependiendo del mtodo de autenticacin), tambin existen
las dos opciones: certificados o una base de datos de claves en el
servidor.

Ataques contra el protocolo SSH

Si no se usan certificados, el protocolo contempla la posibilidad (aunque no
se recomienda) de dar por buena la clave pblica de un servidor la primera
vez que se establezca una conexin, sin necesidad de ninguna
comunicacin previa. Esto no es apropiado en un entorno donde la
seguridad sea crtica, porque representa una vulnerabilidad a ataques "de
hombre en el medio".
En otros entornos, y mientras no se disponga de una infraestructura de
claves ampliamente extendida, aceptar directamente claves recibidas por
primera vez puede suponer un equilibrio entre comodidad de uso y
seguridad.
Una caracterstica interesante aadida a SSH2 es que las longitudes de los
paquetes se envan cifradas. Un atacante que vea los datos intercambiados
como un flujo de bytes no puede saber dnde empieza y dnde acaba cada
paquete SSH2 (si tiene acceso al nivel de paquetes TCP puede intentar
hacer deducciones, pero sin una certeza absoluta). Esto, conjuntamente
con la posibilidad de incluir padding arbitrario (hasta 255 bytes) y enviar
mensajes IGNORE, puede servir para ocultar las caractersticas del trfico y
dificultar los ataques con texto claro conocido.

Ataques contra el protocolo SSH

Los mtodos de autenticacin de usuario mediante listas de acceso se
basan en la confianza del servidor en el administrador del sistema
cliente (del mismo modo que los protocolos rsh y rlogin):
Cuando no se autentica el sistema cliente (posibilidad contemplada
solamente en SSH1), el servidor slo tiene que aceptar conexiones que
provengan de un puerto TCP privilegiado (menor que 1024) para que a
un usuario cualquiera no le sea fcil enviar paquetes suplantando la
identidad de otro.
Cuando hay autenticacin del sistema cliente, el servidor confa que los
usuarios no tendrn acceso a la clave privada de este sistema, porque
si no podran utilizarla para generar mensajes de autenticacin con la
identidad de otro usuario.
Finalmente, igual que pasa con SSL/TLS, el protocolo SSH est
diseado para ofrecer determinadas protecciones, pero el nivel de
seguridad que proporcione en cada caso vendr dado por las
implementaciones y por el uso que se haga del mismo.

Ataques contra el protocolo SSH

Se recomienda que se puedan deshabilitar o restringir las
caractersticas (mtodos de autenticacin de usuario, redireccin de
puertos TCP, etc.) que en un determinado entorno impliquen alguna
vulnerabilidad o posibilidad de abuso.

Aplicaciones que utilizan el protocolo SSH
Muchas de las consideraciones sobre la proteccin que proporciona SSL/TLS son
aplicables tambin al protocolo SSH. Este protocolo est diseado para que un atacante
no pueda leer el contenido de los mensajes ni alterarlos, y tampoco cambiar la secuencia
de los mismos.

La confidencialidad queda garantizada con el mtodo de intercambio de claves basado
en criptografa de clave pblica, que protege contra los ataques "del hombre en el
medio".

Adems, este mtodo permite que el cliente se asegure de que se est conectando al
servidor autntico. Para comprobar que la clave pblica que enva el servidor es
realmente la suya, se pueden usar certificados, o bien una base de datos local del cliente
en la que estn guardadas las claves de los servidores reconocidos. Y para autenticar al
usuario mediante una clave pblica (la suya o la del cliente desde el cual se conecta,
dependiendo del mtodo de autenticacin), tambin existen las dos opciones: certificados
o una base de datos de claves en el servidor.

Si no se usan certificados, el protocolo contempla la posibilidad (aunque no se
recomienda) de dar por buena la clave pblica de un servidor la primera vez que se
establezca una conexin, sin necesidad de ninguna comunicacin previa. Esto no es
apropiado en un entorno donde la seguridad sea crtica, porque representa una
vulnerabilidad a ataques "de hombre en el medio".
Aplicaciones que utilizan el protocolo SSH
En otros entornos, y mientras no se disponga de una infraestructura de claves
ampliamente extendida, aceptar directamente claves recibidas por primera vez puede
suponer un equilibrio entre comodidad de uso y seguridad.

Una caracterstica interesante aadida a SSH2 es que las longitudes de los paquetes se
envan cifradas. Un atacante que vea los datos intercambiados como un flujo de bytes no
puede saber dnde empieza y dnde acaba cada paquete SSH2 (si tiene acceso al nivel
de paquetes TCP puede intentar hacer deducciones, pero sin una certeza absoluta).
Esto, conjuntamente con la posibilidad de incluir padding arbitrario (hasta 255 bytes) y
enviar mensajes IGNORE, puede servir para ocultar las caractersticas del trfico y
dificultar los ataques con texto claro conocido.

Por otra parte, merece la pena sealar que los mtodos de autenticacin de usuario
mediante listas de acceso se basan en la confianza del servidor en el administrador del
sistema cliente (del mismo modo que los protocolos rsh y rlogin):

Cuando no se autentica el sistema cliente (posibilidad contemplada solamente en
SSH1), el servidor slo tiene que aceptar conexiones que provengan de un puerto TCP
privilegiado (menor que 1024) para que a un usuario cualquiera no le sea fcil enviar
paquetes suplantando la identidad de otro.
Aplicaciones que utilizan el protocolo SSH
Cuando hay autenticacin del sistema cliente, el servidor confa que los usuarios no
tendrn acceso a la clave privada de este sistema, porque si no podran utilizarla para
generar mensajes de autenticacin con la identidad de otro usuario.

Finalmente, igual que pasa con SSL/TLS, el protocolo SSH est diseado para ofrecer
determinadas protecciones, pero el nivel de seguridad que proporcione en cada caso
vendr dado por las implementaciones y por el uso que se haga del mismo.

Se recomienda que se puedan deshabilitar o restringir las caractersticas (mtodos de
autenticacin de usuario, redireccin de puertos TCP, etc.) que en un determinado
entorno impliquen alguna vulnerabilidad o posibilidad de abuso.
Ejemplos de redireccin de puertos TCP con SSH
1) Desde un ordenador llamado cerca podemos hacer: ssh -L 5555:srv.lejos.com:23 -l admin medio
Si nos autenticamos correctamente, habremos establecido una conexin interactiva con el ordenador medio como
usuario admin, y adems, cualquier conexin al puerto 5555 de cerca, como sta: telnet cerca 5555
Estar redirigida al puerto 23 TELNET del ordenador srv.lejos .com pasando por medio y con el tramo cerca y
medio protegido con SSH
2) sta sera una forma de proteger una conexin a un servidor HTTP mediante un tnel SSH, suponiendo que
podamos autenticarnos ante este servidor:
ssh -L 5678:localhost:80 www.lejos.com
Un vez realizada esta operacin, podemos introducir la direccni nhttp://localhost:5678/ en cualquier navegador web
del ordenador local, y nos llevar automticamente a la direccin con una conexin cifrada
.
El funcionamiento de este protocolo
- El cliente inicia una conexin TCP sobre el puerto 22 del servicio. Este puerto es el
que utiliza por defecto el protocolo, aunque como veremos en siguientes puntos, se
puede modificar.
- El cliente y el servidor se ponen de acuerdo en la versin del protocolo a utilizar,
as como el algoritmo de cifrado utilizado para el intercambio de la informacin.
- El servidor, que tiene en su poder dos claves (una privada y una pblica), manda su
clave pblica al cliente.
Cuando el cliente recibe la clave enviada por el servidor, la compara con la que tiene
almacenada para verificar su autenticidad.
El protocolo SSH exige que el cliente la confirme la primera vez.
El funcionamiento de este protocolo
- Con la clave pblica del servidor en su poder, el cliente genera una clave de sesin
aleatoria, creando un mensaje que contiene esa clave y el algoritmo seleccionado para
la encriptacin de la informacin. Toda esa informacin es enviada al servidor haciendo
uso de la clave pblica que envi en un paso anterior de forma cifrada.
- Si todo es correcto, el cliente queda autenticado, iniciando la sesin para comunicarse
con el servidor.
.
Concluciones
El tnel SSH es una buena solucin para navegar por internet en el
caso que nos hallemos en Red local No segura.
La navegacin a travs de un tnel SSH garantiza nuestra
confidencialidad ya que nadie podr conocer las pginas web que estamos
visitando ni que estamos haciendo.
La navegacin a travs de un tnel SSH garantiza la integridad de los
datos transmitidos y recibidos ya que la probabilidad que alguien pueda
modificar las datos que enviamos o recibimos es muy baja.
Los tneles SSH nos pueden servir tambin para vulnerar ciertas
restricciones impuestas por nuestro ISP o por ejemplo tambin nos
puede servir para vulnerar ciertas restricciones impuestas por proxies y
firewall.
Los tneles SSH son una buena solucin para asegurar la
comunicacin entre 2 mquinas y para fortificar protocolos
dbiles como por ejemplo HTTP, SMTP. FTP, Telnet, etc.