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 mediante un canal protegido, existe el riesgo de que un tercero se interponga entre ellos, con la capacidad de escuchar e interferir en las comunicaciones. Los ataques de red llevados a cabo por medio de dicho tercero se denominan ataques Man in the Middle (MITM). Existen muchas formas de realizar este tipo de ataque, pero el principio básico es hacer que el cliente se conecte de manera encubierta al servidor del atacante.
2 ¿Cómo protegerse contra MITM?
El método principal de protección contra los ataques MITM es el análisis de la infraestructura de red en el momento de la conexión al servidor y la detección de parámetros sospechosos que no son típicos para la conexión a determinado servidor. Si se utiliza el protocolo SSL para la protección, el cliente puede verificar el certificado del servidor durante el proceso de negociación (handshake). Un certificado puede contener muchos parámetros intercambiados entre el cliente y el servidor durante la autenticación. La práctica estándar para SSL es terminar la conexión inmediatamente si una de las partes acepta un parámetro (nombre del directorio, DNS, correo electrónico, GUID, IP, UPN, URL y cualquier otro) que no es relevante para los parámetros de su entorno. Sin embargo, incluso esta verificación del certificado no puede garantizar una seguridad total, ya que la infraestructura del cliente en el momento del ataque puede modificarse significativamente para pasar la verificación. Es por ello que, a menudo, se utilizan métodos adicionales de validación de certificados. Uno de esos métodos es la firma del certificado por una autoridad de confianza. Se supone que es imposible falsificar dicha firma, y cualquier cliente puede verificar su autenticidad. Por ello, cualquier certificado firmado por una autoridad especial podría ser aceptado como relativamente seguro, dependiendo de la autoridad del emisor.
3 Protección contra MITM en MS SQL Server
La verificación del certificado es opcional en MS SQL, pero se encuentra habilitada por defecto. Dos parámetros principales que participan en la verificación del certificado son la fecha de expiración del certificado y el nombre del host para el cual fue emitido (Common Name). Si un certificado ha expirado o no ha sido emitido para el host con el que se establece la conexión, la conexión se terminará inmediatamente, notificando al usuario. En caso de que una autoridad de certificación participe en una verificación adicional del certificado, el cliente verificará su firma. En tales casos, debe existir un certificado raíz de esta autoridad en el almacén de certificados. Muchos sistemas operativos modernos incluyen conjuntos preconstruidos de certificados raíz de las autoridades más confiables; por ello, al seleccionar una autoridad de certificación para firmar un certificado corporativo, sería prudente elegir una que figure en dicha lista.
4 Certificados en DataSunrise
El proxy de DataSunrise es confiable, pero, sin embargo, es un tercero en la conexión, por lo que todos los mecanismos de protección del cliente contra MITM se activarán en el momento de conectarse a 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 presta el servicio del proxy de DataSunrise. Es este certificado el que verificará el cliente si la protección contra MITM está activada.
5 Posibles configuraciones de DataSunrise que incluyen protección contra MITM
Para proporcionar un nivel similar de protección tanto en la conexión directa como en la conexión mediante proxy, es necesario configurar correctamente los hosts de DataSunrise y del cliente. Pueden existir 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 por defecto corresponda al nombre de host CN=DataSunrise Database Security Suite. Por ello, lo primero que debe hacerse 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. Este es el archivo que debe ser reemplazado.
5.1 Caso general
Este es el caso más sencillo, cuando un administrador dispone de una única instancia de DataSunrise y un servidor MS SQL, y existe un conjunto limitado y preestablecido de clientes que pueden acceder a dichos servidores 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 sencillo para generar nuevas claves. Cree un archivo proxy.cfg (el “commonName” debe incluir el 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] Ejecute 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 se debería 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 el algoritmo de firma “sha384”.
Adicionalmente, se debería generar un archivo certificate.cer que debe instalarse en el almacén de certificados de confianza del cliente.
5.1.2 Instalación de un certificado y claves del proxy a través de la interfaz de usuario
Si el usuario ya dispone de un conjunto de claves y un certificado, éstos pueden ser instalados a través de la interfaz web de DataSunrise.
Para establecer las claves y el certificado para un proxy, realice lo siguiente:
- Crear un Grupo de Claves SSL con el tipo Lado Cliente.
- Rellenar este grupo con todos los parámetros necesarios en codificación Base64: un certificado, una clave privada, parámetros DH, parámetros EC.
- Conectar 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 reinicie el Core de DataSunrise después de haber reemplazado las claves, e instalar un certificado creado para DataSunrise en el almacén 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 se utilizan los consejos generales descritos anteriormente, será necesario instalar un conjunto completo de certificados en el lado del cliente y vigilar su vigencia. Para evitar posibles errores, se pueden firmar todos los certificados con una única autoridad de certificación. Existen también dos opciones:
5.2.1 Su propia Autoridad de Certificación
Esta opción es para crear su propia autoridad de certificación sin dependencias adicionales del sistema operativo. La autoridad de dicho emisor de certificados sería mínima.
Prepare 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 Complete 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] Complete 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 # directorio principal
database = $dir/index # archivo de índice.
new_certs_dir = $dir/new # directorio de nuevos certificados
certificate = $dir/ca.cer # El certificado de la CA
serial = $dir/serial # archivo de número de serie
private_key = $dir/private/ca.pem # clave privada de la CA
RANDFILE = $dir/private/.rand # archivo de números aleatorios
default_days = 365 # duración de la certificación
default_crl_days = 30 # días hasta el siguiente CRL
default_md = sha384
policy = policy_any # política predeterminada
email_in_dn = no # No añadir el correo electrónico al DN del certificado
name_opt = ca_default # opción de visualización del nombre del sujeto
cert_opt = ca_default # opción de visualización del certificado
#copy_extensions = none # No copiar extensiones de la solicitud
[policy_any]
countryName = supplied
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional Genere un certificado raíz ./db/ca.cer y una clave ./db/private/ca.pem. Este certificado (y su clave) se utilizará para firmar todos los certificados futuros. Por lo tanto, ./db/ca.cer debe instalarse en el almacén de certificados de confianza de todos los clientes que verifiquen los certificados de 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 Genere y firme 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 archivos pfx 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 RSA privada
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. Este corresponderá a un proxy.pem recién generado. Después de reemplazar proxy.pem en DataSunrise, es necesario reiniciar el Core para que los cambios tengan efecto. Con un nuevo conjunto de claves también puede utilizar el método 5.1.2 para agregar las claves a la interfaz sin cambiar el proxy.pem.
5.2.2 Ejecución de una Autoridad de Certificación Corporativa
Si se requiere proteger varios hosts clientes, o si existen varios hosts de DataSunrise incluidos en una red corporativa (dominio) o en varias redes de confianza (forest), sería conveniente utilizar los Servicios de Certificados de Active Directory. En este caso, puede utilizar certreq para generar un proxy.pem. Tomemos un archivo proxy.cfg descrito en el subapartado 5.1.1 y generemos un proxy.pem (los comandos deben ejecutarse como un usuario con privilegios suficientes para emitir nuevos certificados o como 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 se empleará para emitir un nuevo certificado. Normalmente, solo aparece un centro en dicha lista:
Pero esto depende de la infraestructura del dominio corporativo. Consulte a su administrador si es necesario.
Habiendo instalado el proxy.pem, no se requiere una configuración adicional del cliente de red, ya que tras la instalación de AD CS, el certificado raíz cubrirá automáticamente todos los hosts del dominio/forest.
Mediante el uso de un conjunto de claves y un certificado (certificate.cer, key.pem, dh.pem, ec.pem), también puede utilizar el método descrito en el subapartado 5.1.2 para agregar las claves a través de la interfaz web sin cambiar el proxy.pem.
5.3 Muchos clientes
Cuando necesite aplicar un certificado a un gran número de clientes, puede utilizar las Políticas de Grupo. Consulte la siguiente guía de Microsoft: Implementar certificados mediante la Directiva de Grupo .
6 Conclusión
Utilizando cualquiera de los métodos descritos anteriormente, puede alcanzar un alto nivel de seguridad en la conexión mediante proxy, pero depende de usted elegir el método que mejor se adapte a su infraestructura. Para garantizar la seguridad total de su base de datos SQL Server, puede utilizar las siguientes herramientas de DataSunrise:
