¿Cómo deshabilitar el reenvío de puerto local SSH?

20

Tengo un servidor que ejecuta Ubuntu y el demonio OpenSSH. Llamémoslo S1.

Uso este servidor desde máquinas cliente (llamemos a una de ellas C1) para hacer un túnel inverso SSH mediante el reenvío de puertos remotos, por ejemplo:

ssh -R 1234:localhost:23 login@S1

En S1, uso el archivo sshd_config predeterminado. Por lo que puedo ver, cualquiera que tenga las credenciales correctas {login, pwd} en S1 puede iniciar sesión en S1 y realizar el reenvío de puertos remotos y el reenvío de puertos locales. Dichas credenciales podrían ser un certificado en el futuro, por lo que, según tengo entendido, cualquiera que tome el certificado puede iniciar sesión en S1 desde cualquier otro lugar (no necesariamente C1) y, por lo tanto, crear reenvíos de puertos locales.

Para mí, permitir el reenvío de puertos locales es demasiado peligroso, ya que permite crear algún tipo de proxy público. Estoy buscando una manera de desactivar solo los reenvíos.

Intenté lo siguiente, pero esto deshabilita el reenvío local y remoto:

AllowTcpForwarding No

También probé lo siguiente, esto solo permitirá -L a SX: 1. Es mejor que nada, pero aún no es lo que necesito, que es una opción de "ninguno".

PermitOpen SX:1

Así que me pregunto si hay una manera, para que pueda prohibir a todos los reenvíos de puertos locales escribir algo como:

PermitOpen none:none

¿Es la siguiente una buena idea?

PermitOpen localhost:1

ssh port-forwarding local

— SCO
fuente

así que, como siempre, vayamos a la raíz de esto: ¿cuál es su verdadero problema, por qué desea configurar algo como esto para dispositivos móviles / integrados, qué quiere resolver?

— akira

El problema a resolver aquí es poder abrir una sesión Telnet, en cualquier lugar desde Internet, a un dispositivo móvil / incrustado conectado a Internet, teniendo en cuenta que el dispositivo podría tener NAT o firewall, por lo que no es accesible desde Internet.

— SCO

telnet .. para que? para perforar agujeros en el firewall google para 'aturdir'

— akira

16

cualquier persona con credenciales de inicio de sesión puede mostrar su propia instancia de sshd, que se ejecuta en un puerto aleatorio y permitir lo que quiera, incluidos los reenvíos locales -L:

% /usr/sbin/sshd -d -f mysshd.config -p 12345

Si no confía en los usuarios para hacer algo con su máquina, no debe permitirles iniciar sesión en primer lugar.

(por cierto, el indicador -D también es "problemático de proxy")

— akira
fuente

Bueno, supongo que puedo configurar una cuenta muy restrictiva para este propósito (por ejemplo, pegar al usuario en su casa, sin listado, sin exploración del sistema de archivos), para que no pueda iniciar y sshd (o instalar e iniciar un binario sshd). El punto es que se supone que los clientes son dispositivos integrados. Pero dado que probablemente incluirán certificados y su memoria flash se puede volcar, es posible que los certificados se filtren, lo que permite que cualquiera pueda iniciar sesión en S1.

— SCO

Usar ChrootDirectory para ese usuario en particular hará el truco, ¡lo intentaremos!

— SCO

1

En claves_autorizadas, establezca command="/sbin/nologin". Esto debería evitar que ejecuten comandos en el servidor.

— justis

La afirmación "cualquier persona con credenciales de inicio de sesión puede mostrar sus propios <whatever>" es falsa. sshse puede usar para conectarse a cuentas que tienen restricciones de inicio de sesión severamente restringidas que no lo permiten. El reenvío de puertos es un agujero de seguridad en dichos depósitos restringidos. Además de ejecutar un comando permitido, el usuario puede crear túneles.

— Kaz

3

Cita de la sshd_configpágina de manual: tenga en cuenta que deshabilitar el reenvío TCP no mejora la seguridad a menos que a los usuarios también se les niegue el acceso al shell , ya que siempre pueden instalar sus propios reenviadores. (El énfasis es mío).

— Kaz

17

Otra solución sería permitir solo el reenvío de puertos a usuarios específicos:

De SSH: la guía definitiva

El reenvío de puertos se puede habilitar o deshabilitar globalmente en sshd. Esto se hace con la palabra clave de configuración del servidor AllowTcpForwarding en / etc / sshd_config. La palabra clave puede tener el valor yes (el valor predeterminado, habilita el reenvío) o no (deshabilita el reenvío):

# SSH1, SSH2, OpenSSH
AllowTcpForwarding no

Además, SSH2 tiene las siguientes opciones:

# SSH2 only
AllowTcpForwardingForUsers
AllowTcpForwardingForGroups

La sintaxis de estos es la misma que para las opciones AllowUsers y AllowGroups. [Sección 5.5.2.1, "Control de acceso a la cuenta"] Especifican una lista de usuarios o grupos que pueden usar el reenvío de puertos; el servidor se niega a cumplir con las solicitudes de reenvío de puertos para cualquier otra persona. Tenga en cuenta que se refieren a la cuenta de destino de la sesión SSH, no al nombre de usuario del cliente (que a menudo no se conoce).

...

Es importante darse cuenta de que las directivas de esta sección en realidad no impiden el reenvío de puertos, a menos que también desactive los inicios de sesión interactivos y restrinja qué programas se pueden ejecutar en el lado remoto. De lo contrario, los usuarios expertos simplemente pueden ejecutar su propia aplicación de reenvío de puertos a través de la sesión SSH. Esta configuración por sí sola puede ser un elemento disuasorio suficiente en una comunidad no técnica, pero no detendrá a alguien que sepa lo que está haciendo.

— cristiano
fuente

1

Básicamente, solo tendré un usuario aprovisionado en S1. AFAIU, en este caso específico, usar AllowTcpForwardingForUsers / AllowTcpForwardingForGroups no funcionará, ¿verdad? Prohibir el inicio de sesión interactivo es una buena idea, ya que hará que los usuarios no puedan iniciar binarios. Pero a cualquier cliente todavía se le permitirá usar la sintaxis -L, ¿verdad? Entonces, por ahora, las mejores opciones serían: 1 / Deshabilitar inicio de sesión interactivo, 2 / PermitOpen con un nombre de host falso: puerto. Me he perdido algo ?

— SCO

La mejor manera de verificar esto sería probar la configuración.

— Christian

No puedo ver estas opciones en el software gratuito OpenSSH. Un google for AllowTcpForwardingForUsersrevela que está configurado en un sshd2_config, que se utiliza en algunos programas comerciales. Vea una de las respuestas a: superuser.com/questions/384643/…

— Kaz

^ OpenSSH tiene Matchbloques en la configuración. Puede Matchen usuarios y grupos, y adjuntar el AllowTcpForwardinginterior.

— Kaz

2

Ahora hay una opción para permitir solo el reenvío local / remoto.

AllowTcpForwarding Especifica si se permite el reenvío TCP. Las opciones disponibles son "sí" o "todos" para permitir el reenvío de TCP, "no" para evitar todo el reenvío de TCP, "local" para permitir el reenvío local (desde la perspectiva de ssh (1)) solamente o "remoto" para permitir el control remoto solo reenvío . El valor predeterminado es "sí". Tenga en cuenta que deshabilitar el reenvío TCP no mejora la seguridad a menos que a los usuarios también se les niegue el acceso al shell, ya que siempre pueden instalar sus propios reenviadores.

Entonces, como ya se dijo, también debe configurar el shell para nologin.

— Markus Rathgeb
fuente

0

Mi solución a este problema fue agregar: PermitOpen fo.local: 80 en la sección principal de sshd_config.

Esto simplemente niega cualquier solicitud de reenvío local además de fo.local: 80.

— MrMisu
fuente

0

Estoy buscando una manera de desactivar solo los reenvíos -L

Si te entiendo correctamente, tus usuarios tienen acceso completo al shell, pero no quieres que puedan abrir conexiones hacia el resto de la red.

El "reenvío de puertos locales" permitido por SSH es solo una de las formas posibles de hacerlo. Otros incluyen el lanzamiento de una instancia de socat, netcato cualquier otro número de herramientas.

La mejor manera de controlar las conexiones salientes y entrantes en Linux es Netfilter, también conocido como IPTables.

Tiene un módulo especial llamado owner ( ipt_owner) que le permite hacer coincidir varias características del creador de paquetes, para paquetes generados localmente. Es válido en las cadenas OUTPUTy POSTROUTING.

Puede usarlo para denegar paquetes salientes generados por ciertos grupos de usuarios, lo que deshabilita cualquier tipo de reenvío de puertos, no solo la -Lopción de SSH.

— Tobia
fuente