En el mundo de la ciberseguridad, existe un concepto conocido como “Reconocimiento”.
Antes de que un hacker (o un bot automatizado) ataque tu sitio, lo escanean. Buscan fruta al alcance de la mano. Si tu sitio web anuncia orgullosamente: “Hola! Estoy ejecutando WordPress 5.8.1!”, practicamente estas desplegando la alfombra roja para ellos. Porque saben exactamente que vulnerabilidades existian en la versión 5.8.1.
En esta guía completa de seguridad, iremos más alla de los simples plugins de “Ocultar Versión”. Nos sumergiremos en Seguridad por Oscuridad (y por que es solo la primera capa de defensa), y luego implementaremos endurecimiento real y robusto a nivel de servidor usando Cabeceras HTTP, protección de login y monitoreo automatizado.
Parte 1: Entendiendo “Seguridad por Oscuridad”
Que es Seguridad por Oscuridad?
La seguridad por oscuridad es la práctica de ocultar información sobre tu sistema para dificultar que los atacantes encuentren vulnerabilidades. Si bien es controvertida en circulos de seguridad, cuando se combina con medidas de seguridad adecuadas, agrega una capa extra de defensa.
El Debate:
- Los críticos dicen: “Un sistema deberia ser seguro incluso si los atacantes saben todo sobre el”
- Los practicantes dicen: “Por que facilitarselo a los atacantes transmitiendo tus vulnerabilidades?”
La Verdad: La seguridad por oscuridad no es suficiente por si sola, pero es una primera capa valiosa de defensa. Piensa en ella como quitar el felpudo de bienvenida de tu puerta principal: no detendra a un ladron determinado, pero podria hacer que los oportunistas se muevan a un objetivo más fácil.
Por Que Importa Ocultar la Versión de WordPress
Las vulnerabilidades del core de WordPress estan documentadas publicamente. Cuando se lanza un parche de seguridad, el registro de cambios declara explicitamente que versiones estan afectadas. Al mostrar tu número de versión, esencialmente les dices a los atacantes:
- Que vulnerabilidades conocidas podrian existir en tu sitio
- Si has aplicado los últimos parches de seguridad
- Que código de exploit específico podria funcionar contra ti
Puntos Comunes de Fuga de Versión:
- Etiqueta meta generator en HTML
- Etiquetas generator en feeds RSS/Atom
- Query strings de scripts y estilos (
?ver=6.7.1) - Archivo readme.html en el directorio raiz
- Respuestas de la REST API de WordPress
Parte 2: Eliminando la Información de Versión de WordPress
La Etiqueta Meta Generator
Por defecto, WordPress inyecta una etiqueta meta en el <head> de tu HTML:
<meta name="generator" content="WordPress 6.7.1" />
Esto es inutil para SEO y peligroso para la seguridad.
La Solución (fragmento PHP)
No instales un plugin pesado solo para esto. Agrega este código limpio a tu functions.php:
/**
* Eliminar Version de WordPress del Head y Feeds
*/
remove_action('wp_head', 'wp_generator');
remove_action('rss2_head', 'the_generator');
remove_action('commentsrss2_head', 'the_generator');
remove_action('wp_head', 'wlwmanifest_link'); // Windows Live Writer (Heredado)
remove_action('wp_head', 'rsd_link'); // Really Simple Discovery
/**
* Eliminar Version de Scripts y Estilos
*/
function wppoland_remove_versión_scripts_styles($src) {
if (strpos($src, 'ver=')) {
$src = remove_query_arg('ver', $src);
}
return $src;
}
add_filter('style_loader_src', 'wppoland_remove_versión_scripts_styles', 9999);
add_filter('script_loader_src', 'wppoland_remove_versión_scripts_styles', 9999);
/**
* Eliminar Version de Feeds RSS
*/
add_filter('the_generator', '__return_empty_string');
Por que importa esto: Rompe la lógica de los scrapers simples de “Script Kiddie”. Si un bot esta escaneando 1 millon de sitios buscando “WordPress 5.X”, tu sitio devolvera una mirada en blanco. El bot sigue adelante.
Nota Importante: Esto es Seguridad por Oscuridad. Es la primera capa, no la única. Un atacante determinado aun puede identificar WordPress a través de otros métodos (endpoints de REST API, estructura de archivos, etc.).
Métodos Adicionales de Eliminacion de Versión
Eliminar de REST API
/**
* Eliminar versión de WordPress de cabeceras REST API
*/
add_filter('rest_api_init', function() {
remove_filter('rest_pre_serve_request', 'rest_send_cors_headers');
}, 15);
add_filter('rest_pre_serve_request', function($value) {
header('X-Powered-By: WordPress');
return $value;
});
Eliminar Archivos Readme y Licencia
/**
* Bloquear acceso a readme.html y license.txt
*/
function wppoland_block_readme_access() {
if (strpos($_SERVER['REQUEST_URI'], 'readme.html') !== false ||
strpos($_SERVER['REQUEST_URI'], 'license.txt') !== false) {
wp_die('Acceso denegado', '403 Prohibido', array('response' => 403));
}
}
add_action('init', 'wppoland_block_readme_access');
O via .htaccess:
<FilesMatch "^(readme\.html|license\.txt)$">
Order deny,allow
Deny from all
</FilesMatch>
Parte 3: Cabeceras de Seguridad HTTP (La Defensa Real)
Ocultar la versión es como quitar el número de la casa de tu puerta. Ayuda, pero no cierra la puerta con llave. Las Cabeceras de Seguridad HTTP son los cerrojos.
En 2026, los navegadores son estrictos. Si no envias las cabeceras correctas, eres vulnerable a XSS (Cross-Site Scripting), Clickjacking y fugas de datos.
1. X-Frame-Options (Anti-Clickjacking)
Esta cabecera le dice al navegador: “No permitas que nadie ponga mi sitio dentro de un <iframe>.” Esto previene que los hackers creen un sitio falso que cargue tu página de banco/login en un marco invisible y capture tus clics.
Implementación (.htaccess):
<IfModule mod_headers.c>
Header always append X-Frame-Options SAMEORIGIN
</IfModule>
Nginx:
add_header X-Frame-Options "SAMEORIGIN" always;
2. X-Content-Type-Options
Previene el “MIME Sniffing”. Si un hacker sube un archivo .jpg que realmente contiene JavaScript ejecutable, esta cabecera le dice al navegador: “El servidor dijo que es una imagen, así que tratala como una imagen, no la ejecutes.”
Implementación:
<IfModule mod_headers.c>
Header set X-Content-Type-Options nosniff
</IfModule>
3. Strict-Transport-Security (HSTS)
Esto es crítico para SSL. Fuerza al navegador a siempre usar HTTPS, incluso si el usuario escribe http://. Previene ataques “Man-in-the-Middle” en Wi-Fi público.
Implementación (Solo haz esto si tienes SSL válido!):
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>
Que significan los parametros:
max-age=31536000: El navegador recuerda por 1 añoincludeSubDomains: Aplicar a todos los subdominiospreload: Enviar a las listas de precarga del navegador
Advertencia: Una vez que configures esta cabecera, los navegadores se negaran a conectar via HTTP durante la duracion específicada. Asegurate de que HTTPS funcióne perfectamente antes de implementar HSTS.
4. Content-Security-Policy (CSP)
Esta es la cabecera más poderosa. Le dice al navegador: “Solo ejecuta scripts de estas fuentes confiables.”
Implementación Básica:
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://www.google-analytics.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:;"
</IfModule>
Desglose:
default-src 'self': Por defecto, solo cargar recursos de tu propio dominioscript-src 'self' 'unsafe-inline': Permitir scripts de tu dominio y scripts inline (necesario para WordPress)img-src 'self' data: https:: Permitir imágenes de tu dominio, URIs de datos y cualquier fuente HTTPS
Advertencia: CSP puede romper tu sitio si se configura mal. Prueba primero en modo “report-only”:
Header set Content-Security-Policy-Report-Only "default-src 'self'; report-uri /csp-report.php"
5. Referrer-Policy
Controla cuanta información se envia cuando un usuario hace clic en un enlace a otro sitio.
<IfModule mod_headers.c>
Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>
6. Permissions-Policy (antes Feature-Policy)
Deshabilita funciones del navegador que no usas (camara, microfono, geolocalización).
<IfModule mod_headers.c>
Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>
Parte 4: Deshabilitar XML-RPC
xmlrpc.php es un archivo API heredado. En la era moderna de REST API, es obsoleto. Sin embargo, es el objetivo #1 de ataques de Fuerza Bruta porque permite a un hacker probar 500 contrasenas en una sola solicitud HTTP (el método “multicall”).
Como eliminarlo:
Método 1: .htaccess
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
Método 2: functions.php
add_filter('xmlrpc_enabled', '__return_false');
Método 3: Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Excepcion: Si usas Jetpack o la app móvil de WordPress, necesitas XML-RPC. En ese caso, bloquea solo los métodos peligrosos.
Parte 5: Endurecimiento del Login
Los endpoints /wp-admin/ y /wp-login.php estan bajo ataque constante. Aqui esta como protegerlos.
1. Limitar Intentos de Login
Por defecto, WordPress permite intentos de login ilimitados. Un bot puede probar 10,000 contrasenas.
Agrega este código:
function wppoland_limit_login_attempts() {
$ip = $_SERVER['REMOTE_ADDR'];
$attempts = get_transient('login_attempts_' . $ip);
if ($attempts >= 5) {
wp_die('Demasiados intentos de login. Intenta de nuevo en 15 minutos.');
}
}
add_action('wp_login_failed', function() {
$ip = $_SERVER['REMOTE_ADDR'];
$attempts = get_transient('login_attempts_' . $ip) ?: 0;
set_transient('login_attempts_' . $ip, $attempts + 1, 15 * MINUTE_IN_SECONDS);
});
2. Deshabilitar Enumeracion de Usuarios
// Deshabilitar enumeracion de usuarios
add_action('template_redirect', function() {
if (is_author()) {
wp_redirect(home_url(), 301);
exit;
}
});
// Bloquear endpoint de usuarios de REST API
add_filter('rest_endpoints', function($endpoints) {
if (isset($endpoints['/wp/v2/users'])) {
unset($endpoints['/wp/v2/users']);
}
if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
}
return $endpoints;
});
Parte 6: Seguridad de Base de Datos
1. Cambiar Prefijo de Tablas
Por defecto, WordPress usa wp_ como prefijo de tablas. Esto facilita la inyeccion SQL.
Durante la Instalación: Establece un prefijo personalizado como xyz_ o prod_.
2. Deshabilitar Edicion de Archivos
WordPress permite a los administradores editar archivos de temas/plugins desde el panel. Si un hacker obtiene acceso de admin, puede inyectar malware.
Deshabilitar en wp-config.php:
define('DISALLOW_FILE_EDIT', true);
3. Asegurar wp-config.php
Este archivo contiene tus credenciales de base de datos. Protegelo.
Establecer permisos estrictos:
chmod 400 wp-config.php
Parte 7: Permisos de Archivos
Las Reglas de Oro:
- Directorios:
755(Lectura/Ejecucion para todos, Escritura solo para el propietario) - Archivos:
644(Lectura para todos, Escritura solo para el propietario) - wp-config.php:
400o440(Solo lectura para propietario/servidor)
Establecerlos todos de una vez:
find /ruta/a/wordpress -type d -exec chmod 755 {} \;
find /ruta/a/wordpress -type f -exec chmod 644 {} \;
chmod 400 wp-config.php
Parte 8: Monitoreo de seguridad
No recomendamos instalar plugins de seguridad. Preferimos monitoreo a nivel de servidor (análisis de logs, fail2ban, WAF del hosting), respaldos regulares y endurecimiento (contrasenas fuertes, actualizaciones, intentos de login limitados). La seguridad se construye a través de la configuración y medidas del servidor, no plugins.
Parte 9: Lista de Verificación Completa de Seguridad
Acciones Inmediatas (Haz Hoy)
- Eliminar versión de WordPress de HTML/feeds
- Eliminar strings de versión de CSS/JS
- Configurar cabecera X-Frame-Options
- Configurar cabecera X-Content-Type-Options
- Configurar Strict-Transport-Security (HSTS) si usas SSL
- Deshabilitar XML-RPC (si no se necesita)
- Instalar limitacion de intentos de login
- Cambiar nombre de usuario “admin” por defecto
Acciones a Corto Plazo (Esta Semana)
- Implementar Content-Security-Policy
- Configurar Referrer-Policy
- Habilitar Autenticación de Dos Factores
- Cambiar URL de login
- Deshabilitar enumeracion de usuarios
- Establecer permisos de archivos correctos (755/644)
Acciones a Largo Plazo (Este Mes)
- Cambiar prefijo de tablas de base de datos (si es posible)
- Deshabilitar edicion de archivos en el panel
- Asegurar wp-config.php (permisos 400)
- Configurar monitoreo de seguridad a nivel de servidor
- Configurar respaldos automatizados
- Programar escaneos regulares de seguridad
Resumen: El Enfoque de Seguridad por Capas
Conoce más sobre los servicios de seguridad WordPress en WPPoland.
La seguridad no es un producto; es un proceso.
- Ocultar información (eliminar strings de versión) - Seguridad por oscuridad
- Endurecer conexión (HSTS, Cabeceras, CSP) - Protección a nivel de navegador
- Cerrar puertas (Deshabilitar XML-RPC, limitar logins) - Reducir superficie de ataque
- Bloquear archivos (Permisos, deshabilitar edicion) - Contener brechas
- Monitorear (Logs del servidor, monitoreo) - Detectar y responder
Haz esto, y seras más seguro que el 99% de los sitios WordPress.
Recuerda: La seguridad es por capas. Ninguna medida individual es perfecta, pero juntas crean una fortaleza. Comienza con lo básico (actualizaciones, contrasenas fuertes), agrega oscuridad (ocultar versión), luego implementa endurecimiento (cabeceras, permisos), y finalmente monitoreo.
El objetivo no es ser inhackeable, eso es imposible. El objetivo es ser un objetivo más dificil que el siguiente sitio, causando que los atacantes se muevan a una presa más fácil.


