La razón más probable es hacer que sea más difícil para las personas que intentan forzar al azar cualquier inicio de sesión SSH que puedan encontrar. Mi máquina con conexión a Internet utiliza el puerto SSH predeterminado, y mis registros solían estar llenos de cosas como esta (extraídas de un archivo de registro real):
sshd[16359]: Invalid user test from 92.241.180.96
sshd[16428]: Invalid user oracle from 92.241.180.96
sshd[16496]: Invalid user backup from 92.241.180.96
sshd[16556]: Invalid user ftpuser from 92.241.180.96
sshd[16612]: Invalid user nagios from 92.241.180.96
sshd[16649]: Invalid user student from 92.241.180.96
sshd[16689]: Invalid user tomcat from 92.241.180.96
sshd[16713]: Invalid user test1 from 92.241.180.96
sshd[16742]: Invalid user test from 92.241.180.96
sshd[16746]: Invalid user cyrus from 92.241.180.96
sshd[16774]: Invalid user temp from 92.241.180.96
sshd[16790]: Invalid user postgres from 92.241.180.96
sshd[16806]: Invalid user samba from 92.241.180.96
En estos días uso DenyHosts para bloquear IP que no se autentican demasiadas veces, pero probablemente sea igual de fácil cambiar de puerto; prácticamente todos los ataques de fuerza bruta de este tipo no van a molestar al escaneo para ver si su sshd está escuchando en otro puerto, simplemente asumirán que no está ejecutando uno y continuarán
Si su configuración sshd no es lo suficientemente adecuada como para enfrentar a los niños tontos de script que solo prueban el puerto 22, de todos modos tiene un problema.
Una reacción más racional sería:
asegúrese de que sus usuarios estén usando contraseñas buenas que sean difíciles de adivinar / fuerza bruta
deshabilite la autenticación de contraseña (al menos para cuentas importantes) y simplemente use la autenticación de clave pública
cuidado con los problemas de seguridad ssh y actualizaciones
Algunas personas también pueden estar molestas por el ruido que sshd escribe en el registro del sistema, por ejemplo:
Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth
Entonces podría ser tentador ocultar el puerto sshd o usar una solución de bloqueo automático (como DenyHosts, Fail2ban o BlockHosts) para aumentar nuevamente la relación señal / ruido .
Pero existen mejores alternativas. Por ejemplo, puede configurar su demonio syslog de modo que el ruido de registro sshd solo se escriba en, digamos, /var/log/sshd-attempts.logy la señal (es decir, los mensajes de registro sshd restantes) se escriba en /var/log/messagesetc., como antes.
La implementación de herramientas de bloqueo automático debe considerarse cuidadosamente porque agregar más complejidad a los sistemas relevantes para la seguridad también significa aumentar el riesgo de explotación . Y, de hecho, a lo largo de los años, hay varios informes de vulnerabilidad DoS para cada DenyHosts , Fail2ban y BlockHosts .
Realmente no estoy de acuerdo con que "es seguridad por oscuridad". Creo que esa respuesta es una falacia común en este caso. El razonamiento de @ Michael generalmente muestra que es una mejor razón para tenerlo en otro lugar. Es principalmente para deshacerse de todos los ataques con bots con script. No significa necesariamente que les tengas miedo, o lo consideres efectivo contra un atacante determinado. Sé que nunca me preocupó que realmente entraran. Pero todo el trozo de troncos era molesto.
xenoterracida
1
@xenoterracide: Si solo le preocupa la legibilidad de sus archivos de registro, existen otras alternativas mejores para excluir el ruido en lugar de cambiar el puerto como una táctica de oscuridad, que era la pregunta. Con respecto al bloqueo de IP, que no era parte de la pregunta: tenga en cuenta que agregar más complejidad a los sistemas relevantes para la seguridad también significa aumentar el riesgo de explotación. Considere, por ejemplo, seclists.org/fulldisclosure/2007/Jun/121 ossec.net/main/attacking-log-analysis-tools . Sí, DenyHosts se vio afectado por esto.
maxschlepzig
1
Hay más que solo legibilidad en mente. Un cambio de puerto debidamente documentado no es seguridad por oscuridad.
xenoterracide
4
Cambiar el puerto SSH es principalmente un teatro de seguridad . Te da una sensación borrosa de haber hecho algo. Has escondido el puerto SSH debajo del felpudo.
Si ejecuta un servidor SSH en Internet, verá muchos intentos fallidos de inicio de sesión en sus registros, desde bots que buscan contraseñas estúpidamente débiles, claves débiles y exploits conocidos en versiones anteriores del servidor. Los intentos fallidos son solo eso: intentos fallidos. En cuanto a evaluar qué tan vulnerable eres, son completamente irrelevantes. De lo que debe preocuparse es de los intentos exitosos de intrusión, y no los verá en sus registros.
Cambiar el puerto predeterminado reducirá la cantidad de visitas de dichos bots, pero eso solo frustra a los atacantes menos sofisticados que son detenidos por cualquier seguridad decente (actualizaciones de seguridad aplicadas regularmente, contraseñas razonablemente seguras o autenticación de contraseña deshabilitada). La única ventaja es reducir el volumen de registros. Si eso es un problema, considere algo como Denyhosts o Fail2ban para limitar la velocidad de conexión, también hará que su ancho de banda sea bueno.
Cambiar el puerto predeterminado tiene una gran desventaja: hace que sea menos probable que pueda iniciar sesión desde detrás de un firewall. Es más probable que los firewalls dejen pasar los servicios en su puerto predeterminado que en algún otro puerto aleatorio. Si no está ejecutando un servidor HTTPS, considere hacer que SSH escuche también en el puerto 443 (o redirija las solicitudes TCP entrantes desde el puerto 443 al puerto 22), ya que algunos firewalls permiten el tráfico que no pueden decodificar en el puerto 443 porque parece como HTTPS
Respuestas:
La razón más probable es hacer que sea más difícil para las personas que intentan forzar al azar cualquier inicio de sesión SSH que puedan encontrar. Mi máquina con conexión a Internet utiliza el puerto SSH predeterminado, y mis registros solían estar llenos de cosas como esta (extraídas de un archivo de registro real):
En estos días uso DenyHosts para bloquear IP que no se autentican demasiadas veces, pero probablemente sea igual de fácil cambiar de puerto; prácticamente todos los ataques de fuerza bruta de este tipo no van a molestar al escaneo para ver si su sshd está escuchando en otro puerto, simplemente asumirán que no está ejecutando uno y continuarán
fuente
No, es una táctica de seguridad por oscuridad .
Si su configuración sshd no es lo suficientemente adecuada como para enfrentar a los niños tontos de script que solo prueban el puerto 22, de todos modos tiene un problema.
Una reacción más racional sería:
Algunas personas también pueden estar molestas por el ruido que sshd escribe en el registro del sistema, por ejemplo:
Entonces podría ser tentador ocultar el puerto sshd o usar una solución de bloqueo automático (como DenyHosts, Fail2ban o BlockHosts) para aumentar nuevamente la relación señal / ruido .
Pero existen mejores alternativas. Por ejemplo, puede configurar su demonio syslog de modo que el ruido de registro sshd solo se escriba en, digamos,
/var/log/sshd-attempts.logy la señal (es decir, los mensajes de registro sshd restantes) se escriba en/var/log/messagesetc., como antes.La implementación de herramientas de bloqueo automático debe considerarse cuidadosamente porque agregar más complejidad a los sistemas relevantes para la seguridad también significa aumentar el riesgo de explotación . Y, de hecho, a lo largo de los años, hay varios informes de vulnerabilidad DoS para cada DenyHosts , Fail2ban y BlockHosts .
fuente
Cambiar el puerto SSH es principalmente un teatro de seguridad . Te da una sensación borrosa de haber hecho algo. Has escondido el puerto SSH debajo del felpudo.
Si ejecuta un servidor SSH en Internet, verá muchos intentos fallidos de inicio de sesión en sus registros, desde bots que buscan contraseñas estúpidamente débiles, claves débiles y exploits conocidos en versiones anteriores del servidor. Los intentos fallidos son solo eso: intentos fallidos. En cuanto a evaluar qué tan vulnerable eres, son completamente irrelevantes. De lo que debe preocuparse es de los intentos exitosos de intrusión, y no los verá en sus registros.
Cambiar el puerto predeterminado reducirá la cantidad de visitas de dichos bots, pero eso solo frustra a los atacantes menos sofisticados que son detenidos por cualquier seguridad decente (actualizaciones de seguridad aplicadas regularmente, contraseñas razonablemente seguras o autenticación de contraseña deshabilitada). La única ventaja es reducir el volumen de registros. Si eso es un problema, considere algo como Denyhosts o Fail2ban para limitar la velocidad de conexión, también hará que su ancho de banda sea bueno.
Cambiar el puerto predeterminado tiene una gran desventaja: hace que sea menos probable que pueda iniciar sesión desde detrás de un firewall. Es más probable que los firewalls dejen pasar los servicios en su puerto predeterminado que en algún otro puerto aleatorio. Si no está ejecutando un servidor HTTPS, considere hacer que SSH escuche también en el puerto 443 (o redirija las solicitudes TCP entrantes desde el puerto 443 al puerto 22), ya que algunos firewalls permiten el tráfico que no pueden decodificar en el puerto 443 porque parece como HTTPS
fuente