Respuestas:
No es tan útil como afirman algunas personas, pero al menos reducirá el impacto en sus archivos de registro, ya que muchos intentos de inicio de sesión de fuerza bruta solo usan el puerto predeterminado en lugar de escanear para ver si SSH está escuchando en otro lugar. Sin embargo, algunos ataques buscarán SSH en otros lugares, por lo que no es una bala de plata.
Si su servidor va a ser un host compartido de algún tipo, en lugar de solo satisfacer las necesidades de sus proyectos, usar un puerto no predeterminado puede ser un problema, ya que tendrá que explicárselo a sus usuarios una y otra vez ¡Cuando se olvidan y sus programas de cliente no se conectan al puerto 22!
Otro posible problema con SSH en un puerto no estándar es si se encuentra con un cliente con un conjunto de filtros de salida restrictivo, que no puede conectarse a su puerto personalizado porque su filtro solo permite, por ejemplo, los puertos 22, 53, 80 y 443 para ser el destino de nuevas conexiones salientes. Esto es poco común, pero ciertamente no es inaudito. De manera similar, algunos ISP pueden ver el tráfico encriptado en un puerto distinto de aquellos en los que generalmente se espera (puerto 443 o HTTPS, 22 para SSH, etc.) como un intento de ocultar una conexión P2P y acelerar (o bloquear) la conexión de manera inconveniente.
Personalmente mantengo SSH en el puerto estándar para mayor comodidad. Siempre que se tomen las precauciones habituales (contraseña segura / política de clave, restricción de inicios de sesión de raíz, ...) no tiene por qué ser una preocupación y el problema de crecimiento del archivo de registro cuando se ve afectado por un ataque de fuerza bruta se puede mitigar utilizando herramientas como como fial2ban para bloquear temporalmente hosts que dan demasiados conjuntos de credenciales de autenticación incorrectos en un espacio de tiempo determinado.
Independientemente del puerto que elija, si se aleja de 22, asegúrese de que esté por debajo de 1024. En la mayoría de las configuraciones Unix-a-like en su configuración predeterminada, solo el root (o los usuarios del grupo raíz) pueden escuchar en los puertos por debajo de 1024, pero cualquier usuario puede escuchar en los puertos superiores. Ejecutar SSH en un puerto más alto aumenta la posibilidad de que un usuario deshonesto (o pirateado) logre bloquear su demonio SSH y reemplazarlo con su propio servidor o un proxy.
Es una forma simple (pero sorprendentemente efectiva) de seguridad a través de la oscuridad .
Si su servidor SSH no está en el puerto 22, es mucho menos probable que lo encuentren aquellos que escanean todo Internet buscando contraseñas débiles en las cuentas predeterminadas. Si está escaneando toda la red, no puede permitirse el lujo de verificar todos los 64k puertos posibles para encontrar el servidor SSH.
Sin embargo, si alguien lo está atacando específicamente, no proporciona ningún beneficio, ya que un nmapescaneo simple revelará el puerto en el que realmente se está ejecutando.
Para evitar realmente los ataques de fuerza bruta, siempre es importante seguir algunos pasos:
Sí, es útil ya que solo ayuda a evitar todos los ataques de fuerza bruta y ayuda a mantener los registros limpios :)
En cuanto al número de puerto que depende de usted, he visto que las empresas usan 1291 con bastante frecuencia. Aunque uso algo más alto solo para ayudar a evitar algunos de los scripts.
No permitir los inicios de sesión ssh raíz y cambiar el número de puerto y quizás algo como fail2ban y debería ser dorado. agregue iptables para una buena medida y mantenga sus cosas actualizadas y no debería tener ningún tipo de problema.
El uso de un puerto ssh no estándar requeriría más explicaciones y documentación, y responder correos electrónicos de "No puedo iniciar sesión".
Considero que los siguientes beneficios de ejecutar sshd en un puerto no estándar son más importantes que los problemas que crea:
Además, si desea ser realmente desagradable, siempre puede ejecutar un sshd falso (con DenyUsers * ) en el puerto estándar 22, mientras que su sshd normal se ejecuta en el puerto 54321. Esto le asegurará que todos los bots y los intrusos quieren eternamente intente iniciar sesión en un servicio que niega todos los inicios de sesión, porque nadie pensará en tratar de encontrar su verdadero servicio sshd.
Mis 2 centavos
Hacer esto por cualquier razón de "seguridad" es falso. Es el mejor ejemplo de seguridad por oscuridad que no es seguridad.
Si desea mantener sus registros un poco más ligeros y limpios, entonces sí es útil, ya que no obtendrá tantos intentos de fuerza bruta de golpe de puerto / script kiddy.
Debido a que hay muchas personas malas que escanean todas las IP del servidor en busca de puertos abiertos en un intento de explotar. Solía tener ataques de martillo en mi puerto SSH todo el día hasta que lo moví a otro puerto y en una IP que ya no estaba vinculada a ninguno de mis sitios web.
Es útil porque los bots de script que intentan ataques de adivinación de contraseña de fuerza bruta generalmente se centran en el Puerto 22, por lo que cambiar los puertos generalmente los descarta. Tendrá que equilibrar el valor de mitigar ese riesgo con la molestia de configurar clientes ssh para conectarse al puerto no estándar (no es un gran problema si no tiene muchos usuarios conectados, sin duda).
Alternativamente, puede mitigar el riesgo de fuerza bruta desactivando la autenticación de contraseña y exigiendo la autenticación de clave RSA.
Por lo general, no cambio el puerto en SSHD, por lo que no puedo sugerir otro número, pero consulte la lista de puertos de uso común para encontrar otro número (es decir, uno que no esté en uso por otra cosa, y por lo tanto podría ser escaneado) .
Siempre cambio mi SSHd para usar el puerto 2222, todos los que necesiten ingresar a mis servidores lo saben y no es ningún secreto. No hay absolutamente ninguna ganancia de seguridad al hacer esto (a menos que el posible hacker sea un imbécil absoluto).
El único beneficio que obtengo de esto es que el registro de autenticación no tiene un millón de intentos fallidos de inicio de sesión para 'root', 'alice', 'bob', 'sally', 'admin', etc.
La seguridad a través de la oscuridad ha demostrado ser inútil, generalmente configuro el acceso ssh con el puerto estándar por todas las razones mencionadas anteriormente (problemas del cliente en la reconfiguración, problemas de firewall y proxy, etc.).
Además de eso, siempre desactivo el inicio de sesión raíz y la autenticación de contraseña y, como último paso, uso fail2ban para deshacerme de esos molestos mensajes en el syslog. En Debian / Ubuntu es tan simple como escribir aptitude install fail2ban. La configuración predeterminada funciona bastante bien, pero generalmente ajusto algunos parámetros para que sean más restrictivos y tengan un tiempo de prohibición más largo (al menos un día) y solo 2 intentos de autenticación fallidos como desencadenante de la prohibición.
Diría que lo que más se protege contra usted al cambiar el puerto SSH son los escaneos automáticos que intentarán obtener acceso utilizando nombres de usuario / contraseñas estándar, si sus políticas de contraseñas son estrictas, no debería preocuparse ellos.
Si deshabilita los inicios de sesión de contraseña en su servidor (lo cual es muy recomendable), cambiar el puerto SSH es completamente inútil. Al deshabilitar los inicios de sesión de contraseña (y requerir autenticación basada en clave), elimina la posibilidad de intentos de contraseña de fuerza bruta, por lo que no está ganando nada al vagar con los números de puerto.
Si continúa permitiendo la autenticación de base de contraseña, entonces se está dejando abierto a la posibilidad de un intento exitoso de fuerza bruta o, más común, en mi experiencia, su contraseña se ve comprometida porque la ingresa cuando usa un sistema que se ejecuta Un keylogger.
man ssh-keygenpara mucha información.
No es una respuesta, pero es demasiado larga para un comentario, así que haré este CW.
He estado pensando en esto por un tiempo y he llegado a la conclusión de que hay mucha verdad en lo que dice Juliano en los comentarios a la respuesta de Alnitak. Sin embargo, encuentro que ejecutar SSH en el puerto 22 simplemente hace que sea demasiado fácil lanzar ataques de cualquier tipo contra él.
Para resolver este problema, ejecuto mis servidores SSH internos en el puerto 22 y utilizo el firewall para reenviar el puerto alto al 22 en las máquinas de destino. Esto brinda cierta seguridad a través de la oscuridad, al tiempo que conserva la seguridad de un puerto bajo, como ha señalado Juliano.
La seguridad a través de la oscuridad no es un principio al que normalmente me suscribo y a menudo se señala que un simple escaneo de puertos revelará el puerto de destino, haciendo que la oscuridad no tenga valor. Para resolver ese problema, mis firewalls (Smoothwall Express), tanto en el trabajo como en el hogar, usan un script llamado Guardian Active Response, que se activa mediante alertas Snort. Por observación, puedo decirle que cuando alcanza más de 3 puertos diferentes de la misma fuente, sus paquetes se descartan hasta el tiempo de restablecimiento preestablecido. Esto hace que sea bastante difícil y extremadamente lento ejecutar un escaneo de puertos, haciendo que la oscuridad realmente valga la pena. De hecho, esto me hizo quedar excluido tantas veces en el pasado que he establecido una exclusión para mi dirección IP de origen (hogar u oficina).
El problema que tiene es que el firewall está configurado para permitir que solo ciertas IP se conecten, y el jefe está cansado de abrir IP específicas cuando está fuera de casa. Si está bloqueando ciertas IP en el firewall, eso puede ser un fastidio.
Dos cosas en las que pienso aquí. Cambiar el puerto protege contra ataques automáticos. Eso es todo, pero es una gran parte del tráfico de ataque promedio que hay ... redes de escaneo de scripts automatizados. Si cambia el puerto predeterminado, esos ataques deberían caer a la nada. Entonces tiene sentido en ese sentido. Pero no hace nada contra un ataque dirigido, ya que el atacante puede escanear desde Nessus o NMAP para determinar qué puerto (s) está utilizando si tiene un pequeño amigo especial que lo odia lo suficiente.
En segundo lugar, si está utilizando servidores similares a UNIX, puede instalar una utilidad como Denyhosts para detener los ataques. Si instala denyhosts, supervisa los intentos de inicio de sesión incorrectos y después de los intentos fallidos (independientemente del número que determine), bloqueará la IP durante el período de tiempo que especifique. Denyhosts también puede hablar con otros hosts de host denegado y pasar listas de prohibición, por lo que si un atacante se bloquea del sistema Linux de Fred en Montana, su sistema también obtendrá esa IP para la prohibición. Muy útil siempre que sus usuarios recuerden sus contraseñas.
Todo depende de sus escenarios de uso. ¿Cuántos programas tiene que son un "dolor de cabeza" para cambiar el puerto de conexión para SSH / SCP (y si no lo permiten o hacen que sea un problema, realmente debe considerar cambiar de proveedor personalmente). Si es solo un miedo potencial, diría que no es un problema. Y este es su jefe, pidiendo algo que no es del todo raro, ya que muchos administradores de sistemas dan la vuelta al puerto SSH (con algunas críticas de personas que odian cualquier cosa que huela a seguridad incluso por oscuridad ... pero realmente reduce ruido de fondo crujido de escaneos automáticos)
Reducido: cambiar el puerto bloquea los scripts automatizados y la mayor parte del tráfico incorrecto. No detendrá a los atacantes dirigidos. Considere instalar también una utilidad de prohibición automatizada. La seguridad en capas no le hace daño si se hace correctamente y cambiar los puertos ayuda más de lo que duele en la mayoría de las situaciones.
Llevo más de 5 años ejecutando SSH en el puerto> 1024. Desde entonces, no he visto ningún intento de escaneo de puertos en mi archivo de registro (excepto el mío). Hay mis servidores que administro que se ejecutan usando el puerto> 1024.
Muchos de los servidores SSH que se ejecutan en el puerto> 1024 tienen sus propios sitios web, lo cual es bastante popular.
Si el servidor SSH se ejecuta en mi propia empresa, tal vez ya haya publicado la dirección IP de ese servidor aquí para que puedan intentar hackear el servidor. Lamentablemente, el servidor SSH no es mío. ;-)
Pero hay otras cosas que tendrías que configurar para que sea seguro. SSH> 1024 solo no sería suficiente. El número de puerto no debe estar en / etc / services, debe usar el reenvío de puertos (por ejemplo, el puerto 1124-> 22), el acceso directo a Root debe estar deshabilitado y otras cosas.
Entonces, si desea discutir, mejor ejecute SSH en el puerto> 1024 durante unos años.
p / s: 1124 no es mi puerto SSH no. Jaja.
Mover bien SSH a un puerto diferente tiene sentido, ayuda con la seguridad pero no enormemente. Por supuesto, para hacerlo, debe tener control sobre sus firewalls, pero eso no es un problema para usted. Lo que creo que deshace el beneficio de mover el puerto es la apertura del rango aceptado; de hecho, diría que más que deshace el beneficio y lo expone más de lo que está hoy. Estoy seguro de que puede convencerlo de que mueva el puerto Y reduzca significativamente el alcance entrante al recopilar una lista de posibles puntos de entrada en lugar de simplemente abrirlos todos.
Cambiar su puerto ssh es un ejercicio inútil que solo le brinda seguridad limitada. Es mejor simplemente deshabilitar la autenticación de contraseña, lo que elimina el riesgo de intentos de contraseña de fuerza bruta, y confiar exclusivamente en la autenticación basada en clave ssh. Si su entorno requiere autenticación de contraseña, adopte algún mecanismo de dos factores, como SecurID o Wikid.
Ambos le brindan un aumento real de la seguridad, mientras que cambiar el puerto ssh solo le da la ilusión de seguridad.
Este es un punto de vista práctico: operé servidores ssh privados visibles públicamente durante más de cuatro años con un puerto SSH cambiado y no tuve un solo intento de escaneo de contraseñas. En aras de este control de calidad, acabo de habilitar 22 en uno de ellos por un día. Como resultado, me escanearon aproximadamente cada 10 minutos con una frecuencia de intento de contraseña de alrededor de 5 por segundo. Además, "scan kiddies" también buscan servidores con ciertas vulnerabilidades de OpenSSH.
Seguro que esto es seguridad por oscuridad que no ayuda si tienes enemigo.
Funciona muy bien, independientemente de los quejidos de la multitud de "seguridad a través de la oscuridad".
Conejos tontos, TODA la seguridad es seguridad a través de la oscuridad. El hecho de que creas que el oscuro protocolo criptográfico Z [que requiere una combinación de muestras de ADN, claves compartidas e imposible de escribir con contraseñas humanas] es realmente seguro no lo hace así. La verdad es que todas y cada una de las medidas de seguridad se basan en probabilidades y suposiciones de los usuarios. Demasiado malo para ti si sé cómo explotar esa suposición, pero ahí está.
De todas formas,
Lo hemos hecho durante años, junto con a) limitar la tasa de intentos de conexión (sin embargo, no sé cómo lo configuramos, algo en la configuración ssh), yb) un script para prohibir a cualquier host que ejecute un ataque de diccionario con más de X conjeturas incorrectas en Y minutos. Prohibimos que el host realice la conexión por un período de tiempo, y eso hace que sea más fácil adaptarse a la topología de las redes cambiantes.
Si sus contraseñas son lo suficientemente complejas y solo pueden hacer 3 intentos en 15 minutos, no hay mucho que temer. Tampoco es tan difícil estar atento a los ataques distribuidos: generalmente recopilamos por subred e ip para descartar ese tipo de cosas.
Finalmente, todo lo que necesita es algún método secreto de ardilla para permitir conexiones a su puerto modificando las reglas f / w. Puede ser cualquier cosa ... smtp, web, consultas mágicas dns. Cosas como SecurID o Wikid solo entregan más información a terceros. Y no me hagas empezar con certificados seguros a través de terceros.