Tengo una aplicación web alojada en Digital Ocean y uso Laravel Forge para mantener un demonio ejecutando un túnel SSH hacia otro servidor (es decir, ssh -L XXX: 127.0.0.1: XXX -p XXXX root @ [dirección ip]).
Hago esto para estar conectado a una base de datos remota en ese servidor.
¿Existe alguna vulnerabilidad importante al hacer esto? ¿Alguien más puede ver el comando del demonio ejecutándose? Pero incluso si fuera posible, ¿no necesitarían la clave SSH para tener acceso al servidor?
¿Existe alguna vulnerabilidad importante al hacer esto?
Depende de la configuración / modelo de amenaza / etc. Hay muchas variables a considerar.
¿Alguien más puede ver el comando del daemon en ejecución?
Sí: cualquier persona con acceso a cualquiera de las máquinas puede ver esto, incluidos todos los parámetros.
Linux:
ps -aux | grep -i 'ssh'
macOS:
ps -Aj | grep -i 'ssh'
Aquí hay un ejemplo:
$ ps -aux | grep -i 'ssh'
root 444 0.0 0.0 37588 5692 ? Ss 13:20 0:00
/usr/local/bin/ssh -L XXX:127.0.0.1:XXX -p XXXX root@[ipaddress]
Pero incluso si eso fuera posible, ¿no necesitarían la clave SSH para tener acceso al servidor?
Bueno, sí y no. Hay algunos factores a considerar:
Si alguien puede comprometer su servidor por cualquier motivo, puede comprometer el servidor de la base de datos remota dependiendo de la configuración y los permisos.
Si el servidor SSH permite la autenticación basada en contraseña, eso podría presentar un problema si descubren las credenciales en su sistema.
Si su servidor SSH acepta claves, pero su clave no requiere una contraseña, esto puede comprometer el servidor de la base de datos.
Si un atacante compromete el servidor de la base de datos, es posible que pueda comprometer a otros servidores de la red. Puede que estés abriendo una enorme lata de gusanos aquí.
Como con toda la seguridad, es importante considerar su modelo de amenaza y capas. La defensa en profundidad es el proceso de crear un montón de diferentes capas de seguridad para evitar el mayor compromiso posible.
Pregúntate a ti mismo: "¿Qué tengo y qué estoy tratando de proteger?" Este es el punto de partida para la ingeniería de seguridad.
En este escenario, recomendaría algo como esto (asumiendo que usted es el propietario de la base de datos):
Asegúrese de que el servidor web solo exponga los puertos necesarios, como 80/443.
Asegúrese de que el servidor de la base de datos se comunique solo con su aplicación web a través de SSH. De forma predeterminada, negará todo excepto lo que se requiere para ejecutar, y permitirá la dirección IP de su aplicación web en el puerto 22. Dependiendo de la escala y la complejidad, puede comunicarse solo con el equilibrador de carga que lo distribuirá en otra web instancias de aplicaciones, pero eso está fuera del alcance aquí.
Asegúrese de que su clave SSH requiere una frase de contraseña. Una muy fuerte.
Asegúrese de que la base de datos no tenga capacidades de E / S de archivos a menos que sea necesario.
Asegúrese de que el servidor de la base de datos no pueda, de manera predeterminada, crear conexiones salientes, excepto en los puertos requeridos. Esto garantiza que si alguien explota su base de datos mediante algún tipo de inyección o explotación (Attacker - > Web App - > SSH Request Forward - > DB Exploit), no le permite al atacante (fácilmente) devolver un shell inverso a su sistema (cubrimos SQLi en el # 1, pero aún así, aquí hay otra capa molesta).
Asegúrese de que ni el servidor de aplicaciones web ni la base de datos se estén ejecutando como root.
Asegúrese de que los permisos para su pivote SSH sean los más bajos posible para administrarlo. Puede configurar usuarios en la configuración de la base de datos, por ejemplo.
Si es posible, asegúrese de que el servidor de la base de datos esté en su propia VPC / VLAN.
Finalmente, si realmente necesitas ir por esta ruta, no debería haber ninguna razón para que te conectes como root. Debe conectarse como usuario estándar y escribir una contraseña segura. Una VPN sería una mejor idea.
Esta no es una lista completa, solo es algo rápido para comenzar.
TLDR: principio de privilegio mínimo.
Primer problema evidente: ssh root @
No hagas eso. No ssh como root . Siempre. SSH como root es una mala práctica, es peor que sudo su - . Si su contraseña o clave se ve comprometida de alguna manera, todo el servidor DB se habrá ido. Separación de privilegios, permisos ajustados, cifrado completo del disco ... todo inútil.
Si alguien obtiene un shell en el servidor de aplicaciones, puede conectarse al servicio de base de datos (servicio, no servidor) sin necesidad de las claves SSH. ¿Por qué? ¡Es un túnel TCP! Pueden conectarse directamente a la base de datos utilizando el puerto local. Ni siquiera necesitan encontrar que está ejecutando un túnel, solo con mirar los puertos abiertos con netstat es suficiente. O mirando tus archivos de configuración. ¿Y qué más habrá en los archivos de configuración? Las credenciales de la base de datos.
Si sus claves SSH no están protegidas por contraseña, pueden acceder a todo el servidor, como root. Ya tenían las credenciales de la base de datos, ahora también tienen acceso de root.
Utilizaría Wireguard u otro servicio VPN para canalizar las solicitudes, y configurar el servidor de seguridad en el servidor de la base de datos para permitir solo conexiones desde la VPN al puerto de la base de datos.
Y cambiaría el puerto por defecto de SSH 22 a otra cosa, y pondría un honeypot en el puerto 22, algo como SSH-Pot : un servidor ssh que nunca se autentica . Eso hace que los robots de escaneo aleatorios extrañen su servidor.
Y como dijo Mark, endurecimiento y menos privilegio. Desactiva tanto como puedas. Si no necesita correo electrónico, deshabilite el correo electrónico. Deshabilite todos y cada uno de los servicios que pueda, hasta que el servicio deje de funcionar. Configure el firewall en el servidor de base de datos para que no permita ninguna conexión entrante, excepto el servicio VPN y el puerto DB dentro de la VPN, y no permita conexiones salientes. Haga lo mismo en el servidor de aplicaciones: permita los puertos 22, 80, 443 y el nuevo puerto ssh (usted lo cambió, ¿verdad?), Y no permita conexiones salientes, excepto el servicio VPN en el servidor DB y el servicio DB .
Lea otras preguntas en las etiquetas ssh ssh-host-key