Riesgo de ejecutar servicios en los puertos 1024

Si hay un proceso fraudulento en tu Raspberry Pi, entonces ya has estado comprometido, aunque el atacante o el proceso malicioso automatizado, obviamente, no ha logrado elevarse a la raíz.

  

El proceso no autorizado no puede acceder a las claves del host, por lo que presentaría un   huellas dactilares diferentes para el usuario cuando se conecta, alertándolas   problema.

Eso es cierto. Sin embargo, esto depende de si es probable que sus usuarios noten esto o no. En un sistema promedio, muchos usuarios hacen clic en las advertencias; sin embargo, con un sistema basado en Linux que usa SSH, esta barra generalmente se eleva lo suficiente para que solo los usuarios semi expertos se conecten, lo que aumenta la posibilidad de que se den cuenta de que algo está mal. p>

  

Si la autenticación basada en clave está en uso, poco se puede obtener de   interceptando comunicaciones.

De acuerdo. Aunque la clave pública podría recuperarse del cliente SSH, no habría forma de que el servicio deshonesto intercepte la clave privada, ya que nunca se envía.

Puede existir un riesgo si se usa la autenticación de contraseña en su lugar, aunque como se indicó, el usuario tendría que haber ignorado los mensajes de advertencia de la clave del host.

Por lo tanto, en resumen, no hay riesgo adicional introducido con un puerto no privilegiado para SSH cuando la autenticación de clave pública está en su lugar. El único ataque que se me ocurre es cuando el demonio SSH deshonesto permite que un usuario se conecte con la esperanza de que el usuario emita inmediatamente un sudo / su y luego ingrese una contraseña que luego se capture. Si esto no se hizo de inmediato, porque el proceso no tendrá los mismos permisos que los del usuario real, es probable que el usuario note que algo anda mal.

Servicios que se ejecutan en puertos < 1024 (al menos en los servidores * nix) generalmente se consideran más seguros, ya que requieren de root (o un usuario de confianza que tenga privilegios de root) para iniciarlos, mientras que los servicios que se ejecutan en puertos > = 1024 pueden ejecutarse por un no confiable (posiblemente, un pícaro) usuario en el servidor.

Por lo tanto, es plausible que un usuario malintencionado en el servidor pueda realizar un ataque como el descrito en la publicación de reddit que copió, sin privilegios de root.

Con respecto a "1.The rogue process cannot access the host keys, so would present a different fingerprint to the user when connecting, alerting them to an issue." : Esto es cierto: si un usuario ha iniciado sesión en el servidor anteriormente, y su cliente SSH fijó la clave pública del servidor. En este caso, el cliente SSH del usuario (probablemente) le advertirá que la clave pública del servidor ha cambiado, y el usuario (probablemente) sabrá que algo está pasando. Sin embargo, solo se advertiría al usuario si se había registrado previamente en el servidor y su cliente fijó la clave pública del servidor.

Con respecto a "2.If key based authentication is in use, little can be gained from intercepting communications." : soy escéptico acerca de esto. El cliente SSH del usuario enviaría su clave pública, como es habitual durante el inicio de una sesión de SSH, luego el servidor SSH falso podría autenticar al cliente (como suele ser el caso cuando la clave pública del cliente está presente en el archivo authorized_keys del servidor) y continúe con la sesión utilizando la clave pública que el cliente envió.

Algunos hilos SE están discutiendo los pros & Contras de esto desde una perspectiva de seguridad . ¿Cambiar el número de puerto predeterminado realmente aumenta la seguridad? y ¿Debo cambiar el puerto SSH a < 1024? .

Sin embargo, también hay un riesgo involucrado, ya que el proceso fraudulento que mencionó en realidad lo bloquea fuera de su servidor. Las posibilidades de que esto ocurra pueden ser bajas, pero ¿y si? Tendrá suerte si puede reiniciar el servidor sin acceso SSH. Y, con suerte, en el inicio, el demonio SSH reclama el puerto antes del proceso deshonesto.