¿Por qué bloquear el puerto 22 de salida?

Soy programador, y he trabajado para algunos clientes cuyas redes bloquean las conexiones salientes en el puerto 22. Considerando que los programadores a menudo necesitan usar el puerto 22 para ssh, esto parece un procedimiento contraproducente. En el mejor de los casos, obliga a los programadores a facturar a la empresa por Internet 3G. En el peor de los casos, significa que no pueden hacer su trabajo de manera efectiva.

Dadas las dificultades que esto crea, ¿podría un administrador de sistemas experimentado explicar el beneficio deseado a lo que parece una acción de perder-perder?

No veo que nadie haya explicado el riesgo específico con el reenvío de puertos SSH en detalle.

Si está dentro de un cortafuegos y tiene acceso SSH saliente a una máquina en Internet público, puede SSH a ese sistema público y en el proceso crear un túnel para que las personas en Internet público puedan acceder a un sistema dentro de su red, completamente sin pasar por el firewall.

Si fred es su escritorio y barney es un servidor importante en su empresa y wilma es público, se ejecuta (en fred):

ssh -R *: 9000: barney: 22 wilma

e iniciar sesión permitirá a un atacante ssh al puerto 9000 en wilma y hablar con el demonio SSH de barney.

Su firewall nunca lo ve como una conexión entrante porque los datos se pasan a través de una conexión que se estableció originalmente en la dirección saliente.

Es molesto, pero es una política de seguridad de red completamente legítima.

Si están bloqueando una mezcolanza de puertos, dejando pasar algunas cosas y bloqueando otras cosas al azar (me encanta la triste historia de Paul Tomblin sobre las personas que bloquean SSH y permiten Telnet), entonces tienen un caso muy extraño sobre cómo proceder a asegurar el perímetro de su red, o sus políticas de seguridad son, al menos desde el exterior, aparentemente mal pensadas. No puede dar sentido a situaciones como esa, así que simplemente les cobra la tarifa actual para las personas que son dolorosas y continúan con su día.

Si están bloqueando TODOS los puertos, a menos que exista un caso comercial específico para permitir el tráfico a través de ese puerto, en ese momento se administra con cuidado , lo están haciendo porque son competentes en sus trabajos.

Cuando intentas escribir una aplicación segura, ¿facilitas que otros procesos lean y escriban información a su antojo o tienes algunas API cuidadosamente documentadas que esperas que llamen las personas y que desinfectas cuidadosamente?

Gestión de riesgos: si cree que el tráfico hacia o desde su red que va a Internet es un riesgo, entonces busca minimizar la cantidad de formas en que el tráfico puede llegar a Internet, tanto en términos de número de rutas como de métodos. Luego puede monitorear y filtrar estas puertas de enlace y puertos "bendecidos" elegidos para tratar de asegurarse de que el tráfico que circula por ellos sea lo que espera.

Esta es una política de firewall "denegación predeterminada" y generalmente se considera una buena idea, con algunas advertencias a las que me referiré. Lo que significa es que todo está bloqueado a menos que haya una razón específica para desbloquearlo, y los beneficios de la razón superan los riesgos.

Editar: Debo aclarar, no solo estoy hablando de los riesgos de permitir un protocolo y bloquear otro, sino de los riesgos potenciales para el negocio de permitir que la información fluya dentro o fuera de la red de manera no controlada camino.

Ahora para las advertencias, y posiblemente un plan para liberar las cosas:

Puede ser molesto cuando te bloquean algo, que es la posición en la que te encuentras con algunos de tus clientes. Con demasiada frecuencia, las personas a cargo del firewall piensan que es su trabajo decir "No", en lugar de "Aquí están los riesgos, ahora cuáles son los beneficios, veamos qué podemos hacer".

Si habla con quien administra la seguridad de la red para sus clientes, pueden estar dispuestos a configurar algo para usted. Si puede identificar algunos sistemas específicos en su extremo al que necesita acceso y / o garantizar que solo se conectará desde una dirección IP específica, puede ser mucho más feliz crear una excepción de firewall para conexiones SSH para esas condiciones específicas de las que sería simplemente abrir conexiones a todo internet. O pueden tener una instalación de VPN que puede usar para hacer un túnel a través del firewall.

Una cierta gran empresa en Rochester NY que solía hacer una gran cantidad de películas bloqueó ssh salientes cuando trabajaba allí, ¡pero permitió telnet ! Cuando pregunté al respecto, dijeron que ssh era un agujero de seguridad.

En otras palabras, las empresas a veces toman decisiones estúpidas y luego inventan excusas sobre la seguridad en lugar de admitir sus errores.

Puedo entender el bloqueo de la comunicación SSH entrante si la empresa no permite inicios de sesión externos. Pero, esta es la primera vez que escucho sobre un bloqueo SSH saliente.

Es importante tener en cuenta que tal firewall probablemente limitará solo al usuario SSH casual. Si alguien realmente quiere usar SSH afuera (que generalmente será a un servidor / máquina al que tienen acceso significativo, fuera de la red empresarial), puede ejecutar fácilmente el servidor SSH en un puerto que no sea el 22 (digamos, el puerto 80). El bloque se omitirá fácilmente.

También hay varias herramientas de dominio público que le permitirán salir de la empresa a través de HTTP (puerto 80 o HTTPS 443) y le proporcionarán proxies para que pueda conectarse al puerto 22 en el exterior.

Editar: Ok, espera un segundo, tengo una idea de por qué esto podría ser una política.

A veces, las personas usan túneles SSH para evitar los firewalls salientes básicos para protocolos como IM y Bittorrent (por ejemplo). Esto // podría // haber desencadenado tal política. Sin embargo, todavía siento que la mayoría de estas herramientas de túnel podrían funcionar en puertos que no sean 22.

La única forma en que se pueden bloquear dichos túneles de salida es detectando la comunicación SSH sobre la marcha y (dinámicamente) bloqueando estas conexiones TCP.

Probablemente sea un problema regulatorio / de cumplimiento. Su empleador quiere poder leer / archivar todas las comunicaciones. Esto es a menudo un requisito en industrias como la banca.

Hay dos razones principales para bloquear el puerto 22 de salida, en mi opinión.

Primero, como la gente ha mencionado, el reenvío de puertos SSH se puede usar como proxy o evitar otros puertos y servicios para evitar que la política de TI indique que dicho tráfico no está permitido.

En segundo lugar, una gran cantidad de malware / botnets utilizará el puerto 22 porque a menudo se considera "seguro" y, por lo tanto, está permitido. Luego pueden iniciar procesos desde ese puerto, y las computadoras infectadas también pueden lanzar ataques de fuerza bruta SSH.

La mayoría de las veces se trata de bloquear todas las conexiones salientes a menos que sea necesario, y hasta que lo intentó, nadie había solicitado que el puerto 22 estuviera disponible para las conexiones salientes (solo 80, 433, etc.). Si este es el caso, entonces la solución puede ser tan simple como contactar a IS / IT y decirles por qué necesita una excepción agregada para que su estación pueda realizar conexiones SSH salientes a hosts específicos o en general.

A veces es preocupante que las personas puedan usar la instalación para usar SSH como una forma de configurar proxies (a través del reenvío de puertos a través del enlace) para eludir otros controles. Esto puede ser un factor muy importante en algunas industrias reguladas (es decir, bancos) donde todas las comunicaciones deben ser monitoreadas / registradas por razones legales (desalentar el uso de información privilegiada, detectar / bloquear la transferencia de datos corporativos o personales, etc.) o compañías donde Existe un gran temor a que las fugas internas revelen, accidentalmente o de otro modo, secretos comerciales. En estos casos, usar su enlace 3G (u otras técnicas como tratar de hacer un túnel SSH a través de HTTP) para eludir las restricciones puede ser una violación de su contrato y, por lo tanto, un delito de despido (o, probablemente peor, un delito legal), así que tenga cuidado de Acuerde su acción antes de intentarlo.

Otra razón podría ser reducir la huella saliente (a los servicios internos accesibles a los hosts dentro de los firewalls de la compañía y al mundo en general) en caso de que algo desafortunado se instale en una máquina que opera la compañía. Si no hay conexiones SSH posibles en el puerto 22, muchos hacks más simples que intentan usar inicios de sesión SSH de fuerza bruta ya que se bloqueará una de sus rutas de propagación. En este caso, es posible que nuevamente pueda solicitar que se agregue una excepción para que su máquina pueda realizar conexiones SSH, si estas conexiones pueden justificarse a las personas que controlan los cortafuegos.

Sus clientes probablemente estén en posesión de datos no triviales que les gustaría conservar. El SSH saliente es algo realmente malo tener abierto para toda una red. Es bastante trivial eludir proxys, filtrar datos confidenciales y ser generalmente desagradable.

En mi opinión, cualquier cosa que pase por el perímetro de la red / internet debe entenderse y controlarse. Si un grupo de desarrolladores necesita acceso a servidores en un proveedor de alojamiento a través de ssh, está bien, pero también debe documentarse. En general, en los lugares en los que he trabajado, establecemos conexiones VPN dedicadas de sitio a sitio a ubicaciones fuera de nuestra red, (esencialmente extendiendo nuestra red interna) y evitamos protocolos de clientes como SSH en Internet.

Porque SSH se puede usar como una VPN. Está encriptado, por lo que los administradores de red literalmente no tienen idea de qué sale de su red (volcado de la base de datos del cliente, etc.). Acabo de cubrir estas cosas en mi columna mensual "Túneles secretos" . El costo de Internet 3G es muchísimo menor que tener que preocuparse por los protocolos encriptados que canalizan sus datos fuera de la red. Además, si bloquea de manera predeterminada el puerto 22 de salida y el tráfico inspecciona, puede encontrar fácilmente SSH en puertos no estándar y, por lo tanto, encontrar personas que violen la política de seguridad.

Conozco a un par de personas que abusan de las capacidades de SSH para instalar un proxy SOCKS a través de SSH, evitando así algunas restricciones del sitio.

O incluso un simple reenvío de puertos ( ssh -L ....), si el puerto está bloqueado debido a restricciones del sitio, iría a:

• el administrador local y
• su gerente de proyecto

llévelos a una mesa y déjelos explicar la razón por la cual esto está bloqueado. Por supuesto, debe tener buenas razones por las que necesita acceso a un puerto SSH externo para desarrollar un producto interno (ser interno: ¿Por qué necesita acceso a boxA.example.com cuando trabaja para una empresa snakeoil.invalid)?

Pero todavía tengo que ver una empresa que bloquea SSH saliente :)

Las respuestas obvias han sido expuestas. Es un protocolo encriptado que se puede utilizar para eludir las políticas mediante la creación de túneles (esta es una excelente manera de superar los filtros web corporativos), así como la amenaza que representan los canales de comunicación no autorizados (proxy inverso).

Es cierto, Telnet debería destruirse en cualquier red moderna. Pero, puedo ver permitir que Telnet salga de la red mientras se prohíbe ssh. Telnet es menos capaz que ssh y siempre puedo monitorear la transmisión, en tiempo real, a través de mis rastreadores. Si no tengo ningún dispositivo telnet en mi red principal, y algún usuario quiere desconectarse, ¿qué me importa? Puedo verlo y verificar que no sea una amenaza.

Por supuesto, todo esto depende de la idea de que la política predeterminada es bloquear toda salida y solo permitir protocolos específicos. Puntos de bonificación si los estás representando antes del borde.

No se trata de bloquear específicamente el puerto 22 porque los administradores tienen algo en contra de SSH, sino más bien solo abrir los puertos que saben que necesitan abrir. Si a su administrador no le han dicho que se necesita abrir SSH, su administrador lo bloqueará, según el mismo principio que se aplica a la desactivación de servicios no utilizados en un servidor.

Claramente, un bloque TCP / 22 saliente es fácil de eludir a menos que los administradores de red hayan tomado esfuerzos serios y serios para bloquear el tráfico SSH en específico . Además, los administradores de activos deben estar lo suficientemente activos como para ejecutar un inventario de activos suficiente para atrapar módems 3G y direcciones IP sospechosas en las 2das NIC. Tenemos el servicio ClearWire en nuestra área, por lo que incluso tenemos WiMax como una opción de ejecución final en torno a la seguridad de nuestra red.

No somos una institución que se preocupa principalmente por la filtración de información. Pero si lo fuéramos, necesitaríamos combinar una política de seguridad de red draconiana con una política de activos draconiana, con auditoría. Que yo sepa, no creo que exista un paquete de seguridad estándar que desconecte el conector de red de un activo que inventarios con una conexión de red externa de algún tipo. Eso puede estar llegando.

En ausencia de dicho paquete, el proceso de inventario de activos es una de las mejores formas de capturar una conexión de red de ejecución final como 3G o WiMax.

Y, por último, el bloqueo ciego de TCP / 22 solo bloqueará a los usuarios menos hábiles que intenten violar el AUP de su red de trabajo.

He visto 22 bloqueados cuando descubrieron que la gente dirigía el tráfico http a través de 22. Fue un obstáculo para aquellos de nosotros que lo necesitábamos, pero la organización se mantuvo firme.

La mayoría de las organizaciones más grandes bloquearán todo y solo permitirán el acceso HTTP / HTTPS a través de un servidor proxy.

Me sorprendería saber que las corporaciones permiten conexiones externas directas desde computadoras de escritorio o servidores a menos que haya una necesidad específica.

Nada le impide ejecutar su sshd remoto en el puerto 80. Tanto ssh como sshd tienen una opción -p para configurar el puerto.

Por supuesto, si sus administradores son inteligentes, deben vigilar el tráfico ssh, no solo el tráfico del puerto 22. Entonces, parece que tienes un problema de política, no un problema tecnológico.

Sin embargo, como otros señalaron, los protocolos cifrados pueden causar acidez estomacal en las personas que tienen que preocuparse por una variedad de problemas de cumplimiento.