Preguntas Frecuentes

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 & 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 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  IP del anfitrión local (usualmente127.0.0.1), lo que hace la validación de dirección IP inútil.

Para desactivar los subdominios intermediarios:

1. Acceda a la interfaz Tweak Settings de WHM (Home >> Server Configuration >> Tweak Settings).
2. Bajo la pestaña Domains en esta interfaz, cambie las siguientes dos opciones a Off:
   • Proxy subdomains
   • Proxy subdomain creation
3. 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á 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 & 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.