¿Hay alguna forma viable de bloquear la utilidad stunnel en el nivel de red?

Dado que excluye la intercepción SSL (es decir, no se pueden instalar certificados) y también excluye cualquier tipo de análisis de patrones de tráfico, no queda mucho. Lo que podría intentarse es analizar el propio protocolo de enlace TLS:

• Las pilas de TLS y también las aplicaciones que usan TLS a menudo dejan una huella digital utilizable en ClientHello, es decir, qué versión de protocolo, qué cifrados se ofrecen en qué orden, qué extensiones se usan y qué orden, etc. Nada nuevo y se puede encontrar mucha información sobre esto . Por supuesto, un cliente podría, en teoría, replicar otro ClientHello perfectamente para ocultarse.
• Se podría hacer un análisis pasivo similar para el lado del servidor. Pero la variedad de configuraciones de servidor que se reflejan en la pila TLS es mucho más grande que en el lado del cliente, por lo que probablemente no sea tan efectivo como analizar el ClientHello.

Para que quede claro: esto es solo heurística. Puede causar falsos positivos y puede no detectar instancias de stunnel. Esto es especialmente cierto en redes complejas con una variedad de clientes diferentes y solo un poco de tiempo para analizar manualmente si se debe permitir una huella dactilar poco común en general, a un objetivo específico o se debe bloquear.

Sin intercepción, de ninguna manera.

Este es un problema que debe resolverse con política , no con tecnología . No puede detener a los usuarios con tecnología, infraestructura o configuración. La única manera segura es la política . Si emplea una regla estricta en webshells, stunnel y acceso remoto, y realmente lo hace cumplir, sus usuarios estarán menos inclinados a hacer agujeros en la pared.

Pero si quieres el camino más frustrante, hay algunas malas noticias: no puedes hacerlo sin intercepción. No importa qué tipo de inspección pasiva emplee, los usuarios lo evitarán.

Conectarse al sitio para ver si hay un sitio web no funcionará. Usando sslh es posible usar el mismo puerto para HTTPS, SSH, OpenVPN, XMPP y HTTP simple, todo en el mismo tiempo.

Otra opción es sacacorchos . Transmitirá SSH a través de su proxy HTTPS de forma transparente. Si no intercepta la conexión y la inspecciona, su firewall no detectará nada.

Incluso si analiza y bloquea otros protocolos, un usuario ingenioso puede usar AjaxTerm o Shell in a Box , filtra los datos incluso si intentas bloquear SSH.

Podría tener un software que establezca su propia conexión con cada host, puerto y SNI observados, y quizás otros parámetros como la versión TLS y los conjuntos de cifrado si cree que alguien podría estar ocultando información en ellos, y ver si responde a una Solicitud como un servidor HTTPS normal. Si no responde con el formato HTTP a través de la conexión SSL / TLS, puede asumir que es SSH aturdido o algo más dudoso como el torrente y ponerlo en una lista negra. Tal vez con vencimiento después de un período definido, en caso de que sea una IP dinámica y se reasigne.

Sin embargo, en lugar de SSH (TCP) sobre SSL / TLS (stunnel), alguien podría usar un software que realice SSH (TCP) sobre HTTPS, es decir, SSH (TCP) sobre HTTP sobre SSL / TLS. Eso será esencialmente imposible de detectar simplemente al intentar una solicitud HTTPS arbitraria, ya que el túnel HTTP podría usar cualquier forma de autenticación u ofuscación que no sepa debido a SSL / TLS. En ese caso, probablemente su única opción sea investigar manualmente los servidores deseados y agregar a la lista blanca aquellos que considere seguros (y estables); a menos que pueda limitarlo estrictamente (tal vez wikipedia, linkedin, algunos bancos y restaurantes locales, y Stack (por supuesto)) probablemente necesitará varios empleados de tiempo completo para cada empleado que quiera monitorear, y luego usted Necesitaré una forma de monitorear los monitores.

Alternativamente, una aproximación barata es solo a RST cualquier conexión que dure más de 30 segundos (edición) entre transmisiones de datos. Aunque los clientes HTTPS (especialmente los navegadores) tenderán a mantener las conexiones inactivas abiertas por un tiempo para ahorrar el costo de la reconexión, el protocolo HTTP (y por lo tanto también HTTPS) está definido y (casi universalmente) implementado para que funcione bien si tiene que rehacer el conexión de transporte con frecuencia (editar) para cualquier o incluso cada solicitud. En contraste, la mayoría de las cosas que se realizan a través de SSH depende de mantener la misma conexión, pero no todas, por lo que un tramposo suficientemente determinado también podría evitar esto.