Comprobación de seguridad en máquinas SQL Server

No entraremos aquí en detalles concretos sobre el SQL-Slammer, que ya fueron analizados en profundidad por Bernardo Quintero en sendos boletines de “una-al-día”. No obstante, no quiero dejar pasar la oportunidad de hacer referencia a un reciente estudio que analiza la velocidad de propagación del gusano. Según este estudio, nos encontramos ante un gusano que ha tenido una velocidad impresionante: cada 8,5 segundos doblaba el número de sistemas infectados y durante los primeros 10 minutos de vida consiguió afectar al 90 por ciento de las máquinas vulnerables.

Durante los últimos meses hemos recogido en diversos boletines de “una-al-día” la existencia creciente de problemas de seguridad en Microsoft SQL Server. Esto y la constatación del gran número de máquinas vulnerables existentes nos ha impulsado a confeccionar esta lista de comprobación que permite analizar el estado de seguridad de un servidor SQL. No obstante, las comprobaciones que realizamos deben considerarse únicamente un punto de referencia, a adaptar a las particularidades de cada instalación.

Todas estas verificaciones deben realizarse siempre en entornos de pruebas, ya que potencialmente pueden afectar a la funcionalidad.

Las pruebas

-Verificar que están instaladas las últimas actualizaciones y hotfixes, tanto para el sistema operativo, como para SQL Server.

La relación de actualizaciones aplicadas a SQL Server puede obtenerse ejecutando la orden “select @@version”. En el momento de escribir este boletín, la última actualización disponible es el Service Pack 3. Por tanto, éste debería aparecer en la parte superior de la relación.

-Evaluar y escoger el protocolo de conexión que permite una mayor seguridad, sin que ello afecte a las prestaciones. Eliminar el resto.

La gran mayoría de instalaciones actuales utilizan únicamente el protocolo TCP/IP. No obstante, en muchas instalaciones se instalan otros protocolos de conexión como named pipes. Si estos protocolos no son utilizados, conviene plantear su desinstalación.

Adicionalmente, en el mercado hay productos que permiten el cifrado de las comunicaciones TCP/IP de SQL Server.

-Proteger las cuentas “sa” y “probe” (SQL Server 6.5) con contraseñas fuertes.

Es imprescindible que las cuentas de administración dispongan de una contraseña fuerte y que ésta sólo pueda ser utilizada por el menor número posible de personas.

La cuenta “probe” se utiliza para el análisis de rendimiento y las transacciones distribuidas. Si la cuenta dispone de contraseña, es posible que algunas funcionalidades dejen de funcionar en la modalidad estándar de seguridad.

-Utilizar una cuenta de usuario con pocos privilegios para la ejecución de SQL Server.

Habitualmente el servicio de SQL Server es ejecutado por el administrador o por LocalSystem. Es aconsejable, en cambio, que sea una cuenta de usuario con los mínimos permisos (derecho “Ejecutar como servicio”). De esta forma, un ataque contra el servidor quedará contenido a nivel de acceso a la máquina.

Si esta modificación se realiza desde el Enterprise Manager, todos los cambios de ACL en archivos, registro y permisos de usuario se realizan de forma automática.

-Verificar la utilización de particiones NTFS

Tanto los archivos de programa como las bases de datos deben residir en particiones NTFS y deben aplicarse las restricciones necesarias a nivel de sistema de archivos para evitar que, si por cualquier razón, alguien obtiene acceso al sistema, pueda cometer una catástrofe.

-Restringir el acceso a los procedimientos almacenados y procedimientos almacenados ampliados potencialmente peligrosos a únicamente los administradores de sistema.

Existen un buen número de procedimientos potencialmente peligrosos, que desde el punto de vista de seguridad no interesa que estén al alcance de todos los usuarios:

sp_sdidebug, xp_availablemedia, xp_cmdshell, xp_deletemail, xp_dirtree, xp_dropwebtask, xp_dsninfo, xp_enumdsn, xp_enumerrorlogs, xp_enumgroups, xp_enumqueuedtasks, xp_eventlog, xp_findnextmsg, xp_fixeddrives, xp_getfiledetails, xp_getnetname, xp_grantlogin, xp_logevent, xp_loginconfig, xp_logininfo, xp_makewebtask, xp_msver, xp_regread, xp_perfend, xp_perfmonitor, xp_perfsample, xp_perfstart, xp_readerrorlog, xp_readmail, xp_revokelogin, xp_runwebtask, xp_schedulersignal, xp_sendmail, xp_servicecontrol, xp_snmp_getstate, xp_snmp_raisetrap, xp_sprintf, xp_sqlinventory, xp_sqlregister, xp_sqltrace, xp_sscanf, xp_startmail, xp_stopmail, xp_subdirs, xp_unc_to_drive y xp_dirtree.

Es conveniente verificar en un entorno de pruebas que la restricción de acceso a estos procedimientos no afecta a la funcionalidad.

Diversas verificaciones

-Verificar periódicamente los permisos de acceso a los procedimientos almacenados y los procedimientos almacenados ampliados por cuentas diferentes a “sa”:

El siguiente código realiza la verificación:

Use master

Select sysobjects.name

From sysobjects, sysprotects

Where sysprotects.uid = 0

AND xtype IN (‘X’,’P’)

AND sysobjects.id = sysprotects.id

Order by name

-Deshabilitar el acceso de invitado a las bases de datos.

Con el objetivo de prevenir el acceso no autorizado a los datos, el acceso deberá realizarse siempre mediante usuarios autenticados. Como excepción a esta regla debe indicarse que las bases de datos master y tempdb requieren la cuenta de usuario invitado.

-Deshabilitar SQL Mail.

Su utilización debe estar muy justificada y ser absolutamente imprescindible, ya que de estar activo estamos ofreciendo a un atacante potencial un nuevo mecanismo para la distribución de troyanos, virus o simplemente lanzar un ataque de denegación de servicio.

-Verificar en master..Sp_helpstartup la existencia de posibles troyanos.

Comprobar que nadie haya dejado una puerta trasera. Si hay alguna cosa rara podemos eliminarla con SP_unmakestartup.

-Verificar master..Sp_password la posible existencia de troyanos.

Comprobar los scripts de las máquinas de producción con los scripts originales para determinar que no se ha realizado ningún cambio no autorizado.

-Habilitar el registro de todos los accesos de usuario.

Para habilitarlo, como administrador de SQL, ejecutar esto en el Query Analyzer:

xp_instance_regwrite N’HKEY_LOCAL_MACHINE’, N’SOFTWAREMicrosoftMSSQLServerMSSQLServer’,N’AuditLevel’, REG_DWORD,3

(todo en una única línea)

-Establecer una tarea programada del sistema que ejecute:

findstr /C:”Login Failed” [vía acceso SQL]log*.*

Redireccionar la salida a un archivo y enviarlo por correo para poder monitorizar los intentos no satisfactorios de conexión.

-Auditar, de forma periódica, la posible existencia de cuentas sin contraseña.

El siguiente código realiza la verificación:

Use master

Select name,

Password

from syslogins

where password is null

order by name

-Siempre que sea posible, utilizar la modalidad de autenticación Windows

El uso de la modalidad de seguridad integrada facilita las tareas de administración ya que ésta se delega al sistema operativo. Asimismo evita que las cadenas de conexión incluyan la contraseña.