asegurando las conexiones SSH

3

Pido esto solo por motivos de seguridad (mi sitio web). Utilizo PuTTY para conectarme a mi servidor a través de SSH, y hoy descubrí que es bastante fácil intentar la conexión a mi servidor; simplemente escriba mi dirección en el campo del nombre de host y podrá seguir adelante e intentar conectarse.

Tuve curiosidad y probé esto en muchos sitios; algunos me permitieron intentar iniciar sesión, pero con la mayoría de los casos, me negué la conexión o algo por el estilo. Incluso obtuve su IP a través de ping y el resultado fue el mismo. Me gustaría saber cómo son exactamente (los administradores) inician sesión en sus servidores. ¿Son algunos servidores SSH-menos? tal vez hay una IP oculta que utilizan?

    
pregunta user1938653 05.11.2016 - 01:57
fuente

4 respuestas

2

La mayoría de los servidores ssh en estos días deben configurarse para permitir solo la autenticación basada en clave pública, no la autenticación basada en contraseña. Permitir la autenticación basada en contraseña es visto por el escáner automático como una invitación a adivinar contraseñas.

Dependiendo de la versión del software de su servidor ssh, es posible que esté usando criptografía desactualizada. Debe deshabilitar el cifrado defectuoso y cambiar a las teclas ed25519. La última versión preliminar de putty los admite.

Puede usar este escáner para verificar su servidor: discovery.cryptosense.com

    
respondido por el Z.T. 05.11.2016 - 02:28
fuente
2

Un puñado de sugerencias:

  • Asegúrese de que está ejecutando la versión más actual de su servidor SSH.
  • Cambie el puerto predeterminado a un puerto alto, vea / etc / ssh / sshd_config en la mayoría de los casos
  • Configúralo para que la raíz no pueda iniciar sesión directamente
  • Si es posible, solo permite la autenticación basada en clave pública, deshabilite otras autorizaciones
  • Si es una opción, aproveche su firewall (IPTables) para restringir el acceso a su SSH Daemon desde solo unas pocas direcciones IP (si es una opción).
  • Verifique los cifrados permitidos con nmap -p --script ssh2-enum-algos
  • Si debe tener acceso a este sistema a nivel mundial, considere el uso de una VPN. Luego, podría solicitar que se establezca primero la conexión VPN y luego una sesión SSH después de establecer la VPN. La ventaja de esto es que agrega una segunda capa de protección que reduce las probabilidades de que exista una vulnerabilidad en ambas capas al mismo tiempo.
  • Usa cuentas separadas de humanos y software. Es bueno contar con cuentas de aplicaciones separadas para el software que accede a sus sistemas.
  • El registro remoto es útil si su sistema se ve comprometido
  • Utilice Fail2Ban
  • Configure la supervisión del registro para que le avise cuando ocurra un comportamiento inusual.
  • Además, siga las prácticas normales de seguridad para mantener seguro el sistema operativo subyacente.
  • Asegúrese de recibir una notificación cuando se lancen nuevos informes a su demonio SSH.
  • Sea disciplinado sobre la verificación de la seguridad de sus sistemas de forma regular.
  • Si es posible, automatice aspectos de las pruebas de seguridad, de modo que le avisen si sus sistemas alguna vez son vulnerables a problemas conocidos.

Tenga en cuenta que solo habilitar la autenticación de clave pública no protegerá su sistema de algunos tipos de vulnerabilidades del demonio ssh.

Nota: si está cambiando el puerto en un sistema remoto, no solo cambie el puerto y espere lo mejor. Habilite el puerto alto de modo que tanto el puerto predeterminado 22 como el nuevo puerto estén funcionando al mismo tiempo. Pruébelo y asegúrese de que sus reglas de firewall estén habilitadas adecuadamente. Una vez que todo funcione en ambos puertos, desactive el puerto predeterminado y vuelva a realizar la prueba para asegurarse de que esté apagado. Del mismo modo, si está utilizando Fail2Ban, asegúrese de ajustar el puerto de escucha SSH en Fail2Ban también.

    
respondido por el Trey Blalock 05.11.2016 - 03:46
fuente
1

Los servidores profesionales o comerciales normalmente se ejecutan detrás de un proxy inverso que solo permite el tráfico al puerto HTTP o HTTPS (o SMTP / IMAP / POP para servidores de correo). Por lo tanto, incluso si tienen un servidor ssh para fines administrativos, no puede acceder a él directamente desde Internet.

Si están administrados localmente (centro de datos privado dentro de la organización), la administración solo es posible desde una LAN, que normalmente solo contiene servidores y personal. También tiene a menudo un acceso VPN para permitir la administración distante. Pero incluso en ese caso los administradores tienen que:

  • conectarse a la VPN
  • ssh a la dirección interna

Al menos eso los protege de las exploraciones de puertos y los niños de secuencias de comandos. Solo se puede acceder directamente a los servidores proxy de reverberación y al acceso VPN. Esto agrega mucha seguridad, ya que un proxy inverso es un software simple que se espera que contenga muchos menos problemas de implementación de seguridad que un servidor web, y la máquina que los admite tiene todos los puertos innecesarios cerrados y el software innecesario del servidor desactivado o eliminado. Y el acceso VPN también es altamente seguro.

    
respondido por el Serge Ballesta 05.11.2016 - 10:45
fuente
0

El puerto que está escuchando SSH se puede cambiar en la configuración, lo que se puede hacer para reducir el escaneo automático y los intentos de fuerza bruta. El puerto SSH también puede incluirse en la lista blanca para permitir solo la conexión de direcciones IP confiables. enlace

También se pueden utilizar métodos de seguridad más avanzados, como la detonación de puertos. La detonación de puertos es cuando el puerto está oculto y solo se revela cuando el servidor recibe un determinado patrón de tráfico de red. enlace

Es poco probable que algunos servidores, como los que ejecutan Windows, estén ejecutando un servidor SSH y normalmente usen RDP para la administración.

    
respondido por el mebmc 05.11.2016 - 02:24
fuente

Lea otras preguntas en las etiquetas