Mejores prácticas de seguridad del servidor de Windows

EXENCIÓN DE RESPONSABILIDAD PARA CLIENTES DE OPERACIONES GESTIONADAS

Para garantizar que Rackspace tenga acceso a su servidor cuando sea necesario, le solicitamos que no cambie las siguientes configuraciones ya que considera las mejores prácticas de seguridad:

Al conectarse a su servidor, Rackspace Support inicia sesión como el usuario rack mediante la conexión de escritorio remoto a la dirección IP pública a través del puerto 3389.
La reconstrucción de servidores existentes o la creación de un nuevo servidor a partir de una instantánea requiere que los inicios de sesión del administrador estén habilitados y que el puerto 445 no esté bloqueado en el firewall de Microsoft® Windows®.

Si debe cambiar estos valores, comuníquese con un administrador de Rackspace para realizar los cambios de una manera que no afecte nuestra capacidad de brindarle una Fanatical Experience ®.

Este artículo proporciona algunas de las mejores prácticas generales de seguridad que se deben tener en cuenta al configurar un servidor de Microsoft Windows que interactúa con la Internet pública. Si bien estas prácticas recomendadas se aplican a cualquier servidor en general, este artículo aborda específicamente los servidores en la nube de RackspacePublic que ejecutan Windows.

Usar reglas de cortafuegos locales

De forma predeterminada, los servidores de nube pública de Rackspace no tienen un dispositivo de firewall. Para los servidores que interactúan con la Internet pública sin un dispositivo de firewall, el firewall de Windows es la única protección entre los recursos de su servidor y sus datos privados y cualquier persona con acceso a una conexión a Internet.

Deshabilite tantas reglas en el firewall como sea posible. Deshabilitar las reglas significa que hay menos puertos abiertos y escuchando a través de la interfaz pública, lo que limita la exposición del servidor a cualquiera que intente acceder a él.

Para aquellos puertos que deben estar abiertos, limite el acceso al servidor al incluir direcciones IP en la lista blanca en esas reglas específicas. Agregue la dirección IP de la computadora local de su hogar u oficina a la lista blanca, incluso si su proveedor de servicios de Internet (ISP) proporciona direcciones IP públicas dinámicas que cambian con el tiempo. Puede realizar cambios en las reglas del cortafuegos según sea necesario desde el Panel de control de la nube iniciando sesión en el servidor de forma remota a través de la consola y agregando una nueva dirección IP.

Al limitar el acceso al servidor a través de la lista blanca de direcciones IP, puede asegurarse de que los usuarios que necesitan acceso al servidor lo tengan, pero aquellos que no lo necesitan están bloqueados de esos puertos abiertos. Los puertos más típicos que deben estar abiertos en el firewall de Windows para alojamiento web en un servidor en la nube son los siguientes:

Puerto	Servicio
80 HTTP	Sitios IIS o aplicación web
443 HTTPS	Aplicaciones web o sitios IIS seguros con SSL

Recomendamos bloquear los siguientes puertos a través de la lista blanca de direcciones IP en la interfaz pública para limitar los ataques de fuerza bruta o los intentos de explotación contra cuentas o servicios con nombres comunes en el servidor:

Puerto	Descripción
3389	Conectividad de escritorio remoto, para iniciar sesión de forma remota en el servidor
21 FTP	Para la transferencia segura de datos entre ubicaciones geográficas locales y el servidor en la nube
990 FTPS (Windows)	Para la transferencia segura de datos entre ubicaciones geográficas locales y el servidor en la nube incorporando un certificado SSL
5000-5050 FTP	Puertos pasivos para comunicación FTP
1433 SQL	Puerto predeterminado utilizado para la comunicación SQL
53 DNS	Puerto predeterminado utilizado para solicitudes de DNS

Considere qué datos están disponibles para otros a través del intercambio de archivos. No recomendamos habilitar el uso compartido de archivos de Windows porque los puertos abiertos en el firewall (puertos 445 y 139) exponen el servidor a intentos de conexión no deseados.

Algunos clientes usan sus servidores para hospedar software administrativo como QuickBooks®, PeachTree, Microsoft Office® (Outlook® para sesiones de escritorio remoto) u otras soluciones de software de terceros. A veces, los clientes desean configurar unidades de red mapeadas para permitirles mover datos fácilmente desde sus computadoras locales a su servidor en la nube por medio de una letra de unidad en la computadora local. Sin embargo, no recomendamos esta práctica. Su servidor es tan seguro como la contraseña más débil.

Además, tenga cuidado con el software que permite que sus usuarios descarguen e instalen en su servidor. Cada paquete de software instalado aumenta la exposición de su servidor a los ataques.

Política de contraseñas

Ya sea que haya aprovisionado o no un servidor en la nube con un firewall de hardware, como se indicó anteriormente, su servidor es tan seguro como la contraseña más débil que tiene acceso a él. Siga estos consejos para las contraseñas:

Utilice contraseñas seguras de al menos 12 a 14 caracteres que incluyan letras mayúsculas y minúsculas, números y caracteres especiales (como !, #, $ y %). Asignar contraseñas simples es extremadamente peligroso, especialmente para un servidor en la nube que está disponible a través de la Internet pública.
Establezca una fecha de caducidad para la contraseña de cada usuario. Aunque es un inconveniente tener que recordar una nueva contraseña periódicamente, esta práctica puede hacer que sus datos estén más seguros.

Debido a que nuestros procesos de automatización posteriores a la compilación dependen de la cuenta de usuario predeterminada del Administrador, no recomendamos cambiar este nombre de usuario en sus servidores en la nube que ejecutan Windows.

Tenga cuidado con quién tiene acceso al servidor a través de la cuenta de Administrador. Si varios usuarios necesitan acceso de administrador al servidor, cree varias cuentas con acceso de administrador. Es más fácil realizar un seguimiento de los usuarios en los archivos de registro buscando una cuenta de usuario específica que intentar descifrar varias entradas del archivo de registro en la cuenta de administrador.

Múltiples instancias de Event Id 4625 en el registro de seguridad o Event Id 1012 en SystemLog puede significar que alguien está tratando de piratear su servidor porque estos eventos están relacionados con intentos fallidos de inicio de sesión.

Para los usuarios que inician sesión a través de Conexión a escritorio remoto (RDC), asegúrese de que cierran sesión en el servidor para liberar los recursos usados en lugar de simplemente cerrar sus ventanas de RDC, lo que deja la sesión abierta en el servidor.

Directorio Activo

Por lo general, desaconsejamos ejecutar Active Directory en un servidor en la nube porque la única protección contra intrusiones es el firewall de Windows, y Active Directory introduce problemas en un entorno de servidor en la nube. Por lo general, Active Directory se usa mejor en un entorno de servidor dedicado donde los servidores se ubican detrás de firewalls físicos y se conectan a través de túneles VPN a través de ese dispositivo de firewall.

Rackspace admite una red privada virtual (VPN) solo si es a través de un firewall de hardware en una solución llamada RackConnect. Es más fácil implementar esta configuración de firewall físico antes de crear servidores porque, en el momento en que se escribió este artículo, el proceso que conecta el firewall y los servidores está automatizado durante el proceso de creación. Los firewalls físicos no se aprovisionan tan rápido como los servidores en la nube y deben solicitarse a través de nuestros equipos híbridos. Para obtener más información sobre firewalls físicos y RackConnect, consulte https://www.rackspace.com/cloud-connectivity/rackconnect/.

Si instala Active Directory en un servidor en la nube, le recomendamos que ejecute dos controladores de dominio en caso de que uno falle (las imágenes no están disponibles actualmente para los controladores de dominio). También recomendamos bloquear DNS para evitar ataques de amplificación de DNS.

Instancias de SQL Server

Para servidores que ejecutan Microsoft SQL Server®, bloquee el puerto SQL 1433 para escuchar solo a través de la interfaz interna, preferiblemente escuchando solo las conexiones de una lista de direcciones IP conocidas de otros servidores que necesitan acceder a SQL Server en el servidor. Puede permitir que el puerto SQL 1433 escuche a través de la interfaz pública, pero debe limitar esta regla a solo las direcciones IP de las computadoras donde los desarrolladores se conectan a las bases de datos en el servidor.

Si no limita estas conexiones al servidor, el puerto 1433 queda expuesto y los piratas informáticos externos lo harán. intente un ataque de fuerza bruta en el servidor a través de este puerto. Estos tipos de ataques provocan un alto tráfico en la red, ralentizan el rendimiento del servidor e incluso provocan caídas de los sitios si se bloquea una cuenta importante. Al limitar el acceso a este puerto, mitigará estos problemas antes de que comiencen.

Para los servidores que ejecutan las ediciones SQL Server Standard o SQL Server Web, recomendamos configurar planes de mantenimiento para volcar los datos de los archivos de la base de datos activa en archivos sin formato de los que puede hacer una copia de seguridad fuera del servidor y limpiar las copias de seguridad para que no llenen su disco duro.

Actualizaciones de Windows

Asegúrese de que las actualizaciones de Windows estén habilitadas y tenga en cuenta el estado de su servidor:asegúrese de que su sistema operativo (SO) de Windows esté parcheado. El martes de parches, que tiene lugar el segundo martes de cada mes en América del Norte, es el día en el que Microsoft lanza regularmente parches de seguridad. Los clientes deben decidir cuál es la mejor manera de implementar una estrategia de aplicación de parches que mantenga sus servidores actualizados. De manera predeterminada, los servidores en la nube de Rackspace buscan actualizaciones entre las 2 a. m. y las 4 a. m. todos los días.

Copias de seguridad del servidor

Establezca algún tipo de plan de recuperación ante desastres. Una opción que ofrecemos es crear imágenes de servidor en la nube todas las noches y escribirlas en sus contenedores de archivos en la nube con una retención predeterminada de siete días. Toma una instantánea del servidor y almacena la imagen en Cloud Files para usarla en la creación de nuevas instancias de servidor o la reconstrucción del servidor existente a partir de esa imagen.

También ofrecemos copias de seguridad a nivel de archivos a través de Cloud Backups. No recomendamos hacer una copia de seguridad de todo C: porque los archivos en vivo que están bloqueados hacen que el trabajo de copia de seguridad se complete con errores. Además, los archivos del sistema de Windows están contenidos en las imágenes base proporcionadas por nosotros o en las imágenes personalizadas tomadas de los servidores, por lo que no necesita hacer una copia de seguridad de esos datos a diario. Recomendamos hacer una copia de seguridad del C :\inetpub (IIS) y cualquier otro dato de usuario que deba respaldarse. Además, si configuró los planes de mantenimiento de SQL Server para volcar los datos en vivo en archivos planos para las copias de seguridad, le recomendamos que también incluya esos directorios en la copia de seguridad.

Verifique los trabajos de respaldo para asegurarse de que se completen correctamente y que los respaldos sean válidos. Cree una nueva instancia de servidor a partir de una imagen para asegurarse de que la imagen sea válida y restaure un archivo desde las copias de seguridad en la nube para verificar que los datos respaldados estén restaurados.

Nota :No todos los servidores pueden beneficiarse de Cloud Images. Específicamente, no puede crear imágenes de servidores que usen Arrancar desde volumen configuraciones Además, si bien una imagen de servidor puede ser útil, las imágenes nunca deben considerarse la única fuente de respaldo porque el proceso de imagen no verifica la integridad del archivo. Rackspace recomienda encarecidamente realizar copias de seguridad a nivel de archivo para sus datos más importantes. Por lo tanto, debe considerar la mejor solución de recuperación ante desastres para su empresa. Puede revisar las diferencias entre las imágenes del servidor y la copia de seguridad en la nube en este artículo:Copia de seguridad en la nube de Rackspace frente a copias de seguridad de imagen del servidor en la nube

Código

La última superficie de ataque expuesta a Internet es el código. Usted y sus desarrolladores deben asegurarse de que su código aplique la autenticación y autorización adecuadas. Por ejemplo, no debe permitir que se ejecute una aplicación web con privilegios de nivel de administrador. La autorización del archivo debe definirse cuidadosamente y todas las entradas en la aplicación deben tener la mejor validación posible para evitar que los piratas informáticos exploten la aplicación web y obtengan el control del servidor.

Los siguientes sitios brindan información sobre cómo mejorar la seguridad de ASP.NET:

https://www.asp.net/web-forms/pluralsight

https://www.iis.net/configreference/system.webserver/security/requestfiltering

https://blogs.iis.net/wadeh/archive/2008/12/18/filtering-for-sql-injection-on-iis-7-and-later.aspx

Conclusión

Según el caso de uso, los clientes pueden tener otras necesidades más específicas que abordar al aprovechar nuestro servicio de servidores en la nube para satisfacer sus necesidades de alojamiento. Sin embargo, estas recomendaciones generales son un buen comienzo cuando se considera la seguridad al crear servidores Windows, en la nube o de otro modo.