Tal como evidenció el gusano SQL-Slammer hace tan sólo unos pocos días,
un gran número de máquinas eran vulnerables ante los problemas de
seguridad.
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
diez minutos de vida consiguió afectar al 90% 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.
* Verificar que están instalados 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.
* 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’SOFTWARE\Microsoft\MSSQLServer\MSSQLServer’,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.
xavi@hispasec.com
Más información:
Analysis of the Sapphire Worm – The Spread of the Sappphire/Slammer Worm
http://www.caida.org/analysis/security/sapphire/
una-al-día (27-01-2003): Lecciones del gusano MS-SQL
http://www.hispasec.com/unaaldia.asp?id=1555
una-al-día (26-01-2003): Alerta: Gusano para MS-SQL
http://www.hispasec.com/unaaldia.asp?id=1554
SQLSecurity Checklist
http://www.sqlsecurity.com/DesktopDefault.aspx?tabindex=3&tabid=4
Lockdown Script Project
http://www.sqlsecurity.com/DesktopDefault.aspx?tabindex=4&tabid=12
Securing SQL Server 2000
http://www.microsoft.com/sql/techinfo/administration/2000/security/securingsqlserver.asp
Auditing SQL Server Activity
http://msdn.microsoft.com/library/en-us/adminsql/ad_security_2ard.asp
SQL Server 2000 Operation Guide – Security Administration
http://www.microsoft.com/technet/prodtechnol/sql/maintain/operate/opsguide/sqlops3.asp
Deja un comentario