¿Debo cambiar el puerto SSH predeterminado en los servidores de Linux?

Internet es un lugar salvaje y aterrador, lleno de descontentos cuyos motivos van desde la curiosidad hasta la empresa criminal. Estas desventajas exploran constantemente las computadoras que ejecutan servicios que esperan explotar; por lo general, los servicios más comunes, como SSH, HTTP, FTP, etc. Las exploraciones generalmente se dividen en una de dos categorías:

1. Las exploraciones de reconocimiento para ver qué dirección IP tiene esos servicios abiertos.
2. Explote las exploraciones contra direcciones IP que se encuentran ejecutando un servicio específico.

Teniendo en cuenta el tamaño de Internet, por lo general no es factible buscar en cada puerto de cada dirección IP para encontrar lo que está escuchando en todas partes. Este es el quid de los consejos para cambiar su puerto predeterminado. Si estas personas desafectadas desean encontrar servidores SSH, comenzarán a sondear cada dirección IP en el puerto 22 (también pueden agregar algunas alternativas comunes, como 222 o 2222). Luego, una vez que tengan su lista de direcciones IP con el puerto 22 abierto, iniciarán su fuerza bruta de contraseña para adivinar los nombres de usuario / contraseñas o lanzarán su kit de exploits de elección y comenzarán a probar vulnerabilidades conocidas (al menos para ellos) en el sistema de destino.

Esto significa que si cambias tu puerto SSH a 34887, entonces ese barrido se lo transmitirá, lo que probablemente resulte en que no seas blanco del ataque.

Parece rosado, ¿verdad? Sin embargo, hay algunas desventajas.

1. Asistencia al cliente: todas las personas que se conecten a su servidor deberán conocer y utilizar el puerto modificado. Si se encuentra en un entorno altamente administrado, esta configuración se puede enviar a los clientes, o si tiene pocos usuarios, debería ser fácil comunicarse.
2. Excepciones a la documentación: la mayoría de los dispositivos de red, como los firewalls y los IDSes, están preconfigurados para que los servicios comunes se ejecuten en puertos comunes. Cualquier regla de firewall relacionada con este servicio en este dispositivo deberá ser inspeccionada y posiblemente modificada. De manera similar, las firmas de IDS se modificarán para que solo realicen una inspección de SSH en el puerto 22. Deberá modificar cada firma, cada vez que se actualicen, con su nuevo puerto. (Como punto de datos, actualmente hay 136 firmas VRT y ET snort relacionadas con SSH).
3. Protecciones del sistema: los Linux modernos a menudo se envían con una capa de kernel MAC y / o sistemas RBAC (por ejemplo, SELinux en RedHat o AppAmor en Debian) y están diseñados para permitir que las aplicaciones hagan exactamente lo que deben hacer . Esto puede abarcar desde acceder al archivo /etc/hosts , escribir en un archivo específico o enviar un paquete a la red. Dependiendo de cómo esté configurado este sistema, puede, por defecto, prohibir que sshd se enlace a un puerto no estándar. Deberá mantener una política local que lo permita.
4. Supervisión de otra parte: si tiene una división de seguridad de la información externa o una supervisión externa, entonces se les debe informar sobre el cambio. Cuando realizo una evaluación de seguridad, o analizamos los registros en busca de amenazas de seguridad, si veo que un servidor SSH se ejecuta en un puerto no estándar (o un servidor SSH en un sistema que no es UNIX / Linux) lo considero como una posible puerta trasera e invocar la parte del sistema comprometida del procedimiento de manejo de incidentes. A veces, se resuelve en 5 minutos después de llamar al administrador y decirle que es legítimo, momento en el que actualizo la documentación, otras veces lo que realmente se cuida es la maldad. En cualquier caso, esto puede resultar en un tiempo de inactividad para usted o, al menos, una llamada de alerta cuando conteste su teléfono y escuche: "Hola, soy Bob de la Oficina de Seguridad de la Información. Tengo algunas preguntas para usted. ".

Antes de cambiar su puerto, debe tener todo esto en cuenta para que sepa que está tomando la mejor decisión. Algunas de esas desventajas pueden no aplicarse, pero algunas ciertamente lo harán. También considera contra qué estás tratando de protegerte. Muchas veces es simplemente más fácil configurar su firewall para permitir solo el acceso a 22 desde hosts específicos, a diferencia de Internet.

Sí, puede ser, no aumentando la seguridad, pero puede reducir la cantidad de intentos de inicio de sesión fallidos en su servidor. Siempre cambio mi ssh predeterminada para reducir las advertencias que recibo de ossec. Además, si utiliza un puerto realmente aleatorio y alguien intenta acceder a su máquina, es probable que sea un ataque dirigido en lugar de un escáner aleatorio.

Como han dicho otros, colocar SSH en un puerto que no sea 22 hará que sea más improbable que lo golpeen con un escaneo aleatorio. Será atacado si el atacante intenta obtener su servidor, no cualquier servidor.

Tengo un servidor con ssh vinculado a un puerto alto aleatorio. Y tengo un honeypot ssh en el puerto 22, que responderá a cualquier intento de inicio de sesión con un mensaje de "acceso denegado".

No creo que sea una defensa por oscuridad , pero defensa en profundidad : para atacar mi servidor, el atacante primero debe encontrar el puerto. Si tengo algunos honeypots falsos (muchos puertos que redireccionan al mismo honeypot), el atacante golpeará muchos falsos y no tendrá forma de saber si golpeó el ssh real o no.

Aunque solo es la defensa. También tengo portsentry activo, por lo que si alguien prueba un escaneo de puertos, estará bloqueado durante una hora. Si aplican la contraseña en la contraseña de la derecha, recibirán un "acceso denegado" durante una hora. Si adivinan la contraseña con éxito, se les presentará un mensaje PAM solicitando el token de autenticación de Google.

El costo de cambiar el puerto es muy bajo, y creo que las desventajas están justificadas por las ventajas.

Dado que la mayoría de los usuarios hablan principalmente de desventajas (que son reales), me gustaría compartir algunas ventajas aquí:

• realmente quieres evitar ataques automatizados. A menos que sea un usuario de alto perfil, la gran mayoría de los ataques no se dirigirán a usted, sino ataques automáticos de mejor esfuerzo que solo intentarán los puertos predeterminados. Evitarlos ayuda de varias maneras:

  • reduce la superficie de ataque (la mayoría de los ataques automatizados)
  • reduce la exposición debido a errores en las bibliotecas sshd o crypto que utiliza
  • algunos errores como heartbleed permiten explotar sus servidores simplemente conectándose a un puerto abierto, incluso sin conocer ninguna contraseña o clave. Al utilizar puertos no estándar, evita esto.
  • algunos errores como débil privado las teclas permiten que los ataques automatizados activen su servidor antes de aplicar los parches. El uso de puertos no estándar de nuevo evita las primeras oleadas de atacantes y le da más tiempo para parchear.
  • reduce el desorden en sus registros, lo que le ahorra mucho tiempo de administración al revisar los registros, lo que le permite concentrar sus esfuerzos en ataques dirigidos más problemáticos
  • proporciona mejor protección con menos trabajo que el kludge que mencionas en la actualización (bloqueo de IP después de 5 inicios de sesión incorrectos, lo que permitirá algunos de los ataques, especialmente si la IP sigue cambiando, especialmente en el mundo IPv6 donde cada atacante tendrá miles de millones de ellos de sobra, y el kludge puede producir falsos positivos al bloquear usuarios legítimos y generar más llamadas de soporte)
  • a veces, incluso las buenas contraseñas se verán comprometidas (a través de otros errores en otros lugares, o los usuarios descuidados que las ingresan en las máquinas con registro de teclas) y se almacenarán en los diccionarios utilizados para los ataques posteriores. Nuevamente, el puerto aleatorio evitará la gran mayoría de esta clase de ataques automatizados (la mayoría de los keyloggers guardarán solo pares de nombre de usuario / contraseña, y no buscarán puertos en configuraciones).

• lo que sea que el atacante no espere, siempre lo apaga por completo, crea más trabajo para él o lo convierte en un objetivo menos interesante. Y también aumenta el tiempo de detección y defensa contra ataques.

• ejecutar en el puerto > 1024 no requiere que sshd se ejecute como root, lo que permite ejecutarlo es solo un usuario para el que es necesario, evitando una clase completa de errores (cierto incluso cuando se toman algunas implementaciones de sshd cuidado adicional para ejecutar con privilegios reducidos cuando no sea necesario).

Supongo que depende de la velocidad con la que vayas a parchear tu servidor y de que tengas algún tipo de servidor de seguridad delante del servidor.

Si deja el servidor abierto al mundo y no tiene nada configurado para avisarle o para que instale automáticamente los parches de OpenSSH, le sugeriría que mueva el servidor a puertos con un número alto aleatorio.

En última instancia, aunque solo mover el número de puerto no disuade a todos, asegúrate de disuadir a los chiquillos de script que solo están revisando los puertos 80, 22, 23, etc. pero no si alguien hiciera un escaneo 1-65535.

Como ya lo han dicho otros, cambiar el puerto SSH predeterminado no le ayuda mucho desde una perspectiva de seguridad. Sin embargo, aún puede ser ventajoso hacerlo si tiene la intención de conectarse a la máquina desde una red donde los administradores han bloqueado el puerto 22. (Muchas escuelas, lugares de trabajo y puntos de acceso WiFi gratuitos bloquean todo el tráfico saliente, excepto el predeterminado). Puertos DNS, HTTP y HTTPS.) En este caso, cambiar su puerto SSH a 53, 80 o 443 (o hacer que su enrutador reenvíe uno de esos puertos a 22) normalmente le permitirá ingresar a su máquina en su máquina cuando estudie / trabaje / viajando.

En casos raros, estas redes pueden no estar simplemente bloqueando puertos, sino también inspeccionando el tráfico para filtrar las conexiones ssh. Para esta situación, debe investigar otras alternativas .

Esto es algo así como una pregunta filosófica: "¿es útil el control X?" Y, como señala la mejor respuesta, también debe considerar "¿cuáles son los costos (soporte al cliente, exenciones a los documentos, soporte al sistema, soporte al monitoreo y costos directos, licencias, etc.) del control X?" / p>

Cualquier cosa es útil en ciertos contextos. Es una buena idea preguntarse en qué contexto se encuentra. A veces, el contexto es de conformidad: está implementando el control X para cumplir con un requisito particular. "Tengo que mover mi puerto ssh porque la política del sistema prohíbe a los oyentes en el puerto 22". Luego, hágalo, solicite una excepción o trabaje para cambiar la política. [Eso sería, imho, una política imprudente.]

Aquí, el contexto es probablemente "Soy un tipo aleatorio, con un host en una red no controlada, y no quiero perder el control de mi caja". Los ataques siempre tienen una fase de investigación: si la investigación es "enviar un SYN en el puerto 22 y ver quién responde", entonces está protegiendo contra ese vector de amenaza específico. (Si la investigación es "realizar un barrido de puertos, recoger pancartas y ver si aparece algo interesante", entonces su control no tiene ningún efecto). Pero ahora ha hecho un gran trabajo para usted mismo, si está utilizando una herramienta. para conectarlo al servidor, necesita descubrir cómo trabajar en ese puerto no estándar, y con algunas herramientas, eso podría no ser posible. En general, y en este contexto, no recomendaría cambiar los puertos.

Uno de los beneficios señalados fue la reducción de los eventos de registro asociados con falsos positivos. En realidad me parece que un negativo! El flujo constante de ataques entrantes en el puerto 22 puede ser realmente útil: si se detienen, sabrá que hay un problema con su fuente de Internet. Creo que el beneficio percibido es falso; la respuesta correcta es ajustar el sistema de detección de anomalías para filtrar los intentos fallidos de inicio de sesión de redes externas.

Cambiar el puerto solo detiene los ataques automáticos contra tu SSH y algunos script kiddies. Si alguien te estaba apuntando, entonces podrían multar el nuevo puerto SSH. La ventaja es que detiene los intentos de inicio de sesión fallidos en sus registros. Por lo general, tengo algo como Logwatch y SSH en un puerto diferente que se ejecuta con PasswordAuthentication configurado como no en mi sshd_config.