Posts del SysAdminSeguridadUncategorized

SSH y Wireshark: examinando tráfico

De manera similar a lo que hicimos con Telnet en el post anterior, en esta oportunidad utilizaremos el protocolo SSH y Wireshark para examinar el tráfico entre nuestro equipo local (nuevamente, 192.168.0.104) y el servidor con IP 192.168.0.29, donde el servicio sshd se encuentra escuchando en el puerto TCP 2990.

SSH y Wireshark

Antes de llevar a cabo la conexión al servidor, crearemos el filtro indicando que deseamos observar el tráfico en el puerto TCP 2990 (1) utilizando la interfaz de red eth0 (3), aplicaremos el mismo haciendo clic en Apply (2), y finalmente comenzaremos la captura, tal como vemos en la Fig. 1:

SSH y Wireshark - Configurando la captura de datos
Figura 1 – Configurando la captura de datos

Al elegir nuevamente la opción Follow TCP stream, veremos que el tráfico es cifrado y el dump en ASCII del mismo no contiene datos que nos permitan identificar o inferir la contraseña o claves utilizadas (método de autenticación que utilizamos en la comunicación para este caso). En la Fig. 2 podemos ver este punto en mayor detalle:

SSH y Wireshark - Examinando la captura de datos
Figura 2 – Examinando la captura de datos

Scp y sftp

Recordemos que OpenSSH también incluye las herramientas scp y sftp para copiar archivos hacia y desde un servidor SSH remoto, tal como explicamos en otra oportunidad. Probemos en observar el tráfico generado al enviar y recibir archivos utilizando estos dos protocolos.

Si realizamos la captura tal como en el caso de la conexión mediante ssh, encontraremos que los datos también aparecen cifrados. Por este motivo, podemos estar confiados en que nuestras comunicaciones utilizando estos protocolos son MUCHO más seguras que si estuviéramos utilizando telnet.

Espero que este post y el anterior les hayan resultado útiles para convencerse de que todos los datos que se envían a través de la red utilizando el protocolo Telnet pueden verse utilizando Wireshark. SSH, por otra parte, no tiene esa vulnerabilidad, por lo que deberíamos utilizarlo para todas nuestras comunicaciones remotas.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *