Cómo Proteger Tu Base de Datos SQL Server Contra Ataques MITM con DataSunrise
1 ¿Qué es MITM?
Cuando un cliente se conecta a un servidor a través de un canal protegido, existe el riesgo de que una tercera parte se conecte entre ellos y tenga la capacidad de escuchar e interferir con las comunicaciones. Los ataques de red lanzados mediante dicha tercera parte se llaman ataques de Hombre en el medio (MITM). Hay muchas maneras de realizar tal ataque, pero el principio básico es hacer secretamente que el cliente se conecte al servidor del atacante.
2 ¿Cómo protegerse contra MITM?
El método principal de protección contra los ataques MITM es analizar la infraestructura de red en el momento de conectarse al servidor y detectar parámetros sospechosos que no son típicos para la conexión a un cierto servidor. Si se utiliza el protocolo SSL para protección, un cliente puede verificar el certificado del servidor durante el apretón de manos. Un certificado puede tener muchos parámetros, intercambiados entre el cliente y el servidor durante la autenticación. La práctica estándar para SSL es terminar una conexión inmediatamente si una parte acepta un parámetro (Nombre del directorio, DNS, Email, GUID, IP, UPN, URL y cualquier otro) que no es relevante para los parámetros de su entorno. Pero incluso tal verificación de certificado no puede garantizar seguridad total, porque la infraestructura del cliente en el momento del ataque puede cambiar significativamente para pasar la verificación. Es por eso que a menudo se utilizan métodos adicionales de validación de certificados. Uno de esos métodos es la firma de un certificado por una autoridad confiable. Se considera que es imposible forjar tal firma, y cada cliente puede verificar su autenticidad. Es por eso que cualquier certificado firmado por una autoridad especial podría ser aceptado como más o menos seguro, dependiendo de la autoridad del emisor.
3 Protección contra MITM en MS SQL Server
La verificación de certificados es opcional en MS SQL, pero está habilitada por defecto. Dos parámetros principales que participan en una verificación de certificados son la fecha de expiración del certificado y el nombre del host para el cual se emitió el certificado (Nombre Común). Si un certificado está vencido, o no está emitido para el host de un servidor con el cual se establece una conexión, la conexión se terminaría inmediatamente con notificación al usuario. En caso de que una autoridad certificadora esté involucrada en una verificación adicional de certificados, el cliente verificará su firma. En tales casos, debería haber un certificado raíz de esta autoridad en el almacenamiento de certificados. Muchos sistemas operativos modernos incluyen conjuntos preconstruidos de certificados raíz de las autoridades más confiables, por lo que al seleccionar una autoridad certificadora para firmar un certificado corporativo, sería prudente seleccionar una de la lista.
En SSMS moderno, hay una casilla adicional «Confiar en el certificado del servidor» en la página de conexión del servidor. Se utiliza para verificar el certificado del servidor.
Al conectarse a un servidor a través de ODBC, hay un parámetro adicional, “TrustServerCertificate”, en la cadena de conexión. El valor “Yes” desactiva la verificación y “No“ – la habilita.
4 Certificados en DataSunrise
El proxy de DataSunrise es confiable, pero, sin embargo, es una tercera parte de la conexión, por lo que todos los medios de protección del cliente contra MITM se activarían en el momento de la conexión con dicho proxy.
En DataSunrise, cada instancia de base de datos opera con un conjunto de claves privadas y un certificado. Desde el punto de vista del cliente, este conjunto pertenece al servidor, pero en general, estas claves no están asociadas de ninguna manera con el servidor final que sirve al proxy de DataSunrise. Es este certificado el que un cliente verificará si se activa la protección contra MITM.
5 Posibles configuraciones de DataSunrise incluyendo protección contra MITM
Para proporcionar un nivel similar de protección de conexión directa y conexión de proxy, es necesario configurar correctamente los hosts de DataSunrise y del cliente. Podrían haber varias opciones de configuración.
Un conjunto predeterminado de claves y un certificado proporcionan una protección mínima. No se garantiza que el certificado predeterminado corresponda al nombre de host CN=DataSunrise Database Security Suite. Es por eso que lo primero que debes hacer para asegurar una conexión es generar un nuevo conjunto de claves y un certificado.
Un conjunto básico de claves y un certificado están incluidos en el archivo proxy.pem. Es este archivo el que debe ser reemplazado.
5.1 Caso general
Este es el caso más sencillo, cuando un administrador solo tiene una instancia de DataSunrise a su disposición, y un servidor MS SQL. Y hay un conjunto limitado y establecido de clientes que pueden acceder a los servidores dados a través de DataSunrise. Este caso involucra dos opciones:
5.1.1 Generación de proxy.pem (certificado autofirmado)
Es el método más simple de generar nuevas claves. Crea un archivo proxy.cfg (“commonName” debe incluir un nombre real del host de DataSunrise):
[req]
distinguished_name = req_distinguished_name
prompt = no
[req_distinguished_name]
countryName = US
stateOrProvinceName = Washington
localityName = Seattle
organizationName = Sunrise
organizationalUnitName = IT
commonName = wmserver.db.local
emailAddress = [email protected] Ejecuta el siguiente archivo .bat en la carpeta donde se encuentra el archivo proxy.config:
SET RANDFILE=random
SET PASS=R0T3qSW2s0459koH54
openssl genrsa -des3 -passout pass:%PASS% -out key.pem 2048
openssl rsa -passin pass:%PASS% -in key.pem -out key.pem
openssl req -config proxy.cfg -new -key key.pem -out certificate.req
openssl req -sha384 -x509 -config proxy.cfg -days 365 -key key.pem -in certificate.req -out certificate.cer
openssl ecparam -genkey -name secp256r1 -out ec.pem
openssl dhparam -out dh.pem 1024
COPY certificate.cer+key.pem+dh.pem+ec.pem proxy.pem /b
DEL random certificate.req key.pem dh.pem ec.pem Después de ejecutar el script, deberíamos obtener un archivo proxy.pem con una clave RSA de 2048 bits, una clave DH de 1024 bits, parámetros EC con la curva “secp256r1” y un certificado emitido por 365 días con algoritmo de firma “sha384”.
Adicionalmente, debería haberse generado un archivo certificate. cer que debe instalarse en el almacenamiento de certificados de confianza del cliente.
5.1.2 Instalación de un certificado y claves de proxy a través de la IU
Si un usuario ya tiene un conjunto de claves y un certificado, pueden instalarse a través de la IU web de DataSunrise.
Para configurar claves y un certificado para un proxy, realiza lo siguiente:
- Crea un Grupo de Claves SSL con el tipo Lado del Cliente.
- Rellena este grupo con todos los parámetros necesarios en codificación Base64: un certificado, una clave privada, parámetros DH, parámetros EC.
- Conecta este grupo a una instancia seleccionándolo de la lista de Grupos de Claves.
Ambas opciones (5.1.1 y 5.1.2) requieren que reinicies el Núcleo de DataSunrise después de haber reemplazado las claves, e instales un certificado creado para DataSunrise en un almacenamiento de certificados de confianza en el lado del cliente.
5.2 Varias instancias de DataSunrise
La siguiente configuración es para múltiples instancias de DataSunrise. Si usas los consejos del caso general descrito anteriormente, sería necesario instalar todo un conjunto de certificados en el lado del cliente y mantener un ojo en su aplicabilidad. Para evitar posibles errores, puedes firmar todos los certificados con una sola autoridad certificadora. Hay dos opciones también.
5.2.1 Tu propia Autoridad Certificadora
Esta opción es para crear tu propia autoridad certificadora sin dependencias adicionales del sistema operativo. La autoridad de tal emisor de certificados sería mínima.
Prepara la infraestructura:
mkdir db
mkdir db\new
mkdir db\private
echo. 2>db\index
echo 01> ./db/serial
echo unique_subject = no> ./db/index.attr Rellena el archivo ca.cfg:
[req]
distinguished_name = req_distinguished_name
prompt = no
RANDFILE = ./db/private/.rand
[req_distinguished_name]
countryName = US
stateOrProvinceName = Washington
localityName = Seattle
organizationName = DataSunrise
organizationalUnitName = IT
commonName = DataSunrise
emailAddress = [email protected] Rellena el archivo proxy.cfg:
[req]
distinguished_name = req_distinguished_name
prompt = no
RANDFILE = ./db/private/.rand
[req_distinguished_name]
countryName = US
stateOrProvinceName = Washington
localityName = Seattle
organizationName = Sunrise
organizationalUnitName = IT
commonName = wmserver.db.local
emailAddress = [email protected]
[ca]
default_ca = CA_default
[CA_default]
dir = ./db # top dir
database = $dir/index # index file.
new_certs_dir = $dir/new # new certs dir
certificate = $dir/ca.cer # The CA cert
serial = $dir/serial # serial no file
private_key = $dir/private/ca.pem # CA private key
RANDFILE = $dir/private/.rand # random number file
default_days = 365 # how long to certify for
default_crl_days = 30 # how long before next CRL
default_md = sha384
policy = policy_any # default policy
email_in_dn = no # Don't add the email into cert DN
name_opt = ca_default # Subject name display option
cert_opt = ca_default # Certificate display option
#copy_extensions = none # Don't copy extensions from request
[policy_any]
countryName = supplied
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional Genera un certificado raíz ./db/ca.cer y una clave ./db/private/ca.pem. Este certificado (su clave) se usará para firmar todos los certificados futuros. Así, ./db/ca.cer debe instalarse en un almacenamiento de certificados de confianza de todos los clientes que verificarán los certificados DataSunrise:
./db/private/ca.pem:
SET RANDFILE=.\db\private\.rand
SET PASS=TxK7T88C27
openssl genrsa -des3 -passout pass:%PASS% -out .\db\private\ca.pem 2048
openssl rsa -passin pass:%PASS% -in .\db\private\ca.pem -out .\db\private\ca.pem
openssl req -new -x509 -days 3650 -key .\db\private\ca.pem -out .\db\ca.cer -config ca.cfg
openssl x509 -noout -text -in .\db\ca.cer Genera y firma proxy.pem:
SET RANDFILE=.\db\private\.rand
SET /P serial=<.\db\serial
SET PASS=RTqSWs0koH
openssl genrsa -des3 -passout pass:%PASS% -out .\db\private\%serial%.pem 2048
openssl rsa -passin pass:%PASS% -in .\db\private\%serial%.pem -out .\db\private\%serial%.pem
openssl req -new -key .\db\private\%serial%.pem -nodes -config proxy.cfg -out .\db\private\%serial%.req
openssl ca -batch -config proxy.cfg -infiles .\db\private\%serial%.req
openssl ecparam -genkey -name secp256r1 -out .\db\private\%serial%.ec.pem
openssl dhparam -out .\db\private\%serial%.dh.pem 1024
COPY .\db\new\%serial%.pem+key.pem+.\db\new\%serial%.dh.pem+.\db\new\%serial%.ec.pem proxy.pem /b
MOVE .\db\new\%serial%.pem .\db\new\%serial%.cer Los certificados creados se guardarán en la carpeta db\new\
Las claves generadas y los pfxs empaquetados (clave y certificado) se guardarán en la carpeta db\private\
Ejemplo. Un conjunto de claves número “01”:
db\new\01.cer — Nuevo certificado db\private\01.pem — Nueva clave privada RSA db\private\01.dh.pem — Nuevos parámetros DH db\private\01.ec.pem — Nuevos parámetros y clave EC
Durante cada generación de proxy.pem se creará un nuevo conjunto de claves. Corresponderá a un nuevo proxy.pem generado. Después de reemplazar el proxy.pem en DataSunrise, es necesario reiniciar el Núcleo para que los cambios surtan efecto. Teniendo un nuevo conjunto de claves, también puedes usar el método 5.1.2 para agregar las claves a la IU sin cambiar el proxy.pem.
5.2.2 Utilizando una Autoridad Certificadora Corporativa
Si es necesario proteger varios hosts de clientes, o hay varios hosts de DataSunrise incluidos en una red corporativa (dominio) o varias redes confiables (bosque), sería útil utilizar Servicios de Certificado de Active Directory. En este caso, puedes usar certreq para generar un proxy.pem. Tomemos un proxy.cfg descrito en la subs. 5.1.1 y generemos un proxy.pem (los comandos deben ser ejecutados como un usuario con privilegios suficientes para emitir nuevos certificados o como un administrador de dominio):
SET RANDFILE=random
SET PASS=89RT90qSWs020koH12
openssl genrsa -des3 -passout pass:%PASS% -out key.pem 2048
openssl rsa -passin pass:%PASS% -in key.pem -out key.pem
openssl req -config proxy.cfg -new -key key.pem -out certificate.req
certreq -submit -attrib "CertificateTemplate:WebServer" certificate.req certificate.cer
openssl ecparam -genkey -name secp256r1 -out ec.pem
openssl dhparam -out dh.pem 1024
COPY certificate.cer+key.pem+dh.pem+ec.pem proxy.pem /b
DEL random certificate.req certreq mostrará un diálogo para seleccionar un centro de certificación corporativo que debería usarse para emitir un nuevo certificado. Usualmente, solo hay un centro en tal lista:
Pero esto depende de la infraestructura del dominio corporativo. Consulta a tu administrador si es necesario.
Habiendo instalado el proxy.pem, no se necesita configuración adicional del cliente de red, porque después de la instalación de AD CS, el certificado raíz cubre automáticamente todos los hosts del dominio/bosque.
Utilizando un conjunto de claves y un certificado (certificate.cer, key.pem, dh.pem, ec.pem), también puedes usar el método descrito en la subs. 5.1.2 para agregar claves a través de la IU web sin cambiar el proxy.pem.
5.3 Muchos clientes
Cuando necesites aplicar un certificado a un gran número de clientes, puedes usar políticas de grupo. Consulta la siguiente guía de Microsoft: https://technet.microsoft.com/en-us/library/cc770315%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396 (Desplegar Certificados mediante el uso de Políticas de Grupo)
6 Conclusión
Utilizando cualquiera de los métodos descritos anteriormente, puedes lograr un alto nivel de seguridad de la conexión de proxy, pero depende de ti elegir el método que mejor se adapte a tu infraestructura. Para asegurar la seguridad total de tu base de datos SQL Server, puedes usar las siguientes herramientas de DataSunrise: