Novedades del Service Pack 2 La llegada del SP2 de Windows XP ha incluido novedades en los siguientes grupos de categorías: • Protección de la red. • Protección de la memoria. • Manipulación segura del correo electrónico. • Mejora de la seguridad en la navegación. • Mantenimiento mejorado de los ordenadores.

Se puede obtener información completa del SP2 de la web de Microsoft http://www.microsoft.com/spain/ technet/recursos/wxpsp2; además, si se quiere conocer en más profundidad cada uno de los cambios y novedades se puede descargar un documento de 175 páginas muy detallado en http://www.microsoft.com/spain /technet/recursos/wxpsp2/mejoras. En éste artículo se van a analizar las novedades que afectan al funcionamiento de SQL Server enumerando los cambios que afectan a nivel de protección de red que tienen relación con SQL Server. Servicios Alerter y Messenger Alerter y Messenger son servicios que sirven para generar alertas administrativas y enviar mensajes entre ordenadores de una red; en versiones anteriores a SP2, el servicio Messenger estaba configurado para iniciarse automáticamente y el servicio Alerter de modo manual; cuando alguno de estos servicios se encontraba activado, el sistema operativo permitía conexiones entrantes a la red que suponía un riesgo de seguridad. Después de instalar el SP2 estos dos servicios están deshabilitados por defecto. Si se necesita hacer uso de ellos deberán arrancarse de manera explícita. Windows Firewall Windows Firewall (WF) gestiona las peticiones de red que se reciben. En el SP2 se ha mejorado y sufrido modificaciones, por defecto está habilitado, y no permite conexiones entrantes no solicitadas mediante TCP/IP; ¿qué quiere decir esto? que todas las peticiones TCP/IP que se reciban, WF las "observa" y decide qué hacer con ellas: • Aceptarlas en función de ciertas excepciones definidas (veremos cómo configurarlas). • Rechazarlas en función de las mismas excepciones.

Para entender cómo actúa WF vamos a suponer que es una entidad externa que se encuentra a medio camino entre la red y el PC; cuando decide aceptar la petición TCP/IP se la pasa al PC y cuando decide rechazarla, la elimina; así de simple: WF se encarga de permitir que una petición TCP/IP "llegue" al PC o no. Y ¿de qué forma WF gestiona los permisos para las peticiones TCP/IP? Para ello WF gestionará una lista de excepciones que será del siguiente tipo: • Excepciones de programa: cuando WF recibe una petición TCP/IP, comprueba cuál es la aplicación destinataria de la petición; si la aplicación destinataria está en la lista de "excepciones de programa", WF acepta que la petición llegue al PC. • Excepciones de puertos: cuando WF recibe una petición TCP/IP comprueba cuál es el puerto TCP o UDP al que va dirigida la petición y en función de la lista de excepciones de puertos acepta o rechaza la petición.

A su vez, dependiendo de la procedencia de la petición, las excepciones se pueden configurar en función de: • Cualquier origen (Acceso global). Petición recibida desde cualquier origen (Internet o Intranet); • Subred local. • Lista personalizada. Lista de direcciones IP.

La configuración por defecto de WF es la siguiente: • Deshabilita (rechaza) todas las peticiones recibidas por TCP y UDP. • Habilita (acepta) "File and Printer Sharing" (compartición de ficheros e impresoras). • Habilita "Message Queuing" (MSMQ). • Habilita "Remote Asistance" (asistencia remota).

Para acceder a la configuración de WF se accede de la misma forma que en versiones anteriores (figura 1). La pestaña general de WF nos permitirá configurarlo para dos estados distintos (figura 2): • Habilitado (On). Dentro de la opción habilitado podemos configurarlo para que WF no nos informe de cuando bloquea peticiones recibidas no permitidas. • Deshabilitado (Off).

Para programar la excepciones usaremos la pestaña "Exceptions" (figura 3) donde en las excepciones de aplicación pulsaremos en el botón "Add Program" seleccionando la aplicación que queremos añadir a la lista de las excepciones (figura 4) y desde el botón "Change Scope" estableceremos la procedencia de la petición (figura 5) para programar la excepción usaremos la pestaña "Exceptions" (figura 3). Por otra parte, para las excepciones de puertos pulsaremos en el botón "Add Ports" donde pondremos nombre a la excepción que vamos a crear, definiremos el número de puerto y protocolo (figura 6) y desde el botón "Change Scope" estableceremos la procedencia de la petición (figura 5) donde en las excepciones de aplicación seleccionaremos "Add Program" (añadir programa) seleccionando la aplicación que queremos añadir a la lista de las excepciones (figura 4) y desde el botón "Change Scope" estableceremos la procedencia de la petición (figura 5). En qué afecta a SQL Server Para poder atender peticiones (sentencia TSQL desde el analizador de consultas, operaciones desde el administrador corporativo, aplicaciones que usan como origen de datos SQL Server, consultas desde otros servidores: servidores vinculados, operaciones de replicación, etc.) SQL Server necesita hacer uso de protocolos de red como TCP/IP, multi-protocolo (RPC), Named Pipes (canalización por nombres), Shared Memory (memoria compartida), etc. Hemos visto que WF se encarga de permitir o denegar las peticiones a través de alguno de estos protocolos, por lo que deberemos tener claro cuales son los protocolos de conexión que usa SQL Server para poder habilitarlos en WF. De los protocolos que usa SQL Server, se verán afectados TCP/IP, multi-protocolo (RPC) y Named Pipes. Vamos a ver cual es la configuración por defecto de las instalaciones de: • SQL Server 7.0 (y MSDE 1.0) • SQL Server 2000 (y MSDE 2000) - SQL Server Analysis Services 2000 - SQL Server Reporting Services SQL Server 7.0, MSDE 1.0 y SQL Server 2000 "Instancia por defecto" SQL Server escucha por defecto por el puerto TCP 1433; durante el proceso de instalación se puede cambiar la configuración del puerto por el que escucha, o una vez instalado se puede cambiar desde "Server Networking Utility" (en MSDE no se instala la entrada en el menú de SQL Server; en su lugar la tendremos en Windows\system32\srvnetcn.exe); si cambiamos el puerto por el que escucha SQL Server con "Server Networking Utility", para que el cambio tenga efecto, deberemos reiniciar el servicio de SQL Server. Durante la instalación también se habilitan las conexiones Named Pipes, multi-protocolo (RPC) y Shared Memory. ¿Cómo habilitar las peticiones de red en SQL Server? • Si las conexiones a SQL Server se realizan desde la misma máquina, no debemos hacer ninguna modificación porque las conexiones se realizan a través de protocolo Shared Memory que no hace uso de protocolos de red. • Si las conexiones a SQL Server se hacen desde otra máquina: - Si se conecta a través de TCP, deberemos habilitar el puerto TCP que tenemos configurado para SQL Server (por defecto TCP 1433). - Si se conecta a través Named Pipes o multi-protocolo a través de Named Pipes, deberemos habilitar la excepción "File and Printer Sharing" (compartición de ficheros e impresoras); también se puede habilitar a través del puerto TCP 445. El método más aconsejable es habilitar los puertos por los que sabemos que se realizarán las peticiones a SQL Server; también podemos habilitar en la lista de excepciones la aplicación (servicio) de SQL Server, pero haciéndolo de esta forma, habilitamos las peticiones TCP o UDP a cualquier puerto. SQL Server 2000 "Instancia con nombre" En una instalación por defecto, el puerto por el que escucha SQL Server es dinámico; de esta forma la única forma de habilitar peticiones de red a las instancias de SQL Server será añadir la aplicación a la lista de excepciones; como recomendación general deberíamos establecer que cada instancia escuche por un puerto específico y añadiendo el puerto a la lista de excepciones (como hemos visto anteriormente, la configuración del puerto por el que escucha SQL Server se puede cambiar con "Server Networking Utility"). SQL Server 2000 y SQLDTC El coordinador de transacciones distribuidas, gestiona las transacciones a través del puerto TCP 135; para habilitarlas, deberemos añadir la aplicación que gestiona las transacciones distribuidas (generalmente c:\Windows\System32\msdtc.exe) a la lista de excepciones de aplicaciones y el puerto TCP 135 a la lista de excepciones de puertos; la necesidad del puerto TCP 135 se debe a que SQLDTC utiliza RPC (llamadas a procedimientos remotos). SQLXML (en SQL Server 2000) SQLXML realiza las peticiones a través de IIS por lo que deberíamos habilitar los puertos TCP 80 para HTTP y TCP 443 para HTTPS (SSL). SQL Server Analysis Services 2000 SQL Analysis Services 2000 escucha por el puerto TCP 2725; si se usan aplicaciones cliente con versiones de MDAC anteriores a la 2.6, los puertos usados son: TCP 2393 y TCP 2394. Si se permite el acceso a través de HTTP o HTTPS habrá que habilitar los puertos TCP 80 (para HTTP) y/o 443 (para HTTPS). SQL Server Reporting Services (en SQL Server 2000) SQL Reporting Services es una aplicación que usa IIS; por defecto escucha por el puerto TCP 443 ( HTTPS); también se puede configurar para que escuche a través de HTTP (puerto TCP 80); si usamos el proveedor WMI para administración remota (rsconfig) también deberemos habilitar el puerto TCP 135. SQL Server Agent Es frecuente que al programar tareas de SQL Server, el estado de finalización de la tarea se envíe a través de Net Send; como hemos visto antes, el servicio Messenger (que es el que se encarga de enviar los mensajes) está deshabilitado; tenemos dos soluciones posibles: • Habilitar el uso de Net Send iniciando el servicio messenger tanto en el servidor como en el cliente. • Reprogramar las tareas para que utilicen otro mecanismo de notificación (por ejemplo: xp_sendmail).