Conceptos de seguridad básicos
Para la versión 11.28 de WHM
Ataques de Cross-site Request Forgery (XSRF)
Los
cross-site request forgeries (falsificaciones de petición en sitios cruzados, conocidos como XSRF) ocurren cuando un usuario malicioso explota la confianza entre un sitio web y el navegador de un usuario. Al explotar esa confianza, los usuarios maliciosos pueden ejecutar comandos no autorizados en un sitio web.
Los ataques XSRF cuentan con dos puntos:
- Acceso a los credenciales de autenticación
- La ejecución encubierta de un comando por medio de un URL
Para más información sobre ataques XSRF, al igual que algunos ejemplos, puede visitar
esta página de Wikipedia.
Métodos de autenticación
Le recomendamos que use un método de autenticación con
cookies para los inicios de sesión de cPanel y WHM. La autenticación HTTP no saldrá de una sesión autenticada a menos que la sesión de la aplicación del navegador web se termine. Si se usa una autenticación HTTP, las credenciales de inicio de sesión se almacenan en caché por el navegador hasta que se termina la aplicación. Algunos navegadores permiten usar un método para eliminar las credenciales, pero este método no es fiable o no está disponible en todos los navegadores. Cuando un navegador almacena en caché las credenciales de inicio de sesión, son vulnerables a un ataque de XSRF.
Debido a las debilidades inherentes de la autenticación HTTP, recomendamos que la desactive en WHM.
Para más información, por favor lea nuestra documentación sobre
autorización HTTP (en inglés).
Cookies (galletas) validadas
Los usuarios maliciosos pueden robarse las
cookies usadas en ataques XSRF. La mayoría de los navegadores no proveen alguna protección para mitigar el ataque. Por eso le proveemos una opción que le permite validar la dirección de IP de origen como parte de la
cookie durante la autenticación. En las solicitudes de autenticación posteriores, las direccciones de IP se comparan a los valores originales en sus
cookies. Un valor que no coincide causa un error y resultará en una nueva solicitud de autenticación.
Cuando usa
cookies validadas, es importante recordar que debe desactivar el acceso de intermediario (
proxy). El acceder interfaces mediante un dominio intermediario causará que se grabe la dirección de IP del anfitrión local (usualmente
127.0.0.1), lo que hace inutilizable la validación de IP.
Para desactivar los subdominios intermediarios:
- Acceda a la interfaz Tweak Settings de WHM (Main >> Server Configuration >> Tweak Settings).
- Bajo la pestaña Domains en esta interfaz, cambie las siguientes dos opciones a Off:
- Proxy subdomains
- Proxy subdomain creation
- Pulse Save para guardar.
Requerir SSL
El requerir que sus usuarios entren al sistema con SSL o TLS es una manera básica de mejorar la seguridad de su sistema. Si los usuarios no usan SSL/TLS (pero usan una conexión insegura por medio de los puertos 2082, 2086 ó 2095), entonces las credenciales de autenticación se envía en texto sin formato, lo que facilita que puedan ser robadas, leídas y se usen de nuevo posteriormente. Desde cPanel 11.25 en adelante, usted puede desactivar las entradas por los puertos 2082, 2086 y 2095, lo que obliga a sus usuarios a usar conexiones seguras (SSL/TLS). Una vez que usted haya activado esta opción en la interfaz
Tweak Settings de WHM, los usuarios que traten de usar los puertos 2082, 2086 y 2095 verán una página que los redirigirán al puerto correcto (protegido).
Tokens de seguridad
Además de los métodos mencionados anteriormente, cPanel también ha incluido
tokens para ayudar a combatir ataques XSRF. Los
tokens se insertan en el URL y son únicos a una sola sesión de entrada. Las solicitudes pedidas sin el
token apropiado producen un error y resultan en una solicitud de reautenticación. Esta acción desbarata efectivamente los ataques porque el URL agresor no tendrá el
token apropiado.
Advertencia: Los
tokens de seguridad pueden causar problemas con los
scripts personalizados y algunas aplicaciones de terceros que se integran con cPanel y WHM. Le recomendamos que verifique que las aplicaciones de terceros sean compatibles con los
tokens de seguridad antes de activarlas. Si usted debe usar aplicaciones que no son compatibles con los
tokens de seguridad, le recomendamos que use las verificaciones de
referrer de URL.
Verificaciones de referrer de URL
Le recomendamos enfáticamente que use
tokens de seguridad en vez de verificaciones de
referrer. Sólo se puede contar con las verificaciones de
referrer cuando se activa la verificación de
referrer en blanco y el activarla resulta en un número inaceptable de falsos positivos. Sin embargo, las verificaciones de
referrer se pueden usar en vez de
tokens de seguridad si usted debe usar aplicaciones de terceros que no son compatibles con los
tokens de seguridad. El
referrer de HTTP (escrito comúnmente como
referer) identifica el URL de la página de origen de un usuario.
Si no es posible usar
tokens de seguridad en su servidor, le recomendamos que active las siguientes dos opciones en su interfaz
Tweak Settings:
- Blank referrer safety check
- Referrer safety check
Intensidad de la contraseña
Las contraseñas débiles proveen poca protección contra ataques de fuerza bruta. Estos ataques ocurren cuando un usuario malicioso trata de adivinar, por prueba y error, la contraseña de una cuenta en específico. Este proceso usualmente está automatizado, que corre de un diccionario preexistente. WHM provee una interfaz que le permite a usted especificar la fortaleza mínima de contraseña que sus usuarios de cPanel podrán usar. Le recomendamos enfáticamente que use un valor de
50 o mayor.
El requisito de fortaleza mínima de contraseña solamente aplica a las contraseñas creadas y modificadas por el producto cPanel. La característica no configura PAM para cumplir los requerimientos. Por lo tanto, un usuario con acceso
shell podrá cambiar su contraseña a una más débil con el comando
passwd.