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.
Soy el único usuario de este servidor. Gracias por aclarar el problema 1024+. Hubiera usado un puerto 48xxx si hubiera elegido. De todos modos en este punto todavía no entiendo si es útil o no = /
dinámico
16
+1 para el> 1024 bit.
MattC
26
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.
"comprobar todos los 64k puertos posibles" ... Ejecutar SSH en cualquier puerto por encima de 1023 es simplemente incorrecto. Hace que el sistema sea más vulnerable que dejarlo ejecutándose en su puerto predeterminado.
Juliano
3
@Juliano - por favor explique. Solo porque tiene que ser root para escuchar en un puerto privilegiado, (AFAIK) no lo hace inseguro para ejecutarse en un puerto no privilegiado.
Alnitak
44
Por cierto, no es seguridad a través de la oscuridad, de lo contrario, también tendrá que llamar a la autenticación de contraseña de la misma manera. La seguridad a través de la oscuridad es cuando no se revela la implementación. Aquí, la implementación está claramente establecida (es "Cambié el puerto de servicio"), y el secreto ("¿qué puerto?") Sigue siendo secreto.
Juliano
55
@John: en realidad veo el punto de @ Juliano. No hace que el demonio SSH sea intrínsecamente menos seguro, pero en el caso general de que se ejecute en un puerto no privilegiado anula la suposición normal de que root inició el demonio. Entonces, si de alguna manera puede detener ese demonio (por ejemplo, haciendo DoSing), puede iniciar su propio demonio falso en su lugar sin necesidad de un exploit de raíz. Ese falso demonio podría capturar suficientes detalles para permitir más exploits.
Alnitak
2
@John, eso es cierto: aún requiere que el atacante haya obtenido suficiente acceso para comenzar un nuevo demonio. El punto clave es que ya no necesitan acceso root para iniciarlo.
Alnitak
21
Para evitar realmente los ataques de fuerza bruta, siempre es importante seguir algunos pasos:
Instalar denyhosts o fail2ban
Limite el número de conexiones por segundo en el puerto ssh
Cambiar puerto ssh
Inicio de sesión root denegado
Habilitar autenticación por clave en lugar de contraseña
Parece una buena lista, excepto la parte de cambio de puerto con la que realmente no estoy de acuerdo, eso es demasiada oscuridad. ¿Un escáner de puertos moderno lo encontrará en unos segundos de todos modos? (y muchas redes no dejarán salir el tráfico aleatorio del puerto, generalmente limitado a decir 22, 80 y 443)
Oskar Duveborn
1
El cambio de puerto limita los ataques de fuerza bruta que comprueba si ssh se ejecuta en el puerto predeterminado, bueno, si el ataque es más grave, solo en este caso el atacante puede realizar un escaneo de los puertos de agujero en su red / hosts.
Ali Mezgani
1
De hecho, creo que detrás de un buen firewall, si mantiene sus servicios actualizados y si cambia la configuración predeterminada de ellos, podría estar a salvo de ataques de personas malintencionadas. y puede no ser de exploits de 0 días o ataques desconocidos
Ali Mezgani
2
El uso de denyhosts / fail2ban mitiga la necesidad de cambiar de puerto o requerir claves. Si no permite contraseñas, no tiene sentido utilizar denyhosts / fail2ban o cambiar los puertos.
Jeremy L
1
El uso de denyhosts / fail2ban no mitiga necesariamente la necesidad de medidas de seguridad adicionales. El objetivo de la seguridad es crear la mayor cantidad de obstáculos posibles para los usuarios que intentan evadir la seguridad. Seguro que probablemente no necesite cambiar el puerto de 22 a 2222, pero diga que aparece otro administrador y vuelve a habilitar la contraseña ... aún tendrá varios otros obstáculos de velocidad. Cada paso mencionado anteriormente le da al administrador un porcentaje cercano a la imposibilidad del 100% de seguridad.
Patrick R
12
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.
Si va a aconsejar usar un puerto no privilegiado 2 años después de muchas otras respuestas mejores, tal vez prepare una razón mejor que 'He visto que las compañías lo hacen'. He visto compañías que hacen muchas cosas. Raramente quiero seguir su ejemplo.
underscore_d
11
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:
El 99.9999% de los ataques de fuerza bruta son realizados por bots que solo buscan el puerto 22 y nunca pierden el tiempo tratando de descubrir el puerto no estándar. Los ataques de fuerza bruta y las contramedidas como denyhosts o fail2ban consumen recursos, que ahorrará simplemente ejecutando el servidor ssh en un puerto no estándar.
Se deshará de todos los informes inútiles sobre los robots que intentan entrar en su sistema. Si aparece alguna IP en el informe de inicio de sesión fallido, es probable que se trate de un ser humano.
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.
Sin embargo, esto podría generar aún más llamadas de soporte.
Brad Gilbert el
3
Esto es cierto, pero la seguridad mejorada tiene un precio. :)
Born To Ride
11
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.
Sí. Cuando tenía ssh en el puerto 22, tenía> 20000 intentos fallidos de contraseña que aparecían en mis registros por día. Lo que significaba que recibía un correo electrónico de advertencia de seguridad todos los días. Tenía la autenticación de contraseña deshabilitada; tenía que tener una clave privada adecuada para iniciar sesión, así que no me preocupaba que alguien entrara, sino que prefería recibir correos electrónicos de advertencia de seguridad solo cuando sucedía algo real.
jdege
10
Ejecutaría ssh en el puerto estándar y usaría algo como fail2ban o denyhosts para limitar el número de ataques de diccionario.
Otra opción es deshabilitar el inicio de sesión con contraseñas altogheter y solo permitir inicios de sesión con ssh-keys.
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.
sin mencionar que un escáner de puertos también probará otros puertos.
Jim Deville el
4
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.
Si usted / completamente inútil / completamente inútil por seguridad /, estaría de acuerdo. Sin embargo, cambiar el puerto es útil para mantener el ruido bajo en el registro de autenticación.
Chris S
"y requiere autenticación basada en clave"? ¿Qué es esto
dinámico
1
@ yes123, SSH puede usar pares de claves público-privadas para autenticar a un usuario en lugar de una contraseña. El par de claves también puede protegerse con una contraseña, lo que ofrece una autenticación de dos factores (algo que sabes = contraseña; algo que tienes = archivo de clave). Si implementa esto, puede deshabilitar los inicios de sesión de contraseña (por lo tanto, alguien que conozca su contraseña local no puede ingresar con el archivo de clave y la contraseña del archivo de clave). Las contraseñas son relativamente inseguras en comparación con las claves, millones de veces más fáciles de aplicar fuerza bruta que los pares de claves (aunque todavía es difícil por lo general). Ver man ssh-keygenpara mucha información.
Chris S
@ yes123, las diversas páginas de manual relacionadas con ssh (sshd, sshd_config, ssh, ssh_config) son lecturas útiles. Este documento parece un buen tutorial sobre autenticación de clave pública con ssh.
larsks
2
A pesar de parecer una típica "seguridad por oscuridad", estimaría que tiene sentido ya que escanear todos los puertos posibles (~ 64k) es mucho más costoso que uno de ellos.
Pero puedo agregar que "tocar el puerto" es mucho mejor.
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).
Buena idea con el puerto hacia adelante, John! Creo que ambos hemos aprendido algo :)
Alnitak
1
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.
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.
-1, parece que no entiendes lo que es la oscuridad ... Hacer que algo no sea obvio no es lo mismo que ponerle un candado. Si bien es cierto que ninguna seguridad es absoluta, definitivamente hay diferencias y agrupar la autenticación de tres factores con la oscuridad no ayuda a nadie.
Chris S
1
Lo siento, Chris, esa es la religión de culto de carga. Tal vez no pueda elegir un candado y, por lo tanto, piense que tener uno lo hace seguro, pero todos los candados se pueden abrir. Piense fuera de la caja: en muchos casos, hacer algo "no obvio" puede ser superior al uso de un candado. Su modelo / vista de seguridad es como dejar su computadora portátil en un automóvil cerrado con la alarma configurada: un tweaker con una piedra y su computadora portátil se ha ido. Pero tal vez no sea un tweaker, sino alguien con un exploit de 0 días y tiempo para matar ... ¡Oh, mira! ¡Chris tiene un objetivo "seguro" y bastante visible! La oscuridad es una parte MUY importante de la seguridad.
Joe aleatorio
Lo siento, pero sus comparaciones y lógica simplemente no se sostienen. Sí sé cómo abrir cerraduras, es más rápido cortarlas, romper una ventana, dar la vuelta. Cada medida de seguridad tiene una cierta cantidad de tiempo y esfuerzo necesarios para sortearla; La oscuridad requiere una pequeña cantidad de tiempo y esfuerzo, del orden de minutos a horas. La seguridad real, como los intentos de contraseña de limitación de velocidad, hace que pasar la contraseña tarde mucho tiempo. Esa disparidad de tiempo significativa es la diferencia entre seguridad "falsa" y "real"; la oscuridad cae en el primero.
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.
fuente
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.fuente
Para evitar realmente los ataques de fuerza bruta, siempre es importante seguir algunos pasos:
fuente
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.
fuente
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
fuente
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.
fuente
Ejecutaría ssh en el puerto estándar y usaría algo como fail2ban o denyhosts para limitar el número de ataques de diccionario.
Otra opción es deshabilitar el inicio de sesión con contraseñas altogheter y solo permitir inicios de sesión con ssh-keys.
fuente
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.
fuente
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) .
fuente
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.
fuente
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.fuente
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.
fuente
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.
fuente
man ssh-keygenpara mucha información.A pesar de parecer una típica "seguridad por oscuridad", estimaría que tiene sentido ya que escanear todos los puertos posibles (~ 64k) es mucho más costoso que uno de ellos.
Pero puedo agregar que "tocar el puerto" es mucho mejor.
fuente
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).
fuente
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.
fuente
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.
fuente
Supongo que si todavía no has descubierto que el puerto es útil, de lo contrario, no.
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente