Configuración del servidor cPanel/Plesk: errores que abren puertas al malware

Configuración del servidor cPanel/Plesk: errores que abren puertas al malware

Cuando analizo servidores comprometidos en mi trabajo diario, descubro que la mayoría de los ataques no llegan porque el malware sea sofisticado, sino porque la configuración de cPanel o Plesk tiene fallos elementales. Estos paneles de control son el corazón de tu infraestructura web, y un error en su setup puede convertir tu servidor en puerta abierta para ciberdelincuentes.

En esta guía te muestro los errores de configuración más peligrosos que veo en la práctica, cómo detectarlos y, lo más importante, cómo blindar tu servidor antes de que sea demasiado tarde.

Por qué cPanel y Plesk son objetivos prioritarios del malware

cPanel y Plesk no son solo herramientas administrativas: son la llave maestra de tu servidor. Alojando decenas o cientos de sitios web, una sola vulnerabilidad o mala configuración puede comprometer toda tu infraestructura. Los atacantes lo saben, y por eso invierten recursos en escanear y explotar brechas en estos paneles.

He visto backdoors instalados en servidores cPanel mediante accesos débiles al WHM (Web Host Manager), cryptominers corriendo con permisos de root, y bases de datos de clientes completas exfiltradas porque nadie había deshabilitado el acceso remoto a MySQL.

Error 1: Contraseña débil o default en WHM/cPanel

Parece obvio, pero es el error número uno. Muchos proveedores de hosting entregan servidores con contraseñas generadas automáticamente que nunca se cambian, o peor, con patrones predecibles.

Lo que ocurre: Los atacantes ejecutan diccionarios contra puertos SSH (22), FTP (21) y WHM (2087/2096). Si tu contraseña es débil o default, el acceso es cuestión de minutos. Una vez dentro, instalan backdoors, webshells o malware de red.

Cómo detectarlo:

• Revisa los logs de acceso SSH: cat /var/log/auth.log | grep «Failed password». Si ves intentos fallidos masivos, alguien ya te está buscando.
• Comprueba los usuarios SSH en tu servidor: awk -F: ‘{print $1}’ /etc/passwd. ¿Hay usuarios que no reconoces?
• En WHM, accede a Security Center y verifica quién ha accedido recientemente.

Cómo remediarlo:

1. Cambia la contraseña root a una de 20+ caracteres: mayúsculas, minúsculas, números y símbolos especiales.
2. Usa passwd en terminal o genera una contraseña con openssl rand -base64 20.
3. En WHM, ve a Security Center → Password & Security → Change Root Password.
4. Documenta la nueva contraseña en un gestor de contraseñas seguro (Bitwarden, 1Password).

Error 2: SSH abierto a todo el mundo (sin restricción de IP)

SSH (puerto 22) es la puerta de entrada a tu servidor. Si está abierto a internet sin restricciones, recibirás miles de intentos de acceso cada día desde bots de todo el mundo.

Lo que ocurre: Incluso con contraseña fuerte, un atacante persistente puede probar millones de combinaciones. Además, pueden explotar vulnerabilidades zero-day en OpenSSH o en herramientas como Exim para ganar acceso.

Cómo detectarlo:

• Ejecuta netstat -tlnp | grep ssh o ss -tlnp | grep ssh. ¿SSH escucha en 0.0.0.0:22? Está abierto a todo el mundo.
• Comprueba el archivo /var/log/auth.log para ataques brute force: grep «sshd» /var/log/auth.log | wc -l.

Cómo remediarlo:

1. Cambia el puerto SSH a uno no estándar (ej: 2222): Edita /etc/ssh/sshd_config y cambia Port 22 a Port 2222.
2. Restringe SSH por IP: Si tienes una IP fija, añade en cPanel/WHM:
   • Ve a Security Center → IP Whitelist Manager
   • Whitelist tu IP corporativa y las de tu proveedor de hosting.
3. Usa firewalls de host: Instala CSF/LFD (ConfigServer Firewall) para limitar intentos de SSH y bloquear IPs maliciosas automáticamente.
4. Reinicia SSH: systemctl restart sshd

Error 3: Acceso remoto a MySQL/bases de datos habilitado

MySQL, PostgreSQL y otros servicios de base de datos están habilitados por defecto para conexiones locales. El problema: si habilitas acceso remoto (bind-address 0.0.0.0) sin firewall, cualquiera puede intentar conectarse desde internet.

Lo que ocurre: Los atacantes lanzan exploits contra MySQL (versiones antiguas tienen CVEs críticas). Si entran, acceden a todas las bases de datos: contraseñas WordPress hasheadas, datos de clientes, información de pagos.

Cómo detectarlo:

• Conecta por SSH y ejecuta: netstat -tlnp | grep mysql o ss -tlnp | grep mysql
• Si ves 0.0.0.0:3306, tu MySQL está abierto a internet.
• Intenta conectar desde fuera del servidor: mysql -h [TU_IP] -u root -p. Si funciona, estás en riesgo.

Cómo remediarlo:

1. Edita /etc/mysql/my.cnf o /etc/mysql/mysql.conf.d/mysqld.cnf
2. Busca bind-address y cambia a bind-address = 127.0.0.1 (solo localhost)
3. Guarda y reinicia: systemctl restart mysql
4. En cPanel/Plesk, desactiva Remote MySQL:
   • cPanel: WHM → Security Center → MySQL Remote Access → Disabled
   • Plesk: Tools & Settings → Server Management → MySQL → Remote Access Off
5. Si necesitas acceso remoto, usa SSH tunneling: ssh -L 3306:localhost:3306 root@tu_servidor

Error 4: FTP sin cifrar en lugar de SFTP

FTP transmite credenciales en texto plano. Cualquiera sniffeando la red ve tu usuario y contraseña. SFTP cifra todo el tráfico, pero muchos servidores aún usan FTP o lo tienen habilitado por defecto.

Lo que ocurre: Un atacante captura tus credenciales FTP, accede a todos los sitios web alojados, inyecta malware, crea backdoors, roba datos.

Cómo detectarlo:

• En cPanel/Plesk, comprueba qué servicios están activos: netstat -tlnp | grep -E «ftp|ssh»
• Si ves puerto 21 (FTP) abierto, estás usando FTP tradicional.

Cómo remediarlo:

1. Deshabilita FTP completamente:
   • cPanel: WHM → Service Manager → FTP → Stop & Disable
   • Plesk: Tools & Settings → Server Components → Deselecciona FTP
2. Usa SFTP (incluido con SSH):
   • Configurado por defecto en cPanel/Plesk. Solo necesitas conectar por SSH con credenciales.
   • Herramientas como FileZilla permiten SFTP fácilmente.
3. Reinicia: systemctl restart vsftpd (si es necesario)

Error 5: No actualizar cPanel/Plesk y sus componentes

cPanel y Plesk lanzan parches de seguridad regularmente. No actualizar es como dejar puertas abiertas con un cartel que dice «aquí hay vulnerabilidades conocidas».

Lo que ocurre: Atacantes aprovechan CVEs públicos en cPanel, Apache, PHP o Exim. Lanzan exploits masivos contra miles de servidores, sabiendo que muchos no se han parcheado.

Cómo detectarlo:

• En WHM, ve a Update Manager o Software Updates. ¿Hay actualizaciones pendientes?
• Ejecuta uname -a para ver tu versión de kernel. Compara con nvd.nist.gov o cisa.gov para CVEs conocidas.

Cómo remediarlo:

1. cPanel: WHM → Update Manager → Update. Elige «Auto Updates» para que se actualice automáticamente.
2. Plesk: Tools & Settings → Updates → Check for updates → Install.
3. Actualiza el kernel y servicios del sistema:
   • CentOS/RHEL: yum update -y
   • Debian/Ubuntu: apt update && apt upgrade -y
4. Reinicia después de actualizaciones del kernel: reboot
5. Establece un calendario de actualizaciones: la primera semana de cada mes.

Error 6: Permisos de archivo incorrectos en directorios públicos

Los permisos UNIX mal configurados permiten que procesos web escriban donde no deberían. Si tu directorio public_html tiene permisos 777, cualquier proceso comprometido puede crear archivos maliciosos.

Lo que ocurre: Un plugin WordPress vulnerabilizado, una aplicación con RFI/LFI, o un script comprometido escriben webshells, backdoors, malware de minería en tu servidor.

Cómo detectarlo:

• Busca directorios con permisos 777 o 666: find /home -type d -perm /700 -user nobody 2>/dev/null | head -20
• Comprueba permisos de public_html: ls -la /home/usuario/public_html | head. Debería ser 755 para directorios, 644 para archivos.

Cómo remediarlo:

1. En cPanel, configura permisos automáticos:
   • WHM → Security Center → Permissions → Set Default File/Directory Permissions
   • Files: 644, Directories: 755
2. Corrige permisos manuales (si es necesario):
   • find /home/usuario/public_html -type f -exec chmod 644 {} ;
   • find /home/usuario/public_html -type d -exec chmod 755 {} ;
3. Para WordPress específicamente:
   • wp-config.php: 600 (solo lectura para propietario)
   • .htaccess: 644
   • /wp-content/uploads: 755

Error 7: No monitorizar logs de seguridad

Los logs son tu línea de defensa. Si no los revisas regularmente, no sabes que estás siendo atacado hasta que es demasiado tarde.

Logs críticos que debes monitorizar:

• /var/log/auth.log – Intentos de login SSH/FTP
• /var/log/apache2/access.log o /var/log/httpd/access_log – Peticiones HTTP (inyecciones SQL, XSS, exploits web)
• /var/log/exim_mainlog – Email (spam, phishing)
• /var/log/cron – Tareas programadas (malware que intenta persistencia)
• Logs de cPanel/Plesk en /var/log/

Cómo detectarlo:

• ¿Últimamente revisaste manualmente tus logs? Si hace más de un mes, estás a ciegas.
• Busca patrones sospechosos: grep «SQL injection» /var/log/apache2/access.log | wc -l

Cómo remediarlo:

1. Instala un monitor de logs automático: CSF/LFD (ConfigServer Firewall) incluye alertas de seguridad.
   • Instala: cd /usr/src && wget https://download.configserver.com/csf.tgz && tar -xzf csf.tgz && cd csf && sh install.sh
   • Configura alertas en /etc/csf/csf.conf
2. Usa herramientas de SIEM: Fail2Ban, Logwatch, o servicios como Sumologic, Splunk.
3. Revisa logs semanalmente: Automatiza con script cron que envíe resumen a tu email.
4. En cPanel/Plesk: Activa alertas por email en Security Center.

Error 8: Módulos/extensiones de PHP inseguros

Módulos PHP como suhosin, exec(), system(), o extensiones desactualizadas pueden ser exploitadas para ejecutar comandos arbitrarios en el servidor.

Lo que ocurre: Un atacante inyecta PHP malicioso (vía plugin vulnerable o upload de archivo), y php.ini permite que se ejecuten comandos del sistema. El atacante crea backdoors, roba archivos, instala malware.

Cómo detectarlo:

• Crea un archivo test.php con <?php phpinfo(); ?> y cárgalo en public_html.
• Busca en la salida:
  • ¿disable_functions está vacío? Problema: todas las funciones están habilitadas.
  • ¿allow_url_fopen está «On»? Riesgo de RFI.
  • ¿magic_quotes_gpc está «Off»? (En PHP 7.x, no existe; en PHP 5.x, debería estar «On»)
• Lista módulos cargados: php -m o desde WHM/Plesk.

Cómo remediarlo:

1. Edita /etc/php.ini (o el archivo de configuración de tu versión de PHP):
   • disable_functions = exec,system,passthru,shell_exec,proc_open,proc_nice,popen,pcntl_exec,eval
   • allow_url_fopen = Off
   • open_basedir = /home/usuario/public_html:/tmp (aísla el acceso a directorios)
2. En cPanel/Plesk, deshabilita módulos innecesarios desde MultiPHP Manager.
3. Actualiza PHP a la última versión compatible con tus aplicaciones. No uses versiones EOL (End of Life).
4. Reinicia Apache/Nginx: systemctl restart apache2 o systemctl restart nginx

Error 9: Firewall desactivado o mal configurado

El firewall del servidor (iptables/nftables en Linux, o CSF/LFD en cPanel) es tu barrera contra ataques de red. Muchos administradores lo desactivan «temporalmente» y nunca lo vuelven a activar.

Lo que ocurre: Cualquier puerto está abierto a internet. Atacantes escanean tu servidor, descubren servicios vulnerables, y explotan.

Cómo detectarlo:

• Comprueba si el firewall está activo: systemctl status firewalld o systemctl status ufw o csf -l (para CSF)
• Lista puertos abiertos: netstat -tlnp o ss -tlnp. ¿Ves servicios innecesarios?

Cómo remediarlo:

1. Activa el firewall:
   • systemctl enable firewalld && systemctl start firewalld (Firewalld)
   • systemctl enable ufw && ufw enable (UFW)
   • csf -e (ConfigServer Firewall)
2. Configura reglas estrictas:
   • Abre solo puertos necesarios: 22 (SSH), 80 (HTTP), 443 (HTTPS), 25/587 (SMTP si es servidor de correo).
   • En cPanel: WHM → Security Center → Firewall Configuration → Add Firewall Whitelist Rules
3. CSF/LFD es recomendable: Incluye protección contra ataques brute force, DDoS, y tiene listas negras actualizadas.

Error 10: No realizar auditorías de seguridad periódicas

Una auditoría de seguridad no es un lujo: es mantenimiento preventivo. Cada 3-6 meses, deberías escanear tu servidor buscando malware, configuraciones débiles y vulnerabilidades.

Lo que ocurre: Los problemas se acumulan silenciosamente. Un plugin desactualizado aquí, una contraseña débil allá, permisos incorrectos en algún otro lado. De repente, descubres que tu servidor está comprometido desde hace meses.

Cómo detectarlo:

• ¿Cuándo fue la última vez que ejecutaste un scan de malware en tu servidor?
• ¿Tienes un registro de cambios en tu configuración de seguridad?
• ¿Revisaste recientemente qué usuarios tienen acceso root/SSH?

Cómo remediarlo:

1. Herramientas de escaneo automático:
   • Maldet (Linux Malware Detect): maldet -a /home para escanear archivos
   • ClamAV: Antivirus de código abierto. freshclam actualiza firmas, clamscan -r /home escanea.
   • Rootkit Hunter (rkhunter): Busca backdoors y rootkits. rkhunter –check
2. Auditoría manual:
   • Revisa usuarios con acceso root: grep «:0:0:» /etc/passwd
   • Busca cambios recientes en archivos del sistema: find /etc -mtime -7 (últimos 7 días)
   • Revisa tareas cron sospechosas: cat /var/spool/cron/crontabs/*
3. Cada mes: Ejecuta al menos un escaneo de malware.
4. Cada trimestre: Auditoría de permisos de archivos, usuarios, y configuración de servicios.

Plan de acción rápido: Checklist de seguridad cPanel/Plesk

Si acabas de leer esto y tienes miedo de tu servidor, aquí está la lista de acciones inmediatas (prioritarias):

1. HOY: Cambia contraseña root a una fuerte (20+ caracteres).
2. HOY: Comprueba logs SSH (/var/log/auth.log) buscando accesos desconocidos.
3. HOY: Deshabilita FTP, habilita solo SFTP.
4. ESTA SEMANA: Cambia puerto SSH a uno no estándar y restringe por IP.
5. ESTA SEMANA: Desactiva acceso remoto a MySQL. Bind-address a 127.0.0.1.
6. ESTA SEMANA: Activa firewall (CSF/LFD es ideal en cPanel).
7. ESTE MES: Actualiza cPanel/Plesk y todos sus componentes.
8. ESTE MES: Escanea servidor con Maldet, ClamAV, y rkhunter.
9. ESTE MES: Configura monitorización de logs automática (CSF/LFD o Fail2Ban).
10. CADA TRIMESTRE: Auditoría de seguridad completa.

Cuándo llamar a un experto: señales de alerta

Si detectas cualquiera de esto, tu servidor probablemente esté comprometido:

• Cientos de intentos fallidos de login en los logs.
• Procesos desconocidos ejecutándose (ej: minero, bot de spam).
• Archivos nuevos que no creaste en public_html o /tmp.
• Tu servidor enviando spam o malware a otros sitios (ISP te avisa).
• Rendimiento muy bajo sin razón aparente (CPU/RAM al máximo).
• Cambios en archivos de sistema que no autorizaste.
• Google Search Console reporta malware en tu sitio.

En estos casos, no intentes «limpiar» tú solo. Un error puede empeorar las cosas o dejar puertas traseras abiertas. Lo recomendable es contactar con un especialista en ciberseguridad que pueda:

• Analizar logs forenses para determinar cómo entró el atacante.
• Identificar y eliminar todo el malware sin dejar rastros.
• Cerrar la vulnerabilidad explotada.
• Recuperar tus datos si han sido robados.
• Aplicar hardening completo para evitar que vuelva a ocurrir.

En ManuelFolgar.com, nos especializamos en limpieza de malware, auditorías de seguridad y hardening de servidores cPanel/Plesk. Si tu servidor ha sido comprometido o quieres blindarlo antes de que lo sea, contacta con nosotros para una auditoría de seguridad profesional. Analizo tu infraestructura completa, identifico riesgos y aplico soluciones probadas.

La seguridad del servidor no es una tarea de una vez: es un proceso continuo. Pero si empiezas con estos diez errores evitados, habrás cerrado la mayoría de puertas por las que entra el malware. Tu servidor, y los datos de tus clientes, te lo agradecerán.