Seguridad completa en WordPress desde los DNS hasta el navegador

Para poder afrontar la máxima seguridad de nuestra web WordPress, primero debemos saber un poco cómo funciona el proceso desde que el usuario solicita una página de nuestra web hasta que ve el resultado solicitado.

Una vez sepamos cómo funciona este proceso, podremos pasar a segurizar cada una de las partes para tener un sitio web suficientemente robusto.

El proceso es bastante más complejo de lo que vamos a analizar en este artículo, pero para los fines buscados nos será suficiente quedarnos con estos pasos:

1. El usuario que quiere ver nuestra página realiza una petición a la URL de la web y dicha petición llega al servicio de DNS (Domain Names Service) que se encarga de llevar dicha petición al servidor web que sirve tu página (traduce la dirección en una IP que entiende la máquina destino).
2. La petición llega al servidor (nuestro hosting) y al ser por el puerto 443 (puerto SSL para https¹), se encarga de gestionarla el servidor web (Nginx, Litespeed o Apache por norma general).
3. El servidor web llama a los procesos encargados de generar la página web que verá el usuario final. Es decir, nuestro CMS (WordPress) y que en el fondo es el lenguaje de programación PHP ejecutando diferentes órdenes y llevando y trayendo datos de una base de datos (MySQL, MariaDB, Percona).
4. Se muestra en pantalla el resultado final (la página web que ve el usuario) y que consiste en HTML, JavaScript, CSS y un conjunto de imágenes, videos, fuentes y otros archivos (pdf, zip, etc).

Debemos hacer que nuestra web sea lo más segura posible en cada una de estas fases, por lo que vamos a verlas por separado para asegurar nuestra web de principio a fin.

1. Los DNS
2. El servidor web
3. PHP
4. La base de datos
5. El resultado web
6. Consideraciones finales

Los DNS

Como ya hemos visto, el servicio de DNS se encarga de traducir la dirección web como por ejemplo wordpress.com en una IP o dirección reconocible por la máquina, del tipo de 192.0.78.9. Además de la seguridad, también influye en el WPO, ya que dichas resoluciones pueden ser muy rápidas o más lentas, impactando en el tiempo de respuesta total de nuestra página².

Pero igual que el DNS lleva al usuario a nuestra web, si lo engañamos, puede llevar el tráfico destinado a nuestra web a otra diferente.

Para evitar este problema de seguridad, deberemos activar DNSSEC (DNS Security Extensions) que son un conjunto de extensiones que aseguran las respuestas DNS para evitar ataques de suplantación (spoofing), evitando que los atacantes redirijan nuestro dominio a servidores maliciosos.

Debemos activarlo desde el panel de nuestro registrador de dominios o proveedor de DNS.

Si nuestro proveedor de dominios es wordpress.com debemos activarlo desde nuestro panel de control: Dominios, Resumen, DNSSEC y comprobar que tenemos marcada la casilla de DNSSEC activado.

Algunos proveedores de DNS también tienen protección contra DoS (Denial of Service) y DDoS (Distributed Denial of Service)³ e incluso WAF completos, como en el caso de Cloudflare, entre otros.

Si nuestra web está alojada en WordPress.com tenemos la opción de Modo defensivo. Este modo integrado en la plataforma protege nuestro sitio de bots de spam y ataques DDoS y se puede activar por un periodo desde una hora hasta 7 días.

El modo defensivo obliga al navegador web que solicita una página a pasar una prueba para demostrar que es un humano. Los usuarios reales verán una página de test durante unos segundos mientras su navegador completa la prueba, mientras que los bots y otros visitantes maliciosos serán bloqueados.

Si nuestro proveedor de DNS lo permite, configurar el RRL o Response Rate Limiting para limitar consultas DNS anómalas y ataques del tipo DNS Amplification Attack.

También puedes ver este contenido en formato vídeo en nuestro canal de YouTube. Aquí lo tienes, protagonizado por el autor de esta entrada en nuestro blog. ¡Haz tu sitio web WordPress más seguro!

El servidor web

Cuando hablamos de seguridad en WordPress el servidor web ocupa un lugar central. Es la pieza que traduce las peticiones que llegan a través de Internet en respuestas que se entregan al navegador. Por lo tanto, si no está bien configurado, puede ser una puerta abierta para ataques, antes incluso de que WordPress entre en juego.

Los servidores web más utilizados para WordPress son Apache, Nginx y LiteSpeed como vimos al inicio de este artículo.

Las reglas para Apache las podemos utilizar en LiteSpeed sin cambios o con modificaciones mínimas. Estas reglas deberemos «traducirlas» para su utilización en Nginx, aunque hay servicios web o IAs que nos harán este trabajo más fácil.

La extensión de navegador Best WordPress Tools (de este autor) nos proporciona algunas reglas de configuración y de seguridad y podemos cambiar entre las opciones de Apache y Nginx.

Antes de pensar en plugins o reglas en .htaccess, es fundamental asegurarnos de que el servidor está correctamente configurado en cuanto a seguridad.

Recomendaciones básicas

Veamos algunas recomendaciones básicas:

• Tan importante como tener WordPress y sus componentes actualizados es mantener al día el sistema operativo y los servicios que lo acompañan (PHP, MySQL/MariaDB, servidor web).

• Desactivar la visualización y navegación de directorios: Si no se configura correctamente, los directorios que no tienen un archivo index.php o index.html pueden mostrar su contenido. Esto permite a un atacante ver qué archivos hay disponibles y acceder a información que puede ser muy importante⁴.

Options -Indexes

• Restringir el acceso a archivos sensibles: Archivos como .htaccess, wp-config.php, .env, composer.json, etc., nunca deben estar accesibles desde el navegador. Podemos bloquearlos directamente desde el servidor.

<FilesMatch "^(\.htaccess|wp-config\.php|\.env|composer\.json)">
    Require all denied
</FilesMatch>

• Desactivar métodos HTTP no necesarios: Algunos métodos como PATCH, TRACE, PUT o DELETE no deberían estar habilitados a menos que haya una razón específica para usarlos.

<LimitExcept GET POST HEAD>
    Deny from all
</LimitExcept>

Módulos de seguridad

Dependiendo del servidor utilizado (Apache, Nginx, LiteSpeed…), existen módulos y configuraciones adicionales que pueden ayudarnos a hacer nuestro WordPress más seguro:

• ModSecurity (para Apache o Nginx): Un firewall de aplicaciones web (WAF) que puede detectar y bloquear patrones de ataque comunes (SQLi, XSS, etc.).
• Fail2ban: Útil para bloquear IPs que hagan intentos repetidos de login o escaneo de puertos.
• Rate Limiting con Nginx: Para frenar ataques de fuerza bruta, limitando el número de peticiones por IP.
• 7G Firewall: Una serie de reglas para Apache y Nginx y fácilmente adaptables a LiteSpeed para bloquear una gran cantidad de peticiones no deseadas y 100% compatible con WordPress.

HTTPS y HSTS desde el servidor

Ya hemos visto que podemos gestionar diversas opciones de seguridad desde un proxy como Cloudflare entre otros, pero además podemos y deberíamos forzar HTTPS desde el propio servidor y añadir encabezados seguros (que veremos en detalle en la sección El resultado web).

Esto obliga a los navegadores a comunicarse solo por HTTPS incluso en futuras visitas a la web (en el siguiente ejemplo durante un año).

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" env=HTTPS

PHP

WordPress está construido sobre PHP, lo que significa que cada línea de código del núcleo, temas y plugins es interpretada por PHP antes de llegar al navegador. Por eso, asegurar PHP es esencial.

Una mala configuración o una versión antigua puede abrir puertas a ataques graves, incluso si todo lo demás está actualizado.

Versión de PHP

No es infrecuente ver servidores que ejecutan versiones antiguas de PHP (como 7.3 o incluso 5.6). Cada versión de PHP deja de recibir parches de seguridad pasados ciertos años, lo que la convierte en una bomba de relojería.

Actualmente, deberíamos estar ejecutando al menos una versión de PHP 8.3 o superior y un mínimo de PHP 7.4, versión a la que WordPress sigue dándole soporte activo.

Además de la seguridad, obtendremos mejoras en rendimiento, menor uso de memoria y funciones modernas que permiten escribir código más limpio y robusto.

Configuraciones de seguridad en php.ini

El archivo de configuración php.ini en ocasiones es un elemento olvidado y, sin embargo, muy potente en cuanto a seguridad.

Veamos algunas directivas interesantes:

• expose_php = Off
  Evitamos que PHP muestre su versión en las cabeceras HTTP. Cuanto menos mostremos a un posible atacante, mejor.
• display_errors = Off
  No mostrar errores en producción, ya que pueden revelar rutas internas, estructuras de archivos y hasta credenciales.
• log_errors = On
  Los errores deben registrarse en un log seguro, pero nunca mostrarse al usuario final.
• disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec
  Desactivar funciones que podrían ser aprovechadas para ejecutar comandos peligrosos en el servidor, especialmente útil en entornos compartidos.
• open_basedir
  Restringir el acceso de PHP solo a ciertas rutas del sistema de archivos. Así podemos evitar que un script PHP lea archivos fuera del entorno web.
• max_input_vars, post_max_size, upload_max_filesize, memory_limit
  Aunque están más relacionadas con el rendimiento, si están mal configuradas pueden facilitar ataques DoS (Denegación de servicio).

Permisos de PHP

Deberemos configurar correctamente las sesiones de PHP y usar un path seguro para almacenar las sesiones, idealmente fuera del document_root de nuestro sitio web.

Asegurarnos de que session.cookie_httponly y session.cookie_secure están configurados correctamente para evitar el robo de cookies vía JavaScript o por conexiones no cifradas.

Los archivos PHP deben tener permisos 644 y ser propiedad del usuario del servidor, pero nunca del usuario root.

Solo se debe permitir subir archivos en wp-content/uploads, y sin posibilidad de ejecutar PHP allí.

La extensión de navegador Best WordPress Tools, mencionada anteriormente, nos muestra las configuraciones necesarias para impedir la ejecución de PHP en las capetas de uploads, plugins y themes (tanto para Apache como para Nginx).

Idealmente, ningún plugin debería ejecutar código PHP desde la carpeta wp-content, pero en ocasiones algunos plugins se saltan esta norma y ejecutan código directamente en dicha carpeta.

Tal es el caso del propio plugin de LiteSpeed que, dependiendo de la configuración, puede necesitar ejecutar directamente el archivo wp-content/plugins/litespeed-cache/guest.vary.php por lo que debemos añadirlo a las excepciones modificando las reglas anteriores.

También podemos bloquear dicha ejecución de PHP desde CloudFlare u otro WAF antes de llegar a nuestro servidor.

Desactivar XML-RPC

XML-RPC es un protocolo que lo más probable es que no estemos utilizando en nuestro WordPress y es conocido por múltiples ataques al mismo. De hecho, si monitorizamos los intentos de acceso a los diferentes archivos, veremos muchas peticiones a este archivo.

Lo ideal es desactivarlo y, si lo necesitásemos para algo en concreto, habilitarlo solo para dicho servicio, IP o donde lo necesitemos.

Desde nuestro tema hijo, o mejor aún, un plugin de personalizaciones que creemos para dichos menesteres, pondremos el siguiente código PHP:

add_filter( 'xmlrpc_enabled', '__return_false' );

Si en lugar de la función nativa de WordPress __return_false creamos una función a medida, podemos devolver true o false según nuestras necesidades⁵, por ejemplo, para una determinada IP, usuario conectado, según de dónde venga la petición, etc.

También podemos bloquear XML-RPC desde el servidor web o desde nuestro WAF antes de llegar al servidor:

<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

La base de datos

Si PHP ejecuta la lógica y el servidor sirve los archivos (valga la redundancia), la base de datos es donde vive y descansa (se almacena) toda la información. Cualquier descuido aquí puede abrir la puerta a ataques como inyecciones SQL, robos de contraseñas, manipulación de contenido o instalación de puertas traseras.

Proteger la base de datos es proteger la parte más importante de nuestro sitio web.

Seguridad desde el inicio

Debemos evitar el uso de nombres genéricos o predecibles como wordpress, wp_user o similares. Usaremos nombres únicos que no puedan ser adivinados fácilmente.

En el archivo wp-config.php:

define( 'DB_NAME', 'wp_d45gh98f3hs2' );
define( 'DB_USER', 'wp_5672asdnjk063k' );
define( 'DB_PASSWORD', 'nuestra-contraseña-fuerte-y-no-predecible' );

El usuario de la base de datos usado por WordPress no debería tener privilegios globales como GRANT, DROP, o ALTER y aquí podríamos realizar una buena labor de seguridad si contamos con alguien dedicado a esta parte de la seguridad y mantenimiento.

El problema es que si no tenemos a alguien con los suficientes conocimientos de bases de datos y acceso a la misma y restringimos estos privilegios, perderemos una parte de las bondades de WordPress y no podremos instalar nuevos plugins o eliminar otros.

Lo ideal sería que solo los usuarios administradores tuvieses determinados privilegios en la Base de datos, quedando para la mayoría de los usuarios los privilegios de SELECT, INSERT, UPDATE y quizás DELETE. Pero estos cambios a nivel del core y acceso granular a la Base de datos entrarían en la modificación a medida del core de WordPress para un uso mucho más avanzado.

Prevención contra SQL Injection

En la prevención de SQL Injection tienen un papel fundamental los WAF y reglas específicas a nivel de servidor.

Aunque el núcleo de WordPress escapa correctamente las consultas si usamos las funciones adecuadas ($wpdb->prepare(), get_posts(), etc.), los desarrolladores de temas y plugins pueden introducir vulnerabilidades si escriben SQL directo mal protegido.

Ejemplo inseguro:

$resultados = $wpdb->get_results( "SELECT * FROM wp_users WHERE user_login = '$usuario'" );

Ejemplo seguro:

$resultados = $wpdb->get_results( $wpdb->prepare( "SELECT * FROM wp_users WHERE user_login = %s", $usuario ) );

Si desarrollas plugins o temas, acostúmbrate a nunca interpolar valores directamente en las consultas SQL. Recuerda la regla de Early check late escape.

Aunque no es una defensa definitiva, usar un prefijo diferente a wp_ en las tablas puede dificultar ataques automáticos que asumen ese nombre por defecto. Siempre es mejor proteger en exceso que quedarnos cortos.

En wp-config.php:

$table_prefix = 'clwp72_';

Si ya tenemos el sitio en marcha, hay plugins o scripts que pueden ayudarnos a realizar el cambio con cuidado. Pero es mejor hacerlo desde el principio, ya que si no lo hacemos adecuadamente, podemos quedar sin acceso a la web.

Cifrado

Las contraseñas de los usuarios en la base de datos están cifradas… pero ojo,
WordPress usa wp_hash_password() con bcrypt (a través de password_hash() si PHP >= 5.5), lo cual es bastante seguro. Pero si un atacante accede a la base de datos, puede lanzar ataques de fuerza bruta o usar tablas rainbow offline.

Por eso es fundamental proteger el acceso a la base de datos: cifrado en tránsito, contraseñas fuertes, y sin accesos innecesarios.

Cifrado en tránsito y en reposo

En tránsito: nos aseguraremos de que WordPress se conecta a la base de datos mediante sockets seguros o conexiones cifradas, especialmente si el servidor MySQL está en otro nodo.

En wp-config.php, podemos añadir:

define( 'DB_HOST', '127.0.0.1:3306' );
define( 'MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL );

Esto requiere que el servidor MySQL tenga configurado SSL y que tengamos los certificados.

En reposo: si usamos servicios tipo Amazon RDS, DigitalOcean Managed DB, etc., podemos activar el cifrado automático del disco o del propio servicio. En MySQL local, podemos cifrar tablas con InnoDB usando FILE_PER_TABLE y cifrado de disco (LUKS, ZFS, etc.).

Copias de seguridad de la base de datos

Tan importante como protegerla es tener un buen plan B (lo veremos en detalle en un artículo específico).

Automatizaremos los backups diarios con mysqldump, WP-CLI o plugins. Recuerda que lo que no automaticemos, acabaremos olvidándonos y dejando de hacerlo.

No guardaremos las copias en el mismo servidor.

Usaremos nombres cifrados o rutas protegidas si las dejamos temporalmente en disco.

wp db export $(date +"%Y-%m-%d").sql --path=/nuestra/ruta/temporal/

Por último, usaremos herramientas como Fail2Ban (de la que ya hablamos en este artículo) para bloquear accesos fallidos repetidos a MySQL.

Y también es de vital importancia revisar los logs de acceso a la base de datos, no solo cuando nos encontremos con un problema, sino como tarea habitual para poder detectar prematuramente intentos de acceso. Recordemos aquello de «más vale prevenir que curar».

El resultado web

Aunque todo lo anterior (DNS, servidor, PHP, base de datos) esté bien asegurado, si la comunicación entre el servidor y el navegador no está asegurada, el sitio puede seguir siendo vulnerable. Desde el momento en que se carga una web, entran en juego riesgos como:

• Inyección de scripts (XSS)
• Robo de cookies
• Manipulación del DOM
• Clickjacking
• Carga de contenido mixto o inseguro

El navegador necesita instrucciones claras para saber cómo comportarse de forma segura. Y esas instrucciones llegan, sobre todo, en forma de cabeceras HTTP.

Cabeceras HTTP de seguridad esenciales

1. Content-Security-Policy (CSP): La más potente y compleja. Indica al navegador qué tipos de recursos puede cargar y desde qué orígenes. Bloquea muchos tipos de ataques XSS y de inyección.

Ejemplo básico:

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com; style-src 'self' 'unsafe-inline';

Podemos empezar en modo «report-only» para ver errores sin bloquear aún:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint

2. X-Content-Type-Options: Previene que los navegadores interpreten los archivos como otro tipo del declarado.

X-Content-Type-Options: nosniff

3. X-Frame-Options: Evita que nuestro sitio se cargue dentro de un iframe, protegiendo contra clickjacking.

X-Frame-Options: SAMEORIGIN

También podemos usar DENY si no usamos iframes nunca.

4. Strict-Transport-Security (HSTS): Fuerza el uso de HTTPS incluso cuando alguien intenta visitar el sitio por HTTP.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Usaremos esta cabecera solo si HTTPS ya está completamente implementado y sin errores, o no podremos acceder a la web.

5. Referrer-Policy: Controla qué se envía en la cabecera Referer cuando el usuario navega desde nuestra web a otra.

Referrer-Policy: no-referrer-when-downgrade

Opciones más estrictas: strict-origin, same-origin, no-referrer.

6. Permissions-Policy (antes Feature-Policy): Controla qué APIs del navegador están disponibles en nuestra web (geolocalización, cámara, micrófono…).

Permissions-Policy: geolocation=(), camera=(), microphone=()

Podemos desactivar todo lo que no usemos en nuestra web. Por defecto, muchos navegadores permiten estas APIs.

Cómo añadir estas cabeceras

En Apache en la configuración del virtualhost o por medio de un archivo .htaccess en el directorio raíz de nuestra web:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'"
    Header set X-Content-Type-Options "nosniff"
    Header set X-Frame-Options "SAMEORIGIN"
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header set Referrer-Policy "no-referrer-when-downgrade"
    Header set Permissions-Policy "geolocation=(), microphone=()"
</IfModule>

En Nginx:

add_header Content-Security-Policy "default-src 'self'";
add_header X-Content-Type-Options "nosniff";
add_header X-Frame-Options "SAMEORIGIN";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
add_header Referrer-Policy "no-referrer-when-downgrade";
add_header Permissions-Policy "geolocation=(), microphone=()";

También podemos añadir o modificar cabeceras desde Cloudflare.

Y por último, podemos añadir estas cabeceras directamente desde PHP con este pequeño código para nuestro plugin de personalizaciones:

/**
 * Añade cabeceras de seguridad personalizadas.
 *
 * @return void
 *
 * @since 1.0
 */
function cl_add_security_headers() {
	header( 'X-Content-Type-Options: nosniff' );
	header( 'X-Frame-Options: SAMEORIGIN' );
	header( 'Referrer-Policy: no-referrer-when-downgrade' );
	header( 'Permissions-Policy: geolocation=(), microphone=(), camera=()' );
	header( 'Strict-Transport-Security: max-age=31536000; includeSubDomains; preload' );

	// Cabecera CSP básica (ajusta a tu sitio).
	header( "Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';" );
}
add_action( 'send_headers', 'cl_add_security_headers' );

Comprobación de las cabeceras

Para probar si se están enviando las cabeceras correctas al navegador, la mejor y más completa opción son las herramientas de desarrollo del navegador que nos permiten hasta modificar cabeceras y guardarlas en nuestro ordenador para ver resultados sin tocar el servidor.

Otra opción menos potente, pero más user-friendly y muy visual, es utilizar un servicio online como: https://securityheaders.com/

Y por último, podemos comprobar las cabeceras directamente desde la consola mediante el uso de curl con el parámetro -I o --head (obtener solo las cabeceras):

curl -I https://tu-sitio.com

También podemos analizar nuestra web con Lighthouse: Chrome DevTools → pestaña «Lighthouse» → realizamos una auditoría y veremos recomendaciones de seguridad, cabeceras, HTTPS, etc.

Opciones del wp-config.php

El archivo de configuración de nuestro WordPress (wp-config.php) también es leído por WordPress si lo situamos un nivel más arriba y fuera de la raíz del sitio web (y, por tanto, no accesible directamente desde web).

Para mantener más ordenado este archivo, es una buena práctica incluir en el mismo user-configs.php o similar para tener agrupadas nuestras personalizaciones:

include __DIR__ . '/user-configs.php';

Una vez más, la extensión de navegador Best WordPress Tools, nos ofrece opciones de seguridad para poner en nuestro archivo wp-config.php como pueden ser:

Ir a la página de API de generación de claves salt: https://api.wordpress.org/secret-key/1.1/salt/

Forzar HTTPS en la página de autenticación de WordPress:

define( 'FORCE_SSL_LOGIN', true );

Forzar HTTPS en el backend de WordPress:

define( 'FORCE_SSL_ADMIN', true );

Fijar WP_SITEURL y WP_HOME sin posibilidad de modificarlo desde el backend de WordPress:

define( 'WP_SITEURL', 'https://es.blog.wordpress.com' );
define( 'WP_HOME', 'https://es.blog.wordpress.com' );

Fijar el dominio de las cookies:

define( 'COOKIE_DOMAIN', 'es.blog.wordpress.com' );

Desactivar la edición de archivos de temas y plugins desde el backend de WordPress:

define( 'DISALLOW_FILE_EDIT', true );

Cookies seguras:

@ini_set( 'session.cookie_httponly', true );
@ini_set( 'session.cookie_secure', true );
@ini_set( 'session.cookie_samesite', 'Lax' );

Consideraciones finales

La seguridad es un tema muy amplio y aunque podamos instalar un par de plugins en nuestro WordPress⁶, es un tema más complejo, desde las contraseñas y seguridad adecuada de los usuarios en WordPress, opciones de seguridad y análisis desde WP CLI, las acciones necesarias a realizar con las copias de seguridad o la reacción y acciones necesarias en caso de ataque e infección de nuestro sitio web (temas que veremos en próximos artículos en más detalle).

Hay muchos más temas que podríamos cubrir, como por ejemplo la conveniencia de claves seguras de los usuarios, habilitar un sistema de doble factor de autenticación 2FA o la necesidad de auditorías periódicas de seguridad. Pero iremos entrando en más detalle de estos y otros temas en próximos artículos.

En lo relativo a la seguridad, es mejor proteger de más que de menos. Por ejemplo, deshabilitar XML-RPC desde nuestro plugin de personalizaciones, desde el servidor web y desde el WAF de Cloudflare (en el caso de que lo utilicemos).

Con esta premisa, el intento de acceso a XML-RPC será parado por CF, pero si el atacante pudiese saltarse el proxy y acceder a nuestra web vía IP, el servidor frenaría dicho intento de acceso y si cambiamos la web de servidor, aún iría con el XML-RPC bloqueado por medio de nuestro script PHP.

Siempre estaremos a tiempo de ir abriendo servicios, URLs, etc. cuando algo no funcione. esto es preferible a que, debido a un exceso de laxitud en la seguridad, tengamos un acceso no controlado que ya sea más complicado de arreglar y con consecuencias inesperadas.

Lo ideal es que la seguridad se controle siempre desde un nivel superior (DNS, servidor, PHP), por lo que, en la mayoría de los casos, debería ser una tarea de nuestro hosting (tarea nuestra es elegir el hosting con las mejores opciones de seguridad).

El hosting de WordPress.com realiza estas tareas por nosotros y nos ofrece:

• Protección WAF y contra DDoS: WordPress.com se encarga de bloquear millones de amenazas diarias, desde hackeos hasta intentos de suplantación.
• Análisis y eliminación de malware: adelántate a las amenazas de seguridad gracias a los análisis de malware automáticos y las reparaciones con un solo clic.
• Registro de actividad en tiempo real: no perderemos detalle de todo lo que pasa en nuestra web con el registro de actividad en tiempo real.

Debemos recordar que la seguridad, al igual que el WPO, no es una tarea que se realiza una vez y ya podemos olvidarnos, sino que se trata de algo que debemos analizar y tener en cuenta continuamente en nuestras webs y las de nuestros clientes.

1. Para http se usa el puerto 80, pero no lo contemplamos en una web que debe ser segura. ↩︎
2. Ver velocidad de los proveedores principales de DNS https://www.dnsperf.com/ ↩︎
3. Ataque de denegación de servicio y ataque de denegación de servicio distribuido https://es.wikipedia.org/wiki/Ataque_de_denegaci%C3%B3n_de_servicio ↩︎
4. Las configuraciones de servidor aquí mostradas, si no se indica lo contrario, son del servidor web Apache. ↩︎
5. Si devolvemos true permitiremos la ejecución de XML-RPC para esa petición y, por el contrario, con false denegaremos la ejecución de XML-RPC. ↩︎
6. Hay multitud de plugins de seguridad disponibles en el repositorio oficial de WordPress como AIOS, Jetpack o Wordfence entre muchos otros. ↩︎