¿Sigue siendo una buena práctica evitar usar los puertos predeterminados para SQL Server?

Históricamente, se ha recomendado no utilizar los puertos predeterminados para las conexiones a SQL Server, como parte de las mejores prácticas de seguridad. En un servidor con una única instancia predeterminada, los siguientes puertos se usarían de manera predeterminada:

• Servicio SQL Server - Puerto 1433 (TCP)
• Servicio de navegador de SQL Server - Puerto 1434 (UDP)
• Conexión de administrador dedicada: puerto 1434 (TCP)

PREGUNTAS

• ¿Sigue siendo relevante este consejo?
• ¿Deberían cambiarse TODOS los puertos anteriores?

Históricamente, se ha recomendado no utilizar los puertos predeterminados para las conexiones a SQL Server, como parte de las mejores prácticas de seguridad.

Lo cual era una tontería entonces y todavía una tontería ahora. La seguridad a través de la oscuridad posiblemente no es seguridad en absoluto.

¿Sigue siendo relevante este consejo?

En mi humilde opinión, nunca fue relevante. Fue necesario para algunos propósitos de cumplimiento porque las personas que redactaban esos cumplimientos no entendían lo que estaban haciendo, nuevamente, en mi humilde opinión.

¿Deberían cambiarse TODOS los puertos anteriores?

Yo no cambiaría ninguno.

Aunque la seguridad a través de la oscuridad no es seguridad real, no diré que no hay casos en los que ayude.

Si un atacante quiere saber dónde está escuchando su servicio, puede averiguarlo fácilmente, pero en caso de un ataque automático tonto, podría tener suerte si cambia el puerto.

El único momento en que puedo recordar dónde realmente ayudó fue durante el tiempo de SQL Slammer, donde SQL Server 2000 era vulnerable y un gusano se propagaba al generar IP aleatorios y conectarse al puerto predeterminado del navegador SQL Server.

Si recuerdo correctamente, era un consejo oficial en el momento de cambiar los puertos hasta que pudieras parchear tu servidor (ya sea porque no había un parche disponible de inmediato o porque no tenías una ventana)

Para que ese gusano ingrese a su red en el momento en que necesitaba tener un SQL Server conectado a Internet en lugar de detrás de un firewall, lo que no debería, pero de todos modos, un número de puerto no predeterminado podría haber ayudado en ese caso específico.

Sin embargo, estoy de acuerdo en que si tiene la seguridad adecuada, la complejidad que agrega probablemente no supere las posibilidades de evitar un incidente.

Históricamente, se ha recomendado no utilizar los puertos predeterminados para las conexiones a SQL Server, como parte de las mejores prácticas de seguridad.

No, no lo fue. Algunas personas equivocadas pueden haberlo presentado como tal, pero he estado haciendo seguridad durante más de 20 años y cambiar los puertos predeterminados siempre ha sido una especie de "aquí hay algo que puede hacer si lo desea, lo que a veces en circunstancias muy específicas proporciona un "seguridad adicional contra algunas amenazas muy específicas".

¿Sigue siendo relevante este consejo?

En circunstancias muy específicas, dependiendo de su modelo de amenaza y análisis de riesgo, puede haber algunos casos en los que este sea un buen consejo. En la gran mayoría de los casos, no, no es relevante ni lo fue nunca.

SÍ , todavía es útil.

Cambiar los puertos predeterminados solo tiene un propósito real: defenderse de escaneos / ataques automáticos, si su servidor de base de datos está abierto a hosts que puedan verse comprometidos.

Si bien eso puede no parecer un gran problema, recuerde que:

• cualquier host podría verse comprometido (o su servidor de bases de datos podría quedar expuesto a Internet en general debido a algún error)
• la mayoría de los ataques de esos días son ataques automáticos , y muchos de ellos intentarán solo puertos predeterminados (ya que apuntar a frutas bajas es más eficiente).

Entonces, sí, si bien por sí solo no lo ayudará mucho si está bajo un ataque dirigido , el uso de puertos aleatorios (y / o hacer que escuche solo en direcciones IPv6 aleatorias) lo hará mucho menos visible, por lo que al menos le dará más tiempo para actualice antes de que el escaneo automatizado de exploits de 0 días lo golpee (¡e incluso podría protegerlo completamente contra dicho escaneo automático por sí solo!)

Además (esto ayudará no solo contra todos los ataques automáticos, sino también contra algunos ataques dirigidos) cuando los atacantes intentan encontrar el puerto de su base de datos para explotarlo mediante escalas de puertos de fuerza bruta, puede ser detectado y defendido (mediante listas negras de rangos de IP del atacante y alertar a los administradores si se ha detectado algún host interno como fuente del ataque)

También tenga en cuenta que cambiar el puerto predeterminado para el servidor y los clientes (especialmente si se implementan automáticamente) es una cantidad de trabajo trivial, y detectar escaneos de fuerza bruta también es fácil; así que realmente debería hacerlo (no solo para los servidores de bases de datos; sino para todos los servicios donde la sobrecarga de configurarlo no es prohibitiva debido a problemas de usabilidad: como 80no se recomienda cambiar el puerto predeterminado para la web , ya que algunas personas (y bots) lo estropeará y es posible que los firewalls aleatorios de todo el mundo no permitan que se establezca la conexión, pero RDP es un gran objetivo, por ejemplo, para un puerto no predeterminado)

No cambiaría el puerto, pero nunca expondría el servicio de la base de datos directamente a través de Internet. Solo a través de un túnel seguro como SSH. Cambiar el puerto de SSH podría ser una buena idea para minimizar el tráfico de los escáneres.