Nosotros      Publicidad

¿Cómo asegurar y optimizar WordPress en Cloudways?

¿Cómo asegurar el acceso a nuestra Web y evitar la actividad de bots maliciosos?, ¿cómo configurar y optimizar el rendimiento de nuestro Servidor y Aplicaciones en Cloudways? Veamos todas las posibilidades en este artículo.

Antonio Paredes / 29.03.2022 / 1:32 am

¿Cómo asegurar y optimizar WordPress en Cloudways?

Hace poco, publicamos un artículo completo sobre cómo migrar al Cloud Hosting de Cloudways, en esta ocasión vamos a abordar dos aspectos vitales para los negocios online: la seguridad y optimización del rendimiento de nuestro Servidor, ya que es importante que no se detengan las operaciones de nuestra empresa debido a brechas de seguridad ni al excesivo consumo de recursos.

Todas las recomendaciones de este artículo son para Servidores y Aplicaciones en Cloudways; sin embargo, muchas de ellas podrían ser aplicadas en los servicios de otros proveedores.

Para asuntos de seguridad usaremos estos dos apartados:

  • En el Servidor: Monitoring, tanto Summary como Details
  • En la Aplicación: Bot Protection, Logs y Access Logs

Posteriormente, abordaremos el tema de la optimización del rendimiento del Servidor y las Aplicaciones. Allí veremos distintos apartados y compartiremos varias recomendaciones en base a nuestra experiencia y también a la información que nos brindaron directamente en soporte técnico.

Bloqueando bots agresivos que intentan iniciar sesión

Existen diversas maneras de bloquear bots agresivos:

  • Cambiar el nombre de la carpeta WP-Admin
  • Usar reCAPTCHA de Google
  • Usar un criterio de lista negra en .htaccess
  • Usar plugins de seguridad de WordPress
  • Usar un criterio de lista blanca en .htaccess
  • Usar Bot Protection de Cloudways

En nuestro caso, evitamos cambiar el nombre de la carpeta WP-Admin dado que para añadir seguridad, deberíamos cambiar ese nombre periódicamente.

Evitamos usar reCAPTCHA de Google porque de igual forma los bots consumen recursos del Servidor enviando solicitudes fallidas.

Evitamos usar el criterio de lista negra en .htaccess porque debemos analizar lo Logs recurrentemente para no añadir a IPs de Google, Facebook u otros servicios online.

Evitamos usar plugins de seguridad de WordPress porque consumen muchos recursos del Servidor.

Decidimos usar el criterio de lista blanca en .htaccess porque de esta forma únicamente debemos añadir nuestra IP a este archivo para poder conectarnos a la administración de WordPress.

También activamos el sistema Bot Protection de Cloudways, el cual no solo activa un plugin en WordPress, sino que también nos muestra datos relevantes en la propia plataforma de Cloudways, como veremos más adelante. Ademas, la visualización de estos reportes a través de la consola de Cloudways es muy fácil ya que las líneas son separadas por los colores gris y blanco, de forma similar a como lo hace Apple con sus aplicaciones.

Todo sistema es vulnerable. Hasta las empresas tecnológicas con mejor reputación son víctimas de ciberataques. Sabiendo esto, lo único que podemos hacer es que sea más complicado para los atacantes escalar los privilegios realizar diversas actividades:

  • Secuestrar nuestros contenidos
  • Reemplazar nuestra información por SPAM
  • Falsificar la identidad de nuestra compañía
  • Usar nuestro Servidor para atacar a terceros

Algunos bots intentan ingresar a WP-Admin y wp-login.php de forma muy agresiva por medio de lo que se conoce como ataque de fuerza bruta: probando nombres de usuario y contraseñas a una alta velocidad durante todo el tiempo posible. Estos ataques pueden prolongarse durante largas horas o días si no son detenidos. Veamos el caso de una de nuestras páginas web:

¿Cómo asegurar y optimizar WordPress en Cloudways?

Esos son los intentos fallidos de inicio de sesión. El sistema Bot Protection de Cloudways es capaz de identificarlos y bloquearlos.

Podemos ver más detalles desde la siguiente ruta:

  • Application Management
  • Monitoring
  • Logs
  • Access Log
  • Apache

Allí podremos ver todo el tráfico web, tanto de bots benignos como los de Google, Microsoft, Facebook y también las URLs que están siendo atacadas. El proceso de análisis puede requerir de tiempo y costumbre para identificar qué IP nos está perjudicando. Veamos nuestro caso:

¿Cómo asegurar y optimizar WordPress en Cloudways?

Podemos recopilar cada IP maliciosa y crear una lista negra para impedir su paso; sin embargo, tal como indicamos previamente, esta es una labor muy ardua porque debemos analizar los Logs y añadir varias IPs cada día. ¿Qué opción tenemos? Usar un criterio de lista blanca con el archivo .htaccess.

La lista blanca permitirá que solo nuestra IP se conecte a WP-Admin y wp-login.php. Este código será de utilidad:

¿Cómo asegurar y optimizar WordPress en Cloudways?

#Bloquea el Login con Lista Blanca
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
############## AGREGA TU IP ##############
RewriteCond %{REMOTE_ADDR} !^XX.XX.XX.XX$
RewriteRule ^(.*)$ - [R=403,L]
</IfModule>

Tan solo debemos reemplazar la cadena XX.XX.XX.XX por nuestra IP. En este servicio y este otro podemos conocer nuestra IP. Esa IP debemos añadirla al archivo .htaccess en la carpeta public_html por medio de un cliente FTP. Figurativamente, esta será nuestra llave para poder acceder a WP-Admin y wp-login.php, de lo contrario tampoco podremos acceder a esas rutas debido a la fuerte restricción que incorporamos.

¿Las conexiones a wp-load.php son ataques?

No. Podríamos creer que algunos hackers envían ataques directos al archivo wp-load.php como se aprecia a continuación:

¿Cómo asegurar y optimizar WordPress en Cloudways?

Sin embargo, esa llamada al archivo wp-load.php en realidad es el sistema Bot Protection de Cloudways. Si nosotros bloqueamos su acceso a wp-load.php o index.php con aspecto similar, Bot Protection no podrá obtener los datos necesarios para mostrarnos la información en sus gráficos, pensaremos que el sistema no funciona e intentaremos muchas cosas erróneas.

Nosotros bloqueamos estas conexiones, como se puede ver en la respuesta 403 del Servidor; sin embargo, luego de conocer más detalles sobre cómo funciona el sistema Bot Protection de Cloudways, permitimos estas conexiones. Este sistema actualiza los datos que nos muestra cada 5 minutos. En caso de no funcionar este sistema, recomendamos desactivarlo y luego de algunos minutos volver a activarlo ya que sí es útil en su propósito.

Tal como indicamos previamente, podemos revisar los accesos a nuestra Aplicación de Cloudways desde:

  • Application Management
  • Monitoring
  • Logs
  • Access Log
  • Apache

Allí veremos los 1,000 registros más recientes. Debemos bajar totalmente el scroll para ver el ingreso más reciente y conforme subamos veremos los ingresos anteriores. A la izquierda se apreciará la fecha y hora para orientarnos fácilmente.

Si queremos ver más registros, debemos hacerlo vía SFTP y SSH, más adelante mostramos la forma de hacerlo correctamente.

En caso que, a pesar de saber que esa conexión a wp-load.php es del sistema Bot Protection de Cloudways, deseemos bloquear las consultas a wp-load.php lo podemos hacer editando el archivo .htaccess de la siguiente manera:

#Bloquea URLs con pubkey=
#Bloquea Bot Protection de Cloudways
RewriteCond %{QUERY_STRING} pubkey= [NC]
RewriteRule .* - [F]

#Bloquea Ejecuciones Externas
#No bloquea Feeds o Redes Sociales
#Sí bloquea Bot Protection de Cloudways
<Files wp-load.php>
 Order Deny,Allow
 Deny from all
 Allow from localhost
 Allow from 127.0.0.1
</Files>

Estos códigos blindan el archivo wp-load.php en caso de necesitarlo: bloquean todas las conexiones externas y únicamente permiten la del propio Servidor.

Aplicando el código anterior en el archivo .htaccess logramos que el Servidor de la respuesta 403, lo cual significa prohibido. Como vemos, luego de HTTP/1.0 figura el código 403 que nos indica que el bloqueo está funcionando actualmente. Si el código fuera 200, significaría que no existe bloqueo alguno y que los intentos de conexión se siguen realizando sin impedimento alguno.

Repetimos que esos códigos anularían el sistema Bot Protection de Cloudways. No recomendamos implementarnos.

Bloqueando a bots de alta frecuencia

Algunos bots se encuentran en listas negras debido a que consumen muchos recursos del Servidor al que visitan de forma reiterada.

Podemos bloquearlos añadiendo el siguiente código en .htaccess:

#Bloqueo de Agents y Referers vacíos
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^-?$
RewriteCond %{HTTP_REFERER} ^-?$
RewriteRule . - [F,L]

#Bloqueo de Bots agresivos
SetEnvIfNoCase User-Agent "wp_is_mobile" bad_bot
SetEnvIfNoCase User-Agent "DataForSeoBot" bad_bot
SetEnvIfNoCase User-Agent "Scrapy" bad_bot
SetEnvIfNoCase User-Agent "PetalBot" bad_bot
SetEnvIfNoCase User-Agent "python-requests" bad_bot
SetEnvIfNoCase User-Agent "MegaIndex" bad_bot
SetEnvIfNoCase User-Agent "uberMetrics" bad_bot
SetEnvIfNoCase User-Agent "Barkrowler" bad_bot
SetEnvIfNoCase User-Agent "Blogtrottr" bad_bot
SetEnvIfNoCase User-Agent "BLEXBot" bad_bot
SetEnvIfNoCase User-Agent "LieBaoFast" bad_bot
SetEnvIfNoCase User-Agent "MQQBrowser" bad_bot
SetEnvIfNoCase User-Agent "Mb2345Browser" bad_bot
SetEnvIfNoCase User-Agent "UCBrowser" bad_bot
SetEnvIfNoCase User-Agent "Baiduspider" bad_bot
SetEnvIfNoCase User-Agent "Yandex" bad_bot
SetEnvIfNoCase User-Agent "mj12bot" bad_bot
SetEnvIfNoCase User-Agent "MicroMessenger" bad_bot
SetEnvIfNoCase User-Agent "DotBot" bad_bot
SetEnvIfNoCase User-Agent "Sogou web spider" bad_bot
SetEnvIfNoCase User-Agent "AspiegelBot" bad_bot
SetEnvIfNoCase User-Agent "PetalBot" bad_bot

<Limit GET POST>
Order Allow,Deny
Allow from all
Deny from env=bad_bot
</Limit>

Luego de aplicar estos códigos, podemos ver que el bloqueo es efectivo debido a la respuesta 403 por parte del Servidor ante las solicitudes de Scrapy, uno de los bots que añadimos a nuestra lista negra.

¿Cómo asegurar y optimizar WordPress en Cloudways?

Analizando Logs completos vía SFTP

Para ello, desde un cliente FTP, debemos conectarnos con el usuario de nuestro Servidor. Repetimos, no con el usuario de nuestra Aplicación, sino de nuestro Servidor.

Luego debemos ir a la siguiente ruta:

/applications/<nuestra-aplicacion>/logs

El nombre de nuestra Aplicación se encuentra bajo un código interno que maneja Cloudways, ¿cómo saber cuál le corresponde a mi Aplicación? Es muy fácil, solo debemos ir a:

  • Application Management
  • Access Details
  • En MySQL Access veremos ese código interno

Si queremos descargar los registros o Logs de acceso más recientes, debemos elegir el archivo en texto que termina en access.log, considerando que los números 1, 2, 3, 4, 5 y la sucesión, corresponden a registros de acceso más antiguos, los cuales también aportan información valiosa para el histórico de intentos de acceso con las IPs respectivas, las URLs a las que intentaron acceder, la respuesta que dio el Servidor a estas solicitudes, etc.

En la siguiente imagen vemos el archivo que debemos descargar para revisar los accesos más recientes:

¿Cómo asegurar y optimizar WordPress en Cloudways?

Bots intentando iniciar sesión en WordPress

¿Cómo asegurar y optimizar WordPress en Cloudways?

Aquí vemos como desde una IP intentan acceder de forma persistente a la administración de WordPress a través de un ataque de fuerza bruta, donde se prueban usuarios y contraseñas hasta lograr concretar el ingreso.

Bots escaneando brechas potenciales

¿Cómo asegurar y optimizar WordPress en Cloudways?

Los bots nunca se cansan. En esta ocasión, identificamos uno que intentaba acceder a archivos maliciosos que no existen en nuestro Servidor; sin embargo, en caso de existir alguno, podrían aprovechar esa brecha para tomar el control de los contenidos. No vamos a querer encontrarnos en ese escenario, por ello recomendamos tener activo el sistema Bot Protection de Cloudways.

Bloqueando solicitudes a /wp-includes/wlwmanifest.xml

Muchos bots maliciosos intentan acceder el contenido del archivo ubicado en /wp-includes/wlwmanifest.xml. Si no utilizamos Windows Live Writer para editar nuestros contenidos de WordPress, podemos añadir el siguiente archivo en nuestro .htaccess:

#Bloquea wlwmanifest.xml
<Files wlwmanifest.xml>
Order Deny,Allow
Deny from all
</Files>

Luego de aplicar este cambio, recomendamos vaciar la caché de Varnish de la siguiente forma:

  • Server Management
  • Manage Services
  • Varnish
  • Clic en Purge

Bloqueando solicitudes a xmlrpc.php

¿Cómo asegurar y optimizar WordPress en Cloudways?

Tal como vemos en la imagen de arriba, muchos bots agresivos envían solicitudes al archivo xmlrpc.php.

Perfmatters no es suficiente

En este caso, el sistema Bot Protection de Cloudways bloqueó estas solicitudes, aunque vía Perfmatters se encuentra deshabilitada la opción XML-RPC. ¿Perfmatters no es suficiente en este caso? La siguiente imagen puede revelarnos más información:

¿Cómo asegurar y optimizar WordPress en Cloudways?

Tal como vemos en la imagen de arriba, a pesar de que Perfmatters realiza su labor, el bloqueo no es inmediato, sino que existe una respuesta 301 de parte del servidor. Podemos evitar esta redirección y actuar inmediatamente en el bloqueo con el siguiente código en el archivo .htaccess.

Bloqueando solicitudes a XML-RPC vía .htaccess

#Bloquea XML-RPC. Perfmatters no es suficiente
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Luego de aplicar este cambio, recomendamos vaciar la caché de Varnish de la siguiente forma:

  • Server Management
  • Manage Services
  • Varnish
  • Clic en Purge

¿Cómo sabemos que funcionan los sistemas de bloqueo?

Para probar que las nuevas implementaciones vía .htaccess funcionan, recomendamos desactivar Bot Protection y luego activarlo nuevamente. Al hacer eso, se borrarán todos los datos previos de los reportes y registros del sistema, pero nos permitirá tener mayor claridad respecto a los nuevos datos de intento de inicio de sesión y nombres de bots peligrosos que intentaron algo contra nuestra página web.

Así se verán los reportes luego de desactivar y activar Bot Protection:

¿Cómo asegurar y optimizar WordPress en Cloudways?

¿Cómo mejorar el rendimiento de nuestro Servidor en Cloudways?

¿Cómo asegurar y optimizar WordPress en Cloudways?

En algunas ocasiones, el problema no son los bots agresivos, sino que el Servidor puede consumir muchos recursos en un momento específico debido a las tareas de mantenimiento o las copias de seguridad programadas. El problema es cuando el consumo del CPU es alto de forma constante a lo largo del día. Para saber eso, debemos ir a:

  • Server Management
  • Monitoring
  • Details
  • Idle CPU
  • Elegir el intervalo de tiempo

Idle CPU nos muestra la CPU disponible a lo largo del intervalo del tiempo solicitado, si el valor de Idle CPU es de 20 % o menos de durante la mayor parte del día, significa que nuestro Servidor está mal optimizado o necesitamos escalar a uno con mejores prestaciones. Cuando el valor de Idle CPU está cerca a 0 es un mal indicador, cuando el valor de Idle CPU está cerca a 100 %, es un buen indicador.

En el caso de la imagen, el equipo de soporte técnico afirmó que fueron procesos automáticos de limpieza y que es normal que consuman mucho CPU en momentos específicos debido a que son procesos del sistema operativo. Es como cuando en nuestra computadora renderizamos un video, compilamos un software o ejecutamos una tarea que requiere de la potencia del hardware. No ocurrirá nada malo, solo que en esos momentos se registrará el uso más intenso de los recursos.

En soporte técnico vieron la siguiente información:

¿Cómo asegurar y optimizar WordPress en Cloudways?

Al respecto, respondieron lo siguiente: "Estos problemas ocurren debido a un cuello de botella de memoria y se activa OOM Killer. Hay muchos procesos de automatización en ejecución que mantienen los servicios activos incluso si la memoria es baja, pero es necesario incrementar los valores por defecto". El equipo de soporte técnico validó los siguientes valores cambiados.

Podemos incrementar los siguientes valores en nuestro Servidor:

  • Execution Limit
  • Memory Limit
  • Max Input Time en PHP
  • OPCache Memory en PHP
  • Max Connections Limit en MySQL
  • Buffer Pool Size en MySQL
  • Static Cache Expiry en NGINX

Para hacerlo, debemos ir a:

  • Server Management
  • Settings and Packages

En la sección Basic editamos lo siguiente:

  • Execution Limit: 300 incrementamos a 900
  • Upload Size: establecemos 512
  • Memory Limit: 512 incrementamos a 1024
  • Clic en Save Changes

En la sección Advanced editamos lo siguiente:

  • Max Input Time en PHP: 64 incrementamos a 128
  • OPCache Memory en PHP: 64 incrementamos a 256
  • Max Connections Limit en MySQL: 150 incrementamos a 450
  • Buffer Pool Size en MySQL: 10 incrementamos a 128
  • Lock Wait Timeout en MySQL: establecemos 120
  • Wait Timeout en MySQL: establecemos 30
  • Static Cache Expiry en NGINX: 42300 incrementamos a 525600

Sugerimos revisar este artículo de Cloudways para conocer los valores que recomiendan en Servidores con características específicas.

¿Cómo mejorar el rendimiento de nuestra Aplicación en Cloudways?

También es posible que, debido al alto tráfico de bots maliciosos, nuestra página web cargue lento. Para evitar problemas de rendimiento, si contamos con 2GB de RAM o más en nuestro Servidor, podemos editar el límite de memoria y aumentar el máximo tiempo de ejecución de PHP.

¿Cómo asegurar y optimizar WordPress en Cloudways?

Para ello debemos elegir nuestra Aplicación e ir a:

  • Application Management
  • Application Settings
  • PHP FPM Settings
  • Asignar php_admin_value[memory_limit] = 512M
  • Asignar php_admin_value[max_execution_time] = 240

De esta forma, estamos aumentando considerablemente los valores por defecto. Esta recomendación fue validada por soporte técnico de Cloudways. También podemos consultar más información sobre los cambios en PHP FPM desde aquí.

¿Usamos WP Rocket o Varnish?

Según la recomendación de Cloudways, lo mejor es usar ambos sistemas, ya que Varnish habilitará la caché a nivel de Servidor, mientras que WP Rocket la activará a nivel de Aplicación.

Lo bueno es que la versión más reciente de WP Rocket detecta que estamos alojados en Cloudways y automáticamente habilita su compatibilidad con Varnish para que no tengamos que buscar entre las opciones del plugin de WordPress.

Backup completo del Servidor

¿Cómo asegurar y optimizar WordPress en Cloudways?

Cada vez que hacemos clic en "Take Backup Now" se eliminará el backup local previo y se generará una nueva copia del momento con el mismo nombre: backup.tgz.

Recomendamos que la programación del backup completo no se realice en una hora punta o múltiplo de de 15 minutos, ya que más adelante brindaremos una indicación sobre esos 15 minutos y el proceso Cron. Recomendamos programar los backups a horas como 03:03 UTC, entre otras similares.

Sugerimos que en su cliente FTP creen accesos directos a la ruta de las copias de seguridad de sus Aplicaciones, comprobando el nombre en código de cada Aplicación a través de:

  • Application Management
  • Access Details
  • Username en MySQL Accesss

Tanto el nombre de la base de datos como el usuario son el nombre en código de nuestra Aplicación, debemos tener cuidado de ello al hacer un acceso directo en nuestro cliente FTP.

Deshabilitando WP-Cron y usando el Cron de Cloudways

Cron es importante porque se encarga de ejecutar los procesos programados como la publicación de un artículo,

Un plugin que nos puede ayudar para visualizar lo programado con WP Cron es WP-Control, el cual también nos permite ejecutar actividades de forma programada.

Si tenemos una web con pocas visitas, podemos programar el evento Cron cada 5 minutos, mientras que si tenemos muchas visitas, podemos programarlo cada 15 minutos o más. Sin embargo, como también recomendamos usar un plugin de caché tipo WP Rocket, lo mejor sería no distanciar tanto la ejecución de estos eventos y decidir por establecer los intervalos de Cron a 15 minutos como máximo.

Desde un cliente FTP editamos el archivo wp-config.php y añadimos la siguiente línea:

define('DISABLE_WP_CRON', true);

Luego vamos a nuestra Aplicación en Cloudways:

  • Application Management
  • Cron Job Management
  • Advanced

En ese apartado ponemos lo siguiente:

*/15 * * * * wget -q -O - https://nuestrodominio.com/wp-cron.php?doing_wp_cron

Veamos cómo quedaría en Cloudways:

¿Cómo asegurar y optimizar WordPress en Cloudways?

Al aplicar esto, cada 15 minutos se ejecutará el Cron desde nuestro Servidor. Es decir a las siguientes horas:

  • 00:15 hrs
  • 00:30 hrs
  • 00:45 hrs
  • 01:00 hrs
  • 01:15 hrs
  • Continúa la secuencia durante las 24 horas

De esta fácil manera logramos optimizar los recursos del Servidor que son usados para tareas programadas como actualizaciones de WordPress, plugins, plantillas, publicaciones programadas, etc.

Para saber si Cron está funcionando o no, podemos solicitar la comprobación a soporte técnico o programar una publicación de WordPress y ver el resultado.

También, vía SSH, podemos ejecutar el siguiente código:

wp cron event list

Es importante recordar que Cron funcionará cuando tengamos una visita no cacheada. Eso quiere decir que si programamos una publicación y no tenemos visitas cacheadas, no se verá nuestra nueva publicación; sin embargo, cuando tenemos visitas cacheadas deberá iniciar sesión un usuario de WordPress o se deberá vaciar el caché para que se ejecute el Cron.

Esto no nos debe preocupar porque, justamente, excluiremos wp-cron.php del sistema de caché, de esta forma automáticamente siempre se ejecutarán las tareas programadas.

Exclusión de wp-cron.php en WP Rocket

¿Cómo asegurar y optimizar WordPress en Cloudways?

Tal como indicamos previamente, tan solo debemos excluir lo siguiente en WP Rocket:

/wp-cron.php

Vaciamos WP Rocket y ya no nos preocuparemos más por este asunto, todo funcionará perfectamente según la programación del Cron cada 15 minutos.

Desactivar la precarga en WP Rocket

¿Cómo asegurar y optimizar WordPress en Cloudways?

Ya que estamos en WP Rocket, no olvidemos desactivar las opciones de precarga, las cuales consumen mucho CPU de nuestro Servidor.

El caso de admin-ajax.php y el Heartbeat

Podemos optimizar nuestras Aplicaciones WordPress en Cloudways de la siguiente manera:

El soporte técnico de Cloudways nos recomienda usar el plugin Heartbeat Control para modificar los latidos a 120 segundos o más. También indican que podemos desactivar de forma segura el Heartbeat por ser usado en el backend.

Entonces, tenemos dos opciones:

  • Aumentar los segundos del Heartbeat
  • Desactivar el Heartbeat

Recomendamos que realicen todas las pruebas necesarias en un entorno Staging, el cual sirve para determinar si un cambio podría o no afectar a nuestro sitio web, ya que algunos plugins podrían usar las solicitudes Ajax.

Entre las funciones que permite Heartbeat API se encuentran las siguientes:

  • Guardado automático
  • Bloquea las publicaciones que están siendo editadas por otros autores

Las solicitudes se realizan cada 15 a 30 segundos mientras se tiene la pestaña abierta del navegador en la consola de administración de WordPress. Desde Cloudways nos brindan una guía realizada por ellos.

Configurar Heartbeat en WP Rocket y Perfmatters

¿Cómo asegurar y optimizar WordPress en Cloudways?

Tal como vemos, en el plugin WP Rocket debemos seleccionar lo siguiente en Heartbeat:

  • Desactivar: Comportamiento en backend
  • Reducir actividad: Comportamiento en el editor de entradas
  • Desactivar: Comportamiento en frontend

En el plugin Perfmatters, recomendamos seleccionar las siguientes opciones:

  • Disable Heartbeat: Only Allow When Editing Posts/Pages
  • Heartbeat Frequency: 60 Seconds
  • Limit Post Revisions: Disable Post Revisions
  • Autosave Interval: 1 Minute (Default)

¿Cómo asegurar y optimizar WordPress en Cloudways?

De esta forma, Heartbeat únicamente estará habilitado en las entradas y páginas que se editan, las revisiones se mantendrán desactivadas y el intervalo de guardado automático será de 1 minuto. A pesar de elegir 1 minuto, por algún motivo, lo hace cada 2 minutos, según nuestras pruebas realizadas.

¿Por qué no configurar el guardado automático cada 5 minutos? Efectivamente, las publicaciones se guardarían cada 5 minutos configurando Perfmatters; sin embargo, comprobamos que WP Rocket obliga a que el Heartbeat sea cada 2 minutos, por lo que WordPress siempre enviará solicitudes automáticas cada 2 minutos a /wp-admin/admin-ajax.php. Sabiendo que será lo mismo configurar el guardado automático cada 1 o 5 minutos, nosotros preferimos que el intervalo establecido vía Perfmatters sea cada 1 minuto.

Al aplicar estos cambios, no necesitaremos añadir código a functions.php ni instalar otros plugins como Heartbeat Control. WP Rocket y Perfmatters cuentan con las opciones para modificar la frecuencia de Heartbeat y también para desactivarla fácilmente; sin embargo, recomendamos no desactivar Heartbeat, ya que perderíamos la importante función de guardado automático.

Usualmente, nosotros desactivamos las revisiones porque no las usamos; sin embargo, la función de guardado automático es vital debido a que podríamos perder la conexión, cerrar la página de casualidad u ocurrir cualquier tipo de evento adverso y perderíamos todo lo avanzado hasta antes de dar clic en el botón de guardar.

El guardado automático funciona tanto con los borradores como en los artículos publicados. En el caso de los borradores, el contenido del artículo se mantendrá siempre actualizado; mientras que en el caso de los artículos publicados, la versión más actualizada se guardará en segundo plano y veremos el siguiente mensaje arriba del título del artículo al editarlo:

"Hay un guardado automático de esta entrada que es más reciente que la versión de abajo. Ver el guardado automático".

¿Cómo asegurar y optimizar WordPress en Cloudways?

Es necesario evaluar si realmente necesitamos tener la API Heartbeat activa para nuestra página web.

Configuración de Perfmatters

¿Cómo asegurar y optimizar WordPress en Cloudways?

Recomendamos configurar el plugin Perfmatters tal como se puede ver en la imagen para optimizar aún más el desempeño de nuestro WordPress.

Gestión del rastreo con Robots.txt

A algunos bots maliciosos les impediremos el acceso, mientras que a otros los limitaremos para evitar un consumo excesivo de recursos de nuestro Servidor.

Es importante que el archivo robots.txt incluya nuestro sitemap. Si usamos Google AdSense como fuente de publicidad, lo mejor será añadir instrucciones específicas.

Si para nosotros es importante que nuestras métricas SEO sean conocidas por motivos comerciales, lo mejor será no impedir el acceso a Semrush, Ahrefs porque tienen prestigio en ese sector; sin embargo, vamos a limitar su frecuencia de rastreo para que no afecte negativamente esta actividad al desempeño de nuestro Servidor.

Este es un modelo de robots.txt que podemos usar:

User-agent: *
Allow: /
Disallow: /wp-content/plugins/
Disallow: /wp-admin/
Disallow: /wp-includes/
Crawl-delay: 100

#Google Images
User-agent: Googlebot-Image
Allow: /

#Google Adsense
User-agent: Mediapartners-Google
Allow: /

Sitemap: https://nuestrodominio.com/sitemap_index.xml

#Reduce la frecuencia
User-agent: Bingbot
Crawl-delay: 100

User-agent: Slurp
Crawl-delay: 100

User-agent: SemrushBot
Crawl-delay: 100

User-agent: SemrushBot-SA
Crawl-delay: 100

User-agent: AhrefsBot
Crawl-delay: 100

User-agent: Baiduspider
Crawl-delay: 100

#Bloquea bots de mala reputación
User-agent: Scrapy
Disallow:/

User-agent: wget
Disallow: /

User-agent: Barkrowler
Disallow: /

User-agent: DataForSeoBot
Disallow: /

User-agent: NPBot
Disallow: /

User-agent: UbiCrawler
Disallow: /

User-agent: DOC
Disallow: /

User-agent: Zao
Disallow: /

User-agent: gsa-crawler
Disallow: /

User-agent: YandexBot
Disallow: /

User-agent: Yandex
Disallow: /

User-agent: YandexImages
Disallow: /

User-agent: WebReaper
Disallow: /

User-agent: CNCDialer
Disallow: /

User-agent: Maxthon
Disallow: /

User-agent: MJ12bot
Disallow: /

User-agent: sitecheck.internetseer.com
Disallow: /

User-agent: Zealbot
Disallow: /

User-agent: MSIECrawler
Disallow: /

User-agent: SiteSnagger
Disallow: /

User-agent: WebStripper
Disallow: /

User-agent: WebCopier
Disallow: /

User-agent: Fetch
Disallow: /

User-agent: Offline Explorer
Disallow: /

User-agent: Teleport
Disallow: /

User-agent: TeleportPro
Disallow: /

User-agent: WebZIP
Disallow: /

User-agent: linko
Disallow: /

User-agent: HTTrack
Disallow: /

User-agent: Microsoft.URL.Control
Disallow: /

User-agent: Xenu
Disallow: /

User-agent: larbin
Disallow: /

User-agent: libwww
Disallow: /

User-agent: ZyBORG
Disallow: /

User-agent: Download Ninja
Disallow: /

User-agent: PetalBot
Disallow: /

Uso de formularios de terceros

¿Cómo asegurar y optimizar WordPress en Cloudways?

Existen muchos plugins de WordPress para insertar formularios en la plataforma; sin embargo, tienen algunas desventajas:

  • Reducen la velocidad de las páginas web
  • Requieren de conocimientos de programación
  • Requieren de una configuración avanzada
  • Se deben actualizar periódicamente
  • Consumen espacio y recursos del Servidor
  • Atraen a bots maliciosos y spammers

¿Nos convendría estar defendiendo nuestra web de spammers y bots diariamente? No. Por ello, recomendamos usar los servicios especializados de empresas de prestigio como las siguientes:

Dejemos que estas empresas se encarguen de lo más complicado en la gestión de formularios y nosotros centrémonos en nuestros negocios.

Recomendaciones finales

Cuando aplicamos todas las recomendaciones de este artículo, logramos que el promedio de consumo del CPU en nuestro Servidor sea alrededor del 5 %, mientras que si no aplicamos esta recomendación el consumo promedio del CPU en nuestro Servidor era de alrededor del 40 %.

¿Se acuerdan que hablamos de Idle CPU? Ahora, nuestro valor promedio es de 95 a 100, cuando no habíamos implementado todos estos cambios el valor promedio de Idle CPU era de 50 a 60. La optimización funciona.

Con estas reglas en .htaccess prácticamente podemos jubilar el sistema Bot Protection de Cloudways. Veremos que prácticamente no tendrá trabajo que hacer; sin embargo, el análisis que nos permite es más gráfico y legible que hacerlo desde los Logs. Algo importante es que Bot Protection no registra los bloqueos efectivos de nuestro código en .htaccess, sino únicamente registra lo que su propio sistema detecta y bloquea; sin embargo, podemos ver desde los Logs lo efectivo que es nuestro código cuando el Servidor da una respuesta 403 a los bots maliciosos.

Nuestra recomendación es que consideren mantener activo Bot Protection por si hay nuevas formas de ataque en las que tengamos que trabajar en una próxima ocasión. Veamos a Bot Protection en acción ante algunos escenarios:

¿Cómo asegurar y optimizar WordPress en Cloudways?

De esta forma, Bot Protection nos ayuda a identificar fácilmente el modo de acción de estos bots maliciosos para poder actuar en consecuencia.

Compartir noticia
       

TECNOLOGÍA 21

Medio especializado en publicaciones tecnológicas con enfoque en negocios desde 2007.

Nuestro alcance principal comprende Iberoamérica.

Reservar atención online

SERVICIOS

Publicidad para empresas
Coberturas y entrevistas
Análisis de productos y servicios

NEWSLETTER SEMANAL

Noticias de tecnología y negocios
Enlaces Archivo / Condiciones

Estás viendo: “¿Cómo asegurar y optimizar WordPress en Cloudways?