WordPress es seguro por diseño. Lo que no es seguro es lo que le agregamos encima: themes copiados, plugins nulled, usuarios “admin”, passwords reusados, wp-config abierto, backups ausentes. La mayoría de los hackeos a pymes que he auditado tenían 2-3 de esas causas.

Este checklist cubre los 14 puntos que frenan la gran mayoría de los ataques automatizados (bots), que son casi todo el tráfico malicioso que recibe tu sitio. Todos gratuitos, todos implementables en una tarde.

Bloque 01 · Configuración de wp-config.php

1 · Cambiar las claves SALT

WordPress usa 8 claves criptográficas (SALTs) para cifrar cookies de sesión. Si alguna vez un developer copió wp-config.php de otro sitio, tu SALT podría ser conocido. Regenéralas:

Ve a api.wordpress.org/secret-key/1.1/salt/, copia las 8 líneas, reemplaza en wp-config.php. Cerrará todas las sesiones activas — aviso a los usuarios.

2 · Prefijo de tablas distinto a wp_

Cambiar wp_ a algo único (ej: smx_a3k_) dificulta ataques SQL injection automatizados que asumen el prefijo estándar. Se configura en wp-config.php $table_prefix = 'smx_a3k_';.

Cuidado: cambiarlo post-instalación requiere migrar la BD. Hazlo desde el inicio del proyecto o con backup completo a mano.

3 · Deshabilitar el editor de archivos vía dashboard

Agrega en wp-config.php:

define('DISALLOW_FILE_EDIT', true);

Esto impide que un atacante con acceso al admin pueda editar tu functions.php directamente desde el dashboard e inyectar código. Fundamental.

4 · Forzar HTTPS y cookies seguras

En wp-config.php:

  • define('FORCE_SSL_ADMIN', true);
  • define('COOKIE_DOMAIN', 'tudominio.cl');

Bloque 02 · Usuarios y autenticación

5 · Nunca usar “admin” como usuario

El username “admin” es el objetivo #1 de ataques de fuerza bruta. Si tu instalación tiene ese usuario:

  1. Crea un usuario nuevo con rol Administrador y nombre único (ej: “smx_tomas”).
  2. Ingresa con el nuevo usuario.
  3. Ve a Users y elimina “admin”, asignando sus posts al usuario nuevo.

6 · Passwords fuertes + 2FA obligatorio

Password mínimo: 16 caracteres mixtos. Usa un administrador de passwords (1Password, Bitwarden). 2FA: el plugin oficial gratuito de Google Authenticator o WP 2FA (free).

7 · Limitar intentos de login

Plugin gratuito: Limit Login Attempts Reloaded. Configuración:

  • Intentos permitidos: 4.
  • Bloqueo: 60 minutos tras 4 fallidos.
  • Bloqueo largo: 24 horas tras 4 bloqueos.
  • Notificación email al admin en bloqueos.

8 · Cambiar URL de login

La mayor parte del tráfico malicioso a WordPress golpea /wp-admin y /wp-login.php. Cambiar la URL (ej: /tu-dominio.cl/acceso-smx) reduce el ruido dramáticamente.

Plugin gratuito: WPS Hide Login. 2 minutos de configuración.

Bloque 03 · Updates y backups

9 · Core, themes, plugins siempre actualizados

La mayoría de los hackeos explotan vulnerabilidades conocidas con parche disponible. Activa updates automáticos para:

  • Core menor automático (ya viene por defecto desde WP 3.7).
  • Core mayor: configurar en wp-config.php define('WP_AUTO_UPDATE_CORE', true);.
  • Themes y plugins: activar “Enable auto-updates” individualmente (en dashboard).

Excepción: si tu sitio es misión-crítica, prefiere review manual semanal antes del update. Pero updatear, sí o sí, cada 7 días máximo.

10 · Backups automáticos off-site

Plugin gratuito: UpdraftPlus. Configuración:

  • BD: diario, retención 7 copias.
  • Archivos: semanal, retención 4 copias.
  • Destino: Google Drive o Dropbox personal (no el mismo hosting).
  • Notificación email en fallo.

Crítico: si tu backup está en el mismo servidor hackeado, no es backup. Es ilusión.

11 · Eliminar themes y plugins inactivos

Un theme inactivo sigue siendo código en tu servidor. Si tiene una vulnerabilidad, puede ser explotado. Elimina todo lo que no uses. Deja solo el theme activo + 1 de fallback oficial (Twenty Twenty-Four).

Bloque 04 · Archivos y permisos

12 · Permisos de archivo correctos

Via FTP/cPanel:

  • Directorios: 755.
  • Archivos: 644.
  • wp-config.php: 440 o 400 (solo propietario lee).
  • Nunca archivos o directorios en 777.

13 · .htaccess de hardening

Agrega en el .htaccess raíz de tu WordPress:

  • Bloquear acceso a wp-config.php, .htaccess, readme.html.
  • Deshabilitar listado de directorios (Options -Indexes).
  • Bloquear ejecución de PHP en /uploads/.
  • Bloquear xmlrpc.php (vector de ataques brute-force DDoS).

<Files wp-config.php> Order allow,deny Deny from all </Files> <Files xmlrpc.php> Order allow,deny Deny from all </Files> Options -Indexes

Bloque 05 · Monitoreo

14 · Wordfence Free + alertas

Wordfence en versión gratuita hace la mayor parte de lo que necesita una pyme:

  • Firewall aplicativo WAF con reglas actualizadas con 30 días de delay (vs las premium en tiempo real — aceptable para pymes).
  • Scanner de malware semanal.
  • Alerta email ante modificaciones de core.
  • Log de intentos de login.

Alternativa gratuita si Wordfence te parece pesado: iThemes Security (ahora Solid Security) en versión free.

La rutina mensual de seguridad (30 min)

Último viernes del mes, 30 minutos:

  • Revisar log de bloqueos de Limit Login Attempts y Wordfence.
  • Confirmar que UpdraftPlus ejecutó backup exitoso.
  • Actualizar core/themes/plugins pendientes.
  • Probar restore en staging de UN backup al azar (cada 3 meses).
  • Revisar Users: sin usuarios desconocidos ni roles inesperados.
  • Cambiar password admin (opcional — cada 6 meses es suficiente si usas 2FA).

Qué NO necesitas (aunque te lo vendan)

  • Wordfence Premium a USD 119/año para pyme con 1 sitio. El free cubre lo esencial.
  • Sucuri Firewall a USD 199/año como primera línea. Cloudflare free + plugin de seguridad entrega la mayor parte del valor.
  • iThemes Security Pro para sitios normales. El free es suficiente.
  • Backups premium tipo BlogVault o BackupBuddy a USD 79-149/año. UpdraftPlus free + tu Google Drive personal es equivalente.

Total ahorro respecto a “el stack premium completo”: USD 400-600/año. Sin diferencia funcional real en sitios de menos de 10.000 visitas/día.

Cliente llega con sitio hackeado. Defacement de home page, admins eliminados, redirect a sitio de apuestas ruso. Llevaba años pagando una suscripción premium de seguridad cara, convencido de estar cubierto.

Diagnóstico: Sucuri nunca activaron el firewall. La suscripción era solo de “monitoreo”. Sitio corría WP 5.8 (obsoleto 18 meses), plugin Contact Form 7 con vulnerabilidad conocida, usuario “admin” con password “Constructora2021”.

Recuperación: restauración desde backup limpio + aplicación de estos 14 puntos sin gastar un peso extra. Sitio caído 3 días. Lección: pagar por seguridad que no se implementa es peor que no pagar.