¿Mejora la seguridad al usar números de puertos desconocidos?

  

¿Mejora la seguridad al usar números de puertos ocultos?

Si ya está utilizando contraseñas de alta entropía o autenticación de clave pública, la respuesta es "en realidad no". En la mayoría de los casos simplemente te estás deshaciendo del ruido en los troncos.

  

Me preocupan las consecuencias imprevistas de desviarse de estas recomendaciones.

Depende del puerto elegido. En Linux, de forma predeterminada, todos los puertos por debajo de 1024 requieren acceso de raíz para escucharlos. Si está utilizando un puerto por encima de 1024, cualquier cuenta de usuario puede escucharlo si todavía no hay un proceso de escucha.

¿Por qué esto importa? Digamos que eligió configurar ssh para enlazar al puerto 20,000 . Si alguien pudiera detener el proceso SSH en un servidor (digamos que de alguna manera encontraron una manera de bloquear el proceso) y tenía acceso local a ese servidor, podrían ejecutar su propio servidor SSH en el puerto 20,000 antes de que se reinicie el servicio. Cualquier persona que inicie sesión estará iniciando sesión en el servidor SSH de los malos.

Esto no es tan importante como solía ser, ya que en estos días solo el personal de TI de confianza tiene acceso de inicio de sesión a los servidores. Pero aún así, tiene la posibilidad de una escalada de privilegios y otra maldad si un atacante se afianza en su servidor.

Aparte de estar por debajo de 1024, el número 22 no tiene nada de especial. En gran parte se eligió porque SSH era un reemplazo para telnet en el puerto 23 , y 21 ya estaba en uso por FTP. Siempre que elija un puerto por debajo de 1024 , el puerto realmente no importa.

  

¿Es esta buena práctica o no? ¿Debemos usar puertos bien conocidos?

No diría que lo recomiendo. Yo tampoco lo desaconsejaría. Como dije, evita mucho ruido en los archivos de registro, pero los beneficios se limitan en gran medida a eso.

Para cualquier persona interesada en la historia de fondo de SSH, puede encontrarla en: enlace

Sí, lo hace. La verdadera pregunta es: ¿cuánto?

¿Por qué lo hace? Ya tienes seguridad básica, por lo que los ataques diarios de bot no te preocupan. Pero podría haber un día de 0 días y los atacantes saben que no pasará mucho tiempo antes de que salga un parche, por lo que se apresuran a usarlo y no se molestan en algo complicado, simplemente golpearán tantas máquinas como sea posible en El puerto estándar. Cualquier tipo de gusano SSH teórico también usaría esta estrategia. Estarías protegido contra eso.

¿Cuánta seguridad adicional te gana esto? Protege contra este y tal vez otros dos escenarios específicos. Agregará, en el mejor de los casos, algunos minutos a cualquier ataque dirigido por parte de cualquier persona que no sea un idiota total. No hace nada para los escenarios contra los que ya está adecuadamente protegido.

Si conecta esos números en su método de análisis de riesgo favorito, debería encontrar algo relativamente pequeño. En el lado negativo, tiene el esfuerzo adicional de establecer un número de puerto no estándar, documentarlo, tal vez faltarlo durante una solución de problemas y perder tiempo, etc.

Mi conjetura es que usted casi se rompería incluso con un análisis. O, en otras palabras: sí, mejora la seguridad, pero no vale la pena porque la mejora es muy pequeña.

No, no mejorará la seguridad. Puede reducir el desorden de registros, ya que los ataques automatizados solo intentarán con los puertos predeterminados, por ejemplo. ssh Pero el puerto seguirá apareciendo como SSH en un escaneo de puertos, y shodan.io .

Esos ataques automáticos generalmente apuntan a la fruta que cuelga poco, con nombres de usuario estándar como root, smith y demás, y contraseñas débiles. Si tienen éxito, tienes un problema en primer lugar.

Si configura ssh para que solo permita la autenticación de claves, no permita inicios de sesión de raíz y use contraseñas razonables, use fail2ban o un mecanismo similar para bloquear a los infractores, no son una amenaza real.

Uso fail2ban configurado para bloquear temporalmente durante cinco minutos después de tres intentos fallidos, y durante una semana después de 3 * 5 intentos fallidos. Esto reduce el desorden de registros y bloquea cualquier progreso real en un ataque de fuerza bruta.

Para un atacante objetivo, no importará qué puerto esté escuchando. Solo importa para ataques automatizados que, en mi opinión, son un riesgo insignificante.

El cambio del puerto predeterminado puede salvarte del escaneo de puertos y las secuencias de comandos del script, pero es posible que no puedas resistirte a ataques dirigidos donde el atacante podría identificar los servicios en ejecución que son irrelevantes para los puertos.

Si solo quiere alejarse de los chiquitos de script de forma, esto puede ser útil, pero es posible que no pueda protegerse del resto de los ataques avanzados.

Mi recomendación es usar un puerto predeterminado (puede reducir la sobrecarga administrativa) e implementar defensas de seguridad de cara múltiple para mitigar los ataques.

Por ejemplo, con el puerto predeterminado en uso, la implementación de la autenticación basada en certificados con SSH solo se permite a ciertas fuentes de confianza.

Yo diría que sí, use números de puerto anormales ya que esto filtrará MUCHOS bots automáticos. pero no confíe en eso, ya que muchos bots que he observado escanearán una red / host en busca de puertos abiertos y los probarán.

Lo mejor es implementar una buena seguridad en su puerto SSH. deshabilite el inicio de sesión de raíz, las IP de la lista blanca si puede, no use contraseñas para los inicios de sesión (use las teclas), también habilite una notificación para cualquier inicio de sesión. Y configurar un firewall, esto es importante.

La ocultación de puertos en números altos como este solo detiene los robots simples que buscarán puertos conocidos. Los niños de Script y los piratas informáticos determinados pueden simplemente escanear puertos en el resto del rango de puertos para encontrar un servicio, por lo que solo detendrá un poco de ruido de registro.

Realmente no importa la convención de no escuchar en el puerto estándar para ese servicio. Los desarrolladores de ese servicio te dan la opción de ejecutarlo en cualquier otro puerto, y cualquier programa que pueda interactuar con él tendrá la opción de especificar a qué puerto quieres hablar.

Estoy de acuerdo con otras publicaciones aquí en que los puertos confidenciales como SSH deben mantenerse en el espacio de puerto privilegiado de 1024.

Una mejor manera de ocultar SSH que realmente funciona es hacer una detonación de puertos. Esto implica cerrar el puerto en iptables hasta que se haya "eliminado" una secuencia de puertos que luego abrirán el puerto deseado.

Por ejemplo, puede enviar un paquete al 8000 4545 28882 7878. Una vez que haya ingresado la secuencia deseada, iptables desbloqueará su puerto deseado. Esto realmente detiene a la mayoría de los chavales y piratas informáticos, ya que no se anuncia ningún puerto. Pero esto no se limita a los ataques de repetición, pero en el punto en el que tiene problemas más importantes de los que preocuparse.

enlace .

Realmente debería usar TCPWrappers y solo permitir que ips y rangos de red conocidos accedan a puertos como SSH. ¿Necesita permitir que las IP de China accedan a SSH? ¿O solo los desarrolladores tendrán que acceder desde la LAN de la oficina? Si funcionan de forma remota, conviértalos en VPN en la LAN

Como lo mencionaron otros, la migración a un puerto no estándar no es una solución de seguridad porque solo filtra los ataques de nivel ingenuo.

Al mismo tiempo, la migración puede ser mucho más valiosa si se combina con otras precauciones. Por ejemplo, coloca un honeypot en el puerto estándar (un entorno que está físicamente aislado del resto de su sistema pero parece una pieza legítima para el atacante). Luego, si ves a alguien roto en el honeypot, es muy probable que sea un hacker, por lo que puedes prohibirlo automáticamente.

Y seguramente, no debe usar versiones obsoletas de software con vulnerabilidades conocidas, independientemente del número de puerto que estén obligados a escuchar.

No, no lo hace, o si quiero ser más preciso, es la protección equivocada contra la amenaza .

Da un paso atrás: ¿de qué amenaza queremos protegerte? La amenaza de la que intentamos proteger es a cualquier persona en la Internet pública que pueda pasar por alto el mecanismo de autenticación normal. Eso es lo que intentan hacer estos "guiones de niños": acceder al servidor mediante SSH aunque no estén autorizados. En particular, su superior desea evitar que estos atacantes puedan comenzar a establecer una conexión SSH.

¿Cuál es la tecnología estándar para evitar el establecimiento de conexiones de red? Un firewall. La respuesta estándar a este problema es simplemente bloquear el puerto 22 completamente al tráfico externo. El mayor problema aquí es que SSH está disponible para la red pública en absoluto , y el firewall lo resuelve por completo, mientras que el puerto oscuro solo lo oculta un poco y en realidad no impide las conexiones. Si se requiere acceso externo, la respuesta estándar para permitir este acceso autorizado es una VPN en la red. Esto bloquearía a los atacantes del conocimiento y de los chavales de script que podrían descubrir cómo encontrar el puerto que realmente estás usando.

Si pierdes al 1% de los atacantes, sigues perdiendo . Necesitas protecciones que funcionen contra el 100% de los atacantes. Si, en cambio, está bloqueando con éxito el 100% de los atacantes (hasta ahora), entonces debe tener implementadas protecciones más sólidas. Estas otras protecciones hacen que el puerto oscuro sea irrelevante, y si ese es el caso (con suerte), todo uso del otro puerto es confundir a las personas que están menos familiarizadas con las prácticas de seguridad reales como usted y, probablemente , pierda el tiempo de las personas que intentan obtener acceso legítimo cuando intentan conectarse (el nuevo sistema no está configurado y tiene que pedirle a alguien el puerto correcto, el administrador olvidó decirle a la persona sobre el puerto no estándar y la persona debe molestarlos nuevamente para diagnosticar el problema) , etc.).

Esta es la razón por la que insistimos en la "seguridad en la oscuridad" y el principio de Kerckhoffs . Debemos evitar distraernos con prácticas que en realidad no nos protegen. Debemos ahorrar nuestro tiempo y esfuerzo para las protecciones que realmente funcionan y evitar la falsa sensación de "seguridad" que nos brindan estos métodos de ofuscación.

Quiero agregar que al final, la seguridad es un juego sobre recursos en ambos lados. El tiempo es un recurso de este tipo.

Esta medida es perder el tiempo de un atacante, por lo que no es tan malo. También puede aprender sobre los recursos de los atacantes cuando todavía se conectan a su puerto personalizado. Tal vez haya un mayor interés en apuntarte en particular.

Sin embargo, si agrega una sobrecarga significativa a sus tareas administrativas, es posible que desee invertir su tiempo en otro lugar. Si no, hazlo pero no confíes en él.

El uso de puertos no estándar para aplicaciones altamente vulnerables es una MUY BUENA práctica. SSH tiene muchas vulnerabilidades y 22 es un puerto predeterminado común para la fuerza bruta.

Dicho esto, probablemente depende. Es muy común, especialmente en un entorno empresarial, ver ataques de fuerza bruta en servidores DMZ contra el puerto 22. Muchas empresas, en finanzas, por ejemplo, usan un puerto predeterminado diferente para el tráfico SSH / SFTP para la transferencia de datos válida entre organizaciones.

La idea en ese caso es más sobre filtrar parte del ruido (Forzado de Brute del Puerto 22) para que el otro tráfico en un puerto alternativo sea más fácil de monitorear. Cualquiera que sea lo suficientemente bueno puede encontrar cualquier puerto abierto en un servidor con acceso a Internet.

Esto se considera una forma de mitigación o reducción del riesgo.

Edit: Debo agregar: Cuando digo buenas prácticas, me refiero a las buenas prácticas en sus dispositivos de Internet. Cualquier cosa detrás de sus cortafuegos es generalmente segura