DataSunrise Logra el Estado de Competencia en AWS DevOps en AWS DevSecOps y Monitoreo, Registro, Rendimiento

Configuración de DataSunrise Sniffer para MS SQL Server

Configuración de DataSunrise Sniffer para MS SQL Server

La característica clave de Microsoft SQL Server es que su aplicación cliente principal, SQL Server Management Studio, siempre requiere cifrado, incluso si la casilla de verificación Encrypt connection está desmarcada.

fed_1

Esto significa que para cualquier sniffer es imposible escuchar el tráfico cifrado o el sniffer requerirá una clave privada del servidor para su descifrado. El sniffer de DataSunrise puede descifrar el tráfico SSL si tiene la clave privada, por lo que nos centraremos en configurar un servidor para la operación de DataSunrise en modo sniffer.

Por defecto, el servidor está configurado para trabajar con claves efímeras: no hay claves estáticas ni certificados establecidos para él. El certificado y la clave se generan para cada conexión. Tal estrategia garantiza un alto nivel de seguridad en todas las conexiones del servidor. Así queda claro que el criptoproveedor integrado de Microsoft en las versiones más nuevas de Windows aumentó el nivel de prioridad de todos sus cifrados efímeros. Y ahora se está volviendo más difícil activar cifrados más apropiados para sniffing sin una configuración adicional del servidor.

Certificado

Para desactivar los cifrados efímeros y obtener una clave privada estática, es necesario instalar un certificado. Esto se puede hacer a través del Administrador de Configuraciones de SQL Server (función Protocols for MSSQLSERVER, configuraciones de red de SQL Server, pestaña Certificate):

fed

Aquí podemos seleccionar un certificado de la lista que se carga desde el almacén de certificados de Windows local.

Hay algunos requisitos de Microsoft para preparar el certificado.

  1. El certificado debe estar en el almacén de certificados del equipo local o en el almacén de certificados del usuario actual.
  2. La hora actual del sistema debe ser posterior a la propiedad Valid from del certificado y anterior a la propiedad Valid to del certificado.
  3. El certificado debe ser para autenticación de servidor. Esto requiere que la propiedad Enhanced Key Usage del certificado especifique Server Authentication (1.3.6.1.5.5.7.3.1).
  4. El certificado debe ser creado utilizando la opción KeySpec de AT_KEYEXCHANGE.
  5. La propiedad Subject del certificado debe indicar que el nombre común (CN) es el mismo que el nombre del host o el nombre de dominio completamente calificado (FQDN) de la computadora del servidor. Si SQL Server se ejecuta en un clúster de conmutación por error, el nombre común debe coincidir con el nombre del host o el FQDN del servidor virtual y los certificados deben provisionarse en todos los nodos del clúster de conmutación por error.

Para crear un certificado que cumpla con estas condiciones, puede usar la utilidad Make Cert incluida en Windows SDK.

makecert -r -pe -n "CN= HERE24322118" -b 01/09/2016 -e 01/09/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

En este ejemplo, se creará y colocará el certificado “HERE24322118” en el almacén de certificados local. En esta etapa, este certificado se puede seleccionar de la lista de certificados del Administrador de Configuración de SQL Server. Y después de reiniciar el servidor, podría usarse para proteger las conexiones de red.

Clave del Servidor

El siguiente paso es obtener la clave del servidor. Para hacer esto, es necesario exportarla desde un almacén de certificados, y extraer key.pem de certname.pfx:

openssl pkcs12 -in certname.pfx -nocerts -out key.pem -nodes

Key.pem es la clave privada que requiere el sniffer.

<>El servidor está configurado y su clave privada está obtenida, pero aún utiliza algoritmos efímeros debido al criptoproveedor. Para deshabilitar los algoritmos de intercambio de claves efímeras, es necesario referirse a la guía correspondiente de Microsoft o su interpretación GUI — IIScrypto.

fed_3

Aquí necesita deshabilitar 2 algoritmos de intercambio de claves: Diffie Hellman y ECDH. Los cambios entrarán en vigor después de que se reinicie el servidor host.

Instalación de la Clave en DataSunrise

El último paso es instalar la clave en DataSunrise. Para hacer esto, abrimos la pestaña Configurations, seleccionamos la base de datos requerida, abrimos la ventana de Certificates, pestaña PrivateKey y pegamos la clave privada copiada del archivo.

fed_4

La configuración del servidor y el firewall para el sniffing de SQL Server está completa. Y pensaremos en cómo hacer que la protección de su infraestructura sea más simple y mejor.

Siguiente

Integrando DataSunrise con Splunk Enterprise

Integrando DataSunrise con Splunk Enterprise

Más información

¿Necesita la ayuda de nuestro equipo de soporte?

Nuestros expertos estarán encantados de responder a sus preguntas.

Información general:
[email protected]
Servicio al Cliente y Soporte Técnico:
support.datasunrise.com
Consultas sobre Asociaciones y Alianzas:
[email protected]