¿Cómo un administrador de red bloquea el SSH inverso en la empresa?

El tráfico SSH se ve diferente de HTTP y HTTPS. El tráfico SSH simplemente canalizado a través del puerto 80 o 443 (es decir, ssh -p80... ) puede detectarse mirando el primer paquete de respuesta que ya contiene la versión SSH y no la versión HTTP o el servidor TLS ServerHello. Pero también podría simplemente imponer el uso de un proxy HTTP dentro de la red, lo que hace que el uso de SSH simple sea imposible.

Esto deja la posibilidad de hacer un túnel SSH dentro de otro protocolo, como simplemente crear un túnel a través del proxy utilizando una solicitud CONECTAR o incluso ocultando la conexión SSH dentro de una conexión TLS completa, usando HTTP simple, usando WebSockets, con DNS o similar . Esto es mucho más difícil de detectar, aunque algunos análisis estadísticos pueden ayudar, ya que SSH muestra un comportamiento diferente al tráfico HTTP normal. Pero tal análisis podría confundirse fácilmente con el tráfico común de WebSockets de hoy.

Al final es una carrera y deberías preguntarte por qué te centras en los túneles SSH de todos modos. Estos túneles no son más que una herramienta para transportar datos entre el interior y el exterior. Dichos transportes de datos también se pueden hacer usando HTTP / HTTPS normal, se pueden hacer con memorias USB, etc. Por lo tanto, enfocarse en un solo vector previene la fuga de datos o para evitar que el atacante ingrese a la red es IMHO de la manera incorrecta. Y para tener una política: es más seguro tener una lista blanca sobre lo que está permitido que tener una lista negra sobre lo que no está permitido.

Una forma de hacerlo un poco más difícil podría ser tener un proxy HTTP en su lugar para que las conexiones no puedan realizarse directamente a través de 80/443 a menos que sea una conexión HTTP válida, pero incluso eso se puede omitir aunque se use algo. como Proxytunnel . Otra forma de evitar esto sería simplemente ejecutar una consola web y acceder a ella normalmente a través de 80/443.

Es probable que no les impida hacerlo más difícil para ellos, pero al final, si tiene en su política que no está permitido y supervisa la red, se pueden enviar advertencias a las personas que infringen esta regla.

Aquí, han bloqueado SSH a través del puerto 443 al bloquear el método CONNECT del Proxy HTTP.

Una segunda solución es utilizar una página falsa de "inicio de sesión". El uso del proxy puede solicitar una contraseña, esto normalmente lo solicita el navegador, o se ingresa en los campos de autenticación en las aplicaciones que pueden usar un proxy. Pero puede omitir esto en el servidor proxy utilizando una página de inicio de sesión falsa que solicite el inicio de sesión / contraseña.

Este método es horrible, ya que solo la aplicación que muestra esta página puede pasar por el proxy. Putty, por ejemplo, no puede mostrar esta página y, por lo tanto, no puede autenticarse ante el proxy.

La primera pregunta debería ser por qué los usuarios / administradores utilizan túneles ssh inversos. Trabajé en una empresa que tenía una VPN realmente mal implementada para la administración remota, que solo permitía la conectividad a un servidor citrix con herramientas deficientes, por lo que usamos túneles remotos SSH para administrar adecuadamente nuestros servidores de forma remota. Los túneles donde solo se permitía salir de un host de bastión. El host se configuró con la autenticación de contraseña deshabilitada, el inicio de sesión de raíz deshabilitado y la autenticación basada en clave habilitada. El túnel inverso permitió que las conexiones ssh se trasladaran a la zona DMZ, luego, desde el bastión, los usuarios solo podían acceder a un puñado de otros hosts. En lugar de ir por el agujero del conejo para bloquear la tunelización de ssh con MITM interceptando proxies, IDS, bloqueando el acceso a las direcciones IP de los administradores y los firewalls DPI. Ofrezca una mejor solución a los usuarios / administradores, satisfaciendo sus requisitos, luego implemente una política de recursos humanos y aplíquela.

Luajit a través de Suricata IDPS proporciona algunos mecanismos avanzados para controlar SSH así como túneles SSL / TLS para evitar la subversión de proxy, shells inversos, y otros.

Echa un vistazo a esta guía bastante completa, aunque no del todo completa, para encontrar certificados autofirmados utilizando Suricata y luajit - enlace

Preguntando cómo asegurar ssh abre una lata de gusanos, aquí están esos gusanos.

Algunos se enojarán cuando digo esto, pero es algo bastante simple que puede lograrse y "debería haberse construido de esta manera" hace mucho tiempo.

Esto se puede hacer, la mayoría de los que no están de acuerdo son neighsayers, y probablemente responsables de las vulnerabilidades a las que nos enfrentamos actualmente en el mundo ... Me estoy desviando del tema.

La sugerencia anterior de forzar todo el tráfico a través de proxies que requieren visibilidad en el tráfico antes de la transferencia es un buen comienzo y debe ser un concepto implementado y alineado con la red y las políticas y metodologías de seguridad física, a veces hasta el la computadora portátil / móvil del guardia de seguridad que realiza tareas en el pasillo.

Controla tus estaciones de trabajo cliente. Cablealos apropiadamente. Segregar de la conexión inalámbrica. Tener un seguimiento constante de estadísticas en el cliente "terminales tontos". Usb se apaga. Proporcionar centros de poder para las personas que necesitan poder. Hacer que todas las exportaciones salgan a través de un proceso de aprobación, que incluye los procedimientos de administración de TI.

El software en estas estaciones de trabajo puede ser una plataforma simple con una capacidad mínima que proporciona una interfaz web o una aplicación cliente que los guiará de forma segura a los recursos accesibles que solo son apropiados para su función.

Se debe evitar la conexión inalámbrica a menos que se encuentre en un troncal completamente diferente.

Los servicios como las "plataformas de redes sociales" deben ser "supervisados en exceso", ya que deben ser alertas más falsas que las alertas reales, para que la empresa pueda beneficiarse de la información que entra y sale de una red de redes sociales "utilizada". "

Todo esto es de un agente de soporte de bajo nivel con demasiado tiempo en sus manos. Sin embargo, si tiene una red con estas metodologías implementadas, comprobará que es valioso saber las idas y venidas de sus empleados, no una invasión de la privacidad, sino un activo. En su lugar de datos seguros, lo único que alguien debe ocultar es la compañía y sus datos, incluido quién los maneja y cómo.

En este día y edad, si tiene una razón para asegurar la información, necesita seguridad en aquellas personas que aseguran proporcionar información segura.

No es necesario que los empleados muevan los datos de la empresa tan libremente como lo hacen estos días.

Todo esto se puede mitigar al mínimo, y mucho menos se debe cumplir con los protocolos de seguridad física, así como para limitar los aspectos de fotografía y video de los métodos de exfil de datos, además del lápiz y el papel habituales, "memorias USB", etc.