# Administración de Sistemas WordPress > WP SysAdmin --- ## Páginas - [Pruebas de WordPress para empresas de hosting](https://www.wpsysadmin.com/hosting/): Última revisión: 26 de enero de 2022 Las empresas de hosting pueden tener alojados centenares de sitos web con WordPress,... - [Newsletter](https://www.wpsysadmin.com/newsletter/) - [El módulo opcional, intl, no está instalado, o ha sido desactivado.](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-intl/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [Servicios](https://www.wpsysadmin.com/servicios/): Algunos de los servicios que ofrecemos para optimizar tu WordPress. Instalación y Configuración Te instalamos un WordPress en un servidor... - [Open Source](https://www.wpsysadmin.com/opensource/): Última revisión: 2 de octubre de 2021 WordPress es un gestor de contenidos de código abierto (open source) y gracias... - [WordPress en AlmaLinux 8.4 (nginx, MariaDB, PHP, Redis)](https://www.wpsysadmin.com/instalacion/almalinux-84-nginx-mariadb-php-redis/): Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: AlmaLinux 8. 4Servidor web: nginxBase de Datos: MariaDBProcesador:... - [El módulo opcional, xmlreader, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-xmlreader/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, zlib, no está instalado, o ha sido desactivado.](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-zlib/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [La zona horaria por defecto de PHP no es válida](https://www.wpsysadmin.com/requerimientos/saludsitio-zonahoraria-invalida/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, libsodium, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-libsodium/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, openssl, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-openssl/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, pcre, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-pcre/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, imagick, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-imagick/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, mod_xml, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-xml/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, zip, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-zip/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, filter, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-filter/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, gd, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-gd/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, iconv, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-iconv/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, mcrypt, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-mcrypt/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, simplexml, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-simplexml/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, curl, no está instalado, o ha sido desactivado.](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-curl/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [Tu sitio no tiene ningún tema por defecto](https://www.wpsysadmin.com/requerimientos/saludsitio-tema-pordefecto/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, dom, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-dom/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, exif, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-exif/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, fileinfo, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-fileinfo/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, hash, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-hash/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo requerido, json, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-json/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, mbstring, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-mbstring/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [El módulo opcional, mysqli, no está instalado, o ha sido desactivado](https://www.wpsysadmin.com/requerimientos/saludsitio-modulo-php-mysqli/): Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el... - [Firewall para Ubuntu con CrowdSec para WordPress](https://www.wpsysadmin.com/extra/crowdsec/): Última revisión: 2 de octubre de 2021 Disponer de un cortafuegos (firewall) a nivel de Sistema Operativo no es una... - [Plesk Obsidian 18 en Ubuntu 20](https://www.wpsysadmin.com/instalacion/plesk-18-ubuntu-20/): Última revisión: 2 de octubre de 2021 Este tutorial ha sido creado en gracias a una licencia de Plesk. Consigue... - [WordPress en Ubuntu 20 con Base de Datos master-slave](https://www.wpsysadmin.com/instalacion/ubuntu-20-mariadb-master-slave/): Última revisión: 2 de octubre de 2021 En algunos momentos podemos tener la necesidad de incrementar el rendimiento de una... - [PHP Antimalware Scanner para WordPress](https://www.wpsysadmin.com/extra/awscan/): Última revisión: 2 de octubre de 2021 Una de las mayores preocupaciones de los usuarios de WordPress es tener algún... - [WordPress en Ubuntu 20 con Tor (nginx, MariaDB, PHP, Redis)](https://www.wpsysadmin.com/instalacion/ubuntu-20-tor-nginx-mariadb-php-redis/): Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: Ubuntu 20Panel de Control: ningunoServidor web: nginxBase de... - [.conf para nginx](https://www.wpsysadmin.com/seguridad/hosting/conf/): Última revisión: 2 de octubre de 2021 Si utilizas nginx, a parte del fichero general de configuración del servidor, es... - [Firewall con WAF for WordPress](https://www.wpsysadmin.com/extra/waf4wordpress/): Última revisión: 2 de octubre de 2021 Si queremos bloquear de forma automática algunos ataques podemos usar fail2ban, una herramienta... - [WP-CLI como herramienta de análisis](https://www.wpsysadmin.com/mantenimiento/wpcli-herramienta-analisis/): Última revisión: 2 de octubre de 2021 Si aún no tienes WP-CLI, instálalo en tu servidor. Una vez lo tengas,... - [Prueba de rendimiento con WP Performance Tester](https://www.wpsysadmin.com/extra/wpperformancetester/): Última revisión: 2 de octubre de 2021 Gracias al plugin WPPerformanceTester podemos realizar de forma sencilla algunas pruebas de rendimiento... - [WordOps para gestionar VPS de WordPress](https://www.wpsysadmin.com/extra/wordops/): Última revisión: 2 de octubre de 2021 Si tenemos WP-CLI que nos permite gestionar por completo todo lo que hay... - [WordPress estático con WP2static](https://www.wpsysadmin.com/extra/wp2static/): Última revisión: 2 de octubre de 2021 Si tenemos sitios sencillos, simplemente con información, pero en los cuales los usuarios... - [Herramientas extra de WordPress](https://www.wpsysadmin.com/extra/): Última revisión: 2 de octubre de 2021 Existen herramientas propias o externas de WordPress que nos sirven para realizar algunas... - [Seguridad WordPress con WPScan](https://www.wpsysadmin.com/extra/wpscan/): Última revisión: 2 de octubre de 2021 WordPress es un sistema seguro, pero siempre podemos esperar ataques de otros hackers... - [WordPress en Ubuntu 20 (nginx, MariaDB, PHP, Redis)](https://www.wpsysadmin.com/instalacion/ubuntu-20-nginx-mariadb-php-redis/): Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: Ubuntu 20 LTEServidor web: nginxBase de Datos: MariaDB... - [Pruebas en Ubuntu 18 y PHP 7](https://www.wpsysadmin.com/hosting/prueba-ubuntu-18-php-7/): Última revisión: 2 de octubre de 2021 Si quieres hacer pruebas en un entorno de desarrollo (sin necesidad de enviar... - [WordPress en Ubuntu 18 (nginx, MariaDB, PHP, Redis)](https://www.wpsysadmin.com/instalacion/ubuntu-18-nginx-mariadb-php-redis/): Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: Ubuntu 18Panel de Control: ningunoServidor web: nginxBase de... - [WordPress en Ubuntu 19 (nginx, MariaDB, PHP, Redis)](https://www.wpsysadmin.com/instalacion/ubuntu-19-nginx-mariadb-php-redis/): Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: Ubuntu 19Panel de Control: ningunoServidor web: nginxBase de... - [.htaccess para Apache y LiteSpeed](https://www.wpsysadmin.com/seguridad/hosting/htaccess/): Última revisión: 2 de octubre de 2021 Si utilizas Apache HTTPD o LiteSpeed o cualquier sistema basado en estos servidores... - [Mejorar el rendimiento de WordPress](https://www.wpsysadmin.com/rendimiento/): Última revisión: 2 de octubre de 2021 WordPress es un sistema estable pero que depende del rendimiento del sistema operativo,... - [Herramientas de mantenimiento de WordPress externas](https://www.wpsysadmin.com/mantenimiento/mantenimiento-externo/): Última revisión: 2 de octubre de 2021 En el caso de tener que gestionar muchos WordPress, puedes hacer uso de... - [Copia de seguridad para WordPress](https://www.wpsysadmin.com/mantenimiento/backup/): Última revisión: 2 de octubre de 2021 WordPress no incorpora por defecto ningún tipo de sistema de copia de seguridad... - [Monitorización de WordPress](https://www.wpsysadmin.com/mantenimiento/monitorizacion/): Última revisión: 2 de octubre de 2021 Tener herramientas de monitorización va a permitirte comprobar si el sitio funciona correctamente,... - [Desarrollar con WordPress](https://www.wpsysadmin.com/desarrollo/): Última revisión: 2 de octubre de 2021 Para aportar a WordPress a nivel de desarrollo existen múltiples posibilidades y opciones.... - [Servidor virtual para WordPress con Git](https://www.wpsysadmin.com/desarrollo/vps-con-git/): Última revisión: 2 de octubre de 2021 Si alguna vez te has planteado contribuir a WordPress, existen muchas formas de... - [Servidor virtual para WordPress con Subversion](https://www.wpsysadmin.com/desarrollo/vps-con-svn/): Última revisión: 2 de octubre de 2021 Si alguna vez te has planteado contribuir a WordPress, existen muchas formas de... - [Probar un patch del Trac de WordPress](https://www.wpsysadmin.com/desarrollo/probar-patch/): Última revisión: 2 de octubre de 2021 Puede que no seas desarrollador, pero que sepas programar y te guste probar... - [Pruebas con PHPUnit 7 para WordPress](https://www.wpsysadmin.com/desarrollo/pruebas-phpunit/): Última revisión: 2 de octubre de 2021 Una de las formas de colaborar en el código de WordPress es verificar... - [Artículos del Blog](https://www.wpsysadmin.com/blog/) - [Requisitos para instalar WordPress](https://www.wpsysadmin.com/requerimientos/): Última revisión: 28 de diciembre de 2021 Aunque WordPress puede funcionar en prácticamente cualquier entorno, aunque sea muy mínimo, hay... - [Instalación de WordPress](https://www.wpsysadmin.com/instalacion/): Última revisión: 2 de octubre de 2021 Si necesitas una instalación paso a paso de tu WordPress, puedes probar con... - [WordPress en CentOS 7 (CyberPanel, LiteSpeed)](https://www.wpsysadmin.com/instalacion/centos-7-cyberpanel-litespeed/): Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: CentOS 7Panel de Control: CyberPanelServidor web: LiteSpeedBase de... - [WordPress en CentOS 7 (nginx, MariaDB, PHP, Redis)](https://www.wpsysadmin.com/instalacion/centos-7-nginx-mariadb-php-redis/): Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: CentOS 7Panel de Control: ningunoServidor web: nginxBase de... - [WordPress en Debian 9 (nginx, MariaDB, PHP, Redis)](https://www.wpsysadmin.com/instalacion/debian-9-nginx-mariadb-php-redis/): Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: Debian 9Panel de Control: ningunoServidor web: nginxBase de... - [WordPress en Ubuntu 18 (LiteSpeed, MariaDB, PHP, Redis)](https://www.wpsysadmin.com/instalacion/ubuntu-18-litespeed-mariadb-php-redis/): Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: Ubuntu 18Panel de Control: ningunoServidor web: LiteSpeedBase de... - [Contacto](https://www.wpsysadmin.com/contacto/): ¿Necesitas ayuda con la Administración de Sistemas de WordPress? ¿Tienes alguna idea o sugerencia para publicar en WPSysAdmin? Por favor,... - [Cambiar las carpetas por defecto de WordPress](https://www.wpsysadmin.com/seguridad/wordpress/carpetas-defecto/): Última revisión: 2 de octubre de 2021 Cuando hablas de WordPress es un clásico hablar del «uvedoblepé content» haciendo referencia... - [Seguridad de los usuarios en WordPress](https://www.wpsysadmin.com/seguridad/wordpress/usuarios/): Última revisión: 2 de octubre de 2021 En WordPress los usuarios tienen un peso importante en el sistema. Tanto si... - [Impedir acceso a servidores externos desde WordPress](https://www.wpsysadmin.com/seguridad/wordpress/servidores-externos/): Última revisión: 2 de octubre de 2021 WordPress es un gestor de contenidos que permite infinidad de opciones, entre ellas... - [Limpieza de multimedia en WordPress](https://www.wpsysadmin.com/seguridad/wordpress/limpieza-multimedia/): Última revisión: 2 de octubre de 2021 Subir imágenes, editarlas, recortarlas y volver a empezar. Sin duda uno de los... - [Unificar CSS y JavaScript en WordPress](https://www.wpsysadmin.com/seguridad/wordpress/unificar-css-js/): Última revisión: 2 de octubre de 2021 En general los ficheros de estilo (CSS) y los de scripting (JavaScript) incluyen... - [Servicio externo de correo](https://www.wpsysadmin.com/seguridad/hosting/servicio-smtp/): Última revisión: 2 de octubre de 2021 El correo basura (spam), esa lacra de Internet que muchos sufrimos todos los... - [Eliminar cabeceras y metas de WordPress](https://www.wpsysadmin.com/seguridad/wordpress/cabeceras-inconvenientes/): Última revisión: 2 de octubre de 2021 Como la mayor parte de gestores de contenidos, WordPress se identifica claramente y... - [Configurar el robots.txt de WordPress](https://www.wpsysadmin.com/seguridad/wordpress/robotstxt/): Última revisión: 2 de octubre de 2021 El fichero de robots. txt que ha de estar en la carpeta raíz... - [Instalar un Anti Spam en WordPress](https://www.wpsysadmin.com/seguridad/activa/antispam/): Última revisión: 2 de octubre de 2021 Un ataque habitual en los sitios con WordPress (principalmente en aquellos que están... - [Analiza tus enlaces de WordPress](https://www.wpsysadmin.com/seguridad/activa/analiza-enlaces/): Última revisión: 2 de octubre de 2021 La seguridad no sólo consiste en que tú te protejas sino también en... - [Bloquear XML-RPC en WordPress](https://www.wpsysadmin.com/seguridad/wordpress/xml-rpc/): Última revisión: 2 de octubre de 2021 Una de las ventajas de WordPress es su flexibilidad a la hora de... - [Aplica el Sentido Común en tu sitio WordPress](https://www.wpsysadmin.com/seguridad/general/sentido-comun/): Última revisión: 2 de octubre de 2021 Dicen que el sentido común es el menos común de los sentidos, y... - [GDPR (General Data Protection Regulation) y WordPress](https://www.wpsysadmin.com/seguridad/general/gdpr/): Última revisión: 2 de octubre de 2021 A partir de finales de mayo de 2018 las empresas europeas, que trabajen... - [Eliminar copias antiguas de entradas en WordPress](https://www.wpsysadmin.com/seguridad/base-de-datos/copias-antiguas/): Última revisión: 2 de octubre de 2021 Una vez más volvemos a temas que afectan principalmente a rendimiento y, en... - [Configurar caché en WordPress](https://www.wpsysadmin.com/seguridad/wordpress/cache/): Última revisión: 2 de octubre de 2021 Una vez más, lo que probablemente sea una recomendación general y muy útil,... - [Configurar una plantilla por defecto en WordPress](https://www.wpsysadmin.com/seguridad/wordpress/plantilla-por-defecto/): Última revisión: 2 de octubre de 2021 Aunque normalmente no es algo que suela pasar, es posible que tu plantilla... - [Copias de seguridad en WordPress](https://www.wpsysadmin.com/seguridad/activa/copias-de-seguridad/): Última revisión: 2 de octubre de 2021 Si hablamos de seguridad hemos de hablar de copias de seguridad (backups). No... - [Configurar herramientas para webmasters en WordPress](https://www.wpsysadmin.com/seguridad/activa/webmasters/): Última revisión: 2 de octubre de 2021 Tener un WordPress es tener un sitio web, y como tal te convierte... - [WordPress y CDN](https://www.wpsysadmin.com/seguridad/activa/cdn/): Última revisión: 2 de octubre de 2021 A la hora de escalar, cachear, evitar ataques nunca hay una situación ideal,... - [Configurar licencias en WordPress](https://www.wpsysadmin.com/seguridad/activa/licencias/): Última revisión: 2 de octubre de 2021 Existen servicios de pago que requieren una licencia para funcionar y habitualmente estas... - [Versión mínima de PHP para WordPress](https://www.wpsysadmin.com/seguridad/desarrollo/version-php/): Última revisión: 2 de octubre de 2021 Desde hace unas pocas versiones de WordPress, todos aquellos desarrolladores de plugins pueden... - [Ocultar la versión de WordPress](https://www.wpsysadmin.com/seguridad/wordpress/ocultar-version/): Última revisión: 2 de octubre de 2021 El primer punto de inicio a la hora de atacar un WordPress es... - [Usar WP-CLI para el mantenimiento de WordPress](https://www.wpsysadmin.com/mantenimiento/wpcli/): Última revisión: 2 de octubre de 2021 Hacer mantenimiento de un sitio WordPress no suele ser complejo, pero a veces... - [Mitigar el CVE-2018-6389 de WordPress](https://www.wpsysadmin.com/seguridad/vulnerabilidades/cve-2018-6389/): Última revisión: 2 de octubre de 2021 Aunque no suele ser muy normal, de tanto en tanto aparecen vulnerabilidades en... - [Limpiar un hackeo](https://www.wpsysadmin.com/seguridad/especial/limpiar/): Última revisión: 2 de octubre de 2021 Es posible que te hayan infectado, hackeado, atacado... cualquiera de estas opciones es... - [Seguridad en las cookies de WordPress](https://www.wpsysadmin.com/seguridad/wordpress/cookies/): Última revisión: 2 de octubre de 2021 Almacenar la información segura para saber quién está navegando por tu WordPress es... - [Desactivar el HTTP TRACE / TRACK](https://www.wpsysadmin.com/seguridad/hosting/desactivar-trace-track/): Última revisión: 2 de octubre de 2021 TRACK y TRACE son dos métodos que vienen por defecto con Apache HTTPD... - [Desactivar los Emoji de WordPress](https://www.wpsysadmin.com/seguridad/wordpress/emoji/): Última revisión: 2 de octubre de 2021 WordPress integra los Emoji desde hace muchas versiones, convirtiendo los iconos de texto... - [Subir ficheros de cualquier tipo a WordPress](https://www.wpsysadmin.com/seguridad/wordpress/ficheros-media/): Última revisión: 2 de octubre de 2021 Cuando hablamos de subir elementos multimedia a través del panel de administración solemos... - [Configurar un Firewall o WAF en WordPress](https://www.wpsysadmin.com/seguridad/activa/firewall-waf/): Última revisión: 2 de octubre de 2021 Y si hacer copias de seguridad podríamos considerarlo seguridad pasiva, también podemos activar... - [WP-Config: la configuración de WordPress](https://www.wpsysadmin.com/seguridad/wordpress/wpconfig/): Última revisión: 2 de octubre de 2021 El fichero de configuración de WordPress esconde muchas funcionalidades que ayudan a mejorar... - [Cómo auditar tu WordPress](https://www.wpsysadmin.com/seguridad/activa/auditor/): Última revisión: 2 de octubre de 2021 Cuando hablamos de seguridad hay que tener un plan de prevención para poder... - [Verificar el checksum de WordPress](https://www.wpsysadmin.com/seguridad/activa/checksum/): Última revisión: 2 de octubre de 2021 Una de las formas más rápida para verificar si un sitio WordPress ha... - [Mantenimiento de WordPress](https://www.wpsysadmin.com/mantenimiento/): Última revisión: 2 de octubre de 2021 WP-CLI Usar WP-CLI para el mantenimiento de WordPress Hacer mantenimiento de un sitio... - [Seguridad para WordPress](https://www.wpsysadmin.com/seguridad/): Última revisión: 2 de octubre de 2021 Aquí vas a encontrar distintos elementos relacionados con la Seguridad de WordPress. Hay... - [Seguridad General para WordPress](https://www.wpsysadmin.com/seguridad/general/): Última revisión: 2 de octubre de 2021 Aprende elementos generales y básicos sobre la Seguridad de WordPress, además de las... - [Especiales de Seguridad WordPress](https://www.wpsysadmin.com/seguridad/especial/): Aquí tienes algunos materiales especiales sobre seguridad de WordPress y que, en principio, pueden aplicar muchos elementos de forma conjunta.... - [Seguridad para Hosting de WordPress](https://www.wpsysadmin.com/seguridad/hosting/): Última revisión: 2 de octubre de 2021 Los servidores de alojamiento web para WordPress permiten algunos elementos específicos de seguridad... - [Seguridad en la Base de Datos de WordPress](https://www.wpsysadmin.com/seguridad/base-de-datos/): Última revisión: 2 de octubre de 2021 Podemos aplicar algunos pequeños cambios para cambiar configuraciones por defecto de WordPress y... - [Seguridad en la Configuración de WordPress](https://www.wpsysadmin.com/seguridad/wordpress/): Última revisión: 2 de octubre de 2021 Aunque WordPress es muy seguro de por sí, existen ciertas posible configuraciones que... - [Seguridad Activa para WordPress](https://www.wpsysadmin.com/seguridad/activa/): Última revisión: 2 de octubre de 2021 A parte de las mejoras que se pueden realizar sobre el propio WordPress,... - [Seguridad para Desarrolladores de WordPress](https://www.wpsysadmin.com/seguridad/desarrollo/): Última revisión: 2 de octubre de 2021 Existen algunos elementos desde plugins y themes que permiten ayudar a mejorar la... - [Mitigación de Vulnerabilidades de WordPress](https://www.wpsysadmin.com/seguridad/vulnerabilidades/): Última revisión: 2 de octubre de 2021 Existen algunos problemas de seguridad con WordPress que, aunque quizá se hayan definido... - [Seguridad del alojamiento web de WordPress](https://www.wpsysadmin.com/seguridad/hosting/alojamiento-web/): Última revisión: 2 de octubre de 2021 Cuando hablamos de seguridad, alojamiento web y WordPress, la única conclusión a la... - [Versiones mínimas para que WordPress funcione](https://www.wpsysadmin.com/seguridad/hosting/versiones/): Última revisión: 2 de octubre de 2021 ¿Cuáles son las versiones mínimas requeridas para que WordPress funcione correctamente? En principio... - [Compatibilidad de PHP en WordPress](https://www.wpsysadmin.com/seguridad/hosting/php/): Última revisión: 2 de octubre de 2021 Si WordPress tiene un punto importante es el de PHP, y esto es... - [Actualizaciones automáticas de WordPress](https://www.wpsysadmin.com/seguridad/wordpress/actualizaciones-automaticas/): Última revisión: 2 de octubre de 2021 Mantener WordPress al día es la clave para evitar problemas de seguridad. WordPress... - [Comenzando con la Seguridad de WordPress](https://www.wpsysadmin.com/seguridad/general/comenzando/): Última revisión: 2 de octubre de 2021 WordPress es un sistema seguro, de código abierto y mantenido por la comunidad... - [Tipos de ataque sobre WordPress](https://www.wpsysadmin.com/seguridad/general/ataques/): Última revisión: 2 de octubre de 2021 Existen infinidad de posibles ataques a tu sitio, ya que existen infinidad de... - [Permisos de ficheros en WordPress](https://www.wpsysadmin.com/seguridad/hosting/permisos-de-ficheros/): Última revisión: 2 de octubre de 2021 Cuando se realiza una instalación nueva de WordPress, un elemento a tener presente... - [Tras la instalación de WordPress](https://www.wpsysadmin.com/seguridad/wordpress/post-instalacion/): Última revisión: 2 de octubre de 2021 Esta configuración que te presento se puede tener configurada previa a la instalación... - [Las Security Keys de WordPress](https://www.wpsysadmin.com/seguridad/wordpress/security-keys/): Última revisión: 2 de octubre de 2021 Cuando entras en tu panel de usuario de WordPress, o dejas un comentario,... - [Limitar el acceso a base de datos de WordPress](https://www.wpsysadmin.com/seguridad/base-de-datos/permisos-base-datos/): Última revisión: 2 de octubre de 2021 Con respecto a la base de datos (MySQL, MariaDB... ) hay pocas cosas... - [Contraseñas seguras para WordPress](https://www.wpsysadmin.com/seguridad/general/contrasenas/): Última revisión: 2 de octubre de 2021 ¿Qué podemos considerar hoy una contraseña segura? Pues probablemente una de 36 caracteres... - [Instalar un certificado TLS / SSL en WordPress](https://www.wpsysadmin.com/seguridad/hosting/certificado/): Última revisión: 2 de octubre de 2021 Cuando navegamos por Internet queremos hacerlo de forma segura. Para ello deberíamos navegar... - [Evitar la numeración de usuarios en WordPress](https://www.wpsysadmin.com/seguridad/base-de-datos/numeracion-usuarios/): Última revisión: 2 de octubre de 2021 Cuando se crean las tablas de WordPress, todos los sistemas de auto incremento... - [Bloquear PHP en uploads en WordPress](https://www.wpsysadmin.com/seguridad/hosting/bloquear-php/): Última revisión: 2 de octubre de 2021 En principio, cuando subes ficheros mediante el panel de Multimedia sólo se permiten... - [Bloquear la edición de ficheros en WordPress](https://www.wpsysadmin.com/seguridad/wordpress/edicion-ficheros/): Última revisión: 2 de octubre de 2021 Las personas, en general, somos curiosas por naturaleza y eso hace que, si... - [Forzar la URL del sitio WordPress](https://www.wpsysadmin.com/seguridad/wordpress/url-sitio/): Última revisión: 2 de octubre de 2021 Uno de los errores más habituales de un usuario administrador en el panel... - [Limitar el acceso a wp-admin de WordPress](https://www.wpsysadmin.com/seguridad/wordpress/acceso-wpadmin/): Última revisión: 2 de octubre de 2021 Aunque podemos cambiar las carpetas por defecto del sistema, no es posible cambiar... - [WordPress SysAdmin](https://www.wpsysadmin.com/): Hola (humano|robot|cosa), Bienvenido a WordPress SysAdmin, el sitio con información sobre Administración de Sistemas para WordPress. En este sitio vas... - [Legal / Privacidad](https://www.wpsysadmin.com/legal/): Propiedad del Sitio Mi nombre es Javier Casares con documento de identificación europeo ES53081177Y. Domicilio fiscal en Carrer de Wagner... --- ## Entradas - [Redirecciones canónicas: www vs. sin-www](https://www.wpsysadmin.com/blog/2022/07/31/redirecciones-canonicas/): Una de las decisiones que va por modas es el uso de un dominio con sitio web asociado y el... - [LMS: alojar tus vídeos de formación académica](https://www.wpsysadmin.com/blog/2022/07/29/lms-alojar-videos/): WordPress sirve para muchas cosas, y una de ellas es todo lo relacionado con los LMS (Learning Management Systems), los... - [Plesk: Redirección de dominio y Let's Encrypt](https://www.wpsysadmin.com/blog/2022/07/23/plesk-redireccion-letsencrypt/): Cuando tienes alojado un dominio en Plesk en el que quieres correo, pero el alojamiento va a ser una redirección,... - [Copias de seguridad WordPress con restic](https://www.wpsysadmin.com/blog/2022/07/10/wordpress-backup-restic/): Hacer copias de seguridad de sitios grandes con WordPress puede complicarse. Si este es tu caso, quizá te interese hacer... - [WordPress con HAProxy](https://www.wpsysadmin.com/blog/2022/07/07/wordpress-haproxy/): Tener varios WordPress en subdominios, carpetas, y sin usar WordPress MultiSite, puede ser una necesidad que por alguna situación del... - [Plugins básicos de seguridad y antispam](https://www.wpsysadmin.com/blog/2022/02/27/plugins-basicos-seguridad-antispam/): Cuando se comienza un proyecto con WordPress una de los primeros momentos es el de elegir los plugins que vamos... - [Procedimiento de actualización de WordPress](https://www.wpsysadmin.com/blog/2022/02/25/procedimiento-actualizacion-wordpress/): Este procedimiento es una propuesta para proyectos grandes en los que hay muchas personas implicadas, y en los que se... - [WordPress Newspack para Google News](https://www.wpsysadmin.com/blog/2022/01/28/wordpress-newspack/): Muchos medios de comunicación medianos quizá no tengan un acceso sencillo a Google News, pero si tienes WordPress puedes adaptar... - [Comparando WordPress de PHP 5.6 a PHP 8.1](https://www.wpsysadmin.com/blog/2021/10/06/comparando-wordpress-de-php-5-6-a-php-8-1/): WordPress 5. 9 va a dar soporte desde la versión de PHP 5. 6 hasta PHP 8. 1 y en... - [MySQLdump con problemas de codificación](https://www.wpsysadmin.com/blog/2021/08/18/mysqldump-codificacion/): Aunque hoy en día todo está en UTF-8 (incluso en UTF-8 mb4) no siempre ha sido así, y cuando hay... - [Encontrar todos los WordPress que tenemos](https://www.wpsysadmin.com/blog/2021/07/31/encontrar-wordpress/): ¿Cuántos WordPress tienes? ¿Lo sabes? Yo a veces no... y esa duda me genera una cuestión: ¿cómo puedo saber cuántos... - [Llave de Seguridad para 2FA / MFA en WordPress](https://www.wpsysadmin.com/blog/2021/07/28/llave-seguridad-2fa/): La seguridad, hoy en día, ya no es suficiente con un usuario y una contraseña, ya sea más o menos... - [Cron para WordPress MultiSite](https://www.wpsysadmin.com/blog/2021/07/19/cron-wordpress-multisite/): Una de las recomendaciones habituales que se hacen para WordPress para una mejor optimización es la de no usar el... - [Comparativa de WordPress Sandbox](https://www.wpsysadmin.com/blog/2021/07/18/wordpress-sandbox/): En muchas ocasiones necesitamos probar un plugin, un tema o alguna funcionalidad concreta de WordPress, pero es muy probable que... - [Usar claves SSH para acceder a un servidor](https://www.wpsysadmin.com/blog/2021/07/15/claves-ssh-acceder-servidor/): Cuando se accede a un servidor se puede hacer por SSH, y por defecto con un usuario y contraseña. Pero... - [Analytics, sin cookies, para WordPress](https://www.wpsysadmin.com/blog/2021/07/14/analytics-sin-cookies/): Con el RGPD, la LOPD y la ePrivacy la medición se ha vuelto más complicada y, si queremos que todo... - [Monitorización en tiempo real de Linux](https://www.wpsysadmin.com/blog/2021/07/13/monitorizacion-tiempo-real-linux/): Seguro que usas la herramienta "top" o incluso "htop" para que se vea más colorido a la hora de analizar... - [Informe diario de tu Ubuntu con Logwatch](https://www.wpsysadmin.com/blog/2021/07/11/informe-ubuntu-logwatch/): Con la herramienta Logwatch podemos recibir cada día en nuestro buzón de correo un resumen del análisis de los logs... - [Actualizar versiones de MariaDB](https://www.wpsysadmin.com/blog/2021/07/08/actualizar-mariadb/): Cada cierto tiempo tenemos actualizaciones de versiones de MariaDB, y puede ser interesante hacer una actualización entre versiones mayores. ¿Cómo... - [Test de estrés para MariaDB / MySQL](https://www.wpsysadmin.com/blog/2021/07/01/test-estres-mariadb-mysql/): De la misma forma que queremos saber cuánto tráfico soporta un sitio web y para el que podemos hacer un... - [MainWP: Este sitio ya contiene un enlace](https://www.wpsysadmin.com/blog/2021/06/30/mainwp-sitio-contiene-enlace/): Si utilizas MainWP es posible que en alguna ocasión se te haya desconfigurado un sitio tras una migración, cambio de... - [Cabeceras HTTP de seguridad](https://www.wpsysadmin.com/blog/2021/06/26/cabeceras-http-seguridad/): Informar al navegador del usuario que visita nuestra página para que permita hacer algunas tareas es algo habitual, y también... - [Usuarios chrooted para SFTP](https://www.wpsysadmin.com/blog/2021/06/25/usuarios-chrooted-sftp/): Cada vez se usa menos el acceso FTP y más el de SFTP por simples razones de seguridad. Pero los... - [Publicar desde un repositorio privado de Github](https://www.wpsysadmin.com/blog/2021/06/25/publicar-repositorio-privado/): Es muy probable que tengas plugins o themes para clientes que no son públicos, o código que usas para alguno... - [Instalar ImageMagick 7 para PHP 8.0](https://www.wpsysadmin.com/blog/2021/06/23/imagemagick-7-php-8/): Ahora que ya tenemos ImageMagick 7 y la extensión para imagick de PHP (mediante PECL), podemos utilizar toda la potencia... - [Permisos de ficheros en WordPress](https://www.wpsysadmin.com/blog/2021/06/08/permisos-ficheros-wordpress/): Los permisos de ficheros son siempre elemento de discordia en cuanto a funcionamiento, seguridad y todo lo que hay alrededor... - [Qué DNS usa WordPress](https://www.wpsysadmin.com/blog/2021/06/05/dns-wordpress/): Todos los dominios, para funcionar, necesitas las DNS (Domain Name Server) que permiten informar de a qué dirección IP corresponde... - [Redirigir correo de un dominio](https://www.wpsysadmin.com/blog/2021/06/04/redirigir-correo/): El correo es de esos servicios en los que habitualmente tienes una cuenta principal y el resto de dominios acaba... - [Configuración Let's Encrypt óptima](https://www.wpsysadmin.com/blog/2021/05/25/configuracion-lets-encrypt-optima/): Aunque los certificados de Let's Encrypt son gratuitos, podemos usarlos, pero debemos hacer que den el máximo rendimiento de seguridad... - [Añadir el PHP de Ubuntu a Plesk](https://www.wpsysadmin.com/blog/2021/05/22/php-ubuntu-plesk/): Plesk incorpora sus propias versiones de PHP que suelen ser las actuales y soportadas por el propio PHP. Pero ¿qué... - [Cachear traducciones de WordPress](https://www.wpsysadmin.com/blog/2021/05/19/cache-traducciones/): WordPress tiene muchas capas de caché disponibles y algo que de forma nativa no se cachea son las frases de... - [Optimizar imágenes en WordPress](https://www.wpsysadmin.com/blog/2021/05/19/optimizar-imagenes/): Una de las claves en Web Performance es la optimización de imágenes, algo que en WordPress se puede hacer mediante... - [Por qué los hosters deberían instalar la extensión PHP-intl](https://www.wpsysadmin.com/blog/2021/05/18/php-intl/): Aproximadamente la mitad de las instalaciones están en un idioma que no es el predeterminado (el inglés) y esto nos... - [Cabeceras HTTP de caché](https://www.wpsysadmin.com/blog/2021/05/03/cabeceras-cache/): Existen seis cabeceras de caché que se pueden utilizar desde el protocolo HTTP a la hora de decirle al navegador... - [Escalar un WooCommerce con muchos productos](https://www.wpsysadmin.com/blog/2021/04/02/escalar-woocommerce/): ¿Cuántos productos son muchos productos para un WooCommerce? La pregunta en sí no es tanto para un WooCommerce sino para... - [Matomo para WordPress](https://www.wpsysadmin.com/blog/2021/04/01/matomo-wordpress/): Cuando buscas un sistema de analítica web, pero no quieres ceder los datos a Google Analytics, la opción más interesante... - [SonarQube: analiza la calidad de tu plugin o theme](https://www.wpsysadmin.com/blog/2021/04/01/sonarqube/): Aunque WordPress tiene sus guías de seguridad para plugins y themes, con sus propias funciones, muchas veces entre tanto código... - [Antivirus para WordPress](https://www.wpsysadmin.com/blog/2021/03/25/antivirus-wordpress/): Cuando pensamos en un antivirus para WordPress como plugin, en realidad tenemos un sistema que busca patrones dentro del código,... - [Test de estrés para WordPress](https://www.wpsysadmin.com/blog/2021/03/23/test-estres-wordpress/): Una de las preocupaciones habituales de los que tienen un sitio web con WordPress es saber cuánto tráfico y a... - [Tu propia VPN con WireGuard](https://www.wpsysadmin.com/blog/2021/03/20/vpn-wireguard/): Es posible que no tenga una IP fija en casa o en el trabajo, y que quieras filtrar los accesos... - [Actualizar el kernel de CentOS 7](https://www.wpsysadmin.com/blog/2021/03/05/actualizar-kernel-centos-7/): El kernel de CentOS 7 está bastante obsoleto por defecto pero se puede actualizar si necesitas una versión superior. - [Firewall en .htaccess](https://www.wpsysadmin.com/blog/2021/02/16/firewall-htaccess/): Una forma sencilla es incorporar algunas reglas de cortafuegos directamente en el . htaccess que bloqueen peticiones por parámetro, o... - [Instalar WordPress Toolkit en cPanel](https://www.wpsysadmin.com/blog/2021/01/19/instalar-wordpress-toolkit-en-cpanel/): La interfaz del WordPress Toolkit le permite instalar, configurar y administrar fácilmente WordPress. Es una herramienta que viene de Plesk... - [Caché inmutable](https://www.wpsysadmin.com/blog/2021/01/13/cache-inmutable/): La caché de ficheros estáticos es uno de los elementos más importantes a la hora de gestionar una buena caché,... - [Migrar un WordPress de MultiSite a Simple](https://www.wpsysadmin.com/blog/2021/01/11/migrar-multisite-simple/): En algunas ocasiones necesitamos sacar uno de los sitios de un WordPres MultiSite a un sitio normal, una instalación simple.... - [AVIF, el nuevo formato de imagen](https://www.wpsysadmin.com/blog/2020/12/09/avif-el-nuevo-formato-de-imagen/): Desde hace un tiempo que teneos entre nosotros el nuevo formato de imagen AVIF. Entre otros, Netflix ya ha decidido... - [Comparando WordPress de PHP 5.6 a PHP 8.0](https://www.wpsysadmin.com/blog/2020/11/28/comparando-wordpress-de-php-5-6-a-php-8-0/): WordPress 5. 6 va a dar soporte desde la versión de PHP 5. 6 hasta PHP 8. 0 y en... - [WordPress hackeado con redirección](https://www.wpsysadmin.com/blog/2019/12/13/wordpress-hackeado-con-redireccion/): Uno de los hackeos más habituales en WordPress que no se han mantenido correctamente es el de las redirecciones hacia... - [Bloqueo de IP maliciosas por .htaccess](https://www.wpsysadmin.com/blog/2019/12/07/bloqueo-ip-maliciosas-htaccess/): Una de las mejores formas de bloquear tráfico indeseado de máquinas y robots o de elementos maliciosos es directamente desde... - [Caché de WordPress](https://www.wpsysadmin.com/blog/2019/10/04/cache-de-wordpress/): WordPress tiene muchas opciones en cuanto a capas de caché. Caché de navegador, de página, de compilador, de objetos, de... - [WordPress en Alta Disponibilidad](https://www.wpsysadmin.com/blog/2019/09/21/wordpress-en-alta-disponibilidad/): Cuando tu WordPress consigue tener mucho tráfico o tienes instalado un WooCommerce y necesitas que siempre esté funcionando es muy... - [Configurar extensiones PHP, para WordPress](https://www.wpsysadmin.com/blog/2019/09/11/configurar-extensiones-php-para-wordpress/): En general damos por hecho que PHP viene bien montado en nuestro alojamiento para WordPress y no suele ser así. - [Cómo configurar, bien, una CDN en WordPress](https://www.wpsysadmin.com/blog/2019/08/25/como-configurar-bien-una-cdn-en-wordpress/): Cuando hablamos de una CDN, hablamos de una red de entrega de contenidos, principalmente estáticos. Esto significa que vamos a... - [Qué hosting elegir para WordPress](https://www.wpsysadmin.com/blog/2019/08/17/que-hosting-elegir-para-wordpress/): Cuando comienzas un proyecto en Internet una de las primeras preguntas que te haces es el hosting para tu sitio... - [Desactivar la WP-JSON API REST](https://www.wpsysadmin.com/blog/2019/06/15/desactivar-wp-json/): WordPress incluye desde hace ya unas cuantas versiones una API que, por defecto, viene activa y abierta a todos los... - [Segurizando un Linux](https://www.wpsysadmin.com/blog/2019/06/15/fugas-de-informacion-linux/): Por norma general WordPress se suele instalar y hacer funcionar sobre Linux, y en este sistema operativo puede haber instalado... - [Alojamiento WordPress rápido, para desarrollo](https://www.wpsysadmin.com/blog/2019/06/09/wordpress-rapido-desarrollo/): En alguna ocasión seguro que necesitas montar un WordPress muy rápido para desarrollar pero evitando tener que montar todo el... - [Cache de Gravatar](https://www.wpsysadmin.com/blog/2019/06/09/cache-gravatar/): Uno de los servicios que vemos con mucha frecuencia en todos los sitios con WordPress (y sin) es el de... - [nginx y plugins de cache](https://www.wpsysadmin.com/blog/2019/06/08/nginx-plugins-cache/): Sin duda nginx es uno de los mejores servidores web existentes hoy en día, pero su configuración ha de hacerse... - [Bloquear request methods de HTTP](https://www.wpsysadmin.com/blog/2019/06/08/bloquear-request-methods/): En el caso de WordPress en general lo más habitual es que sólo se utilicen los métodos de solicitud GET... - [Cuánto cuesta montar un WordPress](https://www.wpsysadmin.com/blog/2019/02/11/cuanto-cuesta-montar-un-wordpress/): Una pregunta recurrente que me llega varias veces por semana es cuánto vale montar un WordPress. Y todo viene por... - [WordPress gestionado](https://www.wpsysadmin.com/blog/2019/01/20/wordpress-gestionado/): Cada día veo más y más empresas, proyectos, lugares en los que se habla de los WordPress gestionados, pero que... - [Optimizar la carga de scripts en WordPress](https://www.wpsysadmin.com/blog/2019/01/03/optimizar-la-carga-de-scripts-en-wordpress/): Cuando hablamos de web performance siempre se analiza la velocidad de carga de los scripts, principalmente con el objetivo de... - [Límite de memoria en WordPress](https://www.wpsysadmin.com/blog/2018/12/15/limite-de-memoria-en-wordpress/): WordPress necesita poca memoria para funcionar, pero solo si hablamos del núcleo principal. - [Instalar WP-CLI en Cloudlinux con CageFS](https://www.wpsysadmin.com/blog/2018/08/19/wpcli-cloudlinux-cagefs/): Si te gestionas tu propio servidor, y en este caso es CloudLinux, es muy probable que una de las ventajas... - [Segurizar un WordPress que no se pueden actualizar](https://www.wpsysadmin.com/blog/2018/07/25/wordpress-no-actualizado/): Hace unos días que rondaba por Twitter un runrún sobre cómo asegurar una instalación de WordPress en la que no... --- # # Detailed Content ## Páginas Última revisión: 26 de enero de 2022 Las empresas de hosting pueden tener alojados centenares de sitos web con WordPress, y por eso es importante que su configuración sea lo más compatible posible con el software. Para verificar esta compatibilidad, el equipo de la Comunidad Hosting de WordPress pone a disposición una serie de pruebas PHPUnit con las que poder comprobar el funcionamiento de WordPress en cualquier entorno. Requisitos El objetivo de estas pruebas es el de comprobar y validar que las próximas actualizaciones de WordPress funcionan correctamente en tu entorno, por lo que lo ideal es tener un alojamiento lo más parecido al que le ofreces a tus clientes. Esto significa que necesitaremos, al menos: Una base de datos (se creará y eliminarán sus contenidos). Puedes usar MySQL, MariaDB o cualquier sistema compatible. Una carpeta donde alojar el software (no público). Una carpeta temporal donde se generarán y eliminarán contenidos. Además de esto, de forma extra, se necesitarán los siguientes elementos: npm (para usar Node. js)Composer 2. xGit Instalación en Ubuntu (ejemplo) npm en Ubuntu apt-get -y install npm Composer 2. x en Ubuntu cd curl -sS https://getcomposer. org/installer -o composer-setup. php php composer-setup. php --install-dir=/usr/local/bin --filename=composer Git en Ubuntu apt-get -y install git Instalando el phpunit-test-runner El phpunit-test-runner es una pequeña pieza de pruebas de PHPUnit específicamente pensada para empresas de hosting. Existe toda una documentación sobre esta herramienta. Además, si lo quieres, puedes hacer aparecer los resultados de tus pruebas en la página de Host Test Results de WordPress. La herramienta se puede ejecutar de forma manual o a través de un sistema automatizado. Para ver el funcionamiento y el objetivo de este documento haremos las pruebas de forma manual, y al final añadiremos un sistema de automatización. Instalación del Runner Lo primero que haremos será descargar y sincronizar la herramienta. cd /home/wordpressbot/ git clone https://github. com/WordPress/phpunit-test-runner. git wordpress-test cd /home/wordpressbot/wordpress-test/ El siguiente paso será el de configurar el entorno. Para ello primero haremos una copia del fichero de ejemplo y posteriormente lo configuraremos. cp . env. default . env vim . env El contenido (de forma resumida) puede ser algo así: export WPT_PREPARE_DIR=/tmp/wp-test-runner export WPT_TEST_DIR=/tmp/wp-test-runner export WPT_REPORT_API_KEY= export WPT_REPORT_URL= export WPT_DB_NAME=wordpressdatabase export WPT_DB_USER=wordpressusername export WPT_DB_PASSWORD=wordpresspassword export WPT_DB_HOST=localhost export WPT_TABLE_PREFIX=${WPT_TABLE_PREFIX-wptests_} export WPT_PHP_EXECUTABLE=${WPT_PHP_EXECUTABLE-php} export WPT_PHPUNIT_CMD= export WPT_RM_TEST_DIR_CMD= export WPT_SSH_CONNECT= export WPT_SSH_OPTIONS= export WPT_SSH_PRIVATE_KEY_BASE64= export WPT_DEBUG= Configuraremos la carpeta donde se harán las pruebas de descarga del software de WordPress y los accesos de la base de datos para poder preparar las pruebas. Para este ejemplo, usaremos una carpeta de pruebas del sistema como puede ser /tmp/wp-test-runner. Se puede usar una carpeta temporal o una existente para ese mismo usuario, por ejemplo. Configuraremos esta ruta completa en: export WPT_PREPARE_DIR=/tmp/wp-test-runner export WPT_TEST_DIR=/tmp/wp-test-runner Lo siguiente será incluir la configuración de la base de datos que hayamos creado previamente. Por ejemplo podemos crearla con este comando: CREATE DATABASE wordpressdatabase CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci; GRANT ALL ON wordpressdatabase. * TO 'wordpressusername'@'localhost' IDENTIFIED BY 'wordpresspassword'; FLUSH PRIVILEGES; Esta base de datos no debe utilizarse para nada más que no sea el uso de estas pruebas. Posteriormente, configuraremos los datos en el fichero de configuración: export WPT_DB_NAME=wordpressdatabase export WPT_DB_USER=wordpressusername export WPT_DB_PASSWORD=wordpresspassword export WPT_DB_HOST=localhost Con esto debería ser suficiente para la ejecución de las pruebas. Ahora que ya tenemos la configuración lista, podemos hacer la primera prueba para validar que todo funciona correctamente. Probando el test Antes de hacer las pruebas actualizaremos todo lo necesario a la última versión y activaremos la configuración del entorno. cd /home/wordpressbot/wordpress-test/ git pull npm update source . env Entraremos en la carpeta donde tenemos el software de pruebas y lo actualizamos descargando la última versión. También actualizaremos el npm por si hay actualizaciones, y finalmente, cargaremos la configuración. A partir de aquí, sólo hemos de ejecutar los 4 ficheros que hacen el conjunto de las pruebas. El primero de ellos es el sistema que verifica que el entorno está listo para funcionar. php prepare. php El segundo de ellos es el que realiza las pruebas en sí. php test. php Una vez acaben las pruebas, se puede generar el reporte. Si has configurado un usuario y contraseña se enviará a WordPress. org. php report. php Este sistema genera dos ficheros en los que está la información de lo que se mandará como respuesta a las pruebas que se están analizando. Puedes ver el contenido de los ficheros fácilmente. cat /tmp/wp-test-runner/env. json cat /tmp/wp-test-runner/junit. xml El primero de ellos incluye la información de todos los elementos necesarios para WordPress, como son PHP y sus extensiones y versiones, y la base de datos, con su versión. El segundo de los ficheros es un rsumen de todos los tests lanzados con sus resultados y que, si se mandan a WordPress. org, se mostrarán los que han fallado en la página de resultados, para así poder trabajarlos, tanto si son elementos a solucionar por parte del hosting, como si son errores que afectan a desarrollo y el Core. Y, para acabar, una vez tienes el sistema terminado, solo hemos de limpiar los ficheros y la base de datos para poder realizar una siguiente prueba en otro momento. php cleanup. php Creando tu bot para WordPress. org Si quieres que los resultados de las pruebas aparezcan en la página de WordPress. org puedes crear un usuario para ello. Lo primero será crear un usuario en WordPress. org. Si tu empresa se llama, por ejemplo, Somos Hosting, S. L. , puedes llamar a tu usuario algo como somoshostingbot. Ten en cuenta que la cuenta de correo asociada debe verificarse con frecuencia, ya que llegarán correos respecto al posible funcionamiento de las pruebas. Crea una issue en la página del test pidiendo la inclusión del bot en la página de resultados como "Test Reporter request", indicando la cuenta de correo que has usado con ese usuario. Cuando se haya creado el usuario en el sistema se te dará acceso a una contraseña de forma que puedas configurar que el sistema mande la información de... --- Visible only to administrators. Edit this content. Email --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, intl, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, intl, no está instalado, o ha sido desactivado. The optional module, intl, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP intl. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP intl. Ubuntu / Debian apt install php-intl CentOS / RHEL yum install php-intl Panel de control cPanel Si tienes panel de control de cPanel / WHM, puedes instalar PHP intl desde la sección de Software / EasyApache / Personalizar. Una vez allí, en la sección de Extensiones PHP se puede buscar "intl" y activar las opciones correspondientes. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), puedes instalar PHP intl desde la sección de Herramientas y configuración / Configuración de PHP. Una vez allí, en se selecciona la versión de PHP correspondiente y dentro se activa la opción "intl". --- Algunos de los servicios que ofrecemos para optimizar tu WordPress. Instalación y Configuración Te instalamos un WordPress en un servidor VPS configurado y optimizado para sacar el máximo rendimiento a la infraestructura. Por defecto se instalará en un VPS con Ubuntu, con las versiones estables para WordPress de PHP, MariaDB, Redis y otros servicios, además de sus configuraciones personalizadas para las necesidades de tu WordPress. No te vamos a dar un alojamiento nosotros. El alojamiento es algo tan importante que ha de estar bajo tu control. Te vamos a recomendar qué necesitas según tu proyecto y podemos montar tu proyecto y optimizarlo al máximo. Un alojamiento compartido puede costarte lo mismo que un alojamiento VPS dedicado para ti, además de tener el control de los servicios y versiones de todo, con una optimización personalizada que un alojamiento compartido no te ofrece, y por el mismo precio. Ya quieras un sitio WordPress nuevo o migrar tu sitio actual, es una buena opción. Por norma general los pasos son los de montar la infraestructura y validar su funcionamiento (Servidor, SSH, Base de Datos, Servidor Web, Capas de Caché... ), hacer una primera migración y validar que funciona, y una vez se esté seguro de que todo está bien, hacer el paso a producción muy planificado. Un proceso que puede ser de un par de días para validar todo. Plesk para WordPress Además, si quieres o tienes un Plesk, podemos hacer las optimizaciones necesarias para su funcionamiento principal con sitios WordPress. Optimización y Performance Si tu WordPress funciona raro, podemos hacer una revisión de la infraestructura, plugins y otros elementos para encontrar cuellos de botella. Hacer un análisis y plantear soluciones y alternativas a aquello que hace o no hace que tu sitio funcione correctamente. Revisaremos, entre otras cosas, las configuraciones del sistema operativo, servidor web, servidor de base de datos, configuraciones de caché, además del propio WordPress. Mantenimiento Hacemos mantenimiento de tu servidor VPS para WordPress, además del propio WordPress. También configuraremos y haremos seguimiento de forma proactiva tanto del servidor, como de los servicios, para que, en caso de que haya algún problema, de forma proactiva lo revisemos. También configuraremos y mantendremos sistemas activos de seguridad (antispam, antivirus, antiDDoS, cortafuegos). Migración Si tienes que migrar tu sitio WordPress y quieres hacerlo de forma segura, y con el tiempo mínimo de caída, podemos migrarlo con seguridad. Por norma general una migración bien preparada será de aproximadamente 6 horas, con un tiempo de caída máximo de 1 hora. Hackeos y Virus ¿Te han hackeado tu WordPress? Si necesitas hacer una limpieza de tu sitio, encontrar los problemas y parchear el sitio y alojamiento, podemos revisar, si tu alojamiento lo permite, todo el código del sitio. Además, haremos un escaneo del sitio con las mismas herramientas que usan los hackers para bloquear la mayor cantidad de detecciones posibles y así, evitar posibles ataques. --- Última revisión: 2 de octubre de 2021 WordPress es un gestor de contenidos de código abierto (open source) y gracias a otras herramientas puedes complementar lo que necesites hacer. Analítica Fathom (Github)Matomo Correo DMARC Report Parser (Github)IMAPSync (Github)Mail-in-a-Box (Github)Modoboa Documentación Taiga (Github) Facturación Crater (Github)Invoice Ninja (Github) Ficheros NextCloud (Github)OwnCloud (Github) Gestión de proyectos Kanboard (Github)OpenNote (Github)OpenProjectWallabag (Github)WeKan (Github) Monitorización PHP Server Monitor (Github) SEO SEO Panel Soporte / Tickets Helpy (Github)Zammad (Github) Si tienes, usas o conoces alguna otra herramienta que esté al día, se mantenga y sea útil, por favor, dímelo y la añadiré a la lista. --- Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: AlmaLinux 8. 4Servidor web: nginxBase de Datos: MariaDBProcesador: PHP 8. 0Caché: Redis Aquí te dejamos un pequeño manual de instalación desde una instalación de sistema operativo básico de AlmaLinux 8. 4. Configurando el Sistema Operativo Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria universal UTC. timedatectl set-timezone UTC Lo siguiente que haremos es comprobar la versión del sistema operativo y, posteriormente, hacer una actualización completa del mismo. cat /etc/centos-release dnf clean all && dnf -y upgrade Una vez esta todo actualizado, instalamos algunas herramientas y software base que puede ser útil tener en el sistema. dnf -y install https://dl. fedoraproject. org/pub/epel/epel-release-latest-8. noarch. rpm dnf -y install https://rpms. remirepo. net/enterprise/remi-release-8. rpm dnf config-manager --set-enabled powertools dnf -y groupinstall "development tools" dnf -y install vim curl zip unzip wget npm ImageMagick ImageMagick-devel libsodium libsodium-devel Antes de acabar, activaremos las actualizaciones automáticas de seguridad del sistema operativo. dnf -y install dnf-automatic Una vez instalado, configuraremos para que actualice sólo las actualizaciones de seguridad. vim /etc/dnf/automatic. conf Y cambiaremos algunas de las configuraciones upgrade_type = security apply_updates = yes emit_via = motd Una vez hayamos guardado, activaremos el sistema de forma automática. systemctl enable --now dnf-automatic. timer Instalación de MariaDB El siguiente paso será la instalación de la base de datos. dnf -y install mariadb-server mariadb Iniciaremos el servicio. systemctl enable mariadb. service systemctl start mariadb. service systemctl status mariadb. service Ahora que está instalada, procederemos a la configuración inicial. Para ello usaremos el sistema de instalación segura, que nos hará algunas preguntas. mysql_secure_installation A la pregunta de si queremos cambiar la contraseña, dependiendo de si hemos puesto o no en la instalación, la cambiaremos. En caso de no haber puesto ninguna, es muy recomendable ponerle una contraseña segura. Set root password? : Y Al resto de preguntas, contestaremos lo siguiente: Remove anonymous users? : Y Disallow root login remotely? : Y Remove test database and access to it? : Y Reload privilege tables now? : Y Instalación de nginx A partir de aquí tenemos la base de datos configurada y vamos a proceder a la instalación del servidor web. En este caso vamos a usar nginx. dnf -y install nginx nginx-filesystem Ahora que tenemos nginx instalado, lo vamos a configurar para que se inicie en los re inicios del sistema automáticamente. systemctl enable nginx. service systemctl start nginx. service systemctl status nginx. service Instalación de PHP En este momento ya tenemos el servidor web, por lo que vamos a instalar y a configurar PHP para que funcione correctamente con la base de datos y el servidor web. En este caso vamos a instalar las versiones de PHP 8. 0 y PHP 7. 4. Primero instalaremos PHP 8. 0 dnf -y install php80 php80-php-fpm php80-php-common php80-php-devel php80-php-cli php80-php-bcmath php80-php-gd php80-php-intl php80-php-imap php80-php-json php80-php-mbstring php80-php-mysqlnd php80-php-opcache php80-php-pear php80-php-soap php80-php-xml php80-php-pecl-zip php80-php-pecl-imagick php80-php-sodium Y después PHP 7. 4 dnf -y install php74 php74-php-fpm php74-php-common php74-php-devel php74-php-cli php74-php-bcmath php74-php-gd php74-php-intl php74-php-imap php74-php-json php74-php-mbstring php74-php-mysqlnd php74-php-opcache php74-php-pear php74-php-soap php74-php-xml php74-php-pecl-zip php74-php-pecl-imagick php74-php-pecl-imagick-devel php74-php-sodium Ahora que ya tenemos PHP correctamente instalado, vamos a activarlo de forma que cuando se reinicie el sistema se ejecute automáticamente. systemctl stop php80-php-fpm. service systemctl enable php80-php-fpm. service systemctl start php80-php-fpm. service systemctl status php80-php-fpm. service systemctl stop php74-php-fpm. service systemctl enable php74-php-fpm. service systemctl start php74-php-fpm. service systemctl status php74-php-fpm. service php -v Instalación de Redis Para trabajar con unas mejoras en el rendimiento de la caché de objetos, vamos a dejar listo Redis como sistema de almacenamiento. dnf -y install redis php80-php-redis php74-php-redis Posteriormente, y de la misma forma que el resto de elementos, lo vamos a configurar para que se inicie automáticamente si se reinicia el servidor. systemctl stop redis. service systemctl enable redis. service systemctl start redis. service systemctl status redis. service Configuración del HTTPS Como vamos a montar nuestra web sobre un servidor web seguro (HTTPS), necesitaremos instalar el generador de certificados de Let's Encrypt. Para ello instalaremos el sistema de creación de certificados certbot. dnf -y install snapd systemctl enable snapd. socket systemctl start snapd. socket ln -s /var/lib/snapd/snap /snap snap install core snap install --classic certbot ln -s /snap/bin/certbot /usr/bin/certbot Si es la primera vez que vamos a usar la cuenta de correo necesaria para recibir avisos de la caducidad de los certificados, deberemos registrarla. certbot register --email wordpress@example. com --agree-tos --no-eff-email En caso de que ya la tengamos activa, podemos actualizarla. certbot update_account --email wordpress@example. com --agree-tos --no-eff-email Para que los certificados se actualicen automáticamente, activaremos una tarea programada (cron) una vez al día que automáticamente renueve los certificados. crontab -e Una vez dentro, configuraremos, por ejemplo, que se ejecute a las 06:45 cada mañana. 45 6 * * * certbot renew Limpiando los sitios por defecto Por defecto, el sistema responde a la dirección IP y a otros elementos. Para evitar que los sitios por defecto se muestren, eliminaremos las páginas por defecto. Eliminamos todos los ficheros por defecto. rm -rf /usr/share/nginx/html/* Y crearemos la página por defecto. vim /usr/share/nginx/html/index. html Donde añadiremos el contenido de la página por defecto. Hello World! Y crearemos un fichero de robots. txt para que no se indexen estas páginas por defecto. vim /usr/share/nginx/html/robots. txt Donde añadiremos el contenido del fichero que impida la indexación. User-Agent: * Disallow: / Instalación de WP-CLI Para la creación de nuestros sitios WordPress, usaremos la instalación mediante WP-CLI. cd curl -O https://raw. githubusercontent. com/wp-cli/builds/gh-pages/phar/wp-cli. phar php wp-cli. phar --info chown nginx: wp-cli. phar chmod +x wp-cli. phar mv wp-cli. phar /usr/local/bin/wp Y validamos que esté instalado y actualizado. wp --info wp cli update Además, podemos instalar la extensión para optimizar las imágenes de nuestro WordPress. Primero instalaremos lo que el sistema incluye. dnf -y install optipng pngquant jpegoptim Posteriormente instalaremos compilando gifsicle. cd wget https://www. lcdf. org/gifsicle/gifsicle-1. 92. tar. gz tar xvf gifsicle-1. 92. tar. gz rm -rf gifsicle-1. 92. tar. gz cd gifsicle-1. 92/ .... --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, xmlreader, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, xmlreader, no está instalado, o ha sido desactivado. The optional module, xmlreader, is not installed, or has been disabled. Extensión alternativa La extensión xmlreader sólo debe es necesaria en caso de no tener la posibilidad de instalar la extensión mod_xml. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP xmlreader. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP xmlreader. Ubuntu / Debian apt -y install php-dev gcc libxml2-dev make CentOS / RHEL yum -y install epel-release yum install --enablerepo=epel -y gcc libxml2-devel make Panel de control cPanel Primero deberemos instalar la biblioteca libxml2 y posteriormente instalar PHP. yum -y install epel-release yum install --enablerepo=epel -y gcc libxml2-devel make Panel de control Plesk Primero deberemos instalar la biblioteca libxml2 y posteriormente instalar PHP. Ubuntu / Debian apt -y install php-dev gcc libxml2-dev make CentOS / RHEL yum -y install epel-release yum install --enablerepo=epel -y gcc libxml2-devel make --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, zlib, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, zlib, no está instalado, o ha sido desactivado. The optional module, zlib, is not installed, or has been disabled. Extensión alternativa La extensión zlib sólo debe es necesaria en caso de no tener la posibilidad de instalar la extensión zip. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP zlib. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP zlib. Ubuntu / Debian apt -y install zlib1g zlib1g-dev CentOS / RHEL yum -y install zlib zlib-devel Panel de control cPanel Si tienes panel de control de cPanel / WHM, puedes instalar PHP zip desde la sección de Software / EasyApache / Personalizar. Una vez allí, en la sección de Extensiones PHP se puede buscar "zip" y activar las opciones correspondientes. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), puedes instalar PHP zip desde la sección de Herramientas y configuración / Configuración de PHP. Una vez allí, en se selecciona la versión de PHP correspondiente y dentro se activa la opción "zip". --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje La zona horaria por defecto de PHP no es válida, tienes la posibilidad de corregirlo con algunos cambios. La zona horaria por defecto de PHP no es válidaPHP default timezone is invalid Cambiar la hora Cuando instalas WordPress por primera vez el sistema configura como zona horaria la UTC. Aunque esta es la hora universal, en sí misma no es una hora, ya que WordPress prefiere la hora de un lugar, ya que si tienes cambio de hora de verano / invierno, el cambio se aplicará de forma automática. Puedes acceder a la opción de Ajustes / Generales, y allí encuentras la sección de Zona Horaria. Puedes buscar tu continente, y una vez allí verás las capitales o ciudades de referencia de cada país y zona horaria. --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, libsodium, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, libsodium, no está instalado, o ha sido desactivado. The optional module, libsodium, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP sodium. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP sodium. Ubuntu / Debian apt -y install build-essential php-pear php-dev cd wget https://download. libsodium. org/libsodium/releases/LATEST. tar. gz tar xvf LATEST. tar. gz rm -rf LATEST. tar. gz cd libsodium-stable/ . /configure make make check make install pecl install libsodium echo "extension=sodium. so" >> /etc/php/8. 0/mods-available/libsodium. ini CentOS / RHEL yum -y install php-pear php-devel yum -y groupinstall "development tools" cd wget https://download. libsodium. org/libsodium/releases/LATEST. tar. gz tar xvf LATEST. tar. gz rm -rf LATEST. tar. gz cd libsodium-stable/ . /configure make make check make install pecl install libsodium echo "extension=sodium. so" >> /etc/php. d/50-libsodium. ini Panel de control cPanel Para instalar PHP sodium en cPanel, que habitualmente funciona sobre CentOS, deberemos primero instalar las bibliotecas de Sodium por SSH. yum -y groupinstall "development tools" cd wget https://download. libsodium. org/libsodium/releases/LATEST. tar. gz tar xvf LATEST. tar. gz rm -rf LATEST. tar. gz cd libsodium-stable/ . /configure make make check make install Una vez tengamos la biblioteca instalada, podemos seguir desde el panel de cPanel. En la sección de Software / Module Installer, tenemos la sección PHP PECL. Allí iremos a la gestión y seleccionaremos la versión de PHP que queramos configurar. Si queremos tenerlo en todas las versiones, deberemos hacer los pasos para cada una de ellas. En la sección "Install a PHP PECL" pondemos "libsodium" y pulsaremos en "Instalar". Al acabar tendremos "libsodium en la lista de extensiones de esa versión de PHP. " Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), puedes instalar PHP sodium desde la sección de Herramientas y configuración / Configuración de PHP. Una vez allí, en se selecciona la versión de PHP correspondiente y dentro se activa la opción "sodium". --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, openssl, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, openssl, no está instalado, o ha sido desactivado. The optional module, openssl, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP openssl. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP openssl. Ubuntu / Debian apt install openssl CentOS / RHEL yum install openssl Panel de control cPanel Por norma general, cPanel ya incluye las bibliotecas de OpenSSL. Panel de control Plesk Por norma general, Plesk ya incluye las bibliotecas de OpenSSL. --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, pcre, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, pcre, no está instalado, o ha sido desactivado. The optional module, pcre, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP pcre. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP pcre. Ubuntu / Debian apt install libpcre3 libpcre3-dev CentOS / RHEL yum install pcre Panel de control cPanel Por norma general, cPanel ya incluye las bibliotecas de PCRE. Panel de control Plesk Por norma general, Plesk ya incluye las bibliotecas de PCRE. --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, imagick, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, imagick, no está instalado, o ha sido desactivado. The optional module, imagick, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP imagick. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP imagick. Ubuntu / Debian apt install imagemagick php-imagick CentOS / RHEL version 7 yum -y groupinstall "Development Tools" yum -y install ImageMagick ImageMagick-devel yum -y install php php-devel php-pear pecl install Imagick echo "extension=imagick. so" >> /etc/php. d/50-imagick. ini CentOS / RHEL version 8 dnf -y install epel-release dnf config-manager --set-enabled powertools dnf -y install ImageMagick ImageMagick-devel dnf -y install php php-devel php-pear pecl install Imagick echo "extension=imagick. so" >> /etc/php. d/50-imagick. ini Panel de control cPanel Para instalar PHP imagick en cPanel, que habitualmente funciona sobre CentOS, deberemos primero instalar las bibliotecas de ImageMagick por SSH. CentOS / RHEL version 7 yum -y groupinstall "Development Tools" yum -y install ImageMagick ImageMagick-devel CentOS / RHEL version 8 dnf -y install epel-release dnf config-manager --set-enabled powertools dnf -y install ImageMagick ImageMagick-devel Una vez tengamos la biblioteca instalada, podemos seguir desde el panel de cPanel. En la sección de Software / Module Installer, tenemos la sección PHP PECL. Allí iremos a la gestión y seleccionaremos la versión de PHP que queramos configurar. Si queremos tenerlo en todas las versiones, deberemos hacer los pasos para cada una de ellas. En la sección "Install a PHP PECL" pondemos "imagick" y pulsaremos en "Instalar". Al acabar tendremos "imagick en la lista de extensiones de esa versión de PHP. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), puedes instalar PHP imagick desde la sección de Herramientas y configuración / Configuración de PHP. Una vez allí, en se selecciona la versión de PHP correspondiente y dentro se activa la opción "imagick". --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, mod_xml, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, mod_xml, no está instalado, o ha sido desactivado. The optional module, mod_xml, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP xml. VPS / Dedicado Por defecto, PHP al instalarse incorpora de forma nativa la extensión PHP xml. Panel de control cPanel Si tienes panel de control de cPanel / WHM, puedes instalar PHP xml desde la sección de Software / EasyApache / Personalizar. Una vez allí, en la sección de Extensiones PHP se puede buscar "xml" y activar las opciones correspondientes. Panel de control Plesk Por defecto, PHP al instalarse incorpora de forma nativa la extensión PHP xml. --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, zip, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, zip, no está instalado, o ha sido desactivado. The optional module, zip, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP zip. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP zip. Ubuntu / Debian apt install php-zip CentOS / RHEL yum install php-zip Panel de control cPanel Si tienes panel de control de cPanel / WHM, puedes instalar PHP zip desde la sección de Software / EasyApache / Personalizar. Una vez allí, en la sección de Extensiones PHP se puede buscar "zip" y activar las opciones correspondientes. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), puedes instalar PHP zip desde la sección de Herramientas y configuración / Configuración de PHP. Una vez allí, en se selecciona la versión de PHP correspondiente y dentro se activa la opción "zip". --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, filter, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, filter, no está instalado, o ha sido desactivado. The optional module, filter, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP filter. VPS / Dedicado Por defecto, PHP al instalarse incorpora de forma nativa la extensión PHP filter. Panel de control cPanel Por defecto, Plesk al instalarse incorpora de forma nativa la extensión PHP filter. Panel de control Plesk Por defecto, Plesk al instalarse incorpora de forma nativa la extensión PHP filter. --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, gd, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, gd, no está instalado, o ha sido desactivado. The optional module, gd, is not installed, or has been disabled. Extensión alternativa La extensión GD sólo debe es necesaria en caso de no tener la posibilidad de instalar la extensión ImageMagick. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP gd. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP gd. Ubuntu / Debian apt install php-gd CentOS / RHEL yum install php-gd Panel de control cPanel Si tienes panel de control de cPanel / WHM, puedes instalar PHP gd desde la sección de Software / EasyApache / Personalizar. Una vez allí, en la sección de Extensiones PHP se puede buscar "gd" y activar las opciones correspondientes. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), puedes instalar PHP gd desde la sección de Herramientas y configuración / Configuración de PHP. Una vez allí, en se selecciona la versión de PHP correspondiente y dentro se activa la opción "gd". --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, iconv, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, iconv, no está instalado, o ha sido desactivado. The optional module, iconv, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP iconv. VPS / Dedicado Por defecto, PHP al instalarse incorpora de forma nativa la extensión PHP iconv. Panel de control cPanel Si tienes panel de control de cPanel / WHM, puedes instalar PHP iconv desde la sección de Software / EasyApache / Personalizar. Una vez allí, en la sección de Extensiones PHP se puede buscar "iconv" y activar las opciones correspondientes. Panel de control Plesk Por defecto, Plesk al instalarse incorpora de forma nativa la extensión PHP iconv. --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, mcrypt, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, mcrypt, no está instalado, o ha sido desactivado. The optional module, mcrypt, is not installed, or has been disabled. Extensión alternativa La extensión mcrypt sólo debe es necesaria en caso de no tener la posibilidad de instalar la extensión libsodium. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP mcrypt. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP mcrypt. A partir de PHP 7. 2 es preferible el uso de libsodium. Ubuntu / Debian apt install php-mcrypt CentOS / RHEL yum install php-mcrypt Panel de control cPanel Primero deberemos instalar la biblioteca libmcrypt. yum -y install epel-release yum install --enablerepo=epel -y gcc libmcrypt-devel make En la sección de Software / Module Installer, tenemos la sección PHP PECL. Allí iremos a la gestión y seleccionaremos la versión de PHP que queramos configurar. Si queremos tenerlo en todas las versiones, deberemos hacer los pasos para cada una de ellas. En la sección "Install a PHP PECL" pondemos "mcrypt" y pulsaremos en "Instalar". Al acabar tendremos "mcrypt en la lista de extensiones de esa versión de PHP. Panel de control Plesk PHP < 7. 1 Si tienes panel de control de Plesk (Vista de proveedor de servicios), puedes instalar PHP mcrypt desde la sección de Herramientas y configuración / Configuración de PHP. Una vez allí, en se selecciona la versión de PHP correspondiente y dentro se activa la opción "mcrypt". PHP 7. 2 Ubuntu / Debian apt-y install plesk-php72-dev gcc libmcrypt-dev make /opt/plesk/php/7. 2/bin/pecl install mcrypt-1. 0. 1 echo 'extension=mcrypt. so' > /opt/plesk/php/7. 2/etc/php. d/mcrypt. ini plesk bin php_handler --reread CentOS / RHEL yum-y install epel-release yum install --enablerepo=epel -y plesk-php72-devel gcc libmcrypt-devel make /opt/plesk/php/7. 2/bin/pecl install mcrypt-1. 0. 1 echo 'extension=mcrypt. so' > /opt/plesk/php/7. 2/etc/php. d/mcrypt. ini plesk bin php_handler --reread PHP 7. 3 Ubuntu / Debian apt-y install plesk-php73-dev gcc libmcrypt-dev make /opt/plesk/php/7. 3/bin/pecl install mcrypt-1. 0. 2 echo 'extension=mcrypt. so' > /opt/plesk/php/7. 3/etc/php. d/mcrypt. ini plesk bin php_handler --reread CentOS / RHEL yum-y install epel-release yum install --enablerepo=epel -y plesk-php73-devel gcc libmcrypt-devel make /opt/plesk/php/7. 3/bin/pecl install mcrypt-1. 0. 2 echo 'extension=mcrypt. so' > /opt/plesk/php/7. 3/etc/php. d/mcrypt. ini plesk bin php_handler --reread PHP 7. 4 Ubuntu / Debian apt-y install plesk-php74-dev gcc libmcrypt-dev make /opt/plesk/php/7. 4/bin/pecl install mcrypt-1. 0. 4 echo 'extension=mcrypt. so' > /opt/plesk/php/7. 4/etc/php. d/mcrypt. ini plesk bin php_handler --reread CentOS / RHEL yum-y install epel-release yum install --enablerepo=epel -y plesk-php74-devel gcc libmcrypt-devel make /opt/plesk/php/7. 4/bin/pecl install mcrypt-1. 0. 4 echo 'extension=mcrypt. so' > /opt/plesk/php/7. 4/etc/php. d/mcrypt. ini plesk bin php_handler --reread --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, simplexml, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, simplexml, no está instalado, o ha sido desactivado. The optional module, simplexml, is not installed, or has been disabled. Extensión alternativa La extensión simplexml sólo debe es necesaria en caso de no tener la posibilidad de instalar la extensión mod_xml. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP simplexml. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP simplexml. Ubuntu / Debian apt -y install php-dev gcc libxml2-dev make CentOS / RHEL yum -y install epel-release yum install --enablerepo=epel -y gcc libxml2-devel make Panel de control cPanel Primero deberemos instalar la biblioteca libxml2 y posteriormente instalar PHP. yum -y install epel-release yum install --enablerepo=epel -y gcc libxml2-devel make Panel de control Plesk Primero deberemos instalar la biblioteca libxml2 y posteriormente instalar PHP. Ubuntu / Debian apt -y install php-dev gcc libxml2-dev make CentOS / RHEL yum -y install epel-release yum install --enablerepo=epel -y gcc libxml2-devel make --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, curl, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, curl, no está instalado, o ha sido desactivado. The optional module, curl, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP curl. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP curl. Ubuntu / Debian apt install php-curl CentOS / RHEL yum install php-curl Panel de control cPanel Si tienes panel de control de cPanel / WHM, puedes instalar PHP curl desde la sección de Software / EasyApache / Personalizar. Una vez allí, en la sección de Extensiones PHP se puede buscar "curl" y activar las opciones correspondientes. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), puedes instalar PHP curl desde la sección de Herramientas y configuración / Configuración de PHP. Una vez allí, en se selecciona la versión de PHP correspondiente y dentro se activa la opción "curl". --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje Tu sitio no tiene ningún tema por defecto. , tienes la posibilidad de corregirlo con algunos cambios. Tu sitio no tiene ningún tema por defecto. Los temas por defecto son usados automáticamente por WordPress si hay algo mal con el tema que has elegido. Your site does not have any default theme. Default themes are used by WordPress automatically if anything is wrong with your chosen theme. Instalar un tema por defecto WordPress necesita un tema para funcionar, aunque pueda hacerlo sin plugins. Es por esto que, en caso de que haya algún problema, es muy recomendable disponer de uno de los temas por defecto para que haga de respaldo. Lo mejor es disponer de uno de los tres últimos temas disponibles, que en este momento son los siguientes: https://es. wordpress. org/themes/twentytwentyone/ https://es. wordpress. org/themes/twentytwenty/ https://es. wordpress. org/themes/twentynineteen/ Una vez tengas instalado alguno de estos temas, el mensaje desaparecerá automáticamente. Ampliando la configuración En caso de querer forzar aún más la configuración, puedes añadir en el Fichero de Configuración de WordPress una línea que avise al sistema cuál es el tema por defecto. define( 'WP_DEFAULT_THEME', 'twentytwentyone' ); --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, dom, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, dom, no está instalado, o ha sido desactivado. The optional module, dom, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP dom. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP dom. Ubuntu / Debian apt install php-dom CentOS / RHEL yum install php-dom Panel de control cPanel Si tienes panel de control de cPanel / WHM, puedes instalar PHP dom desde la sección de Software / EasyApache / Personalizar. Una vez allí, en la sección de Extensiones PHP se puede buscar "dom" y activar las opciones correspondientes. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), puedes instalar PHP dom desde la sección de Herramientas y configuración / Configuración de PHP. Una vez allí, en se selecciona la versión de PHP correspondiente y dentro se activa la opción "dom". --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, exif, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, exif no está instalado, o ha sido desactivado. The optional module, exif, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP exif. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, al instalar PHP se debería instalar automáticamente la extensión PHP exif. Panel de control cPanel Si tienes panel de control de cPanel / WHM, puedes instalar PHP exif desde la sección de Software / EasyApache / Personalizar. Una vez allí, en la sección de Extensiones PHP se puede buscar "exif" y activar las opciones correspondientes. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), al instalar PHP se debe instalar de forma automática la extensión PHP exif. --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, fileinfo, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, fileinfo, no está instalado, o ha sido desactivado. The optional module, fileinfo, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP fileinfo. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, al instalar PHP se debería instalar automáticamente la extensión PHP fileinfo. Panel de control cPanel Si tienes panel de control de cPanel / WHM, puedes instalar PHP fileinfo desde la sección de Software / EasyApache / Personalizar. Una vez allí, en la sección de Extensiones PHP se puede buscar "fileinfo" y activar las opciones correspondientes. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), puedes instalar PHP fileinfo desde la sección de Herramientas y configuración / Configuración de PHP. Una vez allí, en se selecciona la versión de PHP correspondiente y dentro se activa la opción "fileinfo". --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, hash, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, hash, no está instalado, o ha sido desactivado. The optional module, hash, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP hash. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, al instalar PHP se debería instalar automáticamente la extensión PHP hash. Panel de control cPanel Si tienes panel de control de cPanel / WHM, al instalar PHP se debería instalar automáticamente la extensión PHP hash. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), al instalar PHP se debería instalar automáticamente la extensión PHP hash. --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo requerido, json, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo requerido, json, no está instalado, o ha sido desactivado. The required module, json, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP json. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP json. Ubuntu / Debian apt install php-json CentOS / RHEL yum install php-json Panel de control cPanel Si tienes panel de control de cPanel / WHM, al instalar PHP se debería instalar automáticamente la extensión PHP json. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), al instalar PHP se debería instalar automáticamente la extensión PHP json. --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, mbstring, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, mbstring, no está instalado, o ha sido desactivado. The optional module, mbstring, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP mbstring. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP mbstring. Ubuntu / Debian apt install php-mbstring CentOS / RHEL yum install php-mbstring Panel de control cPanel Si tienes panel de control de cPanel / WHM, puedes instalar PHP mbstring desde la sección de Software / EasyApache / Personalizar. Una vez allí, en la sección de Extensiones PHP se puede buscar "mbstring" y activar las opciones correspondientes. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), puedes instalar PHP mbstring desde la sección de Herramientas y configuración / Configuración de PHP. Una vez allí, en se selecciona la versión de PHP correspondiente y dentro se activa la opción "mbstring". --- Última revisión: 2 de octubre de 2021 Si en tu panel de Salud del Sitio de WordPress te aparece el mensaje El módulo opcional, mysqli, no está instalado, o ha sido desactivado. , tienes la posibilidad de corregirlo con algunos cambios. El módulo opcional, mysqli, no está instalado, o ha sido desactivado. The optional module, mysqli, is not installed, or has been disabled. Hosting compartido En caso de tener tu sitio web con WordPress en un hosting compartido, deberás ponerte en contacto con tu proveedor y pedirle que active la extensión PHP mysqli y PHP mysqlnd. VPS / Dedicado Si dispones de acceso a tu servidor VPS o dedicado, deberás instalar la extensión PHP mysqli y PHP mysqlnd. Ubuntu / Debian apt install php-mysqli php-mysqlnd CentOS / RHEL yum install php-mysqli php-mysqlnd Panel de control cPanel Si tienes panel de control de cPanel / WHM, puedes instalar PHP mysqlnd desde la sección de Software / EasyApache / Personalizar. Una vez allí, en la sección de Extensiones PHP se puede buscar "mysqlnd" y activar las opciones correspondientes. Panel de control Plesk Si tienes panel de control de Plesk (Vista de proveedor de servicios), puedes instalar PHP mysqli y PHP mbstring desde la sección de Herramientas y configuración / Configuración de PHP. Una vez allí, en se selecciona la versión de PHP correspondiente y dentro se activa la opción y "mysqli" y "mbstring". --- Última revisión: 2 de octubre de 2021 Disponer de un cortafuegos (firewall) a nivel de Sistema Operativo no es una tarea sencilla habitualmente, y por eso solemos instalarlos como WAF para WordPress... pero ¿y si hubiera un firewall sencillo de instalar y mantenido por la comunidad? CrowdSec es un cortafuegos multijugador masivo de código abierto capaz de analizar el comportamiento de los visitantes y proporcionar una respuesta adaptada a todo tipo de ataques. También aprovecha el poder de la multitud para generar una base de datos de reputación IP global para proteger la red de usuarios. IMPORTANTE: Un firewall puede filtrar tráfico válido, por lo que es muy recomendable analizar con cuidado las excepciones o las configuraciones de plugins que podemos tener, ya que se pueden limitar funcionalidades. Requisitos Un WordPress instalado en Ubuntu con Apache/nginx, PHP y MySQL/MariaDB. Instalando CrowdSec Partimos de la base de que ya tenemos un servidor montado, preferiblemente ya con los servicios funcionando, es decir, con Apache o nginx, cono PHP y con la base de datos MySQL o MariaDB. Si ya tenemos todo instalado será más sencillo que la instaclación detecte todo automáticamente. Comenzaremos con la instalación del repositorio. cd wget -qO - https://s3-eu-west-1. amazonaws. com/crowdsec. debian. pragmatic/crowdsec. asc | apt-key add - && apt-add-repository -y -s "https://s3-eu-west-1. amazonaws. com/crowdsec. debian. pragmatic/$(lsb_release -cs) $(lsb_release -cs) main" apt -y update E instalamos el software. apt -y install crowdsec En la máquina hay nginx y MariaDB y nos aparece esto: Creating crowdsec configuration in /etc/crowdsec crowdsec_wizard: Checking if service 'apache2' is running (ps+systemd) crowdsec_wizard: Checking if service 'httpd' is running (ps+systemd) crowdsec_wizard: Checking if service 'nginx' is running (ps+systemd) crowdsec_wizard: Found 'nginx' running crowdsec_wizard: Checking if service 'sshd' is running (ps+systemd) crowdsec_wizard: Found 'sshd' running crowdsec_wizard: Checking if service 'mysql' is running (ps+systemd) crowdsec_wizard: Found 'mysql' running crowdsec_wizard: Checking if service 'telnet' is running (ps+systemd) crowdsec_wizard: Checking if service 'smb' is running (ps+systemd) Detected services (unattended) : nginx sshd mysql linux crowdsec_wizard: Installing collection 'crowdsecurity/linux' crowdsec_wizard: Installing collection 'crowdsecurity/sshd' crowdsec_wizard: Installing collection 'crowdsecurity/mysql' crowdsec_wizard: Installing collection 'crowdsecurity/nginx' crowdsec_wizard: Found following services : nginx crowdsec_wizard: Found logs file for 'nginx': /var/log/nginx/access. log crowdsec_wizard: Found logs file for 'nginx': /var/log/nginx/error. log crowdsec_wizard: Acquisition file generated crowdsec_wizard: Found logs file for 'sshd': /var/log/auth. log crowdsec_wizard: Acquisition file generated crowdsec_wizard: Found logs file for 'linux': /var/log/syslog crowdsec_wizard: Found logs file for 'linux': /var/log/kern. log crowdsec_wizard: Acquisition file generated El sistema ha detectado automáticamente nginx, SSH, MySQL y "linux". Además ha encontrado una serie de logs para analizar. Una vez instalado, podemos configurarlo para que se active siempre y validamos que está funcionando. systemctl stop crowdsec systemctl enable crowdsec systemctl start crowdsec systemctl status crowdsec Como también tenemos WordPress, instalaremos el sistema que revisa WordPress. cscli collections install crowdsecurity/wordpress systemctl reload crowdsec systemctl status crowdsec Ya tenemos el cortafuegos funcionando... y no deberíamos tener que hacer nada más... el sistema ya ha conectado automáticamente con la API general, por lo que ya está analizando, enviando y recibiendo la información comunitaria. Revisando CrowdSec ¿Qué hay funcionando? cscli hub list Si queremos analizar qué elementos hay activos, podremos ver los distintos parsers, scenarios y collections, que son los tres componentes básicos de cada uno de los sistemas que se controlan. Los parsers son aquellos sistemas que analizan los ficheros de logs y similares buscando los ataques. Los scenarios son los elementos que toman las decisiones de cómo gestionar la información. Las collecctions son la aplicación de todo para cada una de las herramientas. Estadísticas cscli metrics En la parte de métricas tenemos información sobre qué se ha leído y cómo se ha gestionado, cómo se ha aplicado por parte de cada una de las herramientas y posteriormente cómo se ha gestionado la información por las APIs. --- Última revisión: 2 de octubre de 2021 Este tutorial ha sido creado en gracias a una licencia de Plesk. Consigue tus licencias Plesk desde su sitio web o en tu proveedor de alojamiento. COLABORACIÓN Versiones a instalar Sistema Operativo: Ubuntu 20Panel de Control: Plesk Obsidian 18 En Clouding tienes una opción de seleccionar Plesk como panel, por lo que la instalación ya estará hecha y podrás saltarte los primeros pasos. Al crear el VPS te darán los accesos al panel. Configurando el Sistema Operativo Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria Universal. timedatectl set-timezone 'UTC' timedatectl set-ntp on Lo siguiente que haremos es comprobar la versión del sistema operativo y, posteriormente, hacer una actualización completa del mismo. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Instalando Plesk Una vez esta todo actualizado, comenzaremos la instalación de Plesk. sh --- Última revisión: 2 de octubre de 2021 En algunos momentos podemos tener la necesidad de incrementar el rendimiento de una instalación de WordPress a un sistema de Alta Disponibilidad, y un primer punto por donde empezar es el uso de un sistema de distribución de las bases de datos. Este ejemplo es sencillo, en una misma localización y con direcciones IP privadas, pero se podría usar como base para un sistema entre distintos centros de datos. En cualquier caso, aunque los centros de datos sean distintos, se recomienda que sean de la misma empresa ya que suelen disponer de conectividad entre ellos directamente, lo que reduce los tiempos de respuesta. Distribución de infraestructura El objetivo de este tutorial es el de distribuir las bases de datos, y lo haremos de forma que tengamos una base de datos principal (master) y una base de datos secundaria (slave). Además, los ficheros del propio WordPress estarán separados. Máquina 1: Ficheros (nginx + PHP) - IP privada: 10. 0. 0. 1Máquina 2: SQL (primaria / master) - IP privada: 10. 0. 0. 2Máquina 3: SQL (secundaria / slave) - IP privada: 10. 0. 0. 3 En el ejemplo se utilizan las direcciones IP privadas porque, habitualmente, no suelen tener ningún tipo de consumo a la hora de enrutamiento en la mayoría de proveedores cloud, pero se puede usar de la misma manera con direcciones IP públicas. Hay que tener en cuenta que, al menos, para los rangos de IP privada, el puerto del MySQL / MariaDB debe estar accesible desde el exterior. El puerto es el 3306. IMPORTANTE: Aunque la CPU y RAM de las máquinas del SQL pueden ser distintas (según el uso que se les vaya a dar), sí que se recomienda que el tamaño de disco sea exactamente el mismo. Versiones a instalar Sistema Operativo: Ubuntu 20Panel de Control: ningunoServidor web: nginxBase de Datos: MariaDB 10. 5 (master-slave)Procesador: PHP 8. 0Caché: Redis Preparación de datos Cosas que vamos a necesitar tener a mano: Direcciones IP públicas y privadas de las 3 máquinasCrear una clave de root para el SQL principalCrear una clave de root para el SQL secundariaUsuario para la replicación SQL (en el ejemplo será "replica") y una contraseña. Base de datos, usuario y contraseña para la base de datos del WordPress. Servidor SQL primario (master) Configurando el Sistema Operativo Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria global UTC. timedatectl set-timezone 'UTC' timedatectl set-ntp on Lo siguiente que haremos es comprobar la versión del sistema operativo y, posteriormente, hacer una actualización completa del mismo. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Una vez esta todo actualizado, instalamos algunas herramientas y software base que puede ser útil tener en el sistema. apt -y install software-properties-common curl vim zip unzip apt-transport-https Antes de seguir configuraremos que se apliquen las actualizaciones automáticas de seguridad. apt -y install unattended-upgrades dpkg-reconfigure -plow unattended-upgrades Instalación de MariaDB El siguiente paso será la instalación de la base de datos. En este caso vamos a utilizar MariaDB 10. 5. Lo primero que haremos será configurar la descarga, y posteriormente su instalación. curl -sS https://downloads. mariadb. com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10. 5" apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install mariadb-server mariadb-client Ahora que está instalada, procederemos a la configuración inicial. Para ello usaremos el sistema se instalación segura, que nos hará algunas preguntas. mysql_secure_installation A la pregunta de si queremos cambiar la contraseña, dependiendo de si hemos puesto o no en la instalación, la cambiaremos. En caso de no haber puesto ninguna, es muy recomendable ponerle una contraseña segura. Set root password? : Y Al resto de preguntas, contestaremos lo siguiente: Remove anonymous users? : Y Disallow root login remotely? : Y Remove test database and access to it? : Y Reload privilege tables now? : Y En este momento ya tendremos la base de datos configurada. Ahora haremos que se ejecute en los re inicios del sistema y la iniciaremos. systemctl stop mysql. service systemctl enable mysql. service systemctl start mysql. service systemctl status mysql. service Configuraremos el sistema para que se considere este el servidor principal. Para ello tendremos que modificar algunos detalles del fichero de configuración. vim /etc/mysql/mariadb. conf. d/50-server. cnf Los tres elementos ya existen (algunos comentados, otros no). Lo mejor será editar lo existente. recuerda indicar la IP de este servidor. bind-address = 10. 0. 0. 2 server-id = 1 log_bin = /var/log/mysql/mysql-bin. log Para que se aplique la configuración, reiniciaremos el servidor de base de datos. systemctl restart mysql. service Ahora que ya tenemos configurado el servidor como servidor 1, vamos a crear un usuario que permita que otras máquinas accedan a recoger la información. Lo primero será acceder al MariaDB. mysql -p Aquí crearemos un usuario y le daremos permiso para que la máquina secundaria pueda acceder. Es importante que la dirección IP sea la correcta. CREATE USER 'replica'@'10. 0. 0. 3' IDENTIFIED BY 'contraseña_del_usuario_replica'; GRANT REPLICATION SLAVE ON . TO 'replica'@'10. 0. 0. 3'; FLUSH PRIVILEGES; Si todo va bien, podremos confirmar que se ha creado el sistema y está listo para recibir peticiones. SHOW MASTER STATUS; Esto nos devolverá datos del estilo a: +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin. 000001 | 328 | | | +------------------+----------+--------------+------------------+ Que serán necesario para un uso posterior. Debemos quedarnos con el dato del File (mysql-bin. 000001) y Position (328). Podemos dejar la ventana abierta, ya que después tendremos que volver para comprobar que la sincronización funciona. Servidor SQL secundario (slave) Configurando el Sistema Operativo Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria global UTC. timedatectl set-timezone 'UTC' timedatectl set-ntp on Lo siguiente que haremos es comprobar la versión del sistema operativo y, posteriormente,... --- Última revisión: 2 de octubre de 2021 Una de las mayores preocupaciones de los usuarios de WordPress es tener algún ataque y que pase desapercibido, principalmente por la descarga de algún theme o plugin que pueda tener alguna vulnerabilidad o descargas de sitios indebidos. Aunque existen plugins que lo hacen, no dejan de ser otra oportunidad y problema de seguridad, así que utilizaremos una herramienta externa que nos ayude a analizar la posibilidad de encontrarse con ficheros indebidos. AMWScan (PHP Antimalware Scanner) es una herramienta escrita en PHP y que analiza código PHP, por lo que viene perfecto a la hora de analizar WordPress. Además, tiene una integración cuando detecta WordPress que realiza algunas tareas extra, como el checksum de los plugins y themes en el repositorio oficial. Requisitos WordPress Instalación y configuración Para hacer más sencillo su uso, vamos a instalar y a configurar PHP Antimalware Scanner para que se pueda usar como un comando en cualquier parte del sistema Primero descargamos el fichero principal wget https://raw. githubusercontent. com/marcocesarato/PHP-Antimalware-Scanner/master/dist/scanner --no-check-certificate -O /usr/bin/awscan. phar Crearemos el sistema ejecutable vim /usr/bin/awscan y le incluiremos el siguiente contenido #! /bin/bash php /usr/bin/awscan. phar $@ Una vez tengamos el fichero, le daremos permisos y lo configuraremos para su futura ejecución. chmod u+x,g+x /usr/bin/awscan. phar chmod u+x,g+x /usr/bin/awscan export PATH=$PATH":/usr/bin" Análisis En este momento, podemos lanzarlo para probar que funciona. Haremos un análisis completo, aunque permite algunas configuraciones: -e: sólo busca exploits-l: análisis reducido En cualquier caso, la recomendación es primero lanzar un análisis sin parámetros, para revisar todo. Podemos ir a la carpeta donde tenemos el WordPress o ejecutarlo indicándole donde se encuentra. awscan /webs/example. com/ Esto nos devolverá, en el caso de un WordPress, algo tal que así: █████╗ ███╗ ███╗██╗ ██╗███████╗ ██████╗ █████╗ ███╗ ██╗ ██╔══██╗████╗ ████║██║ ██║██╔════╝██╔════╝██╔══██╗████╗ ██║ ███████║██╔████╔██║██║ █╗ ██║███████╗██║ ███████║██╔██╗ ██║ ██╔══██║██║╚██╔╝██║██║███╗██║╚════██║██║ ██╔══██║██║╚██╗██║ ██║ ██║██║ ╚═╝ ██║╚███╔███╔╝███████║╚██████╗██║ ██║██║ ╚████║ ╚═╝ ╚═╝╚═╝ ╚═╝ ╚══╝╚══╝ ╚══════╝ ╚═════╝╚═╝ ╚═╝╚═╝ ╚═══╝ Github: https://github. com/marcocesarato/PHP-Antimalware-Scanner version 0. 7. 5. 177 PHP Antimalware Scanner Created by Marco Cesarato Start scanning... Scan date: 07-01-2021 09:22:35 Scanning /webs/example. com Mapping and retrieving checksums, please wait... Found WordPress 5. 6 (en_US) at "/webs/example. com" Found WordPress Plugin Akismet Anti-Spam 4. 1. 8 Found WordPress Plugin Gutenberg 9. 7. 0 Found WordPress Plugin Health Check & Troubleshooting 1. 4. 5 Found WordPress Plugin Jetpack by WordPress. com 9. 2. 1 Found WordPress Plugin Two Factor 0. 7. 0 Found WordPress Plugin Wordfence Security 7. 4. 14 Retrieving checksums of Wordpress Plugin Health Check & Troubleshooting 1. 4. 5 Retrieving checksums of Wordpress Plugin Jetpack by WordPress. com 9. 2. 1 Retrieving checksums of Wordpress Plugin Two Factor 0. 7. 0 Retrieving checksums of Wordpress Plugin Wordfence Security 7. 4. 14 Verifying files checksum... 100% 2385/2385 Found 51 files to check Checking files... 98% 50/51 ] Scan finished! SUMMARY Files scanned: 51 Files edited: 0 Files quarantined: 0 Files whitelisted: 0 Files ignored: 0 Malware detected: 0 Malware removed: 0 Encontrando contenido malicioso En el caso de que encuentre contenido malicioso, nos devolverá el análisis algunos datos extra. primero nos indicará qué fichero es el que tiene el problema, posteriormente una preview de su contenido y qué funciones o líneas podrían ser la que dan los problemas. Con esto una serie de opciones de qué queremos hacer: Delete file Move to quarantine Dry run evil code fixer Dry run evil line code fixer Open with vim Open with nano Add to whitelist Show source Ignore El sistema lleva integradas algunas posibilidades para corregir el problema, aunque en este caso lo más recomendable es analizar y saber qué es lo que está fallando, si realmente es un problema o no. Un ejemplo del resultado que daría un posible backdoor es este. █████╗ ███╗ ███╗██╗ ██╗███████╗ ██████╗ █████╗ ███╗ ██╗ ██╔══██╗████╗ ████║██║ ██║██╔════╝██╔════╝██╔══██╗████╗ ██║ ███████║██╔████╔██║██║ █╗ ██║███████╗██║ ███████║██╔██╗ ██║ ██╔══██║██║╚██╔╝██║██║███╗██║╚════██║██║ ██╔══██║██║╚██╗██║ ██║ ██║██║ ╚═╝ ██║╚███╔███╔╝███████║╚██████╗██║ ██║██║ ╚████║ ╚═╝ ╚═╝╚═╝ ╚═╝ ╚══╝╚══╝ ╚══════╝ ╚═════╝╚═╝ ╚═╝╚═╝ ╚═══╝ Github: https://github. com/marcocesarato/PHP-Antimalware-Scanner version 0. 7. 5. 177 PHP Antimalware Scanner Created by Marco Cesarato Start scanning... Scan date: 07-01-2021 09:27:57 Scanning /PHP-Malware-Collection/shell/php-backdoor. php Mapping and retrieving checksums, please wait... Found 1 files to check Checking files... 0% 0/1 PROBABLE MALWARE FOUND! /PHP-Malware-Collection/shell/php-backdoor. php =================================== PREVIEW ==================================== 27 | if(isset($_REQUEST)){ 28 | echo ""; 29 | system($_REQUEST); 30 | die; 31 | } ================================================================================ Checksum: 2b5cb105c4ea9b5ebc64705b4bd86bf7 File path: /PHP-Malware-Collection/shell/php-backdoor. php Evil code found: Exploit `execution` - RCE (Remote Code Execution) allow remote attackers to execute PHP code on the target machine via HTTP => system($_REQUEST) Function `system` - Encoded Function `system` => "; system($_REQUEST) Sign `100` - Definition sign `100` => system($_REQUEST Sign `110` - Definition sign `110` => echo ""; system($_REQUEST); die; OPTIONS: Delete file Move to quarantine Dry run evil code fixer Dry run evil line code fixer Open with vim Open with nano Add to whitelist Show source Ignore amwscan > What is your choice? - File '/PHP-Malware-Collection/shell/php-backdoor. php' skipped! Scan finished! SUMMARY Files scanned: 1 Files edited: 0 Files quarantined: 0 Files whitelisted: 0 Files ignored: 1 Malware detected: 1 Malware removed: 0 Files ignored: /PHP-Malware-Collection/shell/php-backdoor. php --- Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: Ubuntu 20Panel de Control: ningunoServidor web: nginxBase de Datos: MariaDB 10. 5Procesador: PHP 8. 0Caché: Redis recuerda que si vas a montar el sistema, tanto en local como en un sitio externo, deberás dejar el puerto 9050 disponible (y si quieres control externo, el 9051) para que puedan abrirse los sockets necesarios de la red Tor. Además, el puerto 80 para las conexiones web. Configurando el Sistema Operativo Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria universal UTC. timedatectl set-timezone 'UTC' timedatectl set-ntp on Lo siguiente que haremos es comprobar la versión del sistema operativo y, posteriormente, hacer una actualización completa del mismo. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Una vez esta todo actualizado, instalamos algunas herramientas y software base que puede ser útil tener en el sistema. apt -y install software-properties-common curl vim zip unzip apt-transport-https Instalación de MariaDB El siguiente paso será la instalación de la base de datos. En este caso vamos a utilizar MariaDB 10. 5. Lo primero que haremos será configurar la descarga, y posteriormente su instalación. curl -sS https://downloads. mariadb. com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10. 5" apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install mariadb-server mariadb-client Ahora que está instalada, procederemos a la configuración inicial. Para ello usaremos el sistema se instalación segura, que nos hará algunas preguntas. mysql_secure_installation A la pregunta de si queremos cambiar la contraseña, dependiendo de si hemos puesto o no en la instalación, la cambiaremos. En caso de no haber puesto ninguna, es muy recomendable ponerle una contraseña segura. Set root password? : Y Al resto de preguntas, contestaremos lo siguiente: Remove anonymous users? : Y Disallow root login remotely? : Y Remove test database and access to it? : Y Reload privilege tables now? : Y En este momento ya tendremos la base de datos configurada. Ahora haremos que se ejecute en los re inicios del sistema y la iniciaremos. systemctl stop mysql. service systemctl enable mysql. service systemctl start mysql. service systemctl status mysql. service Instalación de nginx A partir de aquí tenemos la base de datos configurada y vamos a proceder a la instalación del servidor web. En este caso vamos a usar nginx. Para estar al día, no usaremos la versión que viene con el sistema operativo, sino una más actualizada y mantenida. add-apt-repository ppa:ondrej/nginx apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install nginx nginx-extras Ahora que tenemos nginx instalado, lo vamos a configurar para que se inicie en los re inicios del sistema automáticamente. systemctl stop nginx. service systemctl enable nginx. service systemctl start nginx. service systemctl status nginx. service Instalación de PHP En este momento ya tenemos el servidor web, por lo que vamos a instalar y a configurar PHP para que funcione correctamente con la base de datos y el servidor web. En este caso vamos a instalar la versión PHP 8. 0. Primero haremos la instalación de los paquetes más actualizados (que no son los que vienen con el sistema operativo) y que en caso de necesitarlo, además, nos permitirían tener varias versiones de PHP en paralelo. add-apt-repository ppa:ondrej/php apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install php8. 0 php8. 0-fpm php8. 0-common php8. 0-dev php8. 0-cli php8. 0-bcmath php8. 0-curl php8. 0-gd php8. 0-imap php8. 0-mbstring php8. 0-mysql php8. 0-opcache php8. 0-soap php8. 0-xml php8. 0-zip php8. 0-xdebug libgeoip-dev php-pear pkg-config imagemagick libmagickwand-dev php8. 0-imagick Ahora que ya tenemos PHP correctamente instalado, vamos a activarlo de forma que cuando se reinicie el sistema se ejecute automáticamente. systemctl stop php8. 0-fpm. service systemctl enable php8. 0-fpm. service systemctl start php8. 0-fpm. service systemctl status php8. 0-fpm. service php -v También aprovecharemos en actualizar el PECL. pecl channel-update pecl. php. net Instalación de Redis Para trabajar con unas mejoras en el rendimiento de la caché de objetos, vamos a dejar listo Redis como sistema de almacenamiento. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install redis-server php8. 0-redis Posteriormente, y de la misma forma que el resto de elementos, lo vamos a configurar para que se inicie automáticamente si se reinicia el servidor. systemctl stop redis-server. service systemctl enable redis-server. service systemctl start redis-server. service systemctl status redis-server. service Limpiando los sitios por defecto Por defecto, el sistema responde a la dirección IP y a otros elementos. Para evitar que los sitios por defecto se muestren, eliminaremos las páginas por defecto. Eliminamos todos los ficheros por defecto. rm /var/www/html/index. * Y crearemos la página por defecto. vim /var/www/html/index. html Donde añadiremos el contenido de la página por defecto. Hello World! Y crearemos un fichero de robots. txt para que no se indexen estas páginas por defecto. vim /var/www/html/robots. txt Donde añadiremos el contenido del fichero que impida la indexación. User-Agent: * Disallow: / Instalación de WP-CLI Para la creación de nuestros sitios WordPress, usaremos la instalación mediante WP-CLI. cd /root/ curl -O https://raw. githubusercontent. com/wp-cli/builds/gh-pages/phar/wp-cli. phar php wp-cli. phar --info chown www-data: wp-cli. phar chmod +x wp-cli. phar mv wp-cli. phar /usr/local/bin/wp Y validamos que esté instalado y actualizado. wp --info wp cli update Configuración de la red Tor Desde Ubuntu es muy sencillo configurar la red de Tor ya que sólo hemos de instalarla (no requiere de ninguna configuración extra). apt -y install tor apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Una vez se haya realizado la instalación, podemos sustituir el fichero de configuración por defecto de Tor con el que indicamos a continuación. Hay que tener en cuenta que por defecto Tor viene "sin configuración", por lo que principalmente es activar y adaptar... --- Última revisión: 2 de octubre de 2021 Si utilizas nginx, a parte del fichero general de configuración del servidor, es probable que necesites un fichero de configuración para cada uno de los sitios web en los que trabajes, y aquí hay una configuración bastante más compleja. En este ejemplo vamos a usa un dominio example. com, por lo que todo el tráfico de www. example. com será redirigido a example. com. Configuración detallada por bloques Configuración HTTP La idea es que nada del sitio responda con HTTP, sino sólo con HTTPS, así que cualquier petición que llegue se hará una redirección automáticamente. server { listen 80; listen :80; server_name example. com www. example. com; return 301 https://example. com$request_uri; access_log off; } Configuración HTTPS para www Como sólo vamos a hacer que responsa el "sin-www", le diremos a todo el tráfico que llegue por www que haga una redirección. En este caso hemos de activar toda la parte de certificados y SSL/TLS. server { listen 443 ssl http2; listen :443 ssl http2; ssl_dhparam /etc/letsencrypt/ssl-dhparams. pem; ssl_certificate /etc/letsencrypt/live/example. com/fullchain. pem; ssl_certificate_key /etc/letsencrypt/live/example. com/privkey. pem; ssl_trusted_certificate /etc/letsencrypt/live/example. com/chain. pem; include /etc/letsencrypt/options-ssl-nginx. conf; ssl_stapling on; ssl_stapling_verify on; resolver 208. 67. 222. 222 8. 8. 8. 8 valid=300s; resolver_timeout 2s; add_header Referrer-Policy "strict-origin-when-cross-origin"; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"; add_header X-Frame-Options DENY; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; server_name www. example. com; return 301 https://example. com$request_uri; access_log off; } Configuración general Un poco como el bloque anterior, la configuración general de un sitio seguro. listen 443 ssl http2; listen :443 ssl http2; # SSL ssl_dhparam /etc/letsencrypt/ssl-dhparams. pem; ssl_certificate /etc/letsencrypt/live/example. com/fullchain. pem; ssl_certificate_key /etc/letsencrypt/live/example. com/privkey. pem; ssl_trusted_certificate /etc/letsencrypt/live/example. com/chain. pem; include /etc/letsencrypt/options-ssl-nginx. conf; # SSL OCSP Stapling ssl_stapling on; ssl_stapling_verify on; resolver 208. 67. 222. 222 8. 8. 8. 8 valid=300s; resolver_timeout 2s; # Security headers add_header Referrer-Policy "strict-origin-when-cross-origin"; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"; add_header X-Frame-Options DENY; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; #logs access_log /var/log/nginx/example. com-access. log combined buffer=64k flush=5m; error_log /var/log/nginx/example. com-error. log; Configuración de ruta y defecto Le diremos a qué dominio ha de responder, y qué ficheros ha de leer por orden. Por norma general encontraremos en WordPress ficheros index. php, y si no existe, suele haber un index. html. #CONFIG server_name example. com; root /webs/example. com; index index. php index. html index. htm; Configuración de caché (WP Super Cache) Si tienes un plugin de caché, no podrá auto-configurarse como suele hacerlo con el . htaccess de Apache, así que deberemos añadir la configuración manualmente. En este ejemplo es la configuración para WP Super cache, pero debes revisar la del plugin que uses. set $cache_uri $request_uri; if ($request_method = POST) { set $cache_uri 'null cache'; } if ($query_string ! = "") { set $cache_uri 'null cache'; } if ($request_uri ~* "(/wp-admin/|/xmlrpc. php|/wp-*. php)") { set $cache_uri 'null cache'; } if ($http_cookie ~* "comment_author|wordpress_+|wp-postpass|wordpress_logged_in") { set $cache_uri 'null cache'; } set $cachefile "/wp-content/cache/supercache/$http_host/$cache_uri/index. html"; if ($https ~* "on") { set $cachefile "/wp-content/cache/supercache/$http_host/$cache_uri/index-https. html"; } Bloqueo / Permisos de los . ht Por defecto bloquearemos los accesos externos a los ficheros de configuración, y este mismo. Aunque dejaremos accesos al "Well-Known". location ~ /\. well-known { allow all; } location ~ /\. ht { deny all; } Ficheros estáticos Daremos algo de vida a los ficheros estáticos, tanto para que no den errores, como para configurar su caché. location ~ /favicon. (ico|png) { log_not_found off; access_log off; } location = /robots. txt { allow all; log_not_found off; access_log off; } location ~* \. (bmp|bz2|cur|doc|docx|exe|gif|eot|gz|htc|ico|jpeg|jpg|mid|midi|mp3|mp4|ogg|ogv|otf|png|ppt|pptx|rar|rtf|svg|svgz|tar|tgz|ttf|wav|webm|woff|woff2|xls|xlsx|zip)$ { expires max; add_header Cache-Control "public"; log_not_found off; access_log off; } location ~* \. (atom|css|js|rss)$ { expires 7d; add_header Cache-Control "public"; log_not_found off; access_log off; } location ~* \. (? :ttf|eot|woff|otf)$ { add_header Access-Control-Allow-Origin "*"; } Bloqueo de accesos a ficheros con datos Con estos bloqueos impedimos el acceso a determinados ficheros del sistema, a configuraciones de WordPress o cambiamos la respuesta de lo que devuelve por defecto el servidor web. location ~* readme\. (html|txt) { deny all; } location ~* (licencia|license|LICENSE|olvasdel|lisenssi|liesmich)\. (html|txt) { deny all; } location ~* ^/wp-config { deny all; } location ~* ^/wp-cron\. php { deny all; } location ~* ^/wp-admin/(install|setup-config|upgrade)\. php { deny all; } location ~* ^/wp-admin/maint/repair\. php { deny all; } location ~* ^/wp-links-opml\. php { deny all; } location ~* ^/wp-content/mu-plugins/$ { return 404; } location ~* ^/wp-content/(plugins|themes)/(. +)/$ { return 404; } location ~* ^/wp-content/(? :uploads|files)/. +\. (html|js|php|shtml|swf)$ { deny all; } location ~* ^/wp-content/plugins/. +\. (aac|avi|bz2|cur|docx? |eot|exe|flv|gz|heic|htc|m4a|midi? |mov|mp3|mp4|mpe? g|ogg|ogv|otf|pdf|pptx? |rar|rtf|tar|tgz|tiff? |ttc|wav|wmv|xlsx? |zip) { deny all; } location ~* sftp-config. json { deny all; } location ~* (access|error)_log { deny all; } location ~* installer-log\. txt { deny all; } location ~* ^/wp-content/debug. log { deny all; } location ~* (^#. *#|\. (bak|config|dist|fla|inc|ini|log|psd|sh|sql|sw)|~)$ { deny all; } Mitigation CVE-2018-6389 Por norma general es mejor bloquear el posible ataque que se puede llevar a cabo de forma sencilla con la carga de todos los scripts. Para evitarlo es mejor bloquear su carga. location ~* load-(scripts|styles)\. php { deny all; } Bloqueo del XML-RPC Si no usamos esta tecnología (por ejemplo, desde las Apps de WordPress o tenemos desactivados los pingbacks, por seguridad es una buena opción. # BLOCK XML-RPC location ~* /xmlrpc\. php { deny all; } Bloqueo de usuarios en la REST-API Para evitar de una forma rápida y simple obtener el listado de usuarios de WordPress, podemos limitar el acceso a esta petición. No lo bloquees si estás usando esta funcionalidad de la REST-API. # BLOCK USERS API location ~* ^/wp-json/wp/v2/users/ { deny all; } Configuración de las peticiones Configuramos el servdor para que todas las peticiones que lleguen (y no se hayan bloqueado previamente) sean contestadas por el sistema. En este caso, se incluye el sistema de peticiones de la caché, que sería priopritaria a otras peticiones. location / { try_files $cachefile $uri $uri/ /index. php? $args; } Ejecución de PHP Configuraremos PHP para que pueda responder las peticiones de WordPress. # ROOT PHP location ~ . php$ { fastcgi_pass unix:/var/run/php/php8. 0-fpm. sock; fastcgi_index index. php; fastcgi_buffers 256... --- Última revisión: 2 de octubre de 2021 Si queremos bloquear de forma automática algunos ataques podemos usar fail2ban, una herramienta que suele venir instalada en los sistemas Linux que bloquean peticiones múltiples. Aprovechando la tecnología de fail2ban podemos aplicar una serie de reglas y, en caso de ataque, el firewall se encargará de añadir el bloqueo durante el tiempo que se establezca. Para esto usaremos WAF for WordPress, que incluye varias funcionalidades de bloqueo; principalmente usaremos dos de ellas: la primera que analiza las peticiones HTTP que llegan por la URL, y la segunda que analiza peticiones al core. IMPORTANTE: Un Firewall puede filtrar tráfico válido, por lo que es muy recomendable analizar con cuidado las excepciones o las configuraciones de plugins que podemos tener, ya que se pueden limitar funcionalidades. Requisitos WordPressFail2Ban Configuración de Http_Analyzer Instalación La primera parte del Firewall es la que revisa las peticiones HTTP. En este caso deberemos analizar todas las peticiones justo cuando llegan y antes de que se cargue nada de WordPress. Comenzaremos entrando en la carpeta donde tengamos el wp-config. php, donde descargaremos el fichero del Firewall. wget https://raw. githubusercontent. com/szepeviktor/waf4wordpress/master/http-analyzer/waf4wordpress-http-analyzer. php -O waf4wordpress-http-analyzer. php También se puede descargar de forma manual el ZIP con todos los ficheros y lo encontraremos dentro de la carpeta http-analyzer. Configuración Ahora que tenemos el fichero, lo deberemos configurar. Para ello añadiremos al inicio del fichero wp-config. php las siguientes líneas: require_once __DIR__ . '/waf4wordpress-http-analyzer. php'; new \Waf4WordPress\Http_Analyzer; Esto hará que el fichero quede algo tal que así: --- Última revisión: 2 de octubre de 2021 Si aún no tienes WP-CLI, instálalo en tu servidor. Una vez lo tengas, puedes ampliar su funcionalidad. WP-CLI profile WP-CLI profile hace un análisis de varios indicadores de la ejecución en una instalación de WordPress de forma que puedas detectar puntos lentos en su funcionamiento. Lo primero será instalarlo si no lo tienes ya. wp package install wp-cli/profile-command --allow-root Una vez lo tengamos instalado, podemos ir a la carpeta donde tengamos el WordPress a analizar. cd /home/example. com/public_html/ Cuando estemos en la carpeta donde tenemos nuestro WordPress, podremos realizar una serie de consultas. La primera de ellas es la del "bootstrap", que analizará la instalación base de WordPress, cargando el propio WordPress, los plugins, themes y el inicio. wp profile stage bootstrap --all --allow-root Esto nos devolverá una tabla similar a la siguiente: +--------------------------+----------------+---------+------------+-------------+-------------+------------+--------------+--------------+---------------+ | hook | callback_count | time | query_time | query_count | cache_ratio | cache_hits | cache_misses | request_time | request_count | +--------------------------+----------------+---------+------------+-------------+-------------+------------+--------------+--------------+---------------+ | muplugins_loaded:before | | 0. 1316s | 0. 0006s | 1 | 25% | 1 | 3 | 0s | 0 | | muplugins_loaded | 2 | 0. 0002s | 0s | 0 | 50% | 1 | 1 | 0s | 0 | | plugins_loaded:before | | 0. 0161s | 0. 0006s | 2 | 54. 17% | 13 | 11 | 0s | 0 | | plugins_loaded | 5 | 0. 004s | 0s | 0 | | 0 | 0 | 0s | 0 | | setup_theme:before | | 0. 0002s | 0s | 0 | 100% | 4 | 0 | 0s | 0 | | setup_theme | 2 | 0. 0004s | 0s | 0 | | 0 | 0 | 0s | 0 | | after_setup_theme:before | | 0. 0072s | 0s | 0 | 100% | 89 | 0 | 0s | 0 | | after_setup_theme | 2 | 0. 0008s | 0s | 0 | 100% | 6 | 0 | 0s | 0 | | init:before | | 0. 0024s | 0s | 0 | 100% | 2 | 0 | 0s | 0 | | init | 30 | 0. 0197s | 0. 0006s | 2 | 98. 97% | 192 | 2 | 0s | 0 | | wp_loaded:before | | 0s | 0s | 0 | | 0 | 0 | 0s | 0 | | wp_loaded | 1 | 0s | 0s | 0 | | 0 | 0 | 0s | 0 | | parse_request:before | | 0. 0242s | 0s | 0 | 100% | 4 | 0 | 0s | 0 | | parse_request | 1 | 0s | 0s | 0 | | 0 | 0 | 0s | 0 | | send_headers:before | | 0. 0001s | 0s | 0 | 100% | 4 | 0 | 0s | 0 | | send_headers | 0 | 0s | 0s | 0 | | 0 | 0 | 0s | 0 | | pre_get_posts:before | | 0. 0002s | 0s | 0 | 100% | 2 | 0 | 0s | 0 | | pre_get_posts | 1 | 0s | 0s | 0 | | 0 | 0 | 0s | 0 | | the_posts:before | | 0. 001s | 0. 0005s | 1 | 100% | 6 | 0 | 0s | 0 | | the_posts | 2 | 0s | 0s | 0 | | 0 | 0 | 0s | 0 | | wp:before | | 0s | 0s | 0 | | 0 | 0 | 0s | 0 | | wp | 0 | 0s | 0s | 0 | | 0 | 0 | 0s | 0 | | template_redirect:before | | 0. 0002s | 0s | 0 | | 0 | 0 | 0s | 0 | | template_redirect | 7 | 0. 0006s | 0s | 0 | 100% | 14 | 0 | 0s | 0 | | template_include:before | | 0. 0001s | 0s | 0 | 100% | 2 | 0 | 0s | 0 | | template_include | 0 | 0s | 0s | 0 | | 0 | 0 | 0s | 0 | | wp_head:before | | 0. 0008s | 0s | 0 | 100% | 10 | 0 | 0s | 0 | | wp_head | 25 | 0. 0037s | 0s | 0 | 95. 37% | 103 | 5 | 0s | 0 | | loop_start:before | | 0. 0013s | 0s | 0 | 100% | 64 | 0 | 0s | 0 | | loop_start | 0 | 0s | 0s | 0 | | 0 | 0 | 0s | 0 | | loop_end:before | | 0. 0054s | 0. 0005s | 2 | 97. 39% | 112 | 3 | 0s | 0 | | loop_end | 0 | 0s | 0s | 0 | | 0 | 0 | 0s | 0 | | wp_footer:before | | 0. 0046s | 0. 0012s | 4 | 94. 44% | 68 | 4 | 0s | 0 | | wp_footer | 5 | 0. 0004s | 0s | 0 | 100% | 4 | 0 | 0s | 0 | | wp_footer:after | | 0s | 0s | 0 | | 0 | 0 | 0s | 0 | +--------------------------+----------------+---------+------------+-------------+-------------+------------+--------------+--------------+---------------+ | total (35) | 83 | 0. 2255s | 0. 0041s | 12 | 90. 77% | 701 | 29 | 0s | 0 | +--------------------------+----------------+---------+------------+-------------+-------------+------------+--------------+--------------+---------------+ La segunda prueba es la de hacer una consulta al "loop" para traer información de una entrada o contenido. wp profile stage main_query --all --allow-root Esto nos devolverá una tabla similar a la siguiente: +--------------------------+----------------+---------+------------+-------------+-------------+------------+--------------+--------------+---------------+ | hook | callback_count | time | query_time | query_count | cache_ratio | cache_hits | cache_misses | request_time | request_count | +--------------------------+----------------+---------+------------+-------------+-------------+------------+--------------+--------------+---------------+ | muplugins_loaded:before | | 0. 1427s | 0. 0005s | 1 | 25% | 1 | 3... --- Última revisión: 2 de octubre de 2021 Gracias al plugin WPPerformanceTester podemos realizar de forma sencilla algunas pruebas de rendimiento en nuestro WordPress. Estas pruebas hacen cálculos matemáticos, manipulación de cadenas de texto, iteraciones en bucle, condicionales, pruebas sobre MySQL y acciones sobre $wpdb. Más concretamente hace: Math: 100. 000 pruebas en funciones matemáticasString Manipulation: 100. 000 pruebas en manipulaciónd e cadenas de textoLoops: 1. 000. 000 de iteraciones en bucleConditionals: 1. 000. 000 de pruebas de lógica condicionalMySQL (connect, select, version, encode): 1. 000. 000 de funciones básicas de SQL$wpdb: 250 operaciones de INSERT, SELECT, UPDATE y DELETE mediante $wpdb Esta herramienta puede ir bien para hacer un análisis tanto de hosting compartido como de hosting dedicados o de VPS. Eso sí, se recomienda hacer las pruebas en una instalación independiente de WordPress, ya que estas pruebas pueden saturar o romper la base de datos y perder la información. Esta herramienta está pensada para hacer cálculos sobre el hosting y no pruebas de rendimiento sobre el funcionamiento propio del WordPress, por lo que da igual si hay más o menos plugins o configuraciones instaladas. NOTA: Este plugin hace tiempo que no se actualiza y en las últimas versiones da algunos problemas y errores. En este caso, en vez de descargarte la versión del Git (a menos que se haya actualizado últimamente) te recomiendo descargar nuestra versión que tiene algunas pequeñas correcciones que hacen que se pueda ejecutar en WordPress 5. 4+ y PHP 7. 3+ sin problema. Requisitos En principio sólo es necesario tener un WordPress. En este caso hemos hecho las pruebas creando uno desde cero. Instalación Como es un plugin, lo subiremos mediante el botón de "Añadir nuevo" que encontraremos en la opción plugins de nuestra instalación de WordPress. Una vez lo hayamos subido, lo podemos activar. Una vez activado, en la sección de Herramientas veremos la nueva opción de la herramienta. Si entramos en la herramienta veremos el mensaje gracias al cual podemos comenzar las pruebas. La prueba suele tardar unos segundos, ya que hace bastantes cálculos y bucles y eso requiere de cierto tiempo. Al realizar las pruebas obtendremos dos resultados. La primera es una gráfica comparativa con los tiempos medios de los resultados que la gente envía de forma anónima. La segunda es una tabla con las cifras. Resultados Para entender los resultados hemos hecho algunas pruebas (en el mismo hosting) simplemente ampliando la CPU y memoria de la máquina, y activando y desactivando algunas caché. También se indica la media en los datos recopilados por la herramienta de miles de pruebas. OperaciónCPU: 0,5 / RAM 1 GBCPU: 1 / RAM 2 GBCPU: 2 / RAM 4 GBCPU: 4 / RAM 8 GBIndustriaMath934516521518551String Manipulation664501508499693Loops4544454629Conditionals6770707148Mysql Connect0000Mysql Select Database0000Mysql Query Version1000Mysql Query Benchmark8618378337213792Total Time1032949154865492710556Execution32481778181816634155Queries per second308563550602Tiempos en milisegundos Como se puede ver, estas cifras varias mucho entre máquinas que pueden hacer pocos cálculos, pero llega un momento en el que ampliar la potencia no implica más (esto es debido a la cantidad de pruebas que nunca llegan al límite de los cálculos que puede hacer la máquina). Sin duda es una buena herramienta para analizar si hay algún tipo de cuello de botella en los cálculos de la máquina y para comprar empresas de hosting. --- Última revisión: 2 de octubre de 2021 Si tenemos WP-CLI que nos permite gestionar por completo todo lo que hay alrededor de WordPress, una vez instalado, tenemos WordOps como herramienta para la gestión de la creación y mantenimiento de sitios WordPress en un sistema no gestionado. En este caso, si tienes un servidor con Ubuntu o Debian, pero cada vez que has de crear un WordPress se te hace cuesta arriba, con este sistema puedes montar todo el sistema de forma sencilla, además de crear, actualizar y mantener todo con una serie de comandos como si de WP-CLI se tratase. WordOps provide the ability to deploy a blazing fast and secured WordPress with Nginx by using simple and easy to remember commands. Forked from EasyEngine v3, it's already much more than an up-to-date version of EEv3 with several new features including Let's Encrypt wildcard SSL certificates with DNS API validation support, Linux kernel optimizations or a new custom Nginx package with TLS v1. 3 and Cloudflare HTTP/2 HPACK support. WordOps Requisitos Sistema Operativo recomendado Ubuntu 20Ubuntu 18 Sistema Operativo compatible Ubuntu 16Debian 10Debian 9 El ejemplo de este tutorial es con Ubuntu 20. Instalación Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria universal. timedatectl set-timezone 'UTC' timedatectl set-ntp on Lo siguiente que haremos es comprobar la versión del sistema operativo y, posteriormente, hacer una actualización completa del mismo. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove snap install canonical-livepatch Ahora que tenemos todo actualizado, instalaremos WordOps. cd wget -qO wo wops. cc && sudo bash wo Esta ejecución nos devolverá el resultado de la instalación. En general no es muy rápida, así que ten paciencia. Welcome to WordOps install/update script v3. 13. 2 Installing wo dependencies Installing WordOps Running post-install steps WordOps (wo) require an username & and an email address to configure Git (used to save server configurations) Your informations will ONLY be stored locally Enter your name: Enter your email: Synchronizing wo database, please wait... WordOps (wo) installed successfully To enable bash-completion, just use the command: bash -l To install WordOps recommended stacks, you can use the command: wo stack install To create a first WordPress site, you can use the command: wo site create site. tld --wp Una vez finalizada la instalación, validaremos que funciona haciendo una actualización del software. wo update Podemos activar el auto completado automático, de forma que usando la tecla de tabulación se puedan completar las funciones, o mostrarnos la lista de opciones disponible. source /etc/bash_completion. d/wo_auto. rc Antes de crear ningún sitio, haremos una primera carga de todos los componentes básicos que vamos a utilizar, el stack inicial. Para ello ejecutaremos la instalación base. wo stack install Que instala una lista de servicios para tenerlos preparados. WP-CLI is already installed Start : wo-kernel Adding repository for MySQL, please wait... Adding repository for NGINX, please wait... Adding repository for PHP, please wait... Updating apt-cache Installing APT packages Applying Nginx configuration templates Testing Nginx configuration Restarting Nginx Testing Nginx configuration Restarting Nginx Configuring php7. 3-fpm Restarting php7. 3-fpm Tuning MySQL configuration Restarting mysql Restarting fail2ban Configuring Fail2Ban Configuring Sendmail Downloading PHPMyAdmin Downloading phpRedisAdmin Downloading Composer Downloading Adminer Downloading Adminer theme Downloading MySQLTuner Downloading Netdata Downloading WordOps Dashboard Downloading eXtplorer Downloading cheat. sh Downloading bash_completion Downloading clean. php Downloading opcache. php Downloading Opgui Downloading OCP. php Downloading Webgrind Downloading pt-query-advisor Downloading Anemometer Installing composer Installing Netdata Restarting netdata Configuring packages HTTP Auth User Name: HTTP Auth Password : WordOps backend is available on https://IP_ADDRESS:22222/ Successfully installed packages Existen algunas opciones que podemos usar si las vemos necesarias, como por ejemplo cambiar de MySQL a MariaDB. wo stack migrate --mariadb O instalar PHP 7. 4 wo stack install --php74 Todos los comandos del stack están disponibles en su documentación. Podemos ver las versiones y todo lo instalado haciendo una llamada a su sistema de información. wo info Que nos devolverá la información de versiones de los distintos servicios. NGINX (1. 18. 0): user www-data worker_processes auto worker_connections 50000 keepalive_timeout 8 fastcgi_read_timeout 300 client_max_body_size 100m allow 127. 0. 0. 1 ::1 PHP 7. 2 is not installed PHP (7. 3. 24-3): user expose_php Off memory_limit 128M post_max_size 100M upload_max_filesize 100M max_execution_time 300 Information about www. conf ping. path /ping pm. status_path /status process_manager ondemand pm. max_requests 1500 pm. max_children 50 pm. start_servers 10 pm. min_spare_servers 5 pm. max_spare_servers 15 request_terminate_timeout 300 xdebug. profiler_enable_trigger off listen php73-fpm. sock Information about debug. conf ping. path /ping pm. status_path /status process_manager ondemand pm. max_requests 1500 pm. max_children 50 pm. start_servers 10 pm. min_spare_servers 5 pm. max_spare_servers 15 request_terminate_timeout 300 xdebug. profiler_enable_trigger on listen 127. 0. 0. 1:9173 MySQL (10. 5. 8-MariaDB) on localhost: port 3306 wait_timeout 60 interactive_timeout 28800 max_used_connections 2 datadir /var/lib/mysql/ socket /var/run/mysqld/mysqld. sock my. cnf /etc/mysql/conf. d/my. cnf Panel de WordOps Al final de la instalación del stack nos aparecerá el usuario y contraseña para acceder al panel de información de WordOps. Se accede por el puerto 22222, por lo que deberemos tenerlo accesible si tenemos algún tipo de firewall. https://IP_ADDRESS:22222/ Si queremos tener un panel o sitio por el que entrar con nuestro dominio, podemos crear el certificado con Let's Encrypt. Para ello deberemos crear un sitio (sin contenido). wo site create example. com -le A partir de este momento podremos acceder mediante el propio dominio. https://example. com:22222/ En caso de no recordar la contraseña, no haberla apuntado durante la instalación o querer cambiar los datos, podemos solicitar un cambio en la seguridad. wo secure --auth En cualquier caso, podemos cambiar la configuración de acceso al Backend según su documentación. Creación de un sitio WordPress Creación simple Ahora que tenemos todo el sistema puesto al día, vamos a crear nuestro primer sitio web. En este caso vamos a crear un sitio con el dominio (que automáticamente funcionaría con el www) y con un certificado TLS de Let's Encrypt para que funcione de... --- Última revisión: 2 de octubre de 2021 Si tenemos sitios sencillos, simplemente con información, pero en los cuales los usuarios no interactúan con nada, podríamos plantearnos crear sitios estáticos en los que todo sea HTML, CSS, JavaScript y contenidos como imágenes o documentos, pero sin que intervenga PHP. Esto lo podemos hacer con una herramienta de código abierto como WP2static que busca todas las URL y contenidos del sitio, y genera una versión estática de la misma en unos pocos pasos. Esta herramienta no viene creada a modo de plugin directamente, por lo que tendremos que crear algunos pasos previos, además de configurar dos sitios, el que tiene el WordPress (que puede ser no público) y el que tiene los contenidos finales estáticos, al que accederán los usuarios. Requisitos Acceso SSH a tu cuenta del servidorWP-CLI (para que funcione de forma óptima) Sobre WP2static Hay que tener presente que este plugin sólo tiene el código básico, pero no viene "creado como un plugin", por lo que tendremos que generarlo según vayan apareciendo versiones nuevas. Esto va a requerir varios elementos: Descargar y actualizar el plugin con GitActualizar sus componentes mediante ComposerCrear el PluginSubir el plugin a un sitio "no público"Generar el sitio estático de forma pública El WordPress original no debe estar de forma pública (puede estarlo, pero puede ser un sitio protegido, pero no para que entren los usuarios). Puedes ponerlo en un subdominio, por ejemplo working. example. com aunque luego tengamos el sitio en www. example. com. Para empezar, necesitaremos tener una carpeta "no pública" donde poder trabajar y crear el plugin. Si tu hosting te da unas carpetas del estilo a /home/example/public_html/, podemos usar algo tipo /home/example/wp2static/. Es posible que tu sistema permita la creación de subcarpetas como si se tratasen de subdominios. Primera instalación Lo primero que vamos a hacer y conseguir es crear el plugin que deberemos instalar en nuestro WordPress. El desarrollador inicial tiene creado el núcleo del plugin, pero requiere de ciertas dependencias, así que necesitamos "crear nuestro plugin" antes de poder instalarlo. Iremos a la carpeta base donde vamos a situar el Git. cd /home/example/ Haremos la clonación por primera vez del repositorio Git donde está el WP2Static. git clone https://github. com/leonstafford/wp2static. git Entraremos en la carpeta recién creada donde estarán los ficheros. cd wp2static/ Por defecto, WP2Static, viene para trabajar en modo desarrollo, pero esta versión puede contener fallos o problemas. Así que cambiaremos a la carpeta principal estable. git checkout master Ahora que tenemos el código principal, descargaremos todas las actualizaciones de las dependencias que son necesarias para que el plugin funcione, mediante Composer. composer install En este momento tenemos ya el software creado y listo para crear nuestro plugin. Actualización y mantenimiento Si ya hemos creado previamente el plugin, o queremos validar que esté 100% puesto al día para crear una siguiente versión, podemos realizar unas tareas previas de mantenimiento antes de generar el plugin. Accederemos a la carpeta previamente creada por el Git. cd /home/example/wp2static/ Actualizaremos la información del Git. git pull Nos aseguramos de estar en la rama master. git checkout master Realizamos una actualización de los componentes. composer update En este momento tenemos ya el software actualizado y listo para crear nuestro plugin. Creando el Plugin Ahora que tenemos el software actualizado, completo, y con todos sus componentes, podremos crear el plugin fácilmente. Este comando creará un fichero ZIP que será compatible con los plugins de WordPress, y que podremos subir directamente al panel de administración mediante el Añadir Nuevo (plugin). composer build wp2static Esto crea un fichero ZIP que se encuentra en la carpeta Downloads. cd . . /Downloads/ ls -la Allí tendremos el fichero wp2static. zip, que podremos descargar y usar como Plugin para nuestro WordPress. Instalando / actualizando el plugin Iremos a nuestro sitio web WordPress, accediendo al Panel de Administración working. example. com/wp-admin/ y allí accederemos a la zona de Plugins, donde pulsaremos en "Añadir nuevo". Subiremos el fichero y comenzará el proceso de instalación o actualización. Una vez acabado, validaremos que el plugin esté activo. Una vez activado tendremos la opción WP2Static en el menú de opciones. En la sección de Options actualizaremos la información de la URL que vamos a utilizar https://www. example. com sin la barra final, y configuraremos una cuenta de correo si queremos recibir notificaciones cada vez que se publique una actualización del sitio. Una vez tengamos la configuración, confirmaremos que en la zona de Diagnostics tenemos todo al día y que todo tiene luz verde. Si todo está correctamente configurado, pasaremos a la sección de Jobs, donde en principio estará todo activado. La parte de WP-Cron la dejaremos por defecto a "disable" ya que aprovecharemos WP-CLI para la ejecución de las tareas. Ejecutando los procesos Antes de activar todo el sistema por defecto, haremos una primera prueba para comprobar que todo funciona correctamente. recuerda que para que funcione, necesitas tener instalado y funcionando WP-CLI. Tendremos como base que nuestro sitio WordPress para ejecutar el plugin está en el dominio working. example. com y que se encuentra en la ruta /home/example/working/. cd /home/example/working/ Una vez allí, ejecutaremos los 3 comandos que nos van generando diferentes situaciones. Comenzaremos por la detección de todo el sistema y su validación. wp wp2static detect Esto nos devolverá una serie de mensajes por pantalla Starting to detect WordPress site URLs. Detection complete. 623 URLs added to Crawl Queue. El siguiente paso es que se revisen todas las URL detectadas en el paso anterior y las descargue. wp wp2static crawl Esto nos devolverá una serie de mensajes por pantalla Starting crawling Starting to crawl detected URLs. Using CrawlCache. 404 for URL /blog/page/1/ Crawling complete. 1 crawled, 622 skipped (cached). Crawling completed Finalmente, con estos contenidos, crearemos todo el sitio listo para navegar, cambiando las URL a las direcciones definitivas. wp wp2static post_process Esto nos devolverá una serie de mensajes por pantalla Processing crawled site. Finished processing crawled site. Podemos comprobar que todo el sitio está disponible en la ruta que genera para su... --- Última revisión: 2 de octubre de 2021 Existen herramientas propias o externas de WordPress que nos sirven para realizar algunas tareas interesantes a la hora de gestionar o analizar nuestros sitios o sitios externos. En esta página hay tutoriales o reseñas sobre estas herramientas, cómo instalarlas, utilizarlas o configurarlas. Rendimiento Prueba de rendimiento con WP Performance Tester Gracias al plugin WPPerformanceTester podemos realizar de forma sencilla algunas pruebas de rendimiento en nuestro WordPress. Estas pruebas hacen cálculos matemáticos, manipulación de cadenas de texto, iteraciones en bucle, condicionales, pruebas sobre MySQL y acciones sobre $wpdb. Haz estático WordPress con WP2static Si tenemos sitios sencillos, simplemente con información, pero en los cuales los usuarios no interactúan con nada, podemos crear sitios estáticos en los que todo sea HTML, CSS, JS y contenidos. Seguridad Seguridad WordPress con WPScan WPScan es una herramienta de código abierto que permite analizar la seguridad de cualquier sitio web con WordPress, propio o de otros. Es por esto que es importante proteger tu sitio frente a todos los posibles avisos que de esta herramienta, ya que es la que usan muchos intrusos para analizar. Antimalware Scanner para WordPress AMWScan es una herramienta escrita en PHP y que analiza código PHP, por lo que viene perfecto a la hora de analizar WordPress. Además, tiene una integración cuando detecta WordPress que realiza algunas tareas extra, como el checksum de los plugins y themes en el repositorio oficial. Firewall con WAF for WordPress Usaremos WAF for WordPress, que incluye varias funcionalidades de bloqueo; principalmente usaremos dos de ellas: la primera que analiza las peticiones HTTP que llegan por la URL, y la segunda que analiza peticiones al core. Firewall para Ubuntu con CrowdSec para WordPress Disponer de un cortafuegos (firewall) a nivel de Sistema Operativo no es una tarea sencilla habitualmente, y por eso solemos instalarlos como WAF para WordPress... pero ¿y si hubiera un firewall sencillo de instalar y mantenido por la comunidad? Mantenimiento WordOps para gestionar VPS de WordPress Si tenemos WP-CLI que nos permite gestionar por completo todo lo que hay alrededor de WordPress, una vez instalado, tenemos WordOps como herramienta para la gestión de la creación y mantenimiento de sitios WordPress en un sistema no gestionado. --- Última revisión: 2 de octubre de 2021 WordPress es un sistema seguro, pero siempre podemos esperar ataques de otros hackers o personas que tienen alguna intención maliciosa contra nuestro sitio. Y para evitar esto, analizaremos nuestro sitio con WPScan. WPScan es una herramienta de código abierto que permite analizar la seguridad de cualquier sitio web con WordPress, propio o de otros. Es por esto que es importante proteger tu sitio frente a todos los posibles avisos que de esta herramienta, ya que es la que usan muchos intrusos para analizar. Aunque existe un plugin, sólo recoge las vulnerabilidades de tu sitio y que son fácilmente detectables, pero no otros factores que sí que pueden conseguir los posibles intrusos. Requisitos Linux (Kali o Ubuntu) Instalación Accederemos por SSH a la máquina. En caso de ser un servidor VPS haremos una actualización completa y lo pondremos en hora como sistema inicial. Primero pondremos en hora el sistema. timedatectl set-timezone 'UTC' timedatectl set-ntp on Haremos una revisión del sistema y actualizaremos lo existente. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Antes de instalar WPScan, añadiremos algún software que nos puede ser necesario para su correcto funcionamiento. apt -y install software-properties-common build-essential curl vim zip unzip apt-transport-https libcurl4-gnutls-dev libxml2 libxml2-dev libxslt1-dev ruby-dev git gem ruby zlib1g zlib1g-dev Procederemos a la instalación gem install wpscan Si ejecutamos el siguiente comando, deberíamos obtener un resultado para saber que todo es correcto. wpscan --version Obteniendo lo siguiente _______________________________________________________________ __ _______ _____ \ \ / / __ \ / ____| \ \ /\ / /| |__) | (___ ___ __ _ _ __ ® \ \/ \/ / | ___/ \___ \ / __|/ _` | '_ \ \ /\ / | | ____) | (__| (_| | | | | \/ \/ |_| |_____/ \___|\__,_|_| |_| WordPress Security Scanner by the WPScan Team Version 3. 8. 10 Sponsored by Automattic - https://automattic. com/ @_WPScan_, @ethicalhack3r, @erwan_lr, @firefart _______________________________________________________________ Current Version: 3. 8. 10 Last DB Update: 2020-12-11 Puesta al día Si hace tiempo que no hemos hecho una actualización del software o ejecutado, deberíamos hacer una puesta al día, tanto para actualizar el propio WPScan, como para actualizar la base de datos de análisis y vulnerabilidades. gem update wpscan wpscan --update Con esto tendremos todo lo necesario para hacer los análisis. Análisis En todos los ejemplos se va a utilizar el dominio example. com como dominio de ejemplo, que deberás sustituir por el dominio que quieras analizar. te recomendamos que utilices la URL final, sin redirecciones, para obtener los resultados óptimos. Análisis simple Con esto obtendremos un primer análisis con la configuración por defecto de WPScan. Nos dará cierta información, aunque no completa. wpscan --url https://example. com/ --random-user-agent El resultado será similar a esto URL: https://example. com/ Started: Fri Dec 11 17:04:05 2020 Interesting Finding(s): Headers | Interesting Entries: | - server: Apache | - content-security-policy: upgrade-insecure-requests; | - referrer-policy: origin-when-cross-origin | Found By: Headers (Passive Detection) | Confidence: 100% robots. txt found: https://example. com/robots. txt | Found By: Robots Txt (Aggressive Detection) | Confidence: 100% This site seems to be a multisite | Found By: Direct Access (Aggressive Detection) | Confidence: 100% | Reference: http://codex. wordpress. org/Glossary#Multisite Fingerprinting the version - Time: 00:00:00 (694 / 694) 100. 00% Time: 00:00:00 WordPress version 5. 6 identified (Latest, released on 2020-12-08). | Found By: Unique Fingerprinting (Aggressive Detection) | - https://example. com/wp-admin/js/customize-controls. js md5sum is 60fd86fb779d8562016277fa549883c5 The main theme could not be detected. Enumerating All Plugins (via Passive Methods) Checking Plugin Versions (via Passive and Aggressive Methods) Plugin(s) Identified: wp-super-cache | Location: https://example. com/wp-content/plugins/wp-super-cache/ | Latest Version: 1. 7. 1 | Last Updated: 2020-12-09T09:55:00. 000Z | | Found By: Comment (Passive Detection) | | The version could not be determined. Enumerating Config Backups (via Passive and Aggressive Methods) Checking Config Backups - Time: 00:00:02 (22 / 22) 100. 00% Time: 00:00:02 No Config Backups Found. No WPVulnDB API Token given, as a result vulnerability data has not been output. You can get a free API token with 50 daily requests by registering at https://wpscan. com/register Finished: Fri Dec 11 17:04:24 2020 Requests Done: 75 Cached Requests: 5 Data Sent: 21. 574 KB Data Received: 2. 803 MB Memory used: 232. 898 MB Elapsed time: 00:00:19 Análisis pasivo Este análisis nos devolverá toda la información que el sistema detecte sin realizar una búsqueda activa, simplemente analizando aquello que se encuentra por delante. No es la mejor opción, aunque sí una de las más rápidas. wpscan --url https://example. com/ --random-user-agent --verbose --disable-tls-checks --clear-cache --wp-version-all --plugins-version-all --themes-version-all --detection-mode passive --interesting-findings-detection passive --wp-version-detection passive --main-theme-detection passive --plugins-detection passive --plugins-version-detection passive --themes-detection passive --themes-version-detection passive --timthumbs-detection passive --config-backups-detection passive --db-exports-detection passive --medias-detection passive --users-detection passive Análisis activo Este análisis nos devolverá toda la información que el sistema detecte realizando una búsqueda activa, analizando lo que se puede encontrar, pero también buscando contenidos que a simple vista pueden no verse. En este caso se buscarán los plugins y themes de los que se tiene constancia de alguna vulnerabilidad. wpscan --url https://example. com/ --random-user-agent --verbose --disable-tls-checks --clear-cache --wp-version-all --plugins-version-all --themes-version-all --detection-mode mixed --interesting-findings-detection mixed --wp-version-detection mixed --main-theme-detection mixed --plugins-detection mixed --plugins-version-detection mixed --themes-detection mixed --themes-version-detection mixed --timthumbs-detection mixed --config-backups-detection mixed --db-exports-detection mixed --medias-detection mixed --users-detection mixed --enumerate vp,vt,tt,cb,dbe,u1-25,m1-100 Análisis agresivo Este es el análisis más agresivo que puede ejecutar WPScan. En él se buscan todas las opciones posibles a nivel de plugins (se buscarán todos los que hay en el repositorio oficial), al igual que los themes (se buscarán todos los del repositorio oficial). wpscan --url https://example. com/ --random-user-agent --verbose --disable-tls-checks --clear-cache --wp-version-all --plugins-version-all --themes-version-all --detection-mode mixed --interesting-findings-detection mixed --wp-version-detection mixed --main-theme-detection mixed --plugins-detection mixed --plugins-version-detection mixed --themes-detection mixed --themes-version-detection mixed --timthumbs-detection mixed --config-backups-detection mixed --db-exports-detection mixed --medias-detection mixed --users-detection mixed --enumerate ap,at,tt,cb,dbe,u1-100,m1-1000 Más opciones WPScan tiene algunas opciones extra que pueden ser muy útiles si no podemos dejar el sistema abierto por pantalla, o queremos obtener los resultados en un fichero descargable. Descarga de... --- Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: Ubuntu 20 LTEServidor web: nginxBase de Datos: MariaDB 10. 5Procesador: PHP 8. 0 + PHP 7. 4Caché: Redis Aquí te dejamos un pequeño manual de instalación desde una instalación de sistema operativo básico de Ubuntu 20. Configurando el Sistema Operativo Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria universal UTC. timedatectl set-timezone 'UTC' timedatectl set-ntp on Lo siguiente que haremos es comprobar la versión del sistema operativo y, posteriormente, hacer una actualización completa del mismo. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Una vez esta todo actualizado, instalamos algunas herramientas y software base que puede ser útil tener en el sistema. apt -y install software-properties-common curl vim zip unzip apt-transport-https sendmail npm Antes de acabar, activaremos las actualizaciones automáticas de seguridad del sistema operativo. apt -y install unattended-upgrades dpkg-reconfigure -plow unattended-upgrades Instalación de MariaDB El siguiente paso será la instalación de la base de datos. En este caso vamos a utilizar MariaDB 10. 5. Lo primero que haremos será configurar la descarga, y posteriormente su instalación. curl -sS https://downloads. mariadb. com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10. 5" apt -y install mariadb-server mariadb-client Ahora que está instalada, procederemos a la configuración inicial. Para ello usaremos el sistema de instalación segura, que nos hará algunas preguntas. mysql_secure_installation A la pregunta de si queremos cambiar la contraseña, dependiendo de si hemos puesto o no en la instalación, la cambiaremos. En caso de no haber puesto ninguna, es muy recomendable ponerle una contraseña segura. Set root password? : Y Al resto de preguntas, contestaremos lo siguiente: Remove anonymous users? : Y Disallow root login remotely? : Y Remove test database and access to it? : Y Reload privilege tables now? : Y En este momento ya tendremos la base de datos configurada. Ahora haremos que se ejecute en los re inicios del sistema y la iniciaremos. systemctl stop mysql. service systemctl enable mysql. service systemctl start mysql. service systemctl status mysql. service Instalación de nginx A partir de aquí tenemos la base de datos configurada y vamos a proceder a la instalación del servidor web. En este caso vamos a usar nginx. Para estar al día, no usaremos la versión que viene con el sistema operativo, sino una más actualizada y mantenida. add-apt-repository -y -s ppa:ondrej/nginx apt -y install nginx nginx-extras Ahora que tenemos nginx instalado, lo vamos a configurar para que se inicie en los re inicios del sistema automáticamente. systemctl stop nginx. service systemctl enable nginx. service systemctl start nginx. service systemctl status nginx. service Instalación de PHP En este momento ya tenemos el servidor web, por lo que vamos a instalar y a configurar PHP para que funcione correctamente con la base de datos y el servidor web. En este caso vamos a instalar las versiones de PHP 8. 0 y PHP 7. 4. Primero haremos la instalación de los paquetes más actualizados (que no son los que vienen con el sistema operativo) y que en caso de necesitarlo, además, nos permitirían tener varias versiones de PHP en paralelo. add-apt-repository -y -s ppa:ondrej/php Primero instalaremos PHP 8. 0 apt -y install php8. 0 php8. 0-fpm php8. 0-common php8. 0-dev php8. 0-cli php8. 0-bcmath php8. 0-curl php8. 0-gd php8. 0-intl php8. 0-imap php8. 0-mbstring php8. 0-mysql php8. 0-opcache php8. 0-soap php8. 0-xml php8. 0-zip php8. 0-imagick imagemagick libmagickwand-dev Posteriormente instalaremos PHP 7. 4 apt -y install php7. 4 php7. 4-fpm php7. 4-common php7. 4-dev php7. 4-cli php7. 4-bcmath php7. 4-curl php7. 4-gd php7. 4-intl php7. 4-imap php7. 4-json php7. 4-mbstring php7. 4-mysql php7. 4-opcache php7. 4-soap php7. 4-xml php7. 4-xmlrpc php7. 4-zip php7. 4-imagick imagemagick libmagickwand-dev Y lanzaremos la instalación de la extensión Sodium. apt -y install build-essential php-pear php-dev pkg-config pecl channel-update pecl. php. net cd wget https://download. libsodium. org/libsodium/releases/LATEST. tar. gz tar xvf LATEST. tar. gz rm -rf LATEST. tar. gz cd libsodium-stable/ . /configure make && make check make install cd pecl install libsodium echo "extension=sodium. so" >> /etc/php/8. 0/mods-available/libsodium. ini echo "extension=sodium. so" >> /etc/php/7. 4/mods-available/libsodium. ini Ahora que ya tenemos PHP correctamente instalado, vamos a activarlo de forma que cuando se reinicie el sistema se ejecute automáticamente. systemctl stop php8. 0-fpm. service systemctl enable php8. 0-fpm. service systemctl start php8. 0-fpm. service systemctl status php8. 0-fpm. service systemctl stop php7. 4-fpm. service systemctl enable php7. 4-fpm. service systemctl start php7. 4-fpm. service systemctl status php7. 4-fpm. service php -v Instalación de Redis Para trabajar con unas mejoras en el rendimiento de la caché de objetos, vamos a dejar listo Redis como sistema de almacenamiento. apt -y install redis-server php8. 0-redis php7. 4-redis Posteriormente, y de la misma forma que el resto de elementos, lo vamos a configurar para que se inicie automáticamente si se reinicia el servidor. systemctl stop redis-server. service systemctl enable redis-server. service systemctl start redis-server. service systemctl status redis-server. service Configuración del HTTPS Como vamos a montar nuestra web sobre un servidor web seguro (HTTPS), necesitaremos instalar el generador de certificados de Let's Encrypt. Para ello instalaremos el sistema de creación de certificados certbot. snap install core && snap install --classic certbot ln -s /snap/bin/certbot /usr/bin/certbot Si es la primera vez que vamos a usar la cuenta de correo necesaria para recibir avisos de la caducidad de los certificados, deberemos registrarla. certbot register --email wordpress@example. com --agree-tos --no-eff-email En caso de que ya la tengamos activa, podemos actualizarla. certbot update_account --email wordpress@example. com --agree-tos --no-eff-email Para que los certificados se actualicen automáticamente, activaremos una tarea programada (cron) una vez al día que automáticamente renueve los certificados. crontab -e Una vez dentro, configuraremos, por ejemplo, que se ejecute a las 06:45 cada mañana. 45 6 * * * certbot renew Limpiando los sitios por defecto Por defecto, el sistema responde a la dirección IP y a otros elementos. Para evitar que los sitios por defecto se muestren,... --- Última revisión: 2 de octubre de 2021 Si quieres hacer pruebas en un entorno de desarrollo (sin necesidad de enviar los datos), puedes hacerlo sin problema. El objetivo de esta prueba es trabajar con múltiples opciones y configuraciones, con el objetivo final de que encuentres el mejor entorno para trabajar. Requisitos Aunque no hay unos requisitos mínimos de por sí, en las pruebas que he podido hacer me he encontrado que, al menos, se recomienda: VPS (también se puede usar un entorno local)1 CPU2 GB RAM10 GB SSDUbuntu, CentOS, Debian... Ubuntu 18. 04 LTEMySQL, MariaDB, Percona for MySQLMariaDB 10. 4PHPPHP 7. 4 Hay que tener en cuenta que este ejemplo no plantea una máquina en producción, si no un ejemplo de distintos elementos y pruebas que se pueden ejecutar, contando la instalación se sistemas de caché, extensiones de PHP... Instalación base La instalación base plantea disponer los elementos mínimos para que el sistema funcione. Configuración del Sistema Operativo Lo primero que haremos será poner el sistema en hora. Para evitar problemas y teniendo en cuenta que puede ser una máquina que mande información al WordPress, lo mejor sería configurar el reloj en modo UTC de forma universal. timedatectl set-timezone UTC timedatectl set-ntp on Lo siguiente que haremos es poner la máquina al día en todo su sistema. Con esto nos aseguraremos que todo esté al día y que los conflictos se reducen al mínimo. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Instalaremos algunas herramientas necesarias y habituales como curl, vim, zip o el propio git. apt -y install software-properties-common curl vim unzip git Instalación de la base de datos Instalaremos MariaDB 10. 4 en la prueba. En principio sirve cualquier base de datos compatible con WordPress. curl -sS https://downloads. mariadb. com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10. 4" apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install mariadb-server mariadb-client systemctl restart mysql. service Una vez acabada la instalación haremos una primera configuración para dejarla lista. mysql_secure_installation A partir de este momento el sistema nos hará una serie de preguntas y configuraremos la contraseña de root de la propia base de datos. Enter current password for root (enter for none): Switch to unix_socket authentication n Change the root password? y Remove anonymous users? y Disallow root login remotely? y Remove test database and access to it? y Reload privilege tables now? y Reiniciaremos la base de datos para que tome todos los datos y deje el sistema listo. systemctl restart mysql. service Instalación de PHP Para esta prueba instalaremos PHP 7. 4. En un primer momento sólo vamos a instalar los elementos mínimos, por lo que seguramente tengamos que ampliar posteriormente con algunas extensiones. Como decía al inicio, el objetivo es probar el sistema, por lo que en este momento tiene sentido que nos de error por falta de elementos. add-apt-repository -y ppa:ondrej/php apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install php7. 4 php7. 4-curl php7. 4-dev php7. 4-fpm php7. 4-mbstring php7. 4-mysql php7. 4-mysqlnd apt -y install php-pear pkg-config pecl channel-update pecl. php. net Aunque podemos dejar la configuración de PHP como la tengamos en el sistema habitual que se ofrece a los clientes, para esta prueba haremos unos pequeños cambios. vim /etc/php/7. 4/fpm/php. ini Y cambiaremos estas configuraciones. max_execution_time = 60 memory_limit = 256M post_max_size = 128M upload_max_filesize = 128M date. timezone = 'UTC' Una vez finalizara la reconfiguración, reiniciaremos el servicio y lo activaremos por defecto. systemctl stop php7. 4-fpm. service systemctl enable php7. 4-fpm. service systemctl start php7. 4-fpm. service Instalación de Node Para que las pruebas funcionen correctamente necesitaremos algunos elementos que quizá habitualmente no estén disponibles. Entre ellos etsá NodeJS, Grunt y PhantomJS. Primero instalamos NodeJS cd curl -sL https://deb. nodesource. com/setup_12. x | bash - apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install nodejs Posteriormente instalamos Grunt npm install -g grunt Y finalmente instalamos PhantomJS apt -y install build-essential chrpath libssl-dev libxft-dev libfreetype6 libfreetype6-dev libfontconfig1 libfontconfig1-dev cd wget https://bitbucket. org/ariya/phantomjs/downloads/phantomjs-2. 1. 1-linux-x86_64. tar. bz2 tar xvjf phantomjs-2. 1. 1-linux-x86_64. tar. bz2 -C /usr/local/share/ ln -sf /usr/local/share/phantomjs-2. 1. 1-linux-x86_64/bin/phantomjs /usr/local/bin rm -rf phantomjs-2. 1. 1-linux-x86_64. tar. bz2 Finalizando la configuración Para acabar la configuración de la máquina, haremos algunos ajustes. Para empezar, actualizaremos todo de nuevo y nos aseguramos que no haya quedado ninguna biblioteca colgada. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Y configuraremos la base de datos de pruebas que vamos a utilizar en los test. Entraremos en el servidor. mysql -u root -p Y crearemos una base de datos de prueba. En este caso se llamará wordpress y el usuario también será wordpress. Configura la contraseña que veas conveniente. CREATE DATABASE wordpress CHARACTER SET = utf8mb4 COLLATE = utf8mb4_bin; GRANT ALL ON wordpress. * TO 'wordpress'@'localhost' IDENTIFIED BY '__PASSWORD__'; GRANT ALL ON wordpress. * TO 'wordpress'@'127. 0. 0. 1' IDENTIFIED BY '__PASSWORD__'; FLUSH PRIVILEGES; quit A partir de este momento tenemos toda la base para poder hacer nuestro primer test. Instalación del PHPUnit test Seguiremos las instrucciones que hemos tenido previamente. Por defecto haremos las pruebas en la carpeta /tmp/. cd /home/ git clone https://github. com/WordPress/phpunit-test-runner. git cd /home/phpunit-test-runner/ cp . env. default . env Y estableceremos los contenidos del entorno con los datos de acceso que hemos creado previamente. vim . env Recuerda incluir la carpeta donde está instalado el software y donde estará instalado el WordPress, además de los datos de acceso a la base de datos. export WPT_PREPARE_DIR=/home/wp-test-runner export WPT_TEST_DIR=/home/wp-test-runner export WPT_REPORT_API_KEY= export WPT_REPORT_URL= export WPT_DB_NAME=wordpress export WPT_DB_USER=wordpress export WPT_DB_PASSWORD=__PASSWORD__ export WPT_DB_HOST=localhost export WPT_TABLE_PREFIX=${WPT_TABLE_PREFIX-wptests_} export WPT_PHP_EXECUTABLE=${WPT_PHP_EXECUTABLE-php} WPT_PHPUNIT_CMD= WPT_RM_TEST_DIR_CMD= export WPT_SSH_CONNECT= export WPT_SSH_OPTIONS= export WPT_SSH_PRIVATE_KEY_BASE64= export WPT_DEBUG= Preparando el entorno Antes de hacer la primera prueba, pondremos al día todo. Este proceso se puede ejecutar antes de hacer cada prueba en este entorno si queremos... --- Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: Ubuntu 18Panel de Control: ningunoServidor web: nginxBase de Datos: MariaDB 10. 3Procesador: PHP 7. 3Caché: Redis Aquí te dejamos un pequeño manual de instalación desde una instalación de sistema operativo básico de Ubuntu 18. Configurando el Sistema Operativo Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria de Madrid. timedatectl set-timezone 'Europe/Madrid' timedatectl set-ntp on Lo siguiente que haremos es comprobar la versión del sistema operativo y, posteriormente, hacer una actualización completa del mismo. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Una vez esta todo actualizado, instalamos algunas herramientas y software base que puede ser útil tener en el sistema. apt -y install software-properties-common curl vim unzip ufw Instalación de MariaDB El siguiente paso será la instalación de la base de datos. En este caso vamos a utilizar MariaDB 10. 3. Lo primero que haremos será configurar la descarga, y posteriormente su instalación. apt-key adv --recv-keys --keyserver hkp://keyserver. ubuntu. com:80 0xF1656F24C74CD1D8 add-apt-repository 'deb http://tedeco. fi. upm. es/mirror/mariadb/repo/10. 3/ubuntu bionic main' apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install mariadb-server mariadb-client Ahora que está instalada, procederemos a la configuración inicial. Para ello usaremos el sistema se instalación segura, que nos hará algunas preguntas. mysql_secure_installation A la pregunta de si queremos cambiar la contraseña, dependiendo de si hemos puesto o no en la instalación, la cambiaremos. En caso de no haber puesto ninguna, es muy recomendable ponerle una contraseña segura. Set root password? : Y Al resto de preguntas, contestaremos lo siguiente: Remove anonymous users? : Y Disallow root login remotely? : Y Remove test database and access to it? : Y Reload privilege tables now? : Y En este momento ya tendremos la base de datos configurada. Ahora haremos que se ejecute en los re inicios del sistema y la iniciaremos. systemctl stop mysql. service systemctl start mysql. service Instalación de nginx A partir de aquí tenemos la base de datos configurada y vamos a proceder a la instalación del servidor web. En este caso vamos a usar nginx. Para estar al día, no usaremos la versión que viene con el sistema operativo, sino una más actualizada y mantenida. add-apt-repository ppa:ondrej/nginx apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install nginx nginx-extras Ahora que tenemos nginx instalado, lo vamos a configurar para que se inicie en los re inicios del sistema automáticamente. systemctl stop nginx. service systemctl enable nginx. service systemctl start nginx. service Instalación de PHP En este momento ya tenemos el servidor web, por lo que vamos a instalar y a configurar PHP para que funcione correctamente con la base de datos y el servidor web. En este caso vamos a instalar la versión PHP 7. 3. Primero haremos la instalación de los paquetes más actualizados (que no son los que vienen con el sistema operativo) y que en caso de necesitarlo, además, nos permitirían tener varias versiones de PHP en paralelo. add-apt-repository ppa:ondrej/php apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install php7. 3 php7. 3-fpm php7. 3-common php7. 3-dev php7. 3-cli php7. 3-bcmath php7. 3-curl php7. 3-gd php7. 3-imap php7. 3-json php7. 3-mbstring php7. 3-mysql php7. 3-opcache php7. 3-soap php7. 3-xml php7. 3-xmlrpc php7. 3-zip php-imagick php-libsodium php-ssh2 php-xdebug libgeoip-dev En algunos casos, el sistema integra Apache HTTPD de serie, por lo que haremos una limpieza, por si queda algo de él instalado. apt -y purge apache2* Ahora que ya tenemos PHP correctamente instalado, vamos a activarlo de forma que cuando se reinicie el sistema se ejecute automáticamente. systemctl stop php7. 3-fpm. service systemctl enable php7. 3-fpm. service systemctl start php7. 3-fpm. service Instalación de Redis Para trabajar con unas mejoras en el rendimiento de la caché de objetos, vamos a dejar listo Redis como sistema de almacenamiento. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install redis-server php-redis Posteriormente, y de la misma forma que el resto de elementos, lo vamos a configurar para que se inicie automáticamente si se reinicia el servidor. systemctl stop redis-server. service systemctl enable redis-server. service systemctl start redis-server. service Configuración del HTTPS Como vamos a montar nuestra web sobre un servidor web seguro (HTTPS), necesitaremos instalar el generador de certificados de Let's Encrypt, de forma que previamente prepararemos los sistemas para la creación de claves seguras. openssl dhparam -out /etc/ssl/certs/dhparam. pem 2048 Y en este momento instalaremos el sistema de creación de certificados certbot. add-apt-repository ppa:certbot/certbot apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install python-certbot-nginx Para que los certificados se actualicen automáticamente, activaremos una tarea programada (cron) una vez al día que automáticamente renueve los certificados. crontab -e Una vez dentro, configuraremos, por ejemplo, que se ejecute a las 06:45 cada mañana. 45 6 * * * certbot renew Configuración del firewall Para acabar, vamos a activar el Firewall y dejar solo abierto los puertos de SSH (por los que estamos trabajando en estos momentos) y posteriormente los puertos web, dejando el resto inactivo. ufw app list ufw allow 'OpenSSH' ufw allow 'Nginx Full' ufw enable A partir de este momento podemos reiniciar la máquina si queremos, y ya la tendremos lista para comenzar su uso y montar los sitios web. --- Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: Ubuntu 19Panel de Control: ningunoServidor web: nginxBase de Datos: MariaDB 10. 3Procesador: PHP 7. 3Caché: Redis Aquí te dejamos un pequeño manual de instalación desde una instalación de sistema operativo básico de Ubuntu 19. Configurando el Sistema Operativo Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria de Madrid. timedatectl set-timezone 'Europe/Madrid' timedatectl set-ntp on Lo siguiente que haremos es comprobar la versión del sistema operativo y, posteriormente, hacer una actualización completa del mismo. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Una vez esta todo actualizado, instalamos algunas herramientas y software base que puede ser útil tener en el sistema. apt -y install software-properties-common curl vim unzip ufw Instalación de MariaDB El siguiente paso será la instalación de la base de datos. En este caso vamos a utilizar MariaDB 10. 3. Lo primero que haremos será configurar la descarga, y posteriormente su instalación. apt-key adv --recv-keys --keyserver hkp://keyserver. ubuntu. com:80 0xF1656F24C74CD1D8 add-apt-repository 'deb http://tedeco. fi. upm. es/mirror/mariadb/repo/10. 3/ubuntu bionic main' apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install mariadb-server mariadb-client Ahora que está instalada, procederemos a la configuración inicial. Para ello usaremos el sistema se instalación segura, que nos hará algunas preguntas. mysql_secure_installation A la pregunta de si queremos cambiar la contraseña, dependiendo de si hemos puesto o no en la instalación, la cambiaremos. En caso de no haber puesto ninguna, es muy recomendable ponerle una contraseña segura. Set root password? : Y Al resto de preguntas, contestaremos lo siguiente: Remove anonymous users? : Y Disallow root login remotely? : Y Remove test database and access to it? : Y Reload privilege tables now? : Y En este momento ya tendremos la base de datos configurada. Ahora haremos que se ejecute en los re inicios del sistema y la iniciaremos. systemctl stop mysql. service systemctl start mysql. service Instalación de nginx En este momento tenemos la base de datos configurada y vamos a proceder a la instalación del servidor web. En este caso vamos a usar nginx. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install nginx nginx-extras Ahora que tenemos nginx instalado, lo vamos a configurar para que se inicie en los re inicios del sistema automáticamente. systemctl stop nginx. service systemctl enable nginx. service systemctl start nginx. service Instalación de PHP En este momento ya tenemos el servidor web, por lo que vamos a instalar y a configurar PHP para que funcione correctamente con la base de datos y el servidor web. En este caso vamos a instalar la versión PHP 7. 3. Primero haremos la instalación de los paquetes más actualizados (que no son los que vienen con el sistema operativo) y que en caso de necesitarlo, además, nos permitirían tener varias versiones de PHP en paralelo. add-apt-repository ppa:ondrej/php apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install php7. 3 php7. 3-fpm php7. 3-common php7. 3-dev php7. 3-cli php7. 3-bcmath php7. 3-curl php7. 3-gd php7. 3-imap php7. 3-json php7. 3-mbstring php7. 3-mysql php7. 3-opcache php7. 3-soap php7. 3-xml php7. 3-xmlrpc php7. 3-zip php-imagick php-pear php-ssh2 php-xdebug libgeoip-dev Instalación de sodium En estos momentos faltaría un sistema, que es todo lo referente a la encriptación con libsodium y que tendremos que descargar y compilar antes de seguir instalando. wget https://download. libsodium. org/libsodium/releases/LATEST. tar. gz tar xvf LATEST. tar. gz cd libsodium-stable/ . /configure make && make check make install pecl install libsodium echo "extension=sodium. so" >> /etc/php/7. 3/mods-available/libsodium. ini En algunos casos, el sistema integra Apache HTTPD de serie, por lo que haremos una limpieza, por si queda algo de él instalado. apt -y purge apache2* Ahora que ya tenemos PHP correctamente instalado, vamos a activarlo de forma que cuando se reinicie el sistema se ejecute automáticamente. systemctl stop php7. 3-fpm. service systemctl enable php7. 3-fpm. service systemctl start php7. 3-fpm. service Instalación de Redis Para trabajar con unas mejoras en el rendimiento de la caché de objetos, vamos a dejar listo Redis como sistema de almacenamiento. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install redis-server php-redis Posteriormente, y de la misma forma que el resto de elementos, lo vamos a configurar para que se inicie automáticamente si se reinicia el servidor. systemctl stop redis-server. service systemctl enable redis-server. service systemctl start redis-server. service Configuración del HTTPS Como vamos a montar nuestra web sobre un servidor web seguro (HTTPS), necesitaremos instalar el generador de certificados de Let's Encrypt, de forma que previamente prepararemos los sistemas para la creación de claves seguras. openssl dhparam -out /etc/ssl/certs/dhparam. pem 2048 Y en este momento instalaremos el sistema de creación de certificados certbot. add-apt-repository ppa:certbot/certbot apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install python-certbot-nginx Para que los certificados se actualicen automáticamente, activaremos una tarea programada (cron) una vez al día que automáticamente renueve los certificados. crontab -e Una vez dentro, configuraremos, por ejemplo, que se ejecute a las 06:45 cada mañana. 45 6 * * * certbot renew Configuración del firewall Para acabar, vamos a activar el Firewall y dejar solo abierto los puertos de SSH (por los que estamos trabajando en estos momentos) y posteriormente los puertos web, dejando el resto inactivo. ufw app list ufw allow 'OpenSSH' ufw allow 'Nginx Full' ufw enable A partir de este momento podemos reiniciar la máquina si queremos, y ya la tendremos lista para comenzar su uso y montar los sitios web. --- Última revisión: 2 de octubre de 2021 Si utilizas Apache HTTPD o LiteSpeed o cualquier sistema basado en estos servidores web quizá te interese configurar el fichero . htaccess de la raíz de la configuración de tu WordPress de una manera compleja (más de la que viene por defecto). Configuración detallada por bloques HTTPS via Proxy Es posible que haya un proxy por delante de tu sitio web, por lo que si es así, debemos informar al sistema para decirle que ya está activado y que no ejecute determinados elementos. SetEnvIf X-Forwarded-Proto https HTTPS=on Módulo PageSpeed Aunque puede ser una buena solución en determinados casos, por defecto configuraremos el PageSpeed Module de forma inactiva por defecto ya que habrá varias configuraciones incluidas que hace este módulo en nuestra configuración. ModPagespeed off Bloqueo de ficheros de servidor Por defecto bloquearemos los accesos externos a los ficheros de configuración, y este mismo. Deny from all Deny from all Deny from all Allow from all Activar el CORS para algunos tipos En algunos casos los ficheros de fuentes necesitan ser llamados desde distintas Header set Access-Control-Allow-Origin "*" Desactivar el listado de directorios Algunos sistemas por defecto permiten que al acceder a una carpeta que no tenga un fichero de ejecución por defecto muestre todos los contenidos. Si este es el caso, podemos desactivar esta opción por defecto. Options -Indexes Ficheros por defecto Por defecto configuraremos que el servidor web haga llamadas al index. php, y en última instancia, que llame al fichero principal de WordPress. Además de decirle que siga y use los SymLinks. DirectoryIndex index. php index. html /index. php Options None Options FollowSymLinks ServerSignature Off Dominio canónico Aunque WordPress gestiona bien las redirecciones y los dominios principales, en los casos en los que solo utilicemos un dominio, lo mejor es hacer esa gestión controlada desde el . htaccess. En este caso configuramos tres elementos. Configuramos el dominio principal y realizamos / forzamos su uso. Posteriormente verificamos si está o no activado el HTTPS y, si no se está haciendo la petición, se fuerza. RewriteCond %{HTTP_HOST} ! www\. example\. com RewriteRule (. *) https://www. example. com%{REQUEST_URI} RewriteCond %{HTTPS} ! on RewriteRule (. *) https://%{HTTP_HOST}%{REQUEST_URI} Bloqueo de peticiones "raras" Por norma general suelen realizarse peticiones GET y POST, incluso HEAD. Otros tipos de peticiones suelen ser extrañas y en muy pocos casos serán necesarias para el uso de WordPress. RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule . * - Bloqueo de accesos a ficheros con datos Algunos ficheros habituales en WordPress incluyen información concreta sobre versiones y algunos datos. Gracias a este código bloqueamos los accesos a ficheros de lectura o de licencias. RewriteRule readme\. (html|txt) - RewriteRule (licencia|license|LICENSE|olvasdel|lisenssi|liesmich)\. (html|txt) - Ficheros importantes de WordPress Existen algunos ficheros que por la información que contienen o por su falta de uso puede ser interesenta bloquear. El principal es el wp-config que incluye mucha información. Otros son el wp-cron (que se recomienda ejecutar mediante un administrador de tareas, los ficheros de instalación de WordPress (una vez hecha la instalación estos no son necesarios ejecutar) y un fichero histórico de gestión de enlaces (que la mayoría de instalaciones no utilizan). RewriteRule ^wp-config - RewriteRule ^wp-cron\. php - RewriteRule ^wp-admin/(install|setup-config|upgrade)\. php - RewriteRule ^wp-admin/maint/repair\. php - RewriteRule ^wp-links-opml\. php$ - Bloqueo de listado de usuarios Aunque no es un elemento grave que se sepa la lista de usuarios de un sitio, en algunos casos es posible que no se quiera tener acceso a las fichas o páginas de la lista de usuarios. Para evitar esto podemos bloquear los accesos habituales que incluye el propio sistema de enlaces permanentes. RewriteCond %{QUERY_STRING} ^author= RewriteRule . * - RewriteRule ^author/ - Bloqueo de listados de carpetas Una de las formas de detección de la existencia de elementos (plugins, themes... ) es la detección de la existencia de carpetas. Para que las herramientas de pentesting tengan más problemas, es mejor aplicar un código 404. RewriteRule ^wp-content/mu-plugins/$ - RewriteRule ^wp-content/(plugins|themes)/(. +)/$ - Bloqueo de ficheros "inseguros" En algunas carpetas existen una serie de elementos que, por norma general, no tienen porqué estar o ejecutarse. RewriteRule ^wp-content/(? :uploads|files)/. +\. (html|js|php|shtml|swf)$ - RewriteRule ^wp-content/plugins/. +\. (aac|avi|bz2|cur|docx? |eot|exe|flv|gz|heic|htc|m4a|midi? |mov|mp3|mp4|mpe? g|ogg|ogv|otf|pdf|pptx? |rar|rtf|tar|tgz|tiff? |ttc|wav|wmv|xlsx? |zip) - Otros bloqueos Algunos ficheros generales de configuración, de logs y similares que por norma general no tienen que ser accesibles desde fuera. RewriteRule ^sftp-config. json - RewriteRule (access|error)_log - RewriteRule installer-log\. txt - RewriteRule wp-content/debug\. log - RewriteRule (^#. *#|\. (bak|config|dist|fla|inc|ini|log|psd|sh|sql|sw)|~)$ - Mitigation CVE-2018-6389 Por norma general es mejor bloquear el posible ataque que se puede llevar a cabo de forma sencilla con la carga de todos los scripts. Para evitarlo es mejor bloquear su carga. Deny from all Bloqueo del XML-RPC Si no usas esta tecnología es mejor bloquearla e impedir ataques o accesos inconvenientes. Suele usarse con la App de WordPress o para realizar Pingbacks. Deny from all Bloqueo de la ejecución de PHP en los "uploads" En la carpeta de subida de ficheros no debería haber ficheros PHP, pero es un lugar donde muchos ataques se producen. En este caso bloquearemos su ejecución. Deny from all Control de los wp-includes En la carpeta de los includes suelen haber elementos que no suelen ejecutarse de forma externa, y por esto, en general, es mejor bloquear su ejecución. RewriteRule ^wp-admin/includes/ - RewriteRule ! ^wp-includes/ - RewriteRule ^wp-includes/+\. php$ - RewriteRule ^wp-includes/js/tinymce/langs/. +\. php - RewriteRule ^wp-includes/theme-compat/ - Control simple de ataques XSS Evita ataques muy sencillos de cross-scripting mediante la URL. RewriteCond %{QUERY_STRING} (\|%3E) RewriteCond %{QUERY_STRING} GLOBALS(=|\{0,2}) RewriteCond %{QUERY_STRING} _REQUEST(=|\{0,2}) RewriteRule ^(. *)$ index. php Un detalle importante es que si dentro del panel gestionas códigos de publicidad u otros tipos de scripts, este sistema puede ser muy agresivo según la segunda línea (la que incluye los scripts), por lo que se podría eliminar. Código por defecto de WordPress Integramos el código que nos recomienda y suele generar el propio WordPress. RewriteRule . * - RewriteRule ^index\. php$ - RewriteCond %{REQUEST_FILENAME} ! -f RewriteCond %{REQUEST_FILENAME} ! -d RewriteRule . /index. php Mejorar las... --- Última revisión: 2 de octubre de 2021 WordPress es un sistema estable pero que depende del rendimiento del sistema operativo, servidor web, PHP y base de datos para funcionar correctamente. Al ser un software ejecutado en el servidor, cada vez que un usuario llegue se ejecutará por completo. Es por esto que se recomiendan algunas mejoras y cambios para la mejora del rendimiento de todo el sistema. Caché en WordPress WordPress por defecto es 100% dinámico, lo que significa que cada vez que alguien accede se ha de generar todo por completo, lo que tiene un cálculo muy elevado. Algunos de estos elementos que pueden ralentizar los procesos son consultas a la base de datos, la propia ejecución de PHP, llamadas a API externas... Es por esto que se recomienda cachear. Este proceso permite reutilizar resultados anteriormente calculados en varias ocasiones siguiendo una serie de reglas, lo que reduce el consumo de tareas repetitivas. Normalmente la caché se renueva según pasa un periodo de tiempo predefinido, de forma que durante el tiempo en que la caché está activa los resultados se devuelve rápidamente, ya que se suelen recuperar del disco o de la memoria y no se han de calcular. Existen muchas capas de caché, y en cada una de ellas se puede actuar de una manera distinta. WordPress, conjuntamente con configuraciones del sistema y con plugins, es capaz de utilizarlas. En general se suelen llamar en este orden: Caché del navegador, caché local o Web App ManifestCDN (Content Delivery Network)Caché de página, en servidor web o proxyCaché de página, estática o por PHPOpcode cachéCaché de objetosCaché de fragmentosTransient APICaché de base de datosCaché de ficheros en disco Cada sistema de caché funciona de una forma diferente, puede estar en el mismo servidor o en varios, puede estar en el mismo dominio o en distintos, en incluso puede ser una cadena de llamadas. Además, cada sistema de caché puede requerir ciertas configuraciones que no están habilitadas por defecto, como puede ser un almacenamiento distinto, memoria RAM, conexiones físicas distintas, tiempos de latencia... esto significa que la optimización de la caché, en muchos casos, también dependerá de la configuración de las máquinas que las gestionan. Por ejemplo, el acceso a la memoria RAM es más rápida que el acceso a un disco SSD que es más rápida que el acceso a un disco HDD. Caché del navegador Los navegadores web que usamos para visitar los sitios permiten almacenar información que se puede necesitar en varias ocasiones a lo largo de la navegación por el sitio. Por eso es muy probable que la primera visita a un sitio web vaya más lenta, pero posteriormente la velocidad de carga aumente, ya que parte de la información queda almacenada. Un ejemplo sería el de añadir al fichero . htaccess (en el caso de usar un servidor web Apache HTTPD) con el siguiente contenido, que fuerza a almacenar los distintos tipos los segundos indicados: ExpiresActive on #Varios ExpiresByType application/pdf A2592000 ExpiresByType image/x-icon A2592000 ExpiresByType image/vnd. microsoft. icon A2592000 ExpiresByType image/svg+xml A2592000 #Imagenes ExpiresByType image/jpg A2592000 ExpiresByType image/jpeg A2592000 ExpiresByType image/png A2592000 ExpiresByType image/gif A2592000 ExpiresByType image/webp A2592000 #Media ExpiresByType video/ogg A2592000 ExpiresByType audio/ogg A2592000 ExpiresByType video/mp4 A2592000 ExpiresByType video/webm A2592000 #CSS/JS ExpiresByType text/css A2592000 ExpiresByType text/javascript A2592000 ExpiresByType application/javascript A2592000 ExpiresByType application/x-javascript A2592000 #Fuentes ExpiresByType application/x-font-ttf A2592000 ExpiresByType application/x-font-woff A2592000 ExpiresByType application/font-woff A2592000 ExpiresByType application/font-woff2 A2592000 ExpiresByType application/vnd. ms-fontobject A2592000 ExpiresByType font/ttf A2592000 ExpiresByType font/woff A2592000 ExpiresByType font/woff2 A2592000 En el caso de nginx, podemos añadir en el fichero de configuración del virtualhost los siguientes elementos: # CACHE location ~ "^/favicon. (ico|png)" { etag on; expires 28d; add_header Cache-Control "public, no-transform, inmutable"; } location ~* "\. (bmp|gif|ico|jpeg|jpg|png|svg|svgz|webp)$" { etag on; expires max; add_header Cache-Control "public, no-transform, inmutable"; } location ~* "\. (mid|midi|mp3|ogg|wav)$" { etag on; expires max; add_header Cache-Control "public, no-transform, inmutable"; } location ~* "\. (mp4|ogv|webm)$" { etag on; expires max; add_header Cache-Control "public, no-transform, inmutable"; } location ~* "\. (doc|docx|ppt|pptx|rtf|xls|xlsx)$" { etag on; expires max; add_header Cache-Control "public, no-transform, inmutable"; } location ~* "\. (bz2|gz|rar|tar|tgz|zip)$" { etag on; expires max; add_header Cache-Control "public, no-transform, inmutable"; } location ~* "\. (css|js)$" { etag on; expires 1d; add_header Cache-Control "public, no-transform"; } location ~* "\. (atom|rss)$" { etag on; expires 1h; add_header Cache-Control "public, no-transform"; } location ~* "\. (json|xml)$" { etag on; expires 1h; add_header Cache-Control "public, no-transform"; } location ~* "\. (eot|otf|ttf|woff|woff2)$" { etag on; expires max; add_header Cache-Control "public, no-transform, inmutable"; } CDN - Content Distribution Network Las redes de distribución de contenidos están pensadas para reducir la latencia, los tiempos de respuesta, a la hora de servir contenidos en distintas zonas geográficas. Si tu proyecto WordPress es internacional, sin duda es una buena opción para, al menos, contenidos estáticos como JavaScript o CSS ademas de imágenes y contenidos media. Si tu proyecto es bastante local, lo mejor es disponer de una infraestructura conectada en ese país. Además, por lo general, los CDN también actual como una capa de caché, ya que al disponer de los contenidos y solo servir los estáticos, no han de hacer cálculos y están optimizados para servirse lo más rápido posible. En caso de trabajar con varias capas de caché, has de asegurarte que se purga en todos los niveles, porque puede hacerse una limpieza en un nivel, pero no en otro, y seguir sirviéndose algo que no ha sido invalidado. Algunos CDN que tienen su plugin oficial son (por orden alfabético): 5centsCDN, Akamai, BootstrapCDN, BunnyCDN, CDNsun, Cloudflare, Cloudimage, Cloudinary, Fastly, G-Core Labs, GoCache, Hostry, ImageBoss, Incapsula, KeyCDN, Kolossum, PageCDN, RocketDeliver, SandCage, Shift8, Sirv, SmartVideo, SpareVideos, Statically, Tencent Cloud. Caché de página Cuando se hace una solicitud de una página, por ejemplo la principal de un blog, se ejecutan varios procesos en PHP, se hace el cálculo para la recuperación de los contenidos en la base de datos, se calculan configuraciones personalizadas y finalmente se pinta por pantalla. En muchas ocasiones, los contenidos entre una petición y otra no ha cambiado por lo que ¿por qué no... --- Última revisión: 2 de octubre de 2021 En el caso de tener que gestionar muchos WordPress, puedes hacer uso de algunos sistemas externos. Algunos de estos sistemas son: MainWP (gratis y de pago): Es un plugin para WordPress. Dispone de la opción de Servidor y de Cliente, todo funcionando sobre los WordPress y bajo tu control. Si te preocupa la privacidad y el control de los datos, es muy buena opción ya que tú tienes el control de los mismos. InfiniteWP (gratis y de pago): Es un software complementario a WordPress. Al igual que MainWP, dispone de una herramienta Servidor y Cliente, todo funcionando bajo tu control. ManageWP (gratis y de pago): Es un servicio externo a tu WordPress. En este caso, los datos de tus sitios y el control se harán desde una plataforma externa donde se manda la información. --- Última revisión: 2 de octubre de 2021 WordPress no incorpora por defecto ningún tipo de sistema de copia de seguridad automática, por lo que has de depender de una herramienta de terceros para ello. A la hora de realizar una copia de seguridad has de tener presente que WordPress está compuesto de dos elementos completamente diferenciados: los ficheros y los datos. La parte de ficheros se encuentra almacenada en tu servidor, y se puede acceder por FTP o cualquier otro método, y los datos se encuentran almacenados en la base de datos. Esto significa que a la hora de hacer una copia de seguridad has de hacerlo de las dos partes, ya que una no funciona sin la otra. Dónde hacer copias A la hora de hacer copias de seguridad hay muchos métodos para ello. La primera es la del propio servidor del alojamiento. Normalmente los propios proveedores ofrecen la posibilidad de hacer una copia de todos los contenidos alojados en la máquina. En general estas copias se realizan externamente en un servidor específico de copias de seguridad. En este caso debes conocer su funcionamiento a la hora tanto de ver cómo y cuándo se realizan, como la forma de restaurar la copia, si puede ser parcial, total, y si tienes acceso a los datos de una forma sencilla. Una segunda forma es manual, a través del sistema operativo, de forma que te montes un sistema que haga una copia de todos los ficheros (por ejemplo en un ZIP) y por otro lado hacer un dump de la base de datos para obtener una copia del fichero SQL con todos los datos. Para acabar, y lo más habitual (además de lo que nos pueda proporcionar el proveedor) es disponer de un plugin de copias de seguridad. Plugins hay muchos y en general te recomendamos que pruebes varios hasta que des con el que se adapte a tus necesidades. No es lo mismo hacer una copia de seguridad de un sitio pequeño (200 MB) que hacer uno grande (5 GB). Los tiempos de respuesta y el rendimiento del servidor podrían hacer que el sistema se sature y no se realicen las copias, por lo que te recomendamos que pruebes los distintos sistemas hasta encontrar con el que funcione mejor. Además, también es importante que cuando hagas copias de seguridad se almacenen en al menos dos lugares distintos. Una suele ser el propio servidor donde está el sitio web. A veces el sitio se corrompe pero no afecta a la máquina, por lo que tener los ficheros de forma cercana y a disposición rápida suele ser de gran ayuda. El otro caso es el de tenerlos fuera del servidor, en un lugar externo, e incluso fuera de la misma red o proveedor o país. El hecho de que esté en otro lugar distinto permitiría que aunque ese proveedor tuviera un grave problema (y por ejemplo no tuvieras posibilidad de acceder a él) pudieras restaurar tu sitio desde un lugar externo. Cuándo hacer copias Copias puedes hacer todas las que quieras, aunque con moderación, como todo. En general dependerá de cuántos cambios hagas en tu sitio web y con cuánta frecuencia para determinar cuántos datos estás dispuesto a perder en un caso extremo. Por ejemplo, si tienes un sitio en el que publicas un contenido cada semana, y tus visitantes van publicando algunos comentarios, probablemente una copia de seguridad diaria sea suficiente. En cambio, si por ejemplo eres un medio de comunicación que publica un centenar de artículos de forma diaria y hay mucha interacción, lo más probable es que quieras hacer una copia cada pocas horas. En cualquier caso, lo recomendable es al menos tener una copia diaria durante una semana, y posteriormente almacenar una copia semanal al menos durante unos pocos meses. De esta forma te asegurarías disponer de copias que vayan entre 3 y 6 meses atrás. Una vez más, dependerá del tamaño y configuración de tu sitio. --- Última revisión: 2 de octubre de 2021 Tener herramientas de monitorización va a permitirte comprobar si el sitio funciona correctamente, a muchos niveles distintos. Tiempo de funcionamiento Uno de los sistemas de monitorización básicos es el de saber que está activo el sitio, además de pequeños elementos de velocidad de carga o tiempos de respuesta. Habitualmente se utilizan servicios externos de ping que con cierta frecuencia llaman a tu sitio web y comprueban que funciona y está en línea, y si el acceso es rápido o lento. En caso de que haya algún problema, suele mandar algún tipo de aviso a modo de alerta. Además, estos servicios suelen tener unos paneles en los que poder analizar de forma histórica esos tiempos y posibles caídas del servicio. Rendimiento En general la medición de estos datos suele hacerse de forma interna ya que afectan principalmente a los servicios que dispone de la máquina. Para que un WordPress funcione al menos necesitamos el servidor con su sistema operativo, el servidor web, el PHP y la base de datos. Además, podemos tener los sistemas de almacenamiento de caché. Pues el sistema de monitorización de rendimiento lo que analiza es todo esto. Por ejemplo, algunos datos habituales del servidor y sistema operativo es la carga de CPU y de memoria, el ancho de banda consumido o el espacio y rendimiento del almacenamiento, en la parte del servidor web la cantidad de peticiones y respuestas válidas e invalidas que se devuelven, en el PHP el consumo de memoria y de ejecución y en la base de datos el tamaño, la cantidad de consultas y aquellas que son lentas. --- Última revisión: 2 de octubre de 2021 Para aportar a WordPress a nivel de desarrollo existen múltiples posibilidades y opciones. Estas que presentamos aquí son algunos ejemplos que plantean ser una guía a la hora de preparar infraestructura, pero hay muchas opciones y posibilidades. Separamos las opciones dependiendo del tipo de contribución que quieras hacer. Desarrollo propio SI quieres desarrollar plugins o themes, te recomendamos hacer pruebas en versiones estables de WordPress, pero también hacerlo en las versiones de desarrollo de futuros lanzamientos. Para ello te dejamos estas opciones que pueden ser útiles: VPS con Git: Esta instalación dispone de un Git sincronizado con la rama principal de WordPress, por lo que tendrás elementos de futuras versiones para probar compatibilidades y errores. Desarrollo para la Comunidad WordPress Si quieres hacer pruebas y desarrollar para la Comunidad WordPress te recomendamos un tipo de instalación ligeramente distinta, usando las herramientas que el resto de miembros de la comunidad utiliza. Para ello te dejamos estas opciones que pueden ser útiles: VPS con Subversion: Esta instalación dispone de un Subversion sincronizado con la rama principal de WordPress, por lo que tendrás elementos de futuras versiones para probar compatibilidades y errores, además de poder probar parches pendientes de aprobar. A partir de aquí podrás realizar algunas pruebas y mejoras en el código de WordPress en base a lo que la Comunidad aporta. Entre algunas de esas cosas que puedes hacer tienes: Probar un patch del Trac: Gracias a la instalación del VPS con Subversion podrás aplicar los parches ofrecidos por la comunidad en el Trac y comentar sobre ellos. Pruebas con PHPUnit: Cuando se aplican cambios de PHP, siempre es buena idea pasar una prueba para verificar que no da ningún tipo de error el cambio que puede venir en el parche. --- Última revisión: 2 de octubre de 2021 Si alguna vez te has planteado contribuir a WordPress, existen muchas formas de hacerlo. Desde aquí te planteamos los primeros pasos para ello con la creación de una máquina virtual en la que sincronizar WordPress con su Git, de forma que siempre esté al día. Esta configuración es correcta si quieres disponer de una versión de desarrollo de WordPress que puede ser útil para desarrollar y probar tus plugins o themes. Requisitos Lo primero que necesitaremos para montar un sistema de desarrollo es una cuenta de Git y una máquina donde instalar la versión de desarrollo de WordPress. Git Te recomendamos crear una cuenta directamente en Github, donde se encuentra el repositorio principal de WordPress. A partir de este crearemos nuestro sistema de pruebas y desarrollo. Infraestructura En principio se puede montar el sistema en cualquier tipo de máquina, ya sea una virtual, un Docker o un VPS. En este caso, para que esté al alcance de todos y sin requisitos mínimos, usaremos un VPS de cualquier proveedor. Si te interesa, puedes encontrar algunos VPS para desarrolladores. En este caso hemos usado una máquina con 1 CPU, 2 GB de RAM y 10 GB de disco SSD. Con la mitad de recursos debería funcionar sin problema. Lo que vamos a mostrar se basa en un Ubuntu 18 LTS. Usaremos PHP 7. 4, MariaDB 10. 4 y otros servicios. Hacer un fork del WordPress de Github Lo primero a hacer es entrar en el Github de WordPress y pulsar en el botón Fork que hay en la esquina superior derecha. Pulsamos en el botón Fork para crear una copia en nuestra cuenta. Esto te acaba creando algo del estilo a https://github. com/javiercasares/WordPress. Creamos una máquina Como comentaba antes, podemos crear una máquina en cualquier sitio. Puede ser en un VPS de una empresa de hosting, o puede ser un Docker que tengamos en local. También hay opciones de usar el propio sistema de Vagrant. En este caso crearemos la máquina desde cero con nuestra configuración medianamente personalizada. Como sistema operativo de este ejemplo vamos a usar Ubuntu 18 LTS. Actualización del sistema Lo primero que haremos es poner al día el sistema. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Una vez esto, pondremos en hora el sistema. timedatectl set-timezone UTC timedatectl set-ntp on Además, instalaremos algunas herramientas básicas. apt -y install software-properties-common curl vim unzip Servidor de Base de Datos Para la base de datos vamos a usar MariaDB 10. 4; esta versión tiene un gran cambio en cuanto al sistema de claves con respecto a su versión predecesora, por lo que, para evitar problemas, vamos a usar esta última versión. Lo primero será descargar e instalar el servidor de base de datos. curl -sS https://downloads. mariadb. com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10. 4" apt -y update apt -y install mariadb-server mariadb-client systemctl restart mysql. service Ahora que tenemos la base de datos instalada, ejecutaremos el sistema de configuración por primera vez. mysql_secure_installation Aquí se nos darán algunas opciones y preguntas. Prepara tu contraseña de root de la base de datos y guárdala bien. Enter current password for root (enter for none): Switch to unix_socket authentication n Change the root password? y Remove anonymous users? y Disallow root login remotely? y Remove test database and access to it? y Reload privilege tables now? y Una vez hayamos contestado las preguntas, reiniciaremos la base de datos para dejarla funcionando. systemctl restart mysql. service Servidor Web Para el servidor web vamos a utilizar nginx. Este servidor web funciona muy bien con WordPress a la hora de desarrollar o mantener sitios grandes, aunque no permite el uso de los ficheros . htaccess (se ha de configurar previamente, sin que los usuarios o plugins puedan cambiar la configuración). add-apt-repository ppa:ondrej/nginx apt -y update apt -y install nginx systemctl stop nginx. service systemctl enable nginx. service systemctl start nginx. service Servidor PHP Para que WordPress funcione necesitaremos instalar PHP, el intérprete del código. En este caso usaremos la versión de PHP 7. 4. Además, instalaremos las extensiones recomendadas, lo que supondrá un trabajo extra de configuración. Instalación base de PHP Comenzaremos con el núcleo de PHP y de PHP-FPM, además de las extensiones básicas que vienen pre-compiladas. add-apt-repository ppa:ondrej/php apt -y update apt -y install php7. 4 php7. 4-fpm php7. 4-curl php7. 4-gd php7. 4-mbstring php7. 4-xml php7. 4-zip php7. 4-mysql php7. 4-mysqlnd php7. 4-bcmath php7. 4-gmp php7. 4-tidy php7. 4-dev php-pear pkg-config imagemagick libmagickwand-dev pecl channel-update pecl. php. net Instalación de ImageMagick Esta extensión permite la gestión de imágenes mejoradas sobre GD. pecl install imagick echo 'extension=imagick. so' >> /etc/php/7. 4/mods-available/imagick. ini ln -s /etc/php/7. 4/mods-available/imagick. ini /etc/php/7. 4/fpm/conf. d/30-imagick. ini Instalación de XDiff Esta extensión permite la aplicación de patch que incluyen diferencias de ficheros. cd /usr/src wget http://www. xmailserver. org/libxdiff-0. 23. tar. gz tar -xzf libxdiff-0. 23. tar. gz rm -rf libxdiff-0. 23. tar. gz cd libxdiff-0. 23 . /configure make make install pecl install xdiff echo 'extension=xdiff. so' >> /etc/php/7. 4/mods-available/xdiff. ini ln -s /etc/php/7. 4/mods-available/xdiff. ini /etc/php/7. 4/fpm/conf. d/30-xdiff. ini Instalación de APCu Esta extensión mejora el sistema de caché del código PHP. cd pecl install apcu echo 'extension=apcu. so' >> /etc/php/7. 4/mods-available/apcu. ini ln -s /etc/php/7. 4/mods-available/apcu. ini /etc/php/7. 4/fpm/conf. d/30-apcu. ini Instalación de Redis También instalaremos la extensión del servidor de caché Redis. pecl install redis echo 'extension=redis. so' >> /etc/php/7. 4/mods-available/redis. ini ln -s /etc/php/7. 4/mods-available/redis. ini /etc/php/7. 4/fpm/conf. d/30-redis. ini Configuración de PHP Para el desarrollo, haremos algunos cambios en el fichero de configuración de PHP, sobre todo para dar más margen de maniobra a la memoria y a la visualización de errores por pantalla y a la hora de hacer pruebas. Lo primero que haremos será abrir el fichero de configuración. vim /etc/php/7. 4/fpm/php. ini Y allí haremos algunos cambios en la configuración. max_execution_time = 60 memory_limit = 256M error_reporting = E_ALL display_errors = On post_max_size = 32M upload_max_filesize =... --- Última revisión: 2 de octubre de 2021 Si alguna vez te has planteado contribuir a WordPress, existen muchas formas de hacerlo. Desde aquí te planteamos los primeros pasos para ello con la creación de una máquina virtual en la que sincronizar WordPress con Subversion, de forma que siempre esté al día y que te permita trabajar con el mismo material en el que lo hace la comunidad de desarrolladores. Requisitos En principio no es necesario ningún requisito especial, simplemente disponer de acceso al SVN de WordPress. Infraestructura En principio se puede montar el sistema en cualquier tipo de máquina, ya sea una virtual, un Docker o un VPS. En este caso, para que esté al alcance de todos y sin requisitos mínimos, usaremos un VPS de cualquier proveedor. Si te interesa, puedes encontrar algunos VPS para desarrolladores. En este caso hemos usado una máquina con 1 CPU, 2 GB de RAM y 10 GB de disco SSD. Con la mitad de recursos debería funcionar sin problema. Lo que vamos a mostrar se basa en un Ubuntu 18 LTS. Usaremos PHP 7. 4, MariaDB 10. 4 y otros servicios. Creamos una máquina Como comentaba antes, podemos crear una máquina en cualquier sitio. Puede ser en un VPS de una empresa de hosting, o puede ser un Docker que tengamos en local. También hay opciones de usar el propio sistema de Vagrant. En este caso crearemos la máquina desde cero con nuestra configuración medianamente personalizada. Como sistema operativo de este ejemplo vamos a usar Ubuntu 18 LTS. Actualización del sistema Lo primero que haremos es poner al día el sistema. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Una vez esto, pondremos en hora el sistema. timedatectl set-timezone UTC timedatectl set-ntp on Además, instalaremos algunas herramientas básicas. apt -y install software-properties-common curl vim unzip Servidor de Base de Datos Para la base de datos vamos a usar MariaDB 10. 4; esta versión tiene un gran cambio en cuanto al sistema de claves con respecto a su versión predecesora, por lo que, para evitar problemas, vamos a usar esta última versión. Lo primero será descargar e instalar el servidor de base de datos. curl -sS https://downloads. mariadb. com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10. 4" apt -y update apt -y install mariadb-server mariadb-client systemctl restart mysql. service Ahora que tenemos la base de datos instalada, ejecutaremos el sistema de configuración por primera vez. mysql_secure_installation Aquí se nos darán algunas opciones y preguntas. Prepara tu contraseña de root de la base de datos y guárdala bien. Enter current password for root (enter for none): Switch to unix_socket authentication n Change the root password? y Remove anonymous users? y Disallow root login remotely? y Remove test database and access to it? y Reload privilege tables now? y Una vez hayamos contestado las preguntas, reiniciaremos la base de datos para dejarla funcionando. systemctl restart mysql. service Servidor Web Para el servidor web vamos a utilizar nginx. Este servidor web funciona muy bien con WordPress a la hora de desarrollar o mantener sitios grandes, aunque no permite el uso de los ficheros . htaccess (se ha de configurar previamente, sin que los usuarios o plugins puedan cambiar la configuración). add-apt-repository ppa:ondrej/nginx apt -y update apt -y install nginx systemctl stop nginx. service systemctl enable nginx. service systemctl start nginx. service Servidor PHP Para que WordPress funcione necesitaremos instalar PHP, el intérprete del código. En este caso usaremos la versión de PHP 7. 4. Además, instalaremos las extensiones recomendadas, lo que supondrá un trabajo extra de configuración. Instalación base de PHP Comenzaremos con el núcleo de PHP y de PHP-FPM, además de las extensiones básicas que vienen pre-compiladas. add-apt-repository ppa:ondrej/php apt -y update apt -y install php7. 4 php7. 4-fpm php7. 4-curl php7. 4-gd php7. 4-mbstring php7. 4-xml php7. 4-zip php7. 4-mysql php7. 4-mysqlnd php7. 4-bcmath php7. 4-gmp php7. 4-tidy php7. 4-dev php-pear pkg-config imagemagick libmagickwand-dev Instalación de ImageMagick Esta extensión permite la gestión de imágenes mejoradas sobre GD. pecl channel-update pecl. php. net pecl install imagick echo 'extension=imagick. so' >> /etc/php/7. 4/mods-available/imagick. ini ln -s /etc/php/7. 4/mods-available/imagick. ini /etc/php/7. 4/fpm/conf. d/30-imagick. ini Instalación de XDiff Esta extensión permite la aplicación de patch que incluyen diferencias de ficheros. cd /usr/src wget http://www. xmailserver. org/libxdiff-0. 23. tar. gz tar -xzf libxdiff-0. 23. tar. gz cd libxdiff-0. 23 . /configure make make install pecl install xdiff echo 'extension=xdiff. so' >> /etc/php/7. 4/mods-available/xdiff. ini ln -s /etc/php/7. 4/mods-available/xdiff. ini /etc/php/7. 4/fpm/conf. d/30-xdiff. ini Instalación de APCu Esta extensión mejora el sistema de caché del código PHP. cd pecl install apcu echo 'extension=apcu. so' >> /etc/php/7. 4/mods-available/apcu. ini ln -s /etc/php/7. 4/mods-available/apcu. ini /etc/php/7. 4/fpm/conf. d/30-apcu. ini Instalación de Redis También instalaremos la extensión del servidor de caché Redis. pecl install redis echo 'extension=redis. so' >> /etc/php/7. 4/mods-available/redis. ini ln -s /etc/php/7. 4/mods-available/redis. ini /etc/php/7. 4/fpm/conf. d/30-redis. ini Configuración de PHP Para el desarrollo, haremos algunos cambios en el fichero de configuración de PHP, sobre todo para dar más margen de maniobra a la memoria y a la visualización de errores por pantalla y a la hora de hacer pruebas. Lo primero que haremos será abrir el fichero de configuración. vim /etc/php/7. 4/fpm/php. ini Y allí haremos algunos cambios en la configuración. max_execution_time = 60 memory_limit = 256M error_reporting = E_ALL display_errors = On post_max_size = 32M upload_max_filesize = 32M date. timezone = 'UTC' Una vez esto, configuraremos PHP-FPM para que se active automáticamente con el sistema. systemctl stop php7. 4-fpm. service systemctl enable php7. 4-fpm. service systemctl start php7. 4-fpm. service Servidor de caché Redis Instalaremos el servidor Redis y le daremos algunos cambios a la configuración para que no se sature. Primero lo instalaremos y lo sincronizaremos con PHP. apt -y install redis-server php-redis Abriremos el fichero de configuración. vim /etc/redis/redis. conf Y haremos algunos cambios en la configuración. maxmemory 256mb maxmemory-policy allkeys-lru Finalmente lo reiniciaremos, junto a PHP para que se aplique su extensión. systemctl stop redis-server. service systemctl enable redis-server. service... --- Última revisión: 2 de octubre de 2021 Puede que no seas desarrollador, pero que sepas programar y te guste probar si algunos parches del código de WordPress pueden funcionar, por lo que es más que razonable que colabores en la Comunidad revisando si los patch que se han creado funcionan y cumplen con su cometido. Para hacer estas pruebas necesitarás una instalación de WordPress con Varying Vagrant Vagrants o puedes crear una máquina virtual con Subversion. En cualquier caso tendrás a tu disposición el sistema preparado para poder aplicarlos y revertirlos. NOTA: este ejemplo está basado en el manual de VPS con SVN de este sitio. Encontrar tickets para probar Lo primero será encontrar tickets que tengan un patch pendiente de ser probado. Para ello podemos hacer una búsqueda en el Trac de tickets con . Descargar el parche Lo primero que haremos es ir a la carpeta donde tenemos la instalación de nuestro WordPress. cd /webs/wordpress-svn/ Para no liar las configuraciones, la primera vez crearemos la carpeta para los cambios. mkdir /webs/wordpress-svn/patch/ Cuando la tengamos, entraremos en ella y descargaremos el patch que queramos probar. cd /webs/wordpress-svn/patch/ wget https://core. trac. wordpress. org/raw-attachment/ticket/47912/47912. diff Para saber la dirección URL que hemos de descargar, visitaremos un ticket del Trac y en la zona de ficheros adjuntos miraremos la URL que tiene el fichero. Se pueden descargar tanto ficheros . diff como ficheros . patch. Aplicar el parche Ahora que ya tenemos descargado el fichero, lo hemos de aplicar a la configuración actual del WordPress de desarrollo. Para ello volveremos a la carpeta raíz de la configuración y allí ejecutaremos el parche. cd /webs/wordpress-svn/ patch -p 0 < patch/47912. diff Esto nos devolverá un mensaje que nos dirá qué ficheros o cambios se han producido. Debería ser algo similar a lo siguiente: user@wordpress-svn:/webs/wordpress-svn# patch -p 0 < patch/47912. diff patching file src/wp-includes/formatting. php Hunk #1 succeeded at 2273 (offset 3 lines). patching file tests/phpunit/tests/formatting/SanitizeTitleWithDashes. php Lo normal sería probar el error previamente a aplicar el parche, aplicarlo, y después volver a ejecutar lo mismo para verificar que el sistema funciona. Si pruebas el cambio, tanto si funciona como si no lo hace, es muy recomendable comentarlo en los comentarios del ticket del Trac. IMPORTANTE: Si el parche no funciona, es necesario volver al ticket del Trac y añadir una keyword que diga para que la persona o personas responsables apliquen una actualización en base al último código disponible. En ocasiones hay código muy antiguo pensado vara versiones ya obsoletas y hay que actualizarlo a las versiones más actuales. Retirar todos los cambios aplicados Si hemos hecho cambios y aplicado varios parches, quizá pensemos que es buena idea revertir los cambios para futuras pruebas. Para ello ejecutaremos el comando que nos lo hará. cd /webs/wordpress-svn/ svn revert . -R && svn update --- Última revisión: 2 de octubre de 2021 Una de las formas de colaborar en el código de WordPress es verificar que el código de PHP está normalizado y funciona correctamente. Para ello el equipo de desarrollo del núcleo de WordPress ha decidido hacer pruebas con PHPUnit. Los ejemplos y código que aquí se presenta se basan en la instalación y configuración de VPS con Subversion. A partir de esta configuración revisaremos el sistema con PHPUnit. Instalación de PHPUnit Lo primero que haremos será instalar y configurar de forma global PHPUnit. Para ello tan sólo hemos de seguir los siguientes pasos. cd wget -O phpunit https://phar. phpunit. de/phpunit-7. phar chmod +x phpunit mv phpunit /usr/local/bin/phpunit phpunit --version Este último comando nos mostrará la versión actual del software de forma que sabremos que está funcionando. Base de datos de prueba Estas pruebas eliminan todo el contenido de la base de datos, por lo que, antes de seguir, crearemos una base de datos paralela en la que se realizarán las pruebas. Usaremos el mismo modelo que en la creación de la base de datos principal. mysql -u root -p Necesitarás una contraseña para esta base de datos exclusiva para nuestro WordPress de test. Por favor, crea tu propia contraseña que sea algo segura. CREATE DATABASE wordpresstest CHARACTER SET = utf8mb4 COLLATE = utf8mb4_bin; GRANT ALL ON wordpresstest. * TO 'wordpresstest'@'localhost' IDENTIFIED BY '__PASSWORD__'; GRANT ALL ON wordpresstest. * TO 'wordpresstest'@'127. 0. 0. 1' IDENTIFIED BY '__PASSWORD__'; FLUSH PRIVILEGES; quit Configuración de WordPress para la prueba Ahora que tenemos el software instalado y una base de datos de prueba, crearemos un fichero de configuración en el que incorporar esta información. cd /webs/wordpress-svn/ vim wp-tests-config. php El fichero incorporará una configuración como esta. NOTA: Verifica los datos de conexión y otros elementos a lo largo del fichero. --- Última revisión: 28 de diciembre de 2021 Aunque WordPress puede funcionar en prácticamente cualquier entorno, aunque sea muy mínimo, hay que reconocer que en estos no funciona completamente bien. Es por esto que aquí te vamos a hacer unas recomendaciones mínimas de entorno en el que funcionaría de forma más efectiva. Servidor Web El servidor web es el sistema donde se alojan los ficheros del sitio web y donde llegan los usuarios para consultarlos. Servidores web hay muchos, y en principio cualquiera que soporte conexión con PHP debería servir para trabajar con WordPress. Cuando hablamos del servidor, web, WordPress funciona mejor con estos (ordenados alfabéticamente): Apache HTTPD 2. 4lighttpd 1. 4LiteSpeed Web Server 6. 0 / 5. 4 / 5. 3nginx 1. 21 / 1. 20OpenLiteSpeed 1. 7 / 1. 6 / 1. 5 / 1. 4 Recuerda que si dispones de un sitio web funcionando en producción, se recomienda el uso de la última versión estable de cada uno de los servidores web (principalmente por seguridad, más que por funcionalidad), pero no de versiones alpha, beta o candidatas (RC). PHP PHP es un lenguaje de programación en el que se basa el código de WordPress. Este lenguaje se ejecuta en el servidor y es importante mantenerlo al día, tanto por seguridad como principalmente por funcionalidad. WordPress da soporte a muchas versiones de PHP, algunas ya obsoletas, pero siempre a todas las que están soportadas y mantenidas. Oficialmente el núcleo de WordPress da soporte desde la versión de PHP 5. 6 hasta la versión de PHP 8. 0. Aún así, no todos los themes o plugins les dan soporte. Cuando hablamos de PHP, WordPress (incluyendo sus extensiones) funciona mejor con las siguientes versiones: PHP 8. 0PHP 7. 4PHP 7. 3 (sólo actualizaciones de seguridad) WordPress no funciona con versiones menores a la 5. 6. 20. No se recomiendan versiones anteriores a PHP 7. 3 debido a que ya no tiene soporte de ningún tipo, y solo PHP 7. 3 si tienes la última versión, ya que solo tiene soporte de seguridad. WordPress + PHP matrix WordPress: Versión mayor de WordPressPHP ver. mínima: Versión mínima de PHP soportada por WordPressPHP ver. máxima: Versión máxima de PHP soportada por WordPressLanzamiento: Fecha de lanzamiento de la primera versión mayor de WordPressPHP soportado: Versiones de PHP soportadas y mantenidas por el equipo de PHP WordPressPHP ver. mínimaPHP ver. máximaLanzamientoPHP soportadoWordPress 5. 9*PHP 5. 6. 20PHP 8. 12022-01-25*PHP 7. 4 - 8. 1*WordPress 5. 8PHP 5. 6. 20PHP 8. 02021-07-20PHP 7. 3 - 8. 0WordPress 5. 7PHP 5. 6. 20PHP 8. 02021-03-09PHP 7. 3 - 8. 0WordPress 5. 6PHP 5. 6. 20PHP 8. 02020-12-08PHP 7. 3 - 8. 0WordPress 5. 5PHP 5. 6. 20PHP 7. 42020-08-11PHP 7. 2 - 7. 4WordPress 5. 4PHP 5. 6. 20PHP 7. 42020-03-31PHP 7. 2 - 7. 4WordPress 5. 3PHP 5. 6. 20PHP 7. 42019-11-12PHP 7. 1 - 7. 3WordPress 5. 2PHP 5. 6. 20PHP 7. 32019-05-07PHP 7. 1 - 7. 3WordPress 5. 1PHP 5. 2. 4PHP 7. 32019-02-21PHP 7. 1 - 7. 3WordPress 5. 0PHP 5. 2. 4PHP 7. 32018-12-06PHP 5. 6 - 7. 2WordPress 4. 9PHP 5. 2. 4PHP 7. 22017-11-15PHP 5. 6 - 7. 1WordPress 4. 8PHP 5. 2. 4PHP 7. 12017-06-08PHP 5. 6 - 7. 1WordPress 4. 7PHP 5. 2. 4PHP 7. 12016-12-06PHP 5. 6 - 7. 0WordPress 4. 6PHP 5. 2. 4PHP 7. 02016-08-16PHP 5. 5 - 7. 0WordPress 4. 5PHP 5. 2. 4PHP 7. 02016-04-12PHP 5. 5 - 7. 0WordPress 4. 4PHP 5. 2. 4PHP 7. 02015-12-08PHP 5. 5 - 5. 6WordPress 4. 3PHP 5. 2. 4PHP 5. 62015-08-18PHP 5. 4 - 5. 6WordPress 4. 2PHP 5. 2. 4PHP 5. 62015-04-23PHP 5. 4 - 5. 6WordPress 4. 1PHP 5. 2. 4PHP 5. 62014-12-17PHP 5. 4 - 5. 6WordPress 4. 0PHP 5. 2. 4PHP 5. 52014-09-04PHP 5. 4 - 5. 5WordPress 3. 9PHP 5. 2. 4PHP 5. 52014-04-16PHP 5. 3 - 5. 5WordPress 3. 8PHP 5. 2. 4PHP 5. 52013-12-12PHP 5. 3 - 5. 4WordPress 3. 7PHP 5. 2. 4PHP 5. 52013-10-24PHP 5. 3 - 5. 4WordPress 3. 6PHP 5. 2. 42013-08-01PHP 5. 3 - 5. 4WordPress 3. 5PHP 5. 2. 42012-12-11WordPress 3. 4PHP 5. 2. 42012-06-13WordPress 3. 3PHP 5. 2. 42011-12-12WordPress 3. 2PHP 5. 2. 42011-07-04WordPress 3. 1PHP 4. 32011-02-23WordPress 3. 0PHP 4. 32010-06-17WordPress 2. 9PHP 4. 32009-12-18WordPress 2. 8PHP 4. 32009-06-10WordPress 2. 7PHP 4. 32008-12-10WordPress 2. 6PHP 4. 32008-07-15WordPress 2. 5PHP 4. 32008-03-29WordPress 2. 3PHP 4. 22007-07-24WordPress 2. 2PHP 4. 22007-05-16WordPress 2. 1PHP 4. 22007-01-22WordPress 2. 0PHP 4. 22005-12-26 Extensiones PHP necesarias bcmath: Para operaciones matemáticas de precisión arbitraria PHP ofrece la Calculadora Binaria, la cual admite números de cualquier tamaño y precisión, representados como strings. curl: PHP soporta libcurl, una biblioteca creada por Daniel Stenberg que permite conectarse y comunicarse con diferentes tipos de servidores y diferentes tipos de protocolos. dom: Gracias al Document Object Model, se permite manipular documentos XML mediante la API DOM. exif: Con la extensión Exif (siglas en inglés de Exchangeable image information) se puede trabajar con metadatos de imágenes. fileinfo: Las funciones en este módulo tratan de averiguar el tipo de contenido y la codificación de un fichero buscando ciertas secuencias de bytes mágicas en una posición específica del mismo. hash: Es el motor de cifrado de mensajes y permite mejorar la seguridad directa o incremental de mensajes usando una variedad de algoritmos hash. json: Esta extensión implementa el formato de intercambio de datos JavaScript Object Notation (JSON). libsodium: Sodium es una biblioteca de software moderna y fácil de usar para cifrado, descifrado, firmas, hash de contraseñas y mucho más. mbstring: Proporciona funciones específicas para cadenas de texto multibyte y controla la conversión de la codificación de caracteres entre los posibles esquemas de codificación basadas en Unicode (UTF-8, UTF-16... ). mysqli: La extensión mysqli (mysql improved) permite acceder a la funcionalidad proporcionada por MySQL 4. 1 y posterior. mysqlnd: El Controlador Nativo de MySQL (MySQL Native Driver en inglés) es un sustituto para la Biblioteca Cliente de MySQL (libmysqlclient). openssl: Este módulo utiliza las funciones de OpenSSL... --- Última revisión: 2 de octubre de 2021 Si necesitas una instalación paso a paso de tu WordPress, puedes probar con alguna de estas configuraciones. Estas configuraciones son una guía para tener en cuenta, pero deberás ajustarla a tus necesidades y las de tus clientes. Instalaciones destacadas Ubuntu 20. 04 Sistema Operativo: Ubuntu 20. 04Servidor web: nginxBase de Datos: MariaDBProcesador: PHPCaché: Redis WordPress en Ubuntu AlmaLinux 8. 4 Sistema Operativo: AlmaLinux 8. 4Servidor web: nginxBase de Datos: MariaDBProcesador: PHPCaché: Redis WordPress en AlmaLinux Plesk 18 Obsidian Sistema Operativo: Ubuntu 20Panel de Control: Plesk 18 Obsidian Tutorial de instalación CentOS 7 Sistema Operativo: CentOS 7Panel de Control: ningunoServidor web: nginxBase de Datos: MariaDB 10. 3Procesador: PHP 7. 3Caché: Redis Tutorial de instalación Sistema Operativo: CentOS 7Panel de Control: CyberPanelServidor web: LiteSpeedBase de Datos: MariaDBProcesador: PHPCaché: Redis (alternativa memcached) Tutorial de instalación Debian 9 Sistema Operativo: Debian 9Panel de Control: ningunoServidor web: nginxBase de Datos: MariaDB 10. 3Procesador: PHP 7. 3Caché: Redis Tutorial de instalación Ubuntu 20 Sistema Operativo: Ubuntu 20Panel de Control: ningunoServidor web: nginxBase de Datos: MariaDB 10. 5Procesador: PHP 8. 0Caché: Redis Tutorial de instalación Sistema Operativo: Ubuntu 20Red: TorServidor web: nginxBase de Datos: MariaDB 10. 5Procesador: PHP 8. 0Caché: Redis Tutorial de instalación Sistema Operativo: Ubuntu 20Panel de Control: ningunoServidor web: nginxBase de Datos: MariaDB 10. 5 (master-slave)Procesador: PHP 8. 0Caché: Redis Tutorial de instalación Ubuntu 19 Sistema Operativo: Ubuntu 19Panel de Control: ningunoServidor web: nginxBase de Datos: MariaDB 10. 3Procesador: PHP 7. 3Caché: Redis Tutorial de instalación Ubuntu 18 Sistema Operativo: Ubuntu 18Panel de Control: ningunoServidor web: nginxBase de Datos: MariaDB 10. 3Procesador: PHP 7. 3Caché: Redis Tutorial de instalación Sistema Operativo: Ubuntu 18Panel de Control: ningunoServidor web: LiteSpeedBase de Datos: MariaDB 10. 3Procesador: PHP 7. 3Caché: Redis Tutorial de instalación --- Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: CentOS 7Panel de Control: CyberPanelServidor web: LiteSpeedBase de Datos: MariaDBProcesador: PHPCaché: Redis (alternativa memcached) Aquí te dejamos un pequeño manual de instalación desde una instalación de sistema operativo básico de CentOS 7 con el panel de gestión CyberPanel. Ten presente que en esta instalación vamos a usar la versión de CyberPanel Enterprise que permite el uso de LiteSpeed con todo su potencial, pero con ciertas limitaciones. ¿Para qué es válido? un dominiosubdominios ilimitadosLiteSpeed Caché Requisitos previos Licencia gratuita de Free Starter with CyberPanel. Recursos CentOS 71 CPU2 GB RAM20 GB SSD El precio aproximado de una instalación de este tipo puede rondar los 10,00€/mes. Configuración previa Lo primero es hacer una primera actualización y configuración de la base del sistema operativo. yum clean all && yum -y upgrade yum -y install yum-utils curl vim unzip wget yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria de Madrid. timedatectl set-timezone 'Europe/Madrid' yum -y install ntp systemctl start ntpd systemctl enable ntpd systemctl status ntpd ntpq -p Instalación de CyberPanel Una vez tengamos todo actualizado y con la hora al día, configuraremos el CyberPanel. sh --- Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: CentOS 7Panel de Control: ningunoServidor web: nginxBase de Datos: MariaDB 10. 3Procesador: PHP 7. 3Caché: Redis Aquí te dejamos un pequeño manual de instalación desde una instalación de sistema operativo básico de CentOS 7. Configurando el Sistema Operativo Lo primero es hacer una primera actualización y configuración de la base del sistema operativo. yum clean all && yum -y upgrade yum -y install yum-utils curl vim unzip wget yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria de Madrid. timedatectl set-timezone 'Europe/Madrid' yum -y install ntp systemctl start ntpd systemctl enable ntpd systemctl status ntpd ntpq -p Para poder aprovechar al máximo las últimas versiones, usaremos el repositorio alternativo EPEL. yum -y install https://dl. fedoraproject. org/pub/epel/epel-release-latest-7. noarch. rpm yum -y install http://rpms. remirepo. net/enterprise/remi-release-7. rpm yum -y install https://mirror. webtatic. com/yum/el7/webtatic-release. rpm yum clean all && yum -y upgrade Instalación de MariaDB El siguiente paso será la instalación de la base de datos. En este caso vamos a utilizar MariaDB 10. 3. Lo primero que haremos será configurar la descarga, y posteriormente su instalación. curl -sS https://downloads. mariadb. com/MariaDB/mariadb_repo_setup | bash -s -- --mariadb-server-version=mariadb-10. 3 yum clean all && yum -y upgrade yum -y install MariaDB-server MariaDB-client Ahora que está instalada, procederemos a la configuración inicial. Para ello usaremos el sistema se instalación segura, que nos hará algunas preguntas. mysql_secure_installation A la pregunta de si queremos cambiar la contraseña, dependiendo de si hemos puesto o no en la instalación, la cambiaremos. En caso de no haber puesto ninguna, es muy recomendable ponerle una contraseña segura. Set root password? : Y Al resto de preguntas, contestaremos lo siguiente: Remove anonymous users? : Y Disallow root login remotely? : Y Remove test database and access to it? : Y Reload privilege tables now? : Y En este momento ya tendremos la base de datos configurada. Ahora haremos que se ejecute en los re inicios del sistema y la iniciaremos. systemctl stop mysql. service systemctl enable mysql. service systemctl start mysql. service Instalación de nginx En este momento tenemos la base de datos configurada y vamos a proceder a la instalación del servidor web. En este caso vamos a usar nginx. Para estar al día, no usaremos la versión que viene con el sistema operativo, sino una más actualizada y mantenida. yum clean all && yum -y upgrade yum -y install nginx Ahora que tenemos nginx instalado, lo vamos a configurar para que se inicie en los re inicios del sistema automáticamente. systemctl stop nginx. service systemctl enable nginx. service systemctl start nginx. service Instalación de PHP En este momento ya tenemos el servidor web, por lo que vamos a instalar y a configurar PHP para que funcione correctamente con la base de datos y el servidor web. En este caso vamos a instalar la versión PHP 7. 3. Primero haremos la instalación de los paquetes más actualizados (que no son los que vienen con el sistema operativo) y que en caso de necesitarlo, además, nos permitirían tener varias versiones de PHP en paralelo. yum-config-manager --enable remi-php73 yum clean all && yum -y upgrade yum -y install php73-php php73-php-fpm php73-php-common php73-php-devel php73-php-cli php73-php-bcmath php73-php-pecl-crypto php73-php-gd php73-php-pecl-geoip php73-php-pecl-imagick php73-php-imap php73-php-json php73-php-mbstring php73-php-pecl-mcrypt php73-php-mysqlnd php73-php-opcache php73-php-soap php73-php-sodium php73-php-pecl-ssh2 php73-php-pecl-xdebug php73-php-xml php73-php-xmlrpc php73-php-pecl-zip Ahora que ya tenemos PHP correctamente instalado, vamos a activarlo de forma que cuando se reinicie el sistema se ejecute automáticamente. systemctl stop php-fpm. service systemctl enable php-fpm. service systemctl start php-fpm. service nginx -t nginx -s reload Instalación de Redis Para trabajar con unas mejoras en el rendimiento de la caché de objetos, vamos a dejar listo Redis como sistema de almacenamiento. yum clean all && yum -y upgrade yum -y install redis php73-php-phpiredis Posteriormente, y de la misma forma que el resto de elementos, lo vamos a configurar para que se inicie automáticamente si se reinicia el servidor. systemctl stop redis. service systemctl enable redis. service systemctl start redis. service Configuración del HTTPS Como vamos a montar nuestra web sobre un servidor web seguro (HTTPS), necesitaremos instalar el generador de certificados de Let's Encrypt, de forma que previamente prepararemos los sistemas para la creación de claves seguras. openssl dhparam -out /etc/ssl/certs/dhparam. pem 2048 Y en este momento instalaremos el sistema de creación de certificados certbot. yum clean all && yum -y upgrade yum -y install certbot-nginx Para que los certificados se actualicen automáticamente, activaremos una tarea programada (cron) una vez al día que automáticamente renueve los certificados. crontab -e Una vez dentro, configuraremos, por ejemplo, que se ejecute a las 06:45 cada mañana. 45 6 * * * certbot renew A partir de este momento podemos reiniciar la máquina si queremos, y ya la tendremos lista para comenzar su uso y montar los sitios web. --- Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: Debian 9Panel de Control: ningunoServidor web: nginxBase de Datos: MariaDB 10. 3Procesador: PHP 7. 3Caché: Redis Aquí te dejamos un pequeño manual de instalación desde una instalación de sistema operativo básico de Debian 9. Configurando el Sistema Operativo Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria de Madrid. timedatectl set-timezone 'Europe/Madrid' timedatectl set-ntp on Lo siguiente que haremos es comprobar la versión del sistema operativo y, posteriormente, hacer una actualización completa del mismo. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Una vez esta todo actualizado, instalamos algunas herramientas y software base que puede ser útil tener en el sistema. apt -y install software-properties-common curl vim unzip ufw dirmngr Instalación de MariaDB El siguiente paso será la instalación de la base de datos. En este caso vamos a utilizar MariaDB 10. 3. Lo primero que haremos será configurar la descarga, y posteriormente su instalación. apt-key adv --recv-keys --keyserver hkp://keyserver. ubuntu. com:80 0xF1656F24C74CD1D8 add-apt-repository 'deb http://tedeco. fi. upm. es/mirror/mariadb/repo/10. 3/debian stretch main' apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install mariadb-server mariadb-client Ahora que está instalada, procederemos a la configuración inicial. Para ello usaremos el sistema se instalación segura, que nos hará algunas preguntas. mysql_secure_installation A la pregunta de si queremos cambiar la contraseña, dependiendo de si hemos puesto o no en la instalación, la cambiaremos. En caso de no haber puesto ninguna, es muy recomendable ponerle una contraseña segura. Set root password? : Y Al resto de preguntas, contestaremos lo siguiente: Remove anonymous users? : Y Disallow root login remotely? : Y Remove test database and access to it? : Y Reload privilege tables now? : Y En este momento ya tendremos la base de datos configurada. Ahora haremos que se ejecute en los re inicios del sistema y la iniciaremos. systemctl stop mysql. service systemctl start mysql. service Instalación de nginx En este momento tenemos la base de datos configurada y vamos a proceder a la instalación del servidor web. En este caso vamos a usar nginx. Para estar al día, no usaremos la versión que viene con el sistema operativo, sino una más actualizada y mantenida. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install nginx nginx-extras Ahora que tenemos nginx instalado, lo vamos a configurar para que se inicie en los re inicios del sistema automáticamente. systemctl stop nginx. service systemctl enable nginx. service systemctl start nginx. service Instalación de PHP En este momento ya tenemos el servidor web, por lo que vamos a instalar y a configurar PHP para que funcione correctamente con la base de datos y el servidor web. En este caso vamos a instalar la versión PHP 7. 3. Primero haremos la instalación de los paquetes más actualizados (que no son los que vienen con el sistema operativo) y que en caso de necesitarlo, además, nos permitirían tener varias versiones de PHP en paralelo. apt -y install apt-transport-https lsb-release ca-certificates wget -O /etc/apt/trusted. gpg. d/php. gpg https://packages. sury. org/php/apt. gpg sh -c 'echo "deb https://packages. sury. org/php/ $(lsb_release -sc) main" > /etc/apt/sources. list. d/php. list' apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install php7. 3 php7. 3-fpm php7. 3-common php7. 3-dev php7. 3-cli php7. 3-bcmath php7. 3-curl php7. 3-gd php7. 3-imap php7. 3-json php7. 3-mbstring php7. 3-mysql php7. 3-opcache php7. 3-soap php7. 3-xml php7. 3-xmlrpc php7. 3-zip php-imagick php-libsodium php-ssh2 php-xdebug libgeoip-dev En algunos casos, el sistema integra Apache HTTPD de serie, por lo que haremos una limpieza, por si queda algo de él instalado. apt -y purge apache2* Ahora que ya tenemos PHP correctamente instalado, vamos a activarlo de forma que cuando se reinicie el sistema se ejecute automáticamente. systemctl stop php7. 3-fpm. service systemctl enable php7. 3-fpm. service systemctl start php7. 3-fpm. service Instalación de Redis Para trabajar con unas mejoras en el rendimiento de la caché de objetos, vamos a dejar listo Redis como sistema de almacenamiento. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install redis-server php-redis Posteriormente, y de la misma forma que el resto de elementos, lo vamos a configurar para que se inicie automáticamente si se reinicia el servidor. systemctl stop redis-server. service systemctl enable redis-server. service systemctl start redis-server. service Configuración del HTTPS Como vamos a montar nuestra web sobre un servidor web seguro (HTTPS), necesitaremos instalar el generador de certificados de Let's Encrypt, de forma que previamente prepararemos los sistemas para la creación de claves seguras. openssl dhparam -out /etc/ssl/certs/dhparam. pem 2048 Y en este momento instalaremos el sistema de creación de certificados certbot. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install certbot python-certbot-nginx Para que los certificados se actualicen automáticamente, activaremos una tarea programada (cron) una vez al día que automáticamente renueve los certificados. crontab -e Una vez dentro, configuraremos, por ejemplo, que se ejecute a las 06:45 cada mañana. 45 6 * * * certbot renew Configuración del firewall Para acabar, vamos a activar el Firewall y dejar solo abierto los puertos de SSH (por los que estamos trabajando en estos momentos) y posteriormente los puertos web, dejando el resto inactivo. ufw app list ufw allow 'SMTP' ufw allow 'OpenSSH' ufw allow 'Nginx Full' ufw enable A partir de este momento podemos reiniciar la máquina si queremos, y ya la tendremos lista para comenzar su uso y montar los sitios web. --- Última revisión: 2 de octubre de 2021 Versiones a instalar Sistema Operativo: Ubuntu 18Panel de Control: ningunoServidor web: LiteSpeedBase de Datos: MariaDB 10. 3Procesador: PHP 7. 3Caché: Redis Aquí te dejamos un pequeño manual de instalación desde una instalación de sistema operativo básico de Ubuntu 18. Configurando el Sistema Operativo Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria de Madrid. timedatectl set-timezone 'Europe/Madrid' timedatectl set-ntp on Lo siguiente que haremos es comprobar la versión del sistema operativo y, posteriormente, hacer una actualización completa del mismo. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Una vez esta todo actualizado, instalamos algunas herramientas y software base que puede ser útil tener en el sistema. apt -y install software-properties-common curl vim unzip ufw Instalación de MariaDB El siguiente paso será la instalación de la base de datos. En este caso vamos a utilizar MariaDB 10. 3. Lo primero que haremos será configurar la descarga, y posteriormente su instalación. apt-key adv --recv-keys --keyserver hkp://keyserver. ubuntu. com:80 0xF1656F24C74CD1D8 add-apt-repository 'deb http://tedeco. fi. upm. es/mirror/mariadb/repo/10. 3/ubuntu bionic main' apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install mariadb-server mariadb-client Ahora que está instalada, procederemos a la configuración inicial. Para ello usaremos el sistema se instalación segura, que nos hará algunas preguntas. mysql_secure_installation A la pregunta de si queremos cambiar la contraseña, dependiendo de si hemos puesto o no en la instalación, la cambiaremos. En caso de no haber puesto ninguna, es muy recomendable ponerle una contraseña segura. Set root password? : Y Al resto de preguntas, contestaremos lo siguiente: Remove anonymous users? : Y Disallow root login remotely? : Y Remove test database and access to it? : Y Reload privilege tables now? : Y En este momento ya tendremos la base de datos configurada. Ahora haremos que se ejecute en los re inicios del sistema y la iniciaremos. systemctl stop mysql. service systemctl start mysql. service Instalación de LiteSpeed En este momento tenemos la base de datos configurada y vamos a proceder a la instalación del servidor web. En este caso vamos a usar LiteSpeed. Hay que recordar que para el uso de este servidor web es necesario disponer de una licencia. Para ver la última versión del sistema es muy recomendable visitar la ficha de descargas (en este caso se va a utilizar la versión 5. 3. 8 stable). cd /root/ bash --- ¿Necesitas ayuda con la Administración de Sistemas de WordPress? ¿Tienes alguna idea o sugerencia para publicar en WPSysAdmin? wordpress@wpsysadmin. com Por favor, escríbenos y atenderemos tu petición lo antes posible. Puedes contactar escribiendo un mensaje de correo electrónico. ¿Por qué un correo y no un formulario de contacto? No tenemos la necesidad de almacenar ningún tipo de dato personal tuyo en la web, por lo que preferimos una comunicación directa y fiable por correo electrónico. A partir de ahí ya seguiremos las conversaciones por videollamada, teléfono o cualquier sistema que sea óptimo para ti. --- Última revisión: 2 de octubre de 2021 Cuando hablas de WordPress es un clásico hablar del "uvedoblepé content" haciendo referencia a la carpeta por defecto donde se encuentran plantillas, ficheros, etcétera. Esta es una forma sencilla de detectar si tu instalación tiene WordPress; pero el sistema permite cambiar estas carpetas por otros nombres que tú quieras. Para ello puedes modificar algunos elementos en el fichero de configuración : Carpeta de contenidos define('WP_CONTENT_DIR', '/contenidos'); define('WP_CONTENT_URL', 'https://www. example. com/contenidos'); Carpeta de plugins define('WP_PLUGIN_DIR', '/contenidos/mejoras'); define('WP_PLUGIN_URL', 'https://www. example. com/contenidos/mejoras'); Carpeta de plantillas (themes) $theme_root = WP_CONTENT_DIR. '/plantillas'; define('UPLOADS', 'contenidos/plantillas'); Fichero wp-config. php Si no quieres que tu fichero wp-config. php esté accesible vía URL, una cosa sencilla que se puede hacer es simplemente moverlo a la carpeta superior de tu sistema de ficheros. Esto significa que si por ejemplo tu fichero está en la ruta puedes moverlo a y automáticamente el sistema funcionará. Ten presente que puede haber plugins, plantillas u otras herramientas que intenten acceder directamente al fichero y no lo encuentren, por lo que seguramente es mejor protegerlo de accesos externos que no cambiarlo de directorio. --- Última revisión: 2 de octubre de 2021 En WordPress los usuarios tienen un peso importante en el sistema. Tanto si tienes el gestor completamente cerrado y sólo accedes tú, como si tienes un centenar de personas trabajando con él, es importante evitar que quien no tenga que acceder, no lo haga. El nombre de usuario Históricamente WordPress creaba como usuario por defecto el . Esto hace que las instalaciones más antiguas todavía puedan tenerlo y se debería eliminar, ya que es una fuente de intentos de acceso habituales (también lo son palabras como o ). En general habría que evitar el uso de nombres de usuario simples y es más que recomendable que el nombre de usuario sea distinto a las partes de la cuenta de correo. Si tienes un usuario puedes crear otro usuario (administrador o no) y cuando vayas a borrarlo le transfieres todos los contenidos. Partiendo de esta base, si has de crear un usuario y quieres que sea reconocible para la persona, es mejor usar un usuario del estilo a que no simplemente de . El simple hecho de incluir dos palabras, mayúsculas, minúsculas y espacios aumenta la complejidad habitual que se presupone en un nombre de usuario. Y WordPress, por defecto, te permite usar nombres de usuario complejos. La Contraseña Recuerda leer el artículo sobre Contraseñas para tener presente qué es una contraseña segura. Los usuarios por norma general van a utilizar contraseñas poco seguras, a menos que sea alguien responsable y preocupado por la seguridad y su privacidad. Es por esto que lo mejor es obligar a los usuarios a utilizar una contraseña considerada segura (y con la configuración mínima que tu le indiques). Para ello tienes plugins que fuerzan contraseñas seguras que realizan esta tarea de forma sencilla. Doble verificación (2FA) Aún todo esto, hoy en día existe una forma mucho más efectiva de mejorar la seguridad, y es configurar un sistema de doble verificación. Además de tener un usuario y una contraseña el objetivo es que, tras acceder correctamente, verifiques que realmente eres tú. ¿Cómo conseguirlo? Pues con algo que en general todos llevamos encima: nuestro teléfono móvil. La idea es instalar un plugin de doble verificación, obligatorio para todos los usuarios, de forma que una vez el usuario haya accedido con su usuario y contraseña (más o menos segura) te pedirá una nueva clave numérica que se genera cada minuto y que sólo estará configurada en tu dispositivo móvil. En la pantalla aparecerá ese número, lo introduces y ya podrás disfrutar de tu WordPress. Así, si alguien consigue tus accesos, no podrá acceder ya que también debería tener tu teléfono móvil. IMPORTANTE: No uses verificación por SMS, usa una App. Existen sistemas relativamente sencillos en los que otras Apps tienen acceso a los mensajes SMS que puedes recibir e interceptar o modificar esos mensajes; es por esto que es mejor que el generador de contraseñas lo haga una App y no se reciba mediante SMS. Bloquear intentos de acceso masivos Un detalle importante es el de limitar los accesos de un usuario al panel. En realidad, el objetivo no es tanto limitar al usuario sino limitar a alguien (persona, máquina... ) a que haga muchos intentos de acceso ya sea con un usuario existente o probando distintos. Aunque una contraseña segura y doble verificación es suficiente para que nadie pueda entrar en tu WordPress mediante sistemas de fuerza bruta, puede ser un poco cansado que se estén ejecutando miles de solicitudes de acceso. Es por esto que podemos plantear la instalación de un plugin que cuando detecte este tipo de ataques los bloquee. Podemos instalar un Firewall o tenemos sistemas que se limitan a controlar los intentos de acceso de la zona de acceso. Los permisos Por defecto WordPress lleva unos sencillos niveles de usuario: Administrador, Editor, Suscriptor... Pero si comienzas a añadir funcionalidades que no son las sencillas de publicación, tal vez sea mejor que tus usuarios tengan un rol muy concreto en el que sólo toquen lo que deban tocar. Para ello existen varios plugins de gestión de usuarios, aunque te recomiendo el uso de User Role Editor o de Members. En estos casos verás que aunque un usuario tenga los permisos generales de un nivel, puedes darles o quitarles otros permisos concretos a distintos elementos puntuales. Esto permite crear niveles de usuarios que diferencien tareas habituales que unas personas deben y otras no realizar. Cuando acabes de trabajar... Es fácil: desconecta tu sesión. Dejar la sesión abierta en cualquier dispositivo ofrece una posibilidad de dejar las cookies y la sesión activa para que el que venga detrás tenga acceso a ella. Aunque sea un dispositivo personal, sal. No cuesta nada volver a poner tu contraseña. --- Última revisión: 2 de octubre de 2021 WordPress es un gestor de contenidos que permite infinidad de opciones, entre ellas la de leer elementos externos (tan sencillos como feeds de noticias de otros sitios) o la descarga de otros elementos (como las plantillas y plugins). Este sistema viene activo por defecto lo que hace que cualquier elemento sea capaz de conectarse de forma externa. Si se diera el caso de que se inyectase algún tipo de código malicioso, éste podría conectarse a otros sitios y descargar o actualizar información, algo que por norma general no deseamos que ocurra. Si queremos bloquear los accesos externos podemos activar un elemento en el fichero de configuración: define('WP_HTTP_BLOCK_EXTERNAL', true); Pero esto podría bloquear cualquier llamada externa, por lo que podemos activar una lista blanca de sitios a los que sí se podría acceder: define('WP_ACCESSIBLE_HOSTS', '*. wordpress. org,*. github. com'); En este caso daríamos acceso a los sitios web de WordPress y Github. --- Última revisión: 2 de octubre de 2021 Subir imágenes, editarlas, recortarlas y volver a empezar. Sin duda uno de los esfuerzos mayores en muchas versiones de WordPress ha sido la de trabajar en mejoras del sistema de edición de contenidos multimedia, principalmente las imágenes. Cuando subimos una imagen (la original) automáticamente se crean otras ediciones más pequeñas de la misma que se usarán como destacados o en otros lugares de la plantilla. Pero posteriormente podemos editarlas y recortarlas. Esto genera otro set completo de imágenes sin sobrescribir las primeras. Si finalmente decides que estas imágenes han de desaparecer y eliminas la imagen original, no se eliminan todas estas imágenes recreadas que podrían contener datos que no te interesa que estén accesibles. ¿Cómo se pueden eliminar todas estas imágenes generadas cuando eliminas la imagen original? Pues activando un elemento en el fichero de configuración : define('IMAGE_EDIT_OVERWRITE', true); Ten en cuenta que si utilizas algún sistema del estilo a un CDN es posible que estas imágenes ya se hayan replicado y distribuido por el mundo, por lo que tendrás que hacer un ejercicio de limpieza manual para eliminar esas imágenes que tal vez nunca debieron ver la luz. --- Última revisión: 2 de octubre de 2021 En general los ficheros de estilo (CSS) y los de scripting (JavaScript) incluyen cierta información como las versiones, ya sea en su nombre, en el interior, en algunos comentarios... el hecho de unificarlos, reducirlos y limpiarlos permite que internamente los datos sigan activos (necesarios para el buen funcionamiento de WordPress) pero invisibles para los usuarios. Sistemas de reducción hay varios, normalmente en forma de plugin , y que básicamente han de permitir 3 opciones: limpiar, reducir y unificar CSS, limpiar, reducir y unificar JavaScript y limpiar, reducir y unificar el HTML. El propio WordPress dispone de una forma similar que es la concatenación y compresión de elementos. Para ello habría que incluir en el fichero de configuración los siguientes elementos: define('CONCATENATE_SCRIPTS', true); define('COMPRESS_CSS', true); define('COMPRESS_SCRIPTS', true); Este sistema complica la detección automática, pero no reduce el riesgo por completo. --- Última revisión: 2 de octubre de 2021 El correo basura (spam), esa lacra de Internet que muchos sufrimos todos los días en nuestra bandeja de entrada, es algo que debemos evitar que ocurra debido a nuestro sitio web. Controlar el correo que sale desde nuestro servidor por norma general es algo que no se revisa ni a lo que se le presta atención, además de ser un correo saliente que no va firmado ni securizado. Para mejorar y corregir esto, hacer que los correos lleguen correctamente y de forma segura y atractiva, lo mejor es utilizar un servicio de salida de correo externo (SMTP). Una vez más, existen decenas de plugins para sustituir las funciones mail internas por externas, aunque en este caso recomiendo utilizar Elastic Email que además tiene un plugin propio que facilita su configuración. Entradas DNS para correo Aunque no es el objetivo de este texto entrar a explicar la configuración del correo, ser estricto en la configuración es algo importante, sólo si se hace correctamente. Es por esto que para evitar problemas con el envío de correos desde tu sitio web configures correctamente tus entradas DNS: A: Aunque parezca algo estúpido, para que el correo funcione correctamente, el dominio example. com ha de tener siempre una entrada A hacia una dirección IP. MX: Para poder enviar correo hacen falta direcciones de correo, por lo que si quieres enviar correo has de poder recibir correo. Ten al menos una entrada MX -aunque se recomiendan al menos dos- configurada para recibir. SPF: Con la política de envíos dices desde qué servidores se puede enviar correo. Si vas a mandar correo desde tu máquina, dilo. Si vas a añadir también Google, dilo. DKIM: Firma digitalmente tu correo y consigue que tu destinatario pueda verificar que el correo es tuyo y de nadie más. DMARC: Evita que nadie pueda enviar un correo en tu nombre, combatiendo el phishing y el spam. --- Última revisión: 2 de octubre de 2021 Como la mayor parte de gestores de contenidos, WordPress se identifica claramente y ofrece determinados servicios que luego usaremos (o no). Y habitualmente este hecho implica pequeños elementos que te dejan ver información y disminuyen la seguridad. Es por esto que es muy recomendable ocultar determinadas cabeceras que aparecen en el (u otros elementos, como los feeds) de la página. Existen un par de decenas de códigos que se pueden eliminar si no queremos tener determinados elementos funcionando. Deshabilitar cabeceras --- Última revisión: 2 de octubre de 2021 El fichero de robots. txt que ha de estar en la carpeta raíz del hostname de la instalación (aunque tu WordPress esté en una carpeta), es un fichero que no viene por defecto en WordPress, aunque si lo llamas el sistema genera uno sencillo, y que deberías crear. Este fichero de texto lo que hace es decirle a los robots de búsqueda (como GoogleBot, BingBot, YandexBot, Slurp! ... ) qué deben y qué no deben analizar de tu sitio. ¿Qué deberíamos bloquear de WordPress en este fichero? En principio nada. Hoy en día se pueden conseguir bloquear muchos elementos mediante las configuraciones internas de plugins de seguridad, por lo que si quieres tener un sitio seguro lo mejor es no dar información en este fichero. De esta manera, el fichero tendrá un contenido simple: User-Agent: * Por defecto WordPress genera un fichero virtual con el siguiente contenido: User-Agent: * Disallow: /wp-admin/ Disallow: /wp-admin/admin-ajax. php Aunque esto que expone no es grave, teniendo en cuenta que el acceso al /wp-admin/ ha de pasar previamente por un acceso de usuario, no deja de ser una pista muy clara de que este sitio está construido con WordPress. --- Última revisión: 2 de octubre de 2021 Un ataque habitual en los sitios con WordPress (principalmente en aquellos que están focalizados en escribir entradas tipo blog) es el que se hace de los comentarios mediante ataques por spam. Para ello es básico tener instalado un sistema antispam en los comentarios. WordPress suele venir con uno instalado (no activado) de serie, que es Akismet. No es el único que existe, todo lo contrario, la lista es bastante amplia y larga. Una forma sencilla de bloquear spam, sin necesidad de enviar los contenidos a algún sitio externo, es el de usar la caja de palabras claves que permiten su bloqueo. Se puede actualizar esta caja con palabras claves generadas por la comunidad mediante el plugin Block List Updater. --- Última revisión: 2 de octubre de 2021 La seguridad no sólo consiste en que tú te protejas sino también en proteger a los demás. Es por esta razón que uno de los elementos que deberías revisar cada cierto tiempo son los enlaces salientes de tu sitio web. En muchas ocasiones los enlaces dejan de funcionar o se redirigen a sitios de, digámoslo finamente, dudosa calidad. Es por eso que es muy recomendable utilizar algún complemento que analice los enlaces rotos. Pero no sólo los enlaces que tú publicas, sino aquellos que te hacen referencia. Los trackbacks (sitios webs que te enlazan y aparecen como comentarios) también pueden falsificarse simplemente para hacer spam o para llevar a tus usuarios a sitios poco seguros. Para estos casos puedes desactivarlos, o verificar que cuando se produce uno, realmente te han enlazado desde allí. --- Última revisión: 2 de octubre de 2021 Una de las ventajas de WordPress es su flexibilidad a la hora de ser utilizado por aplicaciones de terceros, y para ellos muchas utilizan el estándar XML-RPC que permite la interacción con el número del gestor de contenidos. Obviamente, si desactivas esta tecnología no podrás usar programas como Open Live Writer o herramientas como IFTTT e incluso la propia App de WordPress para Android o iOS. Existe una herramienta muy interesante para verificar el funcionamiento o no de esta tecnología, llamada WordPress XML-RPC Validation Service. Deshabilitar XML-RPC add_filter('xmlrpc_enabled', '__return_false'); Instrucciones paso a paso Crea el plugin o descárgalo ya creado (descomprime el fichero ZIP). Accede por FTP a la carpeta . Si no tienes esta carpeta, créala. Sube por FTP el fichero a la carpeta . Cuando entres en el panel de administración de tu WordPress, en la zona de Plugins tendrás una sección nueva de plugins Imprescindibles donde aparecerá. Recuerda que al ser Imprescindible no podrás activarlo ni desactivarlo. Deshabilitar Pingbacks XML-RPC function wpdanger_xmlrpc_ping($methods) { unset($methods); unset($methods); return $methods; } function wpdanger_xmlrpc_header($headers) { unset($headers); return $headers; } add_filter('xmlrpc_methods', 'wpdanger_xmlrpc_ping', 9999, 2); add_filter('wp_headers', 'wpdanger_xmlrpc_header', 9999, 2); Instrucciones paso a paso Crea el plugin o descárgalo ya creado (descomprime el fichero ZIP). Accede por FTP a la carpeta . Si no tienes esta carpeta, créala. Sube por FTP el fichero a la carpeta . Cuando entres en el panel de administración de tu WordPress, en la zona de Plugins tendrás una sección nueva de plugins Imprescindibles donde aparecerá. Recuerda que al ser Imprescindible no podrás activarlo ni desactivarlo. Permitir accesos limitados a IP Como este método puede ser muy agresivo, te puedes plantear otras opciones más ligeras que en un futuro cercano te permitan añadir, por ejemplo, una IP desde la que tú puedas acceder, pero el resto no. En Apache HTTPD (dentro del fichero . htaccess): order deny, allow deny from all allow from 8. 8. 8. 8 Has de cambiar 8. 8. 8. 8 por tu dirección IP En nginx (dentro del fichero de configuración del sitio): location = /xmlrpc. php { limit_except POST { deny all; } allow 8. 8. 8. 8; access_log off; log_not_found off; } Has de cambiar 8. 8. 8. 8 por tu dirección IP --- Última revisión: 2 de octubre de 2021 Dicen que el sentido común es el menos común de los sentidos, y por eso te pido un poco de él. La seguridad en general es compleja, no hay nada 100% seguro, y por eso hay que aplicar todos estos consejos y códigos con cabeza, sabiendo el porqué los vas a aplicar y no simplemente copiando y pegando líneas de código "porque sí". Como sabes, WordPress es seguro, y este documento lo que pretende es poner trabas a aquellos que quieran atacar tu sitio por la razón que sea. Simplemente eso. --- Última revisión: 2 de octubre de 2021 A partir de finales de mayo de 2018 las empresas europeas, que trabajen en Europa o aquellos usuarios que lo hagan, van a estar sometidos a la nueva regulación de protección de datos aprobada a mediados de 2016. Esta nueva regulación, que sustituye la de 1995 y que viene dada principalmente por el terrorismo y todos los cambios digitales de estas dos últimas décadas, va a ser aplicada "tal cual", sin que los países tengan que adaptarla a su legislación propia. Esta nueva legislación afecta, por ejemplo, a todas aquellas empresas exteriores a la UE que operen con usuarios europeos, además de estandarizar la legislación de datos a todos los países miembros. El incumplimiento de esta legislación puede alcanzar un 4%-5% de la facturación mundial de las compañías que la incumplan. Entre otros detalles, esta legislación vendría a decirte que has de recoger información sobre algunos de los elementos que WordPress proporciona en tu sitio, como por ejemplo el registro de usuarios, comentarios, datos de contactos de los formularios, datos sobre analítica, etcétera. Algunos plugins para controlar la actividad de usuarios: WP Activity Log, Stream, Activity Log, User Activity Log, WP System Log. Otro detalle a tener presente es que si tu sitio tiene una brecha de seguridad (alguien accede donde no debe) hay un límite de 72 para avisar a la Autoridad Supervisora. En este caso es muy recomendable usar algún complemento de cortafuegos que te avise en tiempo real de intentos de acceso o de ellos mismos. También has de informar de cómo se almacenarán los datos de los usuarios (y cómo tendrán acceso a ellos), su derecho al olvido (cómo vas a eliminar sus datos) y la portabilidad de sus datos (en caso de que quieran llevar su material a otro sitio). Otro detalle importante es el de los plugins, ya que aquellos que muevan datos de los usuarios fuera del sitio (un ejemplo conocido podría ser el de Jetpack) han de tener una política clara de cumplimiento de la GDPR. Algunos plugins recomendados para la gestión de cookies de terceros: GDPR Cookie Compliance, Cookie Notice & Compliance, Complianz, CookieYes. Si estás interesado en este asunto, te recomiendo leer un artículo sencillo (no soy abogado, por lo que son simples conclusiones personales) que escribí sobre esta legislación en Ley de protección de datos europea. --- Última revisión: 2 de octubre de 2021 Una vez más volvemos a temas que afectan principalmente a rendimiento y, en este caso, es el de ir vaciando la base de datos de copias antiguas de entradas o páginas. Según vas actualizando contenidos se van creando copias antiguas. Por norma general esas copias no están accesibles, pero si quieres eliminar algún elemento que puede tener contenidos que nunca debieron estar ahí, lo mejor es limitar el tiempo o cantidad de elementos anteriores. Para ello añadiremos al fichero de configuración el número de días que queremos que un elemento siga en la papelera: define('EMPTY_TRASH_DAYS', 1); El siguiente elemento es si queremos hacer copias de seguridad de las entradas, cuántas, si sí: define('WP_POST_REVISIONS', 5); o si no: define('WP_POST_REVISIONS', false); --- Última revisión: 2 de octubre de 2021 Una vez más, lo que probablemente sea una recomendación general y muy útil, como la de activar las caché de WordPress, se convierte en un elemento que ayuda a aumentar la seguridad de tu sitio. Porque cuando hablamos de seguridad no sólo hablamos de hackeos, sino de posibles ataques DDoS que lo que hacen es dejar inaccesible tu sitio y que tus usuarios no puedan visitarlo. WordPress tiene varios tipos de niveles de caché, pero independientemente de la que usemos lo primero es activarlo en el fichero de configuración : define('WP_CACHE', true); A partir de este momento el sistema ya gestiona la caché de forma automática. Quizá no es la configuración óptima, pero funciona. Así que lo siguiente es gestionar esta caché y para ello, obviamente, usaremos cualquiera de los plugins de cache que existen. Uno sencillo y funcional (además de completo) es el WP Super Cache. Y como decía al principio, caché en WordPress hay de varios tipos, y generalmente se habla de la de las páginas, pero existen otros niveles como los objetos. Para ello es muy recomendable utilizar algún sistema como memcached o Redis para su almacenamiento. Te recomiendo que revises la sección de Mejorar el rendimiento de WordPress donde hay más información. --- Última revisión: 2 de octubre de 2021 Aunque normalmente no es algo que suela pasar, es posible que tu plantilla falle por alguna razón (por alguna incompatibilidad, porque se borren algunos ficheros... ) o simplemente que tengas un WordPress MultiSite y quieras indicar cuál de tus plantillas es la que se configurará con los nuevos sitios, hay que añadir esta línea en el fichero de configuración : define('WP_DEFAULT_THEME', 'twentytwenty'); En general te recomiendo que siempre tengas una de las plantillas propias de WordPress como seguridad, por ejemplo, el TwentyTwenty. --- Última revisión: 2 de octubre de 2021 Si hablamos de seguridad hemos de hablar de copias de seguridad (backups). No tiene sentido poner medidas que ayudan a la seguridad de tu sitio si luego no tienes una copia del mismo que permita restaurar una configuración fallida. Cuando hablamos de copias de seguridad con WordPress hablamos de dos (o tres) partes, dependiendo de tu sitio. Las dos principales son la base de datos y los ficheros. La tercera es la del certificado TLS que permite el acceso por HTTPS. Las copias de seguridad se pueden realizar de muchas maneras, manualmente (como haría un buen administrador de sistemas ? ? ? ? ) o de forma automática mediante un plugin. Una vez más, para esto hay decenas de ellos, aunque te recomiendo uno en concreto que permite almacenar los datos generados en varios lugares. Además de tener copias de seguridad es importante dejar una de ellas en la propia máquina (no accesible por web) y mandar otra a cualquier otro lugar (Dropbox, Amazon, un servidor externo... ). Finalmente, tendremos una copia de seguridad de los ficheros del certificado TLS. Estos ficheros no son necesario que se copien cada día o semana, ya que se actualizan como pronto cada 3 meses. Y finalmente la pregunta del millón: ¿cada cuánto he de hacer las copias de seguridad? Pues en general dependerá de cuánto cambia tu sitio con WordPress. Si cada día publicas varias entradas o contenidos, es posible que sea interesante realizar una copia cada 6-12 horas. Si publicas o cambias elementos una vez cada mucho, con una copia semanal puede que ya tengas suficiente. --- Última revisión: 2 de octubre de 2021 Tener un WordPress es tener un sitio web, y como tal te convierte en webmaster. Esto significa que por Internet te encontrarás muchas herramientas que podrás utilizar para analizar tu sitio web. No voy a poner la infinidad de herramientas, pero sí algunas importantes que, entre otras cosas, te pueden ayudar a encontrar detalles de la seguridad en tu WordPress. Baidu 百度站长平台Bing Webmaster ToolsDNSBLGoogle Search ConsoleREDbotYandex Webmaster --- Última revisión: 2 de octubre de 2021 A la hora de escalar, cachear, evitar ataques nunca hay una situación ideal, pero sí servicios por Internet que te ayudan a protegerte de una forma más o menos sencilla, como son los CDN. Una de estas opciones es la de Cloudflare, que básicamente consiste en activar un servicio en el que ponen una capa intermedia entre el usuario y tu sitio web. Una vez tengas cuenta con ellos, lo primero es activar su plugin en tu sitio. A partir de aquí podrás comenzar a jugar con algunas opciones. Por norma general este servicio no te cacheará las páginas, pero sí que lo hará con otros elementos estáticos. Ejercerá básicamente de CDN (Content Delivery Network), lo que significa que tus imágenes, estilos y scripts se distribuirán para una descarga más rápida. Esto lleva una contra, y es que en caso de que tú hagas cambios, también tendrás que avisar a Cloudflare de ello (en principio, para eso está el plugin). Existen varios manuales que te pueden ser de ayuda: Using Cloudflare with WordPressHardening WordPress SecurityCaching Static HTML with WordPress/WooCommerceSpeed Up WordPress and Improve Performance Recuerda que Cloudflare no evitará que pueda haber ataques a tu sitio a menos que lo actives, pero sí que ayudará a complicarlo un poco debido a que están entre los usuarios / atacantes y tu servidor real. --- Última revisión: 2 de octubre de 2021 Existen servicios de pago que requieren una licencia para funcionar y habitualmente estas licencias se añaden desde el panel de administración. Esto hace que la licencia esté visible para todos aquellos que tienen permisos y que permitiría que algún “listillo” la pueda intentar copiar y usar donde no debe. Para evitarlo, algunos de estos plugins o plantillas permiten configurar la licencia en el fichero de configuración, de forma que quede fuera del alcance de quienes no deben tenerla. Un ejemplo es el de Gravity Forms que permitiría añadir una línea en el fichero de configuración similar a la siguiente: define('GF_LICENSE_KEY', 'abcde123456789'); Otro ejemplo más habitual puede ser el de WordPress. com, que suele ser necesario para plugins como JetPack o Akismet: define('WPCOM_API_KEY', 'abcde123456789'); --- Última revisión: 2 de octubre de 2021 Desde hace unas pocas versiones de WordPress, todos aquellos desarrolladores de plugins pueden indicar la versión mínima de PHP necesaria para que funcione. WordPress está poniendo muchos esfuerzos en mantener al día y con unas versiones actualizadas todos sus productos y servicios, y eso implica a los propios desarrolladores, tal y como se informó en agosto de 2017. La idea es que en la cabecera del plugin se indique con una línea la versión mínima: === Plugin Name === Contributors: (this should be a list of wordpress. org userid's) Donate link: http://example. com/ Tags: comments, spam Requires at least: 4. 6 Tested up to: 4. 8 Requires PHP: 5. 6 Stable tag: 4. 3 License: GPLv2 or later License URI: https://www. gnu. org/licenses/gpl-2. 0. html En este caso, se indica el texto Requires PHP: 5. 6 en el que se informa que la versión mínima de funcionamiento del plugin es 5. 6; por lo tanto, aquellos usuarios que tengan versiones anteriores de PHP en su sistema recibirán un aviso conforme puede no funcionar o directamente bloquear la posible instalación. En el repositorio de plugins, además, aparecerá un aviso de la versión en la zona de información técnica. --- Última revisión: 2 de octubre de 2021 El primer punto de inicio a la hora de atacar un WordPress es saber qué versión está utilizando. La versión de WordPress está bastante disponible, ya que forma parte del código del sitio, por lo que hay que ocultarla de varias formas en varios lugares. ReadMe El principal fichero donde encontrar la versión de WordPress no se encuentra en el código, sino en el fichero readme. html en la propia instalación del software. Es por esto que una de las primeras cosas que debemos hacer para ocultar la versión que aparece en este fichero es dejarlo inaccesible. Una primera opción, si usas un servidor Linux, es quitarle los permisos al fichero, ejecutando: chmod 000 readme. html Aunque siempre existe la opción de devolver un código de inaccesibilidad desde Apache HTTPD (dentro del fichero . htaccess): Deny from all Y de la misma manera podríamos bloquearlo desde nginx: En nginx (dentro del fichero de configuración del sitio). En este caso vamos a ser más agresivos y a bloquear todos los del sitio, ya sean HTML o TXT. location ~* readme. (html|txt) { deny all; } Meta-Información En las plantillas habitualmente encontraremos el meta-generator que incluye la versión que tienes instalada. Este código se encuentra en la cabecera de tu sitio: Para eliminar este código (y el de otros plugins que también lo utilicen) podemos aplicar este código en el fichero de de nuestra plantilla. Otra opción es mediante el sistema explicado en la sección de Cabeceras inconvenientes. remove_action('wp_head', 'wp_generator'); Pero no solo en la plantilla aparece este código, sino también en otros elementos xomo XML, feeds, RSS, etcétera. Para ello también aplicaremos otro filtro. add_filter('the_generator', '__return_false'); Versión en CSS y Javascript De la misma manera que nos encontramos la versión de WordPress en las meta-etiquetas, también la solemos encontrar en las etiquetas de CSS y JavaScript del sitio, normalmente en el parámetro . Esta versión que aparece es la propia del WordPress, por lo que aunque eliminemos la versión de la meta-información, nos queda ocultar las versiones de estos elementos. function wpdanger_remove_ver($src, $handle) { $handles = ; if(strpos($src, 'ver=') && ! in_array($handle, $handles, true)) $src = remove_query_arg('ver', $src); return $src; } add_filter('style_loader_src', 'wpdanger_remove_ver', 9999, 2); add_filter('script_loader_src', 'wpdanger_remove_ver', 9999, 2); Instrucciones paso a paso Crea el plugin o descárgalo ya creado (descomprime el fichero ZIP). Accede por FTP a la carpeta . Si no tienes esta carpeta, créala. Sube por FTP el fichero a la carpeta . Cuando entres en el panel de administración de tu WordPress, en la zona de Plugins tendrás una sección nueva de plugins Imprescindibles donde aparecerá. Recuerda que al ser Imprescindible no podrás activarlo ni desactivarlo. Un método alternativo a este, es usar algunas funciones propias de WordPress: function wpdanger_remove_ver( $src ) { if( strpos( $src, '? ver=' ) ) $src = remove_query_arg( 'ver', $src ); return $src; } add_filter( 'style_loader_src', 'wpdanger_remove_ver', 10, 2 ); add_filter( 'script_loader_src', 'wpdanger_remove_ver', 10, 2 ); --- Última revisión: 2 de octubre de 2021 Hacer mantenimiento de un sitio WordPress no suele ser complejo, pero a veces puede ser complejo gestionar muchos sitios en un mismo servidor. Así que si eres un Administrador de Sistemas al que le gusta la consola, seguramente seas de esos a los que WP-CLI le enamora por toda la funcionalidad que permite. En el sitio oficial tienes disponible un manual de instalación muy sencillo, pero no es de eso de lo que quiero hablaros, sino de la posibilidad que tiene este sistema para hacer mantenimientos y pruebas de estado del sistema. NOTA: Este código está basado en la versión 1. 5. 0 de WP-CLI Una vez lo tengas instalado y funcionando, puedes probar lo siguiente... ya verás que en muchas ocasiones se realizan tareas que pueden parecer repetitivas, pero son básicamente para comprobar que todo está bien y trabajar de forma más tranquila. Instalación de WP-CLI La instalación es bastante simple. curl -O https://raw. githubusercontent. com/wp-cli/builds/gh-pages/phar/wp-cli. phar php wp-cli. phar --info chmod +x wp-cli. phar mv wp-cli. phar /usr/local/bin/wp wp --info Con esto descargamos el software, verificamos que está y lo configuramos en una carpeta para que esté disponible desde todo el sistema. A partir de aquí podemos hacer algunas cosas. NOTA: los comandos a continuación son un ejemplo de lo que se puede hacer, pero tienes documentación de todos los comandos si quieres hacer cosas más específicas. Verificar que tenemos WP-CLI instalado La ejecución tan sencilla como ver la información de la instalación del software. wp --info Actualización del software del WP-CLI Antes de empezar a trabajar con WP-CLI, lo que haremos será una verificación de qué versión estamos utilizando. wp cli version Y posteriormente verificaremos si existe alguna versión nueva. wp cli check-update Lo que nos llevaría, dado el caso, a actualizar el WP-CLI. wp cli update Análisis Antes de realizar ningún cambio, vamos a analizar el estado del sitio web. Aunque WP-CLI permite pasar por parámetro una carpeta local, en este caso lo haremos todo dentro de la propia instalación que vamos a analizar. cd /web/example. com/ Una vez estemos dentro de la instalación de WordPress, haremos una primera verificación para comprobar que el núcleo no está hackeado ni infectado y que los ficheros corresponden con la descarga oficial. wp core verify-checksums De la misma manera, haremos el trabajo para los plugins, eso sí, solo aquellos que se encuentran en el repositorio oficial. wp plugin verify-checksums Lo siguiente que vamos a hacer es verificar la configuración que tenemos el el . Con este repaso visual podremos detectar si hay algún valor que quizá no conozcamos o que no hayamos incluido nosotros. wp config get Posteriormente vamos a hacer un análisis de los usuarios. Este análisis sobre todo va bien cuando tienes una lista de usuarios reducida, ya que si das acceso a otros usuarios, puede ser bastante largo e inútil hacer esta revisión. wp user list De la misma forma, vamos a comprobar que el prefijo de las tablas de la base de datos es el correcto. wp db prefix Y, una vez verificado, vamos a hacer un listado de todas las tablas que tenemos, para verificar que son las correctas y que no han aparecido o desaparecido. wp db tables Una vez aquí, otro dato que podemos analizar son las configuraciones de "rewrite" (URL limpias) que hay disponibles. wp rewrite list Y en caso de que quieras hacer un refresco y regenerarlas, lo puedes hacer. wp rewrite flush Actualización del CORE de WordPress Lo primero que vamos a ver es qué versión del núcleo tenemos instalada. wp core version Y después, si existe alguna nueva versión disponible para instalar. wp core check-update En caso de quererlo, podemos hacer una actualización sencilla, o podemos, de forma alternativa, forzar a que se instale una versión o sobrescribir la actual. wp core update wp core update --force --version 1. 2. 3 Posteriormente, si se realiza una actualización, deberíamos ejecutar el sistema que también haga la actualización de la base de datos si es necesario. wp core update-db Actualización de PLUGINS de WordPress Para empezar, vamos a hacer un listado de todos los plugins que tenemos instalados. wp plugin list Y una vez veamos lo que tenemos, vamos a revisar aquellos que requieren de una actualización. wp plugin update --dry-run --all Si estamos seguros de querer actualizar todo, podemos hacerlo sin problema, o podemos ir plugin a plugin si es, por ejemplo, algo complejo (tipo WooCommerce). wp plugin update --all wp plugin update slug-del-plugin Actualización de THEMES de WordPress El caso de las plantillas es muy similar al de los plugins. Lo primero que haremos es listar todas las plantillas que tenemos. wp theme list Y posteriormente ver cuáles se pueden actualizar. wp theme update --dry-run --all Así, de la misma manera, podemos actualizar todas o una en concreto. wp theme update --all wp theme update slug-de-la-plantilla Actualización de TRANSLATIONS de WordPress Comencemos haciendo una lista de los idiomas disponibles en el sitio. wp language core list --status=installed Y veamos qué idiomas requieren de algún tipo de actualización. wp language core update --dry-run Y, posteriormente, hagamos las actualizaciones. wp language core update Base de datos Tras hacer un mantenimiento de todos los elementos de software, lo siguiente podría ser hacer una revisión de la base de datos, sobre todo tras todas las actualizaciones anteriores. Lo siguiente será ver cuánto ocupa la base de datos. Este dato es poco habitual tenerlo pero muchos alojamientos compartidos tienen limitaciones en su tamaño, por lo que será importante controlar su crecimiento. wp db size Para acabar, haremos una optimización de la base de datos que ayude a desbloquear cualquier tipo de elemento que haya atascado, además del tamaño y recursos de las tablas. wp db optimize En el caso específico de necesitar una revisión concreta de la base de datos porque pensamos que puede estar corrupta o tener algún problema, tenemos los siguientes comandos que analizan, optimizan y reparan los problemas que pueda haber. wp db... --- Última revisión: 2 de octubre de 2021 Aunque no suele ser muy normal, de tanto en tanto aparecen vulnerabilidades en WordPress como la CVE-2018-6389. In WordPress through 4. 9. 2, unauthenticated attackers can cause a denial of service (resource consumption) by using the large list of registered . js files (from wp-includes/script-loader. php) to construct a series of requests to load every file many times. CVE-2018-6389 Este problema viene de los ficheros y que permiten la carga de una serie de scripts y estilos predefinidos. En este caso hablaré del de los scripts aunque el parche a aplicar es para ambos ficheros. NOTA: Esta entrada está documentada a fecha 2018-02-09. Problema Este fichero carga una lista de scripts que se encuentran en el fichero . Esta lista es de más de 180 posibles valores que daría pie a poder hacer una consulta del estilo a: /wp-admin/load-scripts. php? c=1&load%5B%5D=eutil,common,wp-a11y,sack,quicktag,colorpicker,editor,wp-fullscreen-stu,wp-ajax-response,wp-api-request,wp-pointer,autosave,heartbeat,wp-auth-check,wp-lists,prototype,scriptaculous-root,scriptaculous-builder,scriptaculous-dragdrop,scriptaculous-effects,scriptaculous-slider,scriptaculous-sound,scriptaculous-controls,scriptaculous,cropper,jquery,jquery-core,jquery-migrate,jquery-ui-core,jquery-effects-core,jquery-effects-blind,jquery-effects-bounce,jquery-effects-clip,jquery-effects-drop,jquery-effects-explode,jquery-effects-fade,jquery-effects-fold,jquery-effects-highlight,jquery-effects-puff,jquery-effects-pulsate,jquery-effects-scale,jquery-effects-shake,jquery-effects-size,jquery-effects-slide,jquery-effects-transfer,jquery-ui-accordion,jquery-ui-autocomplete,jquery-ui-button,jquery-ui-datepicker,jquery-ui-dialog,jquery-ui-draggable,jquery-ui-droppable,jquery-ui-menu,jquery-ui-mouse,jquery-ui-position,jquery-ui-progressbar,jquery-ui-resizable,jquery-ui-selectable,jquery-ui-selectmenu,jquery-ui-slider,jquery-ui-sortable,jquery-ui-spinner,jquery-ui-tabs,jquery-ui-tooltip,jquery-ui-widget,jquery-form,jquery-color,schedule,jquery-query,jquery-serialize-object,jquery-hotkeys,jquery-table-hotkeys,jquery-touch-punch,suggest,imagesloaded,masonry,jquery-masonry,thickbox,jcrop,swfobject,moxiejs,plupload,plupload-handlers,wp-plupload,swfupload,swfupload-all,swfupload-handlers,comment-repl,json2,underscore,backbone,wp-util,wp-sanitize,wp-backbone,revisions,imgareaselect,mediaelement,mediaelement-core,mediaelement-migrat,mediaelement-vimeo,wp-mediaelement,wp-codemirror,csslint,jshint,esprima,jsonlint,htmlhint,htmlhint-kses,code-editor,wp-theme-plugin-editor,wp-playlist,zxcvbn-async,password-strength-meter,user-profile,language-chooser,user-suggest,admin-ba,wplink,wpdialogs,word-coun,media-upload,hoverIntent,customize-base,customize-loader,customize-preview,customize-models,customize-views,customize-controls,customize-selective-refresh,customize-widgets,customize-preview-widgets,customize-nav-menus,customize-preview-nav-menus,wp-custom-header,accordion,shortcode,media-models,wp-embe,media-views,media-editor,media-audiovideo,mce-view,wp-api,admin-tags,admin-comments,xfn,postbox,tags-box,tags-suggest,post,editor-expand,link,comment,admin-gallery,admin-widgets,media-widgets,media-audio-widget,media-image-widget,media-gallery-widget,media-video-widget,text-widgets,custom-html-widgets,theme,inline-edit-post,inline-edit-tax,plugin-install,updates,farbtastic,iris,wp-color-picker,dashboard,list-revision,media-grid,media,image-edit,set-post-thumbnail,nav-menu,custom-header,custom-background,media-gallery,svg-painter&ver=4. 9 En principio esta dirección se puede cargar sin problema, excepto que al ser un fichero tan grande tarda unos dos segundos en generarse. Eso puede provocar que en un ataque masivo, se acabe saturando el servidor. Situación En estos momentos no hay un parche como tal en el código de WordPress y se plantea si esto es un problema a corregir por el propio sistema o por elementos externos (Firewall, WAF... ). Otras propuestas que hay es la de limitar el número de elementos que se pueden cargar a la hora de hacer la llamada al script. Soluciones Aunque no existe una solución sencilla en este momento, sí que se están planteando algunas posibilidades a varios niveles. nginx Una primera solución que se ha dado es la de aplicar esta regla del nginx que limitaría la longitud de los parámetros a 1024 bytes. Hay que tener en cuenta que la longitud máxima es de más de 2600 bytes. Personalmente y teniendo en cuenta que la cantidad de scripts a cargar no debería ser muy elevada (25 scripts podrían tener una longitud de unos 350 bytes), reduciría el límite a 512. En cualquier caso habría que navegar por el sitio para definir en cada caso (y plantilla) qué es necesario. location ~* ^/wp-admin/load-(scripts|styles). php$ { if ( $query_string ~* "^. {512,}$" ) { return 444; } } Apache HTTPD En el caso particular de Apache HTTPD se plantea otra posible solución, que debe incluir el uso de la cookie de que un usuario ha estado navegando por el sitio web. RewriteEngine on RewriteCond %{HTTP_COOKIE} ! wordpress_logged_in_ RewriteRule /wp-admin/load-scripts. php - Carga de los datos (PHP) Otra posible solución que plantean en un fork de WordPress es cambiar la forma en la que se cargan los datos de este script. Script bash para Linux O la de ejecutar este script de Linux en la carpeta principal del WordPress. Script PHP De la misma forma que el paso anterior se ejecuta desde la línea de comandos de Linux, esta solución te plantea que subas el fichero a la carpeta raíz, la ejecutes (él hará cambios en los ficheros) y elimines el fichero. Reglas de ModSecurity Aunque siempre puedes aplicar una regla como esta a tu firewall. SecRule REQUEST_URI "@rx (? i:/wp-admin/load-scripts. php? . *? (load%5B%5D|load\|load%5B\]|load\*,){20,})" "id:1,msg:'Potential use of CVE-2018-6389',deny" --- Última revisión: 2 de octubre de 2021 Es posible que te hayan infectado, hackeado, atacado... cualquiera de estas opciones es posible si tu sitio tiene un agujero de seguridad por falta de actualización o por disponer activado o no una plantilla o plugin que ha sido mal desarrollada. Antes de empezar, te recomiendo pasarte por los Foros de Soporte de Seguridad, donde encontrarás problemas y soluciones de otros miembros de la comunidad, además de un interesante documento sobre limpiar un WordPress. Antes de nada Haz una copia de seguridad / backup. Primeros pasos Cuando tienes un problema de ataque, hackeo o simplemente la sospecha de que algo raro puede estar pasando, uno de los primeros pasos es el de bloquear el acceso a todo el mundo para que no pueda acceder. Puedes "cerrar la web" (ponerla en modo mantenimiento) si consideras que puede ser perjudicial para tus visitas, o simplemente hacer un cierre de la parte interior, impidiendo que otros usuarios hagan inicio de sesión. Una vez has cerrado el acceso, lo siguiente es proceder a cambiar las principales contraseñas del sitio. Cambiar las contraseñas de todos los administradores del WordPress y las del alojamiento / FTP, e incluso la de la base de datos. Si ha habido una fuga de datos sin duda alguien intentará acceder a ellos y lo principal es que si lo intenta no pueda. Una vez hemos hecho esto, lo siguiente es reinstalar WordPress. Podríamos plantearnos usar el botón de reinstalar que incluye la propia plataforma, pero en este caso, es mucho mejor hacer la subida directamente por FTP, de forma que tú te descargues WordPress y lo subas poco a poco. Actualizar todo El segundo paso es clave. Ya tienes actualizado el núcleo de WordPress, pero ¿tienes actualizado el resto de elementos? Lo primero es entrar en el panel de administración y actualizar todos los elementos que haya. Todos los plugins que no utilices (y estén desactivados), bórralos. Aún habiendo actualizado todo, deberías ir plugin a plugin y plantilla a plantilla buscando la página web de ese plugin (en el repositorio oficial o no) y verificar que la versión que tienes instalada es la misma versión que se indica como última. En el repositorio oficial es sencillo, pero si tienes plugins de sitios como Codecanyon o Themeforest deberías buscar la última versión de los mismos y descargarlas. Si los compraste hace tiempo y no tienes la última versión, hazlo. Pasar un antivirus Aquí podemos tratar de trabajar con varias opciones, una de ellas bastante complicada, que es la de pasar el antivirus sobre el servidor o mediante algún plugin o sistema. Por otro lado hay otra opción que suele ser más simple: usar el antivirus de tu ordenador. Lo primero es verificar que tienes un antivirus y comprobar que está actualizado a su última versión. Una vez hayas verificado esto deberías conectarte por FTP y descargarte todo tu sitio web. Según se vaya descargando el sitio se irá pasando el antivirus por lo que si hay algún virus o malware conocido el sistema lo detectará y tú serás capaz de poder eliminarlo del servidor igualmente. NOTA: Los virus que se ejecutan en los sitios web, en general, no son virus que afecten a tu ordenador, por lo que si vas con cuidado no debería ocurrir nada indeseado. Tras la descarga del sitio web, deberías descargarte también una copia de la base de datos. Por norma general tu alojamiento tendrá un panel del tipo phpMyAdmin con el que podrás hacer un Exportar de todo el sitio. Una vez más Haz una copia de seguridad / backup. No sobrescribas la anterior, guárdala junto a ella. Revisión del WordPress El siguiente paso es el de darse un "paseo" por el WordPress en busca de configuraciones o cosas raras que no deban estar ahí. Haz un repaso en las entradas y categorías para revisar que no encuentres ningún artículo que no deba estar ahí; lo mismo que con las páginas. En los medios revisa la galería para de un vistazo verificar que no haya imágenes, ficheros ZIP o similares que no te suenen. En las plantillas y plugins, una vez más, elimina aquellos que no utilices, y los que utilices confirma que están actualizados. Revisa todos los usuarios del sitio. En caso de tener dudas, obliga a que los usuarios tengan que acceder con un sistema de doble verificación. Incluso fuerza un cambio de contraseña y cambia los Security Keys en el wp-config. Aprovecha a revisar en el fichero wp-config que no haya ningún elemento que no creas que deba estar ahí. Confirma que los textos y configuraciones generales son las correctas. Regenera los enlaces permanentes. Revisión del servidor Es posible que habiendo revisado tu WordPress no hayas encontrado nada extraño, y es porque uno de los puntos frecuentes de ataque es el propio servidor, así que deberías darle un vistazo. En caso de no tener conocimientos de administración de sistemas, puedes buscar a uno, o pedirle a tu alojamiento que haga una revisión de algunos elementos. Para comenzar, de las versiones del sistema operativo, PHP, servidor web... de la misma manera que hay que actualizar WordPress, también hay que actualizar el sistema operativo (como con tu ordenador). Si no lo tienes ya, activa un certificado TLS, para navegar con HTTPS, y así la conexión entre tus visitas y el servidor será segura. Ahora que tenemos el servidor al día, vamos a revisar la relación entre el servidor y WordPress. Lo primero será revisar los permisos de acceso a los ficheros. Por mucho que te digan que has de usar 777, o que de las tres cifras la última no sea cero, no hagas caso. Si quieres proteger correctamente el sistema, el dueño, tú, ha de tener control completo sobre ellos (7xx en carpetas, 6xx en ficheros), el servidor web ha de tener permisos parciales (x5x en carpetas, x4x en ficheros) y el resto de usuarios del sistema no ha de tener acceso (xx0 en carpetas, xx0 en... --- Última revisión: 2 de octubre de 2021 Almacenar la información segura para saber quién está navegando por tu WordPress es importante y por eso lo es también saber dónde y cómo se guarda la información (y que esté segurizada). Para ello, en una instalación simple de WordPress, definiremos concretamente dónde se almacenarán las galletas (cookies) para que no sean tan fácilmente accesibles. Configuración Hash (COOKIEHASH) Esta constante indica de forma única tu sitio. Habitualmente se ejecuta la función siguiente si no está configurada en el . if ( ! defined( 'COOKIEHASH' ) ) { $siteurl = get_site_option( 'siteurl' ); if ( $siteurl ) define( 'COOKIEHASH', md5( $siteurl ) ); else define( 'COOKIEHASH', '' ); } Esto significa que por norma general nos encontraremos un MD5 de nuestra URL. Si queremos hacerla más segura, lo más recomendable es complicar el identificador. define( 'COOKIEHASH', 'qLk9K5wdF4SwcwbMRNWP3kwscBJqcWtYmTvA' ); NOTA: Cambia el código extraño por uno generado en este sitio. User (USER_COOKIE), Password (PASS_COOKIE), Authentication (AUTH_COOKIE), Secure Authentication (SECURE_AUTH_COOKIE), Logged In (LOGGED_IN_COOKIE) Estas cookies se generan en base a la cookie anterior, por lo que en principio no hay que configurarla nada. Su formato es el siguiente: if ( ! defined('USER_COOKIE') ) define('USER_COOKIE', 'wordpressuser_' . COOKIEHASH); if ( ! defined('PASS_COOKIE') ) define('PASS_COOKIE', 'wordpresspass_' . COOKIEHASH); if ( ! defined('AUTH_COOKIE') ) define('AUTH_COOKIE', 'wordpress_' . COOKIEHASH); if ( ! defined('SECURE_AUTH_COOKIE') ) define('SECURE_AUTH_COOKIE', 'wordpress_sec_' . COOKIEHASH); if ( ! defined('LOGGED_IN_COOKIE') ) define('LOGGED_IN_COOKIE', 'wordpress_logged_in_' . COOKIEHASH); Test (TEST_COOKIE) Esta cookie, como su nombre indica, es una cookie de pruebas, para verificar que hay WordPress. Es otra de las cookies que no requieren configuración, ya que se generan automáticamente. if ( ! defined('TEST_COOKIE') ) define('TEST_COOKIE', 'wordpress_test_cookie'); Path Path (COOKIEPATH) En esta cookie indicaremos el "path" a partir de cuál se aplican las cookies. Si por ejemplo tienes tu sitio alojado en la carpeta raíz del dominio (https://www. wpdanger. com/) el path sería "/", pero si está en una carpeta (https://www. wpdanger. com/blog/), sería el de la carpeta, "/blog/"; if ( ! defined('COOKIEPATH') ) define('COOKIEPATH', preg_replace('|https? ://+|i', '', get_option('home') . '/' ) ); De esta forma, si lo quieres aplicar tú manualmente, puedes hacerlo con la siguiente constante: define('COOKIEPATH', '/inicio/'); Site Path (SITECOOKIEPATH) Este caso es similar al anterior, aunque más concreto a dónde se encuentra la carpeta del . De esta forma, pondríamos la URL delante del panel de administración. if ( ! defined('SITECOOKIEPATH') ) define('SITECOOKIEPATH', preg_replace('|https? ://+|i', '', get_option('siteurl') . '/' ) ); De esta forma, si lo quieres aplicar tú manualmente, puedes hacerlo con la siguiente constante: define('SITECOOKIEPATH', '/'); Admin Path (ADMIN_COOKIE_PATH) Partiendo del punto anterior, tendremos en qué dirección se guarda el panel de administración. De esta forma si cambias tu dirección del panel debes cambiarlo aquí también. if ( ! defined('ADMIN_COOKIE_PATH') ) define( 'ADMIN_COOKIE_PATH', SITECOOKIEPATH . 'wp-admin' ); Por defecto, sería esto: define( 'ADMIN_COOKIE_PATH', '/wp-admin' ); Plugins Path (PLUGINS_COOKIE_PATH) Al igual que el caso anterior, si cambias la carpeta donde alojar las cookies, también deberás cambiar la de tus plugins... if ( ! defined('PLUGINS_COOKIE_PATH') ) define( 'PLUGINS_COOKIE_PATH', preg_replace('|https? ://+|i', '', WP_PLUGIN_URL) ); Por defecto, sería esto: define( 'PLUGINS_COOKIE_PATH', '/wp-content/plugins' ); Hostname Domain (COOKIE_DOMAIN) Esta cookie por defecto va en blanco, aunque la puedes forzar. Básicamente es sobre qué dominio (o mejor dicho, hostname) quiere cargar las cookies. if ( ! defined('COOKIE_DOMAIN') ) define('COOKIE_DOMAIN', false); Por defecto la puedes omitir o por ejemplo poner tu dominio: define('COOKIE_DOMAIN', 'www. wpsysadmin. com'); Con esto las cookies se establecerán en el dominio principal que corresponda y posteriormente se irán guardando por carpetas según quién las necesite. Los usuarios del panel de administración solo tendrán disponibles sus cookies cuando estén en el panel. Los plugins solo tendrán acceso a sus cookies... Un caso especial es de aquellas instalaciones con WordPress MultiSite que, en ese caso, por la posibilidad de tener varios hostname, es mejor que el sistema configure todo de forma automática; lo mejor es no incluir ninguna de estas líneas de código o dejar sus contenidos vacíos y que lo gestione automáticamente el sistema. En WordPress Multisite solo encontrarás las constantes COOKIEPATH, SITECOOKIEPATH, ADMIN_COOKIE_PATH y COOKIE_DOMAIN. --- Última revisión: 2 de octubre de 2021 TRACK y TRACE son dos métodos que vienen por defecto con Apache HTTPD y que se usan principalmente para análisis, pero estos métodos, usados en WordPress, pueden comprometer la seguridad del sitio ya que hay algunos ataques posibles de Cross Site Tracing (XST) y Cross Site Scripting (XSS) que podrían robar los datos de las cookies y alguna otra información del servidor web. Para desactivar estos métodos solo has de añadir estas líneas de código en el de la raíz del sitio. RewriteEngine on RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule . * - --- Última revisión: 2 de octubre de 2021 WordPress integra los Emoji desde hace muchas versiones, convirtiendo los iconos de texto en imagen. Pero este sistema implica algunos problemas de detección de versiones que, si no los utilizas en tus textos, no tiene mucho sentido dejar activos. Para desactivarlos puedes aplicar: --- Última revisión: 2 de octubre de 2021 Cuando hablamos de subir elementos multimedia a través del panel de administración solemos hacer referencia a imágenes, documentos y ficheros conocidos. Audio: M4A, MP3, OGG, WAV. Documentos: DOC/DOCX, ODT, PDF, PPT/PPTX/PPS/PPSX, PSD, XLS/XLSXImágenes: GIF, ICO, JPG/JPEG, PNG. Vídeo: 3GP/3G2, AVI, MOV, MP4/M4V, MPG, OGV, WMV. Esta propuesta en realidad va en contra de la seguridad, ya que lo que permite es todo lo contrario, que los administradores del sitio puedan subir cualquier tipo de fichero a través del panel; aun así, por determinadas necesidades, es posible que lo requieras activar en el fichero de configuración : define('ALLOW_UNFILTERED_UPLOADS', true); Otra opción es la de añadir extensiones a través del retoque de los MIME Types existentes, pudiendo añadir o eliminar los deseados. Para ello podemos añadir en el fichero de o creando un plugin específico: function wpdanger_mime_type( $mime_types ) { $mime_types = 'application/json'; // Añadir JSON $mime_types = 'image/svg+xml'; // Añadir SVG unset( $mime_types ); // Eliminar . GIF return $mime_types; } add_filter( 'upload_mimes', 'wpdanger_mime_type', 1, 1 ); --- Última revisión: 2 de octubre de 2021 Y si hacer copias de seguridad podríamos considerarlo seguridad pasiva, también podemos activar determinadas herramientas de seguridad activa que intenten evitar "lo más en tiempo real posible" ataques o cambios. Para llegar a este nivel podemos considerar dos frentes a tener en cuenta: bloquear ataques (firewall) y bloquear cambios de ficheros (malware). Firewall En el caso de los cortafuegos existen de dos tipos, los propios de software o los externos. En WordPress los más conocidos son los propios, que suelen funcionar mediante un plugin que va descargando una serie de reglas que bloquean los ataques. Esto hace que tu propio sitio web sea el que hace de cortafuegos, y en algunas ocasiones ha provocado que estos plugins tengan agujeros de seguridad, por lo que, aunque son soluciones interesantes, no son las mejores al 100%. Los más conocidos son el de Wordfence o el de Sucuri. Si quieres realmente estar seguro, lo mejor es poner una máquina por delante del sitio, de forma que cuando un usuario o atacante se conecte en realidad no sepa ni tu dirección IP. Estos Firewall externos también suelen ejercer de CDN. Uno de los más conocidos es el que tiene Cloudflare. Malware Para analizar cambios en el sistema puedes también utilizar algún plugin que haga comparaciones y análisis del contenido de los ficheros. Al igual que antes, los más conocidos son Wordfence y Sucuri. Para estos casos, lo más recomendable es dejar el sistema apagado y cuando sea necesario o se requiera, hacer el análisis. --- Última revisión: 2 de octubre de 2021 El fichero de configuración de WordPress esconde muchas funcionalidades que ayudan a mejorar la seguridad y rendimiento del sistema. ¿Conoces todas las posibilidades que te ofrece? NOTA: Existen artículos específicos para las constantes de seguridad de Cookies y de las Security Keys. Estos elementos no tienen porqué estar siempre en tu configuración. Simplemente has de tener en cuenta que existen y usarlos según tus necesidades. Por defecto, si no los añades, ellos ya incluyen ciertas características y configuraciones. Mantenimiento WordPress Cache (WP_CACHE) Para saber más sobre este elemento, por favor visita la página sobre Caché. Memory Limit (WP_MEMORY_LIMIT) Por defecto WordPress, en instalación simple, viene configurado para consumir un máximo de 40MB y en el caso de un MultiSite de 64MB; pero es posible que en alguna ocasión recibas algún mensaje del estilo a "Allowed memory size of xxxxxx bytes exhausted" debido al consumo de la plantilla o de plugins. En estos casos puedes modificar la cantidad de memoria máxima que puede utilizar cada carga. define( 'WP_MEMORY_LIMIT', '128M' ); Por norma general un máximo de 128 MB debería ser más que suficiente para funcionar. En caso de disponer de servidores muy potentes con mucha memoria RAM, y de tener alguna instalación complejas, como podría ser un bbPress, un WooCommerce o similar, podrías aumentarlo más. define( 'WP_MEMORY_LIMIT', '256M' ); Pasar de los 256 MB no sería una buena opción, ya que supondría que hay algún problema de fondo que está empeorando tu WordPress. Max Memory Limit (WP_MAX_MEMORY_LIMIT) En el caso del panel de administración, las tareas que se ejecutan pueden ser mucho más complejas y pesadas. Es por esto que en el caso interno, se puede aumentar la memoria a unos niveles distintos. define( 'WP_MAX_MEMORY_LIMIT', '256M' ); En general, aún siendo una instalación compleja, el panel de administración nunca debería sobrepasar la cifra de los 256 MB. Seguridad Disable Plugins and Themes Editors (DISALLOW_FILE_EDIT) Para saber más sobre este elemento, por favor visita la página sobre Edición de ficheros. Force SSL Admin (FORCE_SSL_ADMIN) Para saber más sobre este elemento, por favor visita la página sobre Certificado TLS. Force SSL Login (FORCE_SSL_LOGIN) Para saber más sobre este elemento, por favor visita la página sobre Certificado TLS. Disallow Unfiltered HTML (DISALLOW_UNFILTERED_HTML) Por defecto WordPress viene con una medida de seguridad elevada a la hora de añadir código HTML en entradas, comentarios y demás espacios. Este sistema, por ejemplo, evitaría la posibilidad de usar la etiqueta que podría afectar negativamente por ataques XSS. Aún así, se puede eliminar este filtro y que todos los usuarios de la plataforma tengan la posibilidad de incluir el código HTML que deseen. define( 'DISALLOW_UNFILTERED_HTML', true ); Allow Unfiltered uploads (ALLOW_UNFILTERED_UPLOADS) Para saber más sobre este elemento, por favor visita la página sobre Subir ficheros sin filtro. Block External Url (WP_HTTP_BLOCK_EXTERNAL) Para saber más sobre este elemento, por favor visita la página sobre Servidores externos. Manage Accessible Hosts (WP_ACCESSIBLE_HOSTS) Para saber más sobre este elemento, por favor visita la página sobre Servidores externos. Actualizaciones Disable Automatic Updates (AUTOMATIC_UPDATER_DISABLED) Para saber más sobre este elemento, por favor visita la página sobre Actualizaciones automáticas. Disable Core Updates (WP_AUTO_UPDATE_CORE) Para saber más sobre este elemento, por favor visita la página sobre Actualizaciones automáticas. Disable Plugins and Themes Install and Updates (DISALLOW_FILE_MODS) Para saber más sobre este elemento, por favor visita la página sobre Edición de ficheros. Updates Method (FS_METHOD, FTP_BASE, FTP_CONTENT_DIR, FTP_PLUGIN_DIR, FTP_PUBKEY, FTP_PRIKEY, FTP_USER, FTP_PASS, FTP_HOST, FTP_SSL) Por norma general WordPress sabe encontrar la opción para actualizarse él mismo, o los plugins y plantillas sin necesidad de tener que decirle cómo hacerlo. Pero en ocasiones hay instalaciones complejas o servidores en los que existe alguna limitación o configuración distinta a la habitual y por tanto WordPress pedirá los accesos para poder hacer los cambios necesarios. Si te encuentras en estos casos, para no tener que darle los accesos a nadie o tú mismo no tener que estar configurándolos cada vez que los pida, puedes incorporar los datos directamente al fichero de configuración. - FS_METHOD indica qué metodo se utilizará para realizar la actualización: "direct" (Direct File I/O del PHP), "ssh2" (SSH PHP Extension), "ftpext" (FTP PHP Extension for FTP Access) o "ftpsockets" (PHP Sockets Class for FTP Access). - FTP_BASE es la ruta absoluta de la instalación del WordPress. - FTP_CONTENT_DIR es la ruta absoluta de la carpeta . - FTP_PLUGIN_DIR es la ruta absoluta de la carpeta de los plugins. - FTP_PUBKEY es la ruta absoluta de la carpeta de la clave pública SSH. - FTP_PRIKEY es la ruta absoluta de la carpeta de la clave privada SSH. - FTP_USER es el usuario del FTP o SSH. - FTP_PASS es la contraseña para el usuario. Si usas clave SSH se puede omitir. - FTP_HOST es la combinación hostname:puerto de acceso al serviro (FTP o SSH). El puerto FTP por defecto es 21 y en SSH es 22. - FTP_SSL (true / false) según la conexión soporte SSL. Esto no es para SFTP. define( 'FS_METHOD', 'ftpext' ); define( 'FTP_BASE', '/path/to/wordpress/' ); define( 'FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/' ); define( 'FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/' ); define( 'FTP_PUBKEY', '/home/username/. ssh/id_rsa. pub' ); define( 'FTP_PRIKEY', '/home/username/. ssh/id_rsa' ); define( 'FTP_USER', 'username' ); define( 'FTP_PASS', 'password' ); define( 'FTP_HOST', 'ftp. example. org' ); define( 'FTP_SSL', false ); Entradas Post Auto save interval (AUTOSAVE_INTERVAL) Por defecto WordPress salva automáticamente los contenidos que se van escribiendo en una entrada cada 60 segundos. Si eres de los que escribe lento, puedes aumentar el tiempo, o si eres de los que tiene miedo a perder la última frase puedes reducirlo. define( 'AUTOSAVE_INTERVAL', 30 ); // segundos Empty Trash Days (EMPTY_TRASH_DAYS) Para saber más sobre este elemento, por favor visita la página sobre Copias antiguas. Disable Post Revisions and Revisions Max Count (WP_POST_REVISIONS) Para saber más sobre este elemento, por favor visita la página sobre Copias antiguas. Localización / Idiomas WordPress Language (WPLANG) ¿Cuál es el idioma por defecto de tu instalación WordPress? Aunque actualmente se puede configurar desde el panel de administración, puedes forzar el idioma... --- Última revisión: 2 de octubre de 2021 Cuando hablamos de seguridad hay que tener un plan de prevención para poder recuperar los datos (mediante copias de seguridad y otros sistemas) pero también hay que saber qué ha ocurrido para llegar a ese punto. En este momento entra en juego el sistema auditor. Estos sistemas auditores crean un registro de todos los cambios que se producen en el sitio, cuándo y quién los realiza. De esta forma podemos analizar claramente todo aquel que entra en el panel de administración qué cambios se han realizado en qué zonas del sitio. Existen varios plugins que realizan esta tarea, cada uno con mayor o menor configuración y opciones. Activity LogSimple HistoryStreamUser Activity LogWP Activity LogWP Document Revisions --- Última revisión: 2 de octubre de 2021 Una de las formas más rápida para verificar si un sitio WordPress ha sido comprometido es el uso de alguna herramienta que valide el código de una forma poco costosa. Para ello habitualmente se utilizan sistemas como checksum que básicamente comparan fichero a fichero mediante un hash (código único) que permite comparar tus ficheros con los que se pueden descargar originalmente. WP-CLI Quizá la forma más sencilla de verificar si ha habido alguna modificación en tu instalación de WordPress es la de utilizar WP-CLI. Actualmente se puede verificar el núcleo y los plugins. wp core verify-checksums --locale=es_ES --version=4. 9. 1 wp plugin verify-checksums --all Plugins Existen varios plugins que realizan la verificación checksum de los contenidos. Checksum Verifier DIY (hazlo tú mismo) Aunque existen sistemas ya preparados, quizá te interese hacerlo tú mismo. Para ello puedes crearte un fichero PHP que ejecute y muestre los análisis. Puedes crear un fichero en la raíz de tu instalación con el siguiente contenido. Necesitarás disponer de al menos PHP 5. 6 para poder ejecutar este sistema. define('ABSPATH', '. /'); if ( defined( 'ABSPATH' ) ) { include( ABSPATH . 'wp-includes/version. php' ); $wp_locale = isset( $wp_local_package ) ? $wp_local_package : 'en_US'; $apiurl = 'https://api. wordpress. org/core/checksums/1. 0/? version=' . $wp_version . '&locale=' . $wp_locale; $json = json_decode ( file_get_contents ( $apiurl ) ); $checksums = $json->checksums; foreach( $checksums as $file => $checksum ) { $file_path = ABSPATH . $file; if ( file_exists( $file_path ) ) { if ( md5_file ($file_path) ! == $checksum ) { echo '¡Checksum de " . $file_path . " no es coincidente! '; } } } } --- Última revisión: 2 de octubre de 2021 WP-CLI Usar WP-CLI para el mantenimiento de WordPress Hacer mantenimiento de un sitio WordPress no suele ser complejo, pero a veces puede ser complejo gestionar muchos sitios en un mismo servidor. WP-CLI como herramienta de análisis Con extensiones como WP-CLI profile o WP-CLI doctor podremos analizar cuellos de botella y realizar una pequeña auditoría automática de la situación de nuestros WordPerss. Copias de Seguridad Copia de seguridad para WordPress WordPress no incorpora por defecto ningún tipo de sistema de copia de seguridad automática, por lo que has de depender de una herramienta de terceros para ello. Monitorización Monitorización de WordPress Tener herramientas de monitorización va a permitirte comprobar si el sitio funciona correctamente, a muchos niveles distintos. Herramientas Herramientas de mantenimiento de WordPress externas En el caso de tener que gestionar muchos WordPress, puedes hacer uso de algunos sistemas externos. --- Última revisión: 2 de octubre de 2021 Aquí vas a encontrar distintos elementos relacionados con la Seguridad de WordPress. Hay elementos generales, al alcance de todo el mundo, y otros que requieren conocimientos técnicos o de sistemas. General Aprende elementos generales y básicos sobre la Seguridad de WordPress, además de las obligaciones que tienes como responsable de un sitio web con WordPress. Comenzando con la Seguridad de WordPressWordPress es un sistema seguro, de código abierto y mantenido por la comunidad lo que lo hace fácilmente actualizable en cuanto se detecta cualquier problema. Aplica el Sentido Común en tu sitio WordPressDicen que el sentido común es el menos común de los sentidos, y por eso te pido un poco de él. Tipos de ataque sobre WordPressExisten infinidad de posibles ataques a tu sitio, ya que existen infinidad de posibles puntos de acceso a los mismos, ya sean por el propio WordPress, pero también por el servidor, los usuarios, comentarios, códigos de script, etcétera. Contraseñas seguras para WordPress¿Qué podemos considerar hoy una contraseña segura? Pues probablemente una de 24 caracteres alfanuméricos y con símbolos. A partir de ahí, lo que queramos. GDPR (General Data Protection Regulation) y WordPressEntre otros detalles, esta legislación vendría a decirte que has de recoger información sobre algunos de los elementos que WordPress proporciona en tu sitio, como por ejemplo el registro de usuarios, comentarios, datos de contactos de los formularios, datos sobre analítica, etcétera. Especial Aquí tienes algunos materiales especiales sobre seguridad de WordPress y que, en principio, pueden aplicar muchos elementos de forma conjunta. Limpiar un hackeoEs posible que te hayan infectado, hackeado, atacado... cualquiera de estas opciones es posible si tu sitio tiene un agujero de seguridad por falta de actualización o por una plantilla o plugin. Hosting Los servidores de alojamiento web para WordPress permiten algunos elementos específicos de seguridad para WordPress, además de los sistemas de seguridad generales. Seguridad del alojamiento web de WordPressCuando hablamos de seguridad, alojamiento web y WordPress, la única conclusión a la que se puede llegar es: tu proveedor de alojamiento web ha de ofrecerte una plataforma segura. Versiones mínimas para que WordPress funcione¿Cuáles son las versiones mínimas requeridas para que WordPress funcione correctamente? Instalar un certificado TLS / SSL en WordPressCuando navegamos por Internet queremos hacerlo de forma segura. Para ello deberíamos navegar por sitios de confianza con la barrita verde o el candado. Compatibilidad de PHP en WordPressSi WordPress tiene un punto importante es el de PHP, y esto es lo que más se está potenciando últimamente (por no decir casi desde siempre). Permisos de ficheros en WordPressCuando se realiza una instalación nueva de WordPress, un elemento a tener presente es quién es el propietario de los ficheros del sistema y qué permisos tienen para poderse leer o escribir. Bloquear PHP en uploads en WordPressEn principio, cuando subes ficheros mediante el panel de Multimedia sólo se permiten elementos como imágenes, ficheros de texto y similares, pero no se permiten ficheros PHP (el lenguaje de programación con el que se hace WordPress) entre otros. Servicio externo de correoEl correo basura (spam), esa lacra de Internet que muchos sufrimos todos los días en nuestra bandeja de entrada, es algo que debemos evitar que ocurra debido a nuestro sitio web. Desactivar el HTTP TRACE / TRACKTRACK y TRACE son dos métodos que se usan principalmente para análisis, pero estos métodos, usados en WordPress, pueden comprometer la seguridad del sitio. . htaccess para Apache y LiteSpeedSi utilizas Apache HTTPD o LiteSpeed, configura el fichero . htaccess de la raíz de la configuración de tu WordPress de una manera compleja (más de la que viene por defecto). . conf para nginxSi utilizas nginx, configura el fichero . conf de la configuración de tu WordPress de una manera compleja (más de la que viene por defecto). Base de Datos Podemos aplicar algunos pequeños cambios para cambiar configuraciones por defecto de WordPress y complicar posibles accesos a la información. Limitar el acceso a base de datos de WordPressCon respecto a la base de datos (MySQL, MariaDB... ) hay pocas cosas a hacer propiamente dichas desde el punto de vista de WordPress, pero sí que se pueden poner algunas complicaciones para aquellos que intenten acceder a ella. Evitar la numeración de usuarios en WordPressCuando se crean las tablas de WordPress, todos los sistemas de auto incremento comienzan en la cifra número 1. Eliminar copias antiguas de entradas en WordPressUna vez más volvemos a temas que afectan principalmente a rendimiento y, en este caso, es el de ir vaciando la base de datos de copias antiguas de entradas o páginas. WordPress Aunque WordPress es muy seguro de por sí, existen ciertas posible configuraciones que se pueden aplicar directamente sobre WordPress. WP-Config: la configuración de WordPressEl fichero de configuración de WordPress esconde muchas funcionalidades que ayudan a mejorar la seguridad y rendimiento del sistema. ¿Conoces todas las posibilidades que te ofrece? Las Security Keys de WordPressDesde la versión 2. 6. 0 de WordPress existen unos pequeños algoritmos para encriptar los datos guardados en cookies y que sea más complejo saber quién eres o cómo acceder a tu usuario. Seguridad en las cookies de WordPressEn una instalación simple de WordPress, definiremos concretamente dónde se almacenarán las galletas (cookies) para que no sean tan fácilmente accesibles. Eliminar cabeceras y metas de WordPressComo la mayor parte de gestores de contenidos, WordPress se identifica claramente y ofrece determinados servicios que luego usaremos (o no). Unificar CSS y JavaScript en WordPressEn general los ficheros de estilo (CSS) y los de scripting (JavaScript) incluyen cierta información como las versiones, ya sea en su nombre, en el interior, en algunos comentarios... Ocultar la versión de WordPressLa versión de WordPress está bastante disponible, ya que forma parte del código del sitio, por lo que hay que ocultarla de varias formas en varios lugares. Configurar caché en WordPressUna vez más, lo que probablemente sea una recomendación general y muy útil, como la de activar las caché de WordPress, se convierte en un elemento que ayuda a... --- Última revisión: 2 de octubre de 2021 Aprende elementos generales y básicos sobre la Seguridad de WordPress, además de las obligaciones que tienes como responsable de un sitio web con WordPress. ComenzandoSentido ComúnAtaquesContraseñasGDPR (General Data Protection Regulation) --- Aquí tienes algunos materiales especiales sobre seguridad de WordPress y que, en principio, pueden aplicar muchos elementos de forma conjunta. Limpiar un hackeo --- Última revisión: 2 de octubre de 2021 Los servidores de alojamiento web para WordPress permiten algunos elementos específicos de seguridad para WordPress, además de los sistemas de seguridad generales. Alojamiento WebVersionesCertificado TLSPHPPermisos de ficherosBloquear PHP en uploadsServicio externo de correoDesactivar HTTP TRACE / TRACK. htaccess (Apache). conf (nginx) --- Última revisión: 2 de octubre de 2021 Podemos aplicar algunos pequeños cambios para cambiar configuraciones por defecto de WordPress y complicar posibles accesos a la información. Permisos a base de datosNumeración de los usuariosCopias antiguas --- Última revisión: 2 de octubre de 2021 Aunque WordPress es muy seguro de por sí, existen ciertas posible configuraciones que se pueden aplicar directamente sobre WordPress. wp-config. phpSecurity KeysCookiesCabeceras inconvenientesUnificar CSS y JavaScriptOcultar la versión de WordPressCachéCarpetas por defectoPost instalaciónEdición de ficherosURL del sitioServidores externosXML-RPCAcceso a wp-adminActualizaciones automáticasUsuariosLimpieza de multimediarobots. txtPlantilla por defectoEmojiSubir ficheros sin filtro --- Última revisión: 2 de octubre de 2021 A parte de las mejoras que se pueden realizar sobre el propio WordPress, también podemos trabajar en la aplicación de mejoras que aplican elementos de seguridad proactiva. Anti SpamAnaliza tus enlacesCopias de seguridadFirewall / WAFChecksumHerramientas para WebmastersCDNLicenciasAuditor --- Última revisión: 2 de octubre de 2021 Existen algunos elementos desde plugins y themes que permiten ayudar a mejorar la seguridad de los distintos elementos añadidos de WordPress. Versión mínima de PHP --- Última revisión: 2 de octubre de 2021 Existen algunos problemas de seguridad con WordPress que, aunque quizá se hayan definido en que no son problemáticos, pueden requerir una pequeña corrección. Mitigar el CVE-2018-6389 --- Última revisión: 2 de octubre de 2021 Cuando hablamos de seguridad, alojamiento web y WordPress, la única conclusión a la que se puede llegar es: tu proveedor de alojamiento web ha de ofrecerte una plataforma segura. Existen muchos tipos de alojamiento web, desde hosting compartido, gestionado, -llámalo cloud, máquinas virtuales... - hasta el otro extremo en el que tienes hosting dedicado, auto gestionado, -llámalo VPS, Amazon... -. Las principales preguntas que has de hacerte al elegir un alojamiento son qué versiones de sistema operativo van a ofrecerte, si son actualizables a versiones más nuevas, quién se va a encargar de gestionar las máquinas. Si para tu proyecto dispones de un administrador de sistemas, o simplemente tu proyecto se puede considerar mediano o grande, lo mejor es disponer de un alojamiento dedicado, gestionado por ti mismo, en el que básicamente dediques un 3% de la facturación a ello. Esta es una regla sencilla pero que ayuda a poder plantear una idea base de lo que necesitas invertir en alojamiento web. Por otro lado, y partiendo de esta base, existen muchos alojamientos web que ofrecen servicios especializados para WordPress. El hecho de que tu proveedor conozca en profundidad el software que vas a utilizar te permitirá disponer de un servicio que, en caso de generar problemas, pueda solventarse con la simbiosis entre software y hardware. Tu alojamiento web es como la tienda física de tu negocio. No es lo mismo tener tu tienda física en el centro de una ciudad o en un centro comercial que en las afueras. Cada uno de estos lugares tienen sus elementos a favor y sus inconvenientes. Elige correctamente tu alojamiento web ya que influirá en gran medida en la seguridad de tu sitio. Mantén tu reloj en hora Estar al día con la hora de tu servidor y de tu sitio web es importante por muchas razones. Por un lado, porque si hay que revisar "logs", saber a qué hora exacta ocurren las cosas es importante. De la misma forma si usas herramientas de verificación es posible que sincronicen los datos de tu sitio web con los de tu móvil (por ejemplo). Recuerda que los servidores es mejor que siempre estén configurados en hora UTC, y luego podrás configurar tu WordPress con el huso horario que quieras. --- Última revisión: 2 de octubre de 2021 ¿Cuáles son las versiones mínimas requeridas para que WordPress funcione correctamente? En principio WordPress funciona con MySQL, PHP y un servidor web, lo que deja un margen muy amplio para funcionar, aunque las configuraciones más habituales son la de Linux, nginx o Apache, MySQL y PHP. Sistema Operativo En cuanto a sistemas operativos WordPress funciona en cualquier plataforma que soporte el resto de software necesario (base de datos y lenguaje de programación). Los sistemas operativos más habituales son CentOS y Ubuntu. En el caso de elegir este último, lo más recomendable es usar una versión LTS (Long Term Support) (con soporte de larga duración) de forma que durante varios años no tendrás que preocuparte de incompatibilidades. Una lista de versiones mínimas recomendadas es: NOTA: Es recomendable usar versiones estables y mantenidas de los sistemas operativos. Sistema OperativoVersiónCentOS8 / 7Debian11Fedora35 / 34FreeBSD13. 0 / 12. 2Ubuntu20 / 18 / 16Esta tabla está generada con fecha 2021-10-02 En cualquier caso, hay que utilizar siempre sistema operativos compatibles con 64bits (todos los anteriores le dan soporte) aunque dependerá mucho de la infraestructura de servidores que se vaya a utilizar. Servidor Web En cuanto a servidores web, existen varios aunque los más conocidos son Apache HTTPD y nginx. Ambos tienen mucha documentación de configuraciones para WordPress y son los que más compatibilidad disponen. Una lista de versiones mínimas recomendadas es: NOTA: Es recomendable usar versiones estables y mantenidas de los servidores web. Servidor WebVersiónApache HTTPD2. 4nginx1. 21 / 1. 20OpenLiteSpeed1. 7 / 1. 6 / 1. 5 / 1. 4LiteSpeed6. 0 / 5. 4 / 5. 3Esta tabla está generada con fecha 2021-10-02 Base de Datos A la hora de trabajar con bases de datos podemos disponer de muchas configuraciones. Por norma general trabajaremos en un sistema monolítico (no distribuido) aunque se puede escalar la base de datos de la manera que sea necesaria. En este caso será algo transparente para WordPress por lo que la decisión de la escalabilidad será del administrador de sistemas. Aunque existen diferencias entre las distintas distribuciones de bases de datos, en general para WordPress es bastante indiferente trabajar con unas u otras. Una lista de versiones mínimas recomendadas es: NOTA: Es recomendable usar versiones estables y mantenidas de las bases de datos. Base de DatosVersiónMariaDB Server10. 6 / 10. 5 / 10. 4 / 10. 3 / 10. 2MySQL Community Server8. 0Percona Server for MySQL8. 0Esta tabla está generada con fecha 2021-10-02 PHP Uno de los puntos donde WordPress tiene mucho recorrido es el PHP y es que históricamente se ha sido muy flexible con el uso de este lenguaje y su compatibilidad con versiones anteriores, pero por el lanzamiento de nuevas versiones y con grandes mejoras en la encriptación y seguridad, lo más recomendable es usar la última versión estable de PHP. NOTA: Es recomendable usar versiones estables y mantenidas de PHP. Lenguaje de ProgramaciónVersiónPHP8. 0 / 7. 4 / 7. 3Esta tabla está generada con fecha 2021-10-02 Certificados TLS (SSL) Obviamente, WordPress funciona vía web, y por tanto funciona sobre HTTP, pero hoy en día es básico disponer de un sitio con HTTPS (Hypertext Transfer Protocol Secure) y esto implica utilizar un certificado de cifrado. En este caso si nos ceñimos a temas de seguridad concretos la única opción es la de usar un certificado TLS 1. 2 o TLS 1. 3. Para ello puedes comprar certificados de cualquier tipo, o utilizar los certificados de Let's Encrypt. NOTA: Es recomendable usar versiones estables y mantenidas de TLS. Certificado de EncriptaciónVersiónTLS1. 3 / 1. 2Esta tabla está generada con fecha 2020-11-21 En la página de WordPress tienes unos requerimientos mínimos necesarios para funcionar correctamente. --- Última revisión: 2 de octubre de 2021 Si WordPress tiene un punto importante es el de PHP, y esto es lo que más se está potenciando últimamente (por no decir casi desde siempre). Y es por esto que muchos de los proyectos internos que se están desarrollando alrededor de WordPress como Project Tide o Servehappy. Ocultar la versión Sin duda lo primero que hemos de hacer es ocultar la versión de PHP para que no sea pública desde las peticiones del servidor web. Para ello, deberemos configurar el fichero para que la línea de visualización de la versión no aparezca. expose_php = Off Ocultar los errores De la misma manera que ocultamos la versión de PHP, también deberemos asegurarnos que no mostramos posibles errores de ejecución del propio PHP. Esto puede generar la "pantalla blanca de la muerte" debido a que si algo falla, no podremos ver nada y en caso de necesitarlo, se deberán activar las herramientas que el propio WordPress trae para hacer debug. display_errors = Off Compatibilidad PHP Tanto si eres desarrollador como simplemente usuario, has de estar encima de qué versión usar de PHP. Es por esto que es muy recomendable usar como versión mínima la versión 7. 0, aunque como versión recomendada la versión 7. 2. A partir de aquí ¿cómo saber si los plugins o plantillas que tienes son compatibles con las versiones recomendadas? Pues para ello lo mejor es utilizar el plugin WP Compatibility Checker. Con este plugin obtendrás de forma resumida si los plugins son compatibles, y si no lo son, qué deberían de mejorarse o cambiarse. Al instalarlo vas a poder elegir qué versión analizar y sus resultados. WP-CLI Además, un detalle muy interesante es que se puede hacer este análisis de todos los plugins / plantillas o de sólo los activos vía WP-CLI. wp phpcompat {version} {version} PHP version to test. Whether to scan only active plugins and themes or all of them. default: active options: - active - all Integración con Plugins En los últimos tiempos WordPress ha añadido un campo que indica la versión mínima de PHP necesaria para que funcionen algunos elementos (por ejemplo, los plugins). === Plugin Name === Contributors: (this should be a list of wordpress. org userid’s) Donate link: http://example. com/ Tags: comments, spam Requires at least: 4. 6 Tested up to: 4. 8 Requires PHP: 5. 6 Stable tag: 4. 3 License: GPLv2 or later License URI: https://www. gnu. org/licenses/gpl-2. 0. html --- Última revisión: 2 de octubre de 2021 Mantener WordPress al día es la clave para evitar problemas de seguridad. WordPress es un sistema seguro en su core, pero las ampliaciones por plugins o plantillas que no se mantienen al día según van apareciendo nuevas versiones o mejoras son lo que pueden provocar problemas. Por defecto, WordPress se actualiza automáticamente y por defecto con versiones PATCH (según el Semantic Versioning). Esto significa que las versiones de seguridad se corrigen automáticamente. Aún así, esto no es ninguna solución y es muy útil configurar el sistema para que todo fluya. A la hora de tomar la decisión de si actualizar o no, la pregunta habitual es ¿tengo un WordPress complejo o sencillo? Un WordPress complejo es aquel que tiene plugins complejos (como WooCommerce) o críticos en cuanto a negocio. Auto-Actualizaciones WordPress a partir de su versión 5. 6 incluye un sistema de auto-actualizaciones a todos los niveles, incluido el núcleo, plugins, themes y traducciones. Desde la sección del menú Actualizaciones puedes gestionar la configuración del núcleo y traducciones, en la sección de plugins puedes activar sus actualizaciones automáticas, e igualmente con los themes. Actualizaciones del núcleo Actualización del núcleo 100% automática // wp-config. php define('WP_AUTO_UPDATE_CORE', true); Actualización del núcleo sólo de versiones menores // wp-config. php define('WP_AUTO_UPDATE_CORE’, 'minor'); Deshabilitar actualizaciones automáticas // wp-config. php define('AUTOMATIC_UPDATER_DISABLED', true); Mantén actualizado todo WordPress Si quieres mantener al día con las últimas versiones de todos lo que está en el repositorio oficial de WordPress (o aquellas plantillas y plugins que tengan un sistema de actualización automática) puedes forzarlo mediante unos filtros. Para evitar dependencias de plantillas o de otras combinaciones, lo mejor es subir este código como un plugin "mu" (must-use). defined('ABSPATH') or die('Bye bye! '); add_filter('auto_update_core', '__return_true'); add_filter('auto_update_plugin', '__return_true'); add_filter('auto_update_theme', '__return_true'); add_filter('auto_update_translation', '__return_true'); add_filter('auto_core_update_send_email', '__return_true'); Instrucciones paso a paso Crea el plugin o descárgalo ya creado (descomprime el fichero ZIP). Accede por FTP a la carpeta . Si no tienes esta carpeta, créala. Sube por FTP el fichero a la carpeta . Cuando entres en el panel de administración de tu WordPress, en la zona de Plugins tendrás una sección nueva de plugins Imprescindibles donde aparecerá. Recuerda que al ser Imprescindible no podrás activarlo ni desactivarlo. Mantén desactualizado todo WordPress En algunas instalaciones complejas, sobre todo aquellas en las que hay que vigilar que todo esté funcionando siempre, como pueden ser sitios de alta disponibilidad o de comercio electrónico, que usan plugins complejos como puede ser WooCommerce, en ocasiones es mejor organizarse una agenda de actualizaciones (por ejemplo un día a la semana hacer las actualizaciones) y haberlas probado previamente en un estado de staging. En estos casos lo mejor es impedir que WordPress se actualice, y para ello hemos de bloquear cualquier tipo de actualización automática. Para evitar dependencias de plantillas o de otras combinaciones, lo mejor es subir este código como un plugin "mu" (must-use). defined('ABSPATH') or die('Bye bye! '); add_filter('auto_update_core', '__return_false'); add_filter('auto_update_plugin', '__return_false'); add_filter('auto_update_theme', '__return_false'); add_filter('auto_update_translation', '__return_false'); add_filter('auto_core_update_send_email', '__return_false'); Instrucciones paso a paso Crea el plugin o descárgalo ya creado (descomprime el fichero ZIP). Accede por FTP a la carpeta . Si no tienes esta carpeta, créala. Sube por FTP el fichero a la carpeta . Cuando entres en el panel de administración de tu WordPress, en la zona de Plugins tendrás una sección nueva de plugins Imprescindibles donde aparecerá. Recuerda que al ser Imprescindible no podrás activarlo ni desactivarlo. Recuperar la versión anterior de un plugin o plantilla En algunas ocasiones es posible que la actualización de un plugin o plantilla no sea lo esperado. En estos casos (sobre todo en versiones menores, ya que las mayores suelen implicar cambios que dificultan el volver atrás) puede ser muy útil el uso de herramientas como WP Rollback. ¿Cuándo se actualizó ese complemento o plantilla? Está muy bien actualizar los complementos (plugins) o las plantillas (themes) pero ¿por qué instalas un complemento que hace más de un año que no se actualiza? Está claro que hay plugins que seguramente por su funcionalidad no requieren de grandes cambios, pero simplemente por mantener las fechas y los datos de testeo actualizados, cualquier desarrollador de un plugin o theme debería actualizar los datos. Y es que todos los complementos llevan interiormente un dato que debería estar al día: versión "hasta la que se ha probado". Si van apareciendo versiones y versiones de WordPress y el programador del plugin no va probando en esas nuevas versiones su funcionamiento ¿quién lo va a hacer? --- Última revisión: 2 de octubre de 2021 WordPress es un sistema seguro, de código abierto y mantenido por la comunidad lo que lo hace fácilmente actualizable en cuanto se detecta cualquier problema. Y es que WordPress es un sistema compuesto por muchos elementos, algunos desarrollados por terceros, que hay que ir actualizando y manteniendo. En este documento se van a dar soluciones sencillas (aunque a veces complejas de implementar) que han de servir de base para tu configuración y mantenimiento. Los plugins, plantillas o soluciones que se dan te han de servir de guía por lo que, en la mayoría de casos, te recomendamos contactar con un Administrador de Sistemas (SysAdmin) que ayude con las configuraciones más complejas. IMPORTANTE: Si no sabes lo que haces, es mejor que no toques. --- Última revisión: 2 de octubre de 2021 Existen infinidad de posibles ataques a tu sitio, ya que existen infinidad de posibles puntos de acceso a los mismos, ya sean por el propio WordPress, pero también por el servidor, los usuarios, comentarios, códigos de script, etcétera. Algunos de los más habituales pueden ser estos: Authentication Bypass: Agujero de seguridad que permite saltarse el formulario de acceso y acceder al sitio. Brute Force: Se intenta iniciar sesión adivinando el nombre de usuario y la contraseña de la cuenta de administrador (o de un usuario). Cross-Site Request Forgery (CSRF): El código se introduce y ejecuta desde la URL. Cross-site Scripting (XSS): Se puede inyectar código en un sitio, normalmente a través de un campo de formulario. Denial of Service (DoS): Un sitio se cae debido a un ataque constante de tráfico que suele proceder de una red de máquinas controladas. Path Traversal: Posibilidad de listar los directorios de un sitio y ejecutar comandos fuera del directorio raíz del servidor. Distributed Denial of Service (DDoS): Similar a un ataque DoS, excepto que las redes de máquinas suelen haber sido infectadas. File Upload: Se puede subir un fichero con código malicioso en un servidor sin restricciones. Full Path Disclosure (FPD): Se expone la ruta de acceso a la carpeta raíz del sitio; habitualmente es debido a que están activos los mensajes de error que las muestran. Local File Inclusion (LFI): Un atacante es capaz de controlar qué archivo se ejecuta en una hora programada que fue configurada anteriormente. Malware: Un sitio o programa malintencionado con el propósito de infectar al usuario u otra máquina. Open Redirect: El sitio redirige a otro debido a alguna vulnerabilidad, a menudo un sitio de spam o de suplantación de identidad. Phishing (Identity Theft): Un sitio que se parece a otro conocido y de confianza, pero que se utiliza para recopilar credenciales de inicio de sesión, números de tarjetas de crédito, etcétera, engañando al usuario. Remote Code Execution (RCE): Capacidad de ejecutar código en un sitio desde una máquina diferente. Remote File Inclusion (RFI): Posibilidad de ejecutar un script externo en un sitio al que se suele cargar malware, desde un sitio diferente. Security Bypass: Similar al Authentication Bypass, pero en este caso permite saltarse algún sistema de seguridad establecido. Server-side Request Forgery (SSRF): Toma de control de un servidor, ya sea parcial o total, para obligarlo a ejecutar peticiones de forma remota. SQL Injection (SQLI): Se produce cuando consultas SQL se pueden introducir y ejecutar desde la URL de un sitio. User Enumeration: Posibilidad de encontrar la lista de usuarios de un sitio desde la zona pública, para posteriormente realizar un ataque de Brute Force. XML External Entity (XXE): Un fichero XML que por la generación de errores deja expuesto algún tipo de ruta, mensaje o acceso a información confidencial. --- Última revisión: 2 de octubre de 2021 Cuando se realiza una instalación nueva de WordPress, un elemento a tener presente es quién es el propietario de los ficheros del sistema y qué permisos tienen para poderse leer o escribir. Esto es importante porque en momentos de un posible hackeo se podrán extender los problemas más o menos. Lo primero es asegurarse qué usuario va a ser el que acceda a los ficheros y a qué grupo pertenece. Por norma general los sistemas vienen configurados para Apache HTTPD o nginx, por lo que podemos configurarlo para ellos. Se puede ejecutar este comando por SSH desde la carpeta de instalación del WordPress. En Apache HTTPD: chown -R apache:apache . / En nginx: chown -R www-data:www-data . / Posteriormente hay que dar los permisos de correspondientes a los ficheros. En general daremos permisos 755 a las carpetas, y 644 a los ficheros. find /var/www/html/ -type d -exec chmod 755 {} \; find /var/www/html/ -type f -exec chmod 644 {} \; Si el sistema está bien configurado, podría ser un poco más agresivo y bloquear aún más accesos externos de usuarios indeseados. En este caso dejaremos siempre la última de las tres cifras a cero. En la medida de lo posible esta es la mejor opción y más segura. find /var/www/html/ -type d -exec chmod 750 {} \; find /var/www/html/ -type f -exec chmod 640 {} \; Una vez hayamos dado estos permisos a todo el WordPress, haremos un par de excepciones con dos ficheros muy concretos: el y el . El primero de ellos hemos de dejar que el sistema sea capaz de leerlo, pero ya está, nadie más debería cambiar o acceder. chmod 600 wp-config. php Si queremos ser algo más agresivos y que ni el propio sistema sea capaz de modificarlo (lo mejor es que ningún fichero lo modifique), podemos ejecutar el comando: chmod 400 wp-config. php En el primer caso el fichero podría leerse y escribirse; en el segundo sólo leerse. Esto podría hacer que, si tu WordPress necesita hacer algún cambio en el fichero, no se pueda llegar a aplicar y lo tengas que modificar manualmente. El segundo es un fichero que ofrece una pequeña situación con la seguridad, la versión del WordPress. Es el fichero más sencillo para detectarla y no aporta nada más al sitio, por lo que bloquearemos su lectura, dejando sólo que se pueda escribir cuando haya actualizaciones. chmod 200 readme. html Aunque si queremos ponernos en modo más agresivo, este fichero no debería ser accesible para nada, por lo que podemos quitarle todos los permisos. chmod 000 readme. html Para finalizar, de la misma forma que hemos cambiado los permisos en los ficheros, vamos a bloquear su acceso de forma pública por los usuarios web. Así, el sistema será capaz de leerlos o actualizarlos, pero no serán navegables. En Apache HTTPD (dentro del fichero . htaccess): deny from all deny from all deny from all En nginx (dentro del fichero de configuración del sitio): location ~ . php$ { location ~ wp-config { deny all; } location ~ /xmlrpc. php { limit_except POST { deny all; } } } location ~* readme. (html|txt) { deny all; } location ~* ^license. txt { deny all; } Para acabar, un detalle que puede venir de serie activo en los servidores Apache HTTPD es el listado de los contenidos de los directorios. Para evitar esto, y que no se muestren los ficheros de algunas carpetas como la de , debemos desactivar una opción en el . htaccess. En Apache HTTPD (dentro del fichero . htaccess): Options -Indexes --- Última revisión: 2 de octubre de 2021 Esta configuración que te presento se puede tener configurada previa a la instalación de un nuevo WordPress, pero hay un elemento que necesitarás en la instalación y que luego tendrás que bloquear. Es el fichero de creación de la Configuración y el de Instalación . Cuando acabes de instalar tu WordPress por primera vez, ya no necesitarás este fichero, y nadie tampoco debería de poder acceder, así que limitaremos su acceso: En Apache HTTPD (en el fichero . htaccess de la carpeta /wp-admin/): deny from all En nginx: location ~* ^/wp-admin/(install|setup-config). php { deny all; } --- Última revisión: 2 de octubre de 2021 Cuando entras en tu panel de usuario de WordPress, o dejas un comentario, habitualmente se guardan ciertos datos en las cookies. Si los datos no estuvieran encriptados podría aparecer algo como tu cuenta de correo o tu nombre de usuario, siendo algo que permitiría fácilmente detectar quién eres. Desde la versión 2. 6. 0 de WordPress, existen unos pequeños algoritmos para encriptar esos datos y que sea más complejo saber quién eres o cómo acceder a tu usuario. Para ello has de configurar los siguientes elementos en tu fichero de configuración . Puedes crear tus propias claves, aunque lo mejor es que utilices una herramienta que genera códigos aleatorios y complejos desde la dirección del Secret Key de WordPress. Esto hará que te aparezcan unos códigos similares a estos: define('AUTH_KEY', 'v4QcpUh8S4uBjW7CCHLaMwQYUxsaJE4d8bDS'); define('SECURE_AUTH_KEY', 'a2vgj6zKCcbveWuGacVLhS4X7XWqP9Gy5sWq'); define('LOGGED_IN_KEY', 'ECkrCQaDyke6uvhHJ3SunY2a38t363eWYbBH'); define('NONCE_KEY', 'bDK6Lz4KVeTVAnhctZZP5aNCgjEz8auA6nKc'); define('AUTH_SALT', 'LG6xqeQve7MWZHEZaDSdNRkJ8KmVSGGhHgga'); define('SECURE_AUTH_SALT', 'jrhya2UmbNtAY4BTNukXEJ2e9VgMX499FMgA'); define('LOGGED_IN_SALT', 'Mp14>0/]G@31||{yPjt}$! lbd:Vz9Dec:FRY8uYD1Eg6. hDW2+P+l{[|V1@Yii --- Última revisión: 2 de octubre de 2021 Con respecto a la base de datos (MySQL, MariaDB... ) hay pocas cosas a hacer propiamente dichas desde el punto de vista de WordPress, pero sí que se pueden poner algunas complicaciones para aquellos que intenten acceder a ella. Acceso La primera es la del acceso a la misma. Por norma general WordPress se instala en máquinas que pueden tener acceso externo, por lo que hemos de bloquearlo. Para ello, cuando creemos el usuario, hemos de limitarlo para que, por ejemplo, sólo se pueda acceder desde la misma máquina si tienes todo en un mismo servidor: GRANT ALL ON tu_database. * TO 'tu_usuario'@'localhost' IDENTIFIED BY 'tu_contraseña'; Recuerda sustituir los elementos 'tu_database', 'tu_usuario', 'localhost' y 'tu_contraseña' por los que proporcione tu proveedor. Con esto, tu usuario sólo tendrá acceso a una base de datos y sólo desde la misma máquina. Así, si tienes WordPress y te roban los accesos de una web, no podrían acceder a los de otra máquina. Además, si tienes tu servidor web en una máquina y tu base de datos en otra, puedes aplicar una configuración similar (ejemplo con IP privadas): GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, SELECT, UPDATE ON tu_database. * TO 'tu_usuario'@'10. 0. 0. 2' IDENTIFIED BY 'tu_contraseña'; Recuerda sustituir los elementos 'tu_database', 'tu_usuario', '10. 0. 0. 2' y 'tu_contraseña' por los que proporcione tu proveedor. O con IP públicas: GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, SELECT, UPDATE ON tu_database. * TO 'tu_usuario'@'8. 8. 8. 8' IDENTIFIED BY 'tu_contraseña'; Recuerda sustituir los elementos 'tu_database', 'tu_usuario', '8. 8. 8. 8' y 'tu_contraseña' por los que proporcione tu proveedor. De esta forma sólo las máquinas con esas IP podrían acceder a tu base de datos. Ten presente que todo esto se puede complicar mucho y que estos son ejemplos sencillos pero útiles. Úsalos como base para tu configuración personalizada. Hay algunos detalles más que se pueden deshabilitar en determinados casos. Por ejemplo, si tu base de datos está en la misma máquina que el sitio web (o sea, el servidor es "localhost") podrías desactivar (o al menos comprobar) que no funcionaría ningún acceso externo. Para ello puedes buscar el fichero de configuración de MySQL en o , y verificar que en la zona de configuración ] tienes incluidas estas dos líneas: skip-networking bind-address=127. 0. 0. 1 Además, algo que seguramente nunca harás con tu WordPress y su base de datos es cargar ficheros en la misma, por lo que desactivaremos los comandos de LOCAL INFILE, en la misma zona que el punto anterior: set-variable=local-infile=0 Prefijo de tablas Otro de los elementos clásicos de seguridad en WordPress es el "prefijo" de las tablas de la base de datos. Este sistema permite que cohabiten varios WordPress en una única base de datos. Por defecto el prefijo histórico de WordPress es el , que deberíamos cambiar. Lo más habitual es poner un nombre sencillo. Si mi web es example. com, lo más probable es que ponga como prefijo ; esto es mejor que el caso anterior, pero algo bastante fácil de encontrar. Es por esto que te recomiendo utilizar nombres más aleatorios del estilo a en el que cruces letras y números. Recuerda sólo utilizar letras en minúsculas de la a la , y números del al . Por poner algunos ejemplos más: , , ... Cambiaremos el nombre de los prefijos en el fichero de configuración : $table_prefix = 'wp_'; Recuerda sustituir 'wp_' por tu nuevo prefijo, solo en instalaciones nuevas. ¿Qué ocurre si mi instalación de WordPress es antigua y tengo ya muchas tablas y configuraciones? Puedes utilizar un plugin como Brozzme DB Prefix. --- Última revisión: 2 de octubre de 2021 ¿Qué podemos considerar hoy una contraseña segura? Pues probablemente una de 36 caracteres alfanuméricos y con símbolos. A partir de ahí, lo que queramos. Y es que hay varias reglas a seguir cuando hablemos de una contraseña; la primera y más importante: ser lo más única y aleatoria posible. Obviamente hay contraseñas que debemos facilitarnos para el uso diario, pero en esos casos es muy recomendable cambiarla con cierta frecuencia. Otro detalle importante es que las contraseñas es mejor generarlas con sistemas aleatorios y no "tú con tu teclado", debido a que no es tan aleatorio como podría parecer. Puedes por ejemplo probar a generar una contraseña con la herramienta Password Generator. Recuerda mantener una copia de seguridad de tus contraseñas, por lo que pueda pasar, preferiblemente en aplicaciones preparadas para ello. Si tienes varios WordPress, recuerda no usar la misma contraseña entre ellos. Es sencillo saber si tienes más de un sitio web, y si comprometes uno de ellos, intenta evitar los otros usando contraseñas distintas. Recuerda que tu usuario y contraseña es probable que circule por Internet ya... 1400 Million Clear Text Credentials Discovered in a Single Database. --- Última revisión: 2 de octubre de 2021 Cuando navegamos por Internet queremos hacerlo de forma segura. Para ello deberíamos navegar por sitios de confianza "con la barrita verde" (o el candado). Este sistema diferencia el HTTP del HTTPS . A grandes rasgos la diferencia que hay entre uno y otro es que la información de usuarios, contraseñas, formularios, etcétera, en el segundo caso va encriptada desde tu navegador hasta el servidor. Así, si un hacker es capaz de interceptar tus datos, los vería encriptados y no podría conocer su contenido de forma fácil. Para conseguir esto hemos de instalar un certificado TLS en el servidor web (Apache HTTPD, nginx... ). Hay que tener en cuenta que habitualmente (mal) se llama a todos los certificados "SSL" (aunque esa tecnología es previa y obsoleta). Es posible que por temas de compatibilidad a tus usuarios no les quieras ofrecer esto por defecto en todo el sitio, pero como mínimo tú si que deberías tenerlo configurado en el panel de administración . Los pasos son los siguientes: Consigue, instala y configura un certificado TLS. Puedes conseguir uno mediante el sistema abierto de Let’s Encrypt (por ejemplo, mediante el sitio web SSL for Free) o comprando un certificado en cualquiera de los proveedores habituales. En la medida de lo posible, configura todo tu sitio web para que únicamente funcione con HTTPS. En caso de no ser posible, al menos, que puedas navegar por HTTP y HTTPS indistintamente. Asegúrate de que el certificado está funcionando correctamente. Existen herramientas para verificarlos. Cuando accedas al panel de administración, fuerza que se active el HTTPS. Para hacer esto último, añade unas líneas en el fichero de configuración de WordPress : define('FORCE_SSL_LOGIN', true); define('FORCE_SSL_ADMIN', true); Desde WordPress 5. 7 la herramienta de Salud del Sitio dispone de una funcionalidad que facilita este proceso. --- Última revisión: 2 de octubre de 2021 Cuando se crean las tablas de WordPress, todos los sistemas de auto incremento comienzan en la cifra número 1. Esto hace que el primer usuario que crees será el usuario con identificador 1, el siguiente es el 2. Los sistemas que atacan los usuarios de forma automática, aprovechan esta numeración y suelen analizar los usuarios entre el 1 y el 10, como punto de inicio. Así que una vez hayas realizado la instalación de tu WordPress, el siguiente paso es cambiar esta numeración automática. ALTER TABLE wp_users AUTO_INCREMENT = 128; Recuerda cambiar el prefijo 'wp_' de la tabla por el que hayas elegido. En este momento, volveremos a acceder al WordPress, crearemos un nuevo usuario administrador, y eliminaremos el usuario generado por la instalación, que ya no será de utilidad. Con este sistema, en principio, ese nuevo usuario (y los siguientes) habrán comenzado por la cifra 128, de forma que cualquier ataque que se quiera realizar de forma secuencial quedará invalidado. --- Última revisión: 2 de octubre de 2021 En principio, cuando subes ficheros mediante el panel de Multimedia sólo se permiten elementos como imágenes, ficheros de texto y similares, pero no se permiten ficheros PHP (el lenguaje de programación con el que se hace WordPress) entre otros. Si esto estuviera activo, podría permitir que un hacker pueda ejecutar procesos maliciosos que no se deben ejecutar. Para ello deberíamos bloquear la posibilidad de ejecutar ficheros PHP en esta carpeta. En Apache HTTPD (dentro del fichero . htaccess en la carpeta ): deny from all Si queremos ser más agresivos, podemos bloquear muchos más lugares donde no es necesario que el público tenga que acceder, y que el núcleo de WordPress sí: En nginx (dentro del fichero de configuración del sitio): location ~* /wp-includes/. *\. php$ { deny all; access_log off; log_not_found off; } location ~* /wp-content/. *\. php$ { deny all; access_log off; log_not_found off; } location ~* /(? :uploads|files)/. *\. php$ { deny all; access_log off; log_not_found off; } ¿Qué carpetas habría que bloquear? Aunque en principio la única carpeta que no debería tener acceso a ejecutar ficheros PHP es la de subida de multimedias, se puede hacer extensiva a otras partes de código. En estos casos hay que vigilar los plugins y plantillas que tengan ciertos requerimientos (aunque harían un mal uso de la idea original de WordPress). /wp-content/uploads/: Es la carpeta donde los usuarios suben contenidos; el menú de subida de multimedia de WordPress por defecto no deja subir PHP, pero en muchas ocasiones hay agujeros de seguridad que dejan incluir contenidos aquí. Evitando la ejecución de cualquier lenguaje de programación de servidor (PHP, Python, Perl... ) evitaremos que nos puedan incluir algún tipo de Web-Shell. /wp-includes/: Esta carpeta en principio sólo incluye elementos "include" del sistema. Suelen ser ficheros CSS y JavaScript, aunque en algunos casos también son PHP. Pero estos ficheros PHP no son llamados por el usuario sino por el sistema mediante las funciones include por lo que no tienen porqué ser accesibles desde el navegador. --- Última revisión: 2 de octubre de 2021 Las personas, en general, somos curiosas por naturaleza y eso hace que, si desde el panel de administración se puede tocar algo, lo toquemos. Esto, en la parte de las plantillas, puede implicar que “algo deje de funcionar”. Para ello existe la posibilidad de bloquear la edición de ficheros y que, en caso de ser necesario, se tenga que hacer vía FTP o SSH. Para ello añadiremos la siguiente línea el fichero de configuración : define('DISALLOW_FILE_EDIT', true); Además, podemos ser un poco más agresivos y bloquear la posibilidad de que se puedan añadir plantillas (themes) o extensiones (plugins) desde el panel de administración. Para ello añadiremos la siguiente línea el fichero de configuración : define('DISALLOW_FILE_MODS', true); --- Última revisión: 2 de octubre de 2021 Uno de los errores más habituales de un usuario administrador en el panel de administración de WordPress es cambiar las direcciones URL que aparecen en la primera pantalla de configuración: las direcciones de la página principal del sitio. Para evitar que cualquier persona, de forma deliberada o por error, haga un cambio en las direcciones y por tanto el sitio deje de funcionar, lo mejor es bloquear esas direcciones desde el fichero de configuración . Para ello añadiremos dos líneas: define('WP_SITEURL', 'https://www. example. com'); define('WP_HOME', 'https://www. example. com'); Con esto consigues que las direcciones URL queden bloqueadas desde el panel y no se puedan producir cambios indeseados que impidan el acceso al sitio. --- Última revisión: 2 de octubre de 2021 Aunque podemos cambiar las carpetas por defecto del sistema, no es posible cambiar las de la administración . Hay dos opciones en este caso. Bloqueo por IP o usuario/contraseña La primera y más habitual es la que se suele sugerir es bloquear el acceso a esta carpeta limitada a una serie de IP, pero también sabemos que en general (al menos con IPv4) los usuarios no suelen tener una IP fija para acceder por ahí. Así que si tienes IP fija, podrías configurarlo, pero si no, esta opción no es tan viable. En Apache HTTPD (dentro del fichero . htaccess en la carpeta /wp-admin/) puedes limitar tu conexión a una IP en concreto: order deny, allow allow from 8. 8. 8. 8 deny from all Has de cambiar 8. 8. 8. 8 por tu dirección IP Otra posibilidad sería la de mostrar un mensaje de acceso de usuario de sistema operativo (que no dependa de WordPress) pudiendo bloquear, por ejemplo, las peticiones a la página de /wp-login. php: AuthUserFile ~/. htpasswd AuthName "Acceso privado bajo llave" AuthType Basic require user miusuariosecreto De la misma forma, en nginx se puede configurar lo siguiente: location /wp-admin { allow 8. 8. 8. 8; deny all; } Has de cambiar 8. 8. 8. 8 por tu dirección IP Y también se podría configurar bajo una solicitud de contraseña: location /wp-login. php { auth_basic "Acceso privado bajo llave"; auth_basic_user_file . htpasswd; } Si quieres tener varios usuarios y contraseñas, deberás configurar el fichero . htpasswd con los accesos según convenga. Cambio de dirección URL del wp-admin La segunda es la de utilizar un plugin que te permita cambiar la dirección URL, más similar a los cambios anteriores. Uno de ellos es WPS Hide Login, que te permitirá cambiar el acceso. Ten presente que en cualquiera de los dos casos se generan una serie de problemas asociados. Para comenzar las cachés; si utilizas algún sistema deberás configurarlo para que no cachee esta nueva dirección. Por otro están las llamadas AJAX asíncronas que se suelen hacer a ficheros de esta carpeta: si bloqueas la carpeta a una IP o cambias el nombre, es posible que pierdas toda esta funcionalidad. Para evitar esto, en Apache HTTPD deberías desbloquear el acceso al fichero: Order allow, deny Allow from all Satisfy any Y de la misma forma, en nginx: location /wp-admin/admin-ajax. php { allow all; } Ataques de fuerza bruta Además de los accesos bloqueados de usuarios conocidos, también hay que disponer de sistemas que eviten el ataque por volumen de intentos de acceso en un periodo de tiempo. Algunos sistemas que limitan los accesos como Limit Login Attempt permiten configurar cuantas oportunidades tiene para acceder un usuario desde una dirección IP en un periodo de tiempo. De esta forma, si hay un ataque por fuerza bruta de usuario / contraseña, se podrá bloquear los intentos durante un periodo definido. Desconexión automática Otro momento a tener muy presente es aquel usuario que accede al panel, lo deja abierto y "se va". Este usuario inactivo que deja su sesión abierta posteriormente se puede encontrar con problemas porque alguien haya utilizado su cuenta para realizar fechorías. Para ello podemos utilizar algún plugin como Inactive Logout que permiten que un usuario conectado al panel, pero inactivo durante una serie de minutos, reciba un mensaje de aviso de si quiere seguir conectado al panel, y si no lo contesta, se le expulsa, por lo que posteriormente tendrá que volver a conectarse. Verificación de cuentas Cuando intentas acceder al panel de administración y al poner tu usuario o contraseña da un error, ese mensaje deja entrever si lo que ha fallado es el usuario y contraseña, o solo la contraseña (de forma que implícitamente estás diciendo que ese usuario sí que existe). Estos mensajes de error que pueden ser tan claros, se pueden sobrescribir mediante un plugin. function disable_wordpress_login_errors { return 'Meeeeec! '; } add_filter('login_errors', 'disable_wordpress_login_errors'); Instrucciones paso a paso Crea el plugin o descárgalo ya creado (descomprime el fichero ZIP). Accede por FTP a la carpeta . Si no tienes esta carpeta, créala. Sube por FTP el fichero a la carpeta . Cuando entres en el panel de administración de tu WordPress, en la zona de Plugins tendrás una sección nueva de plugins Imprescindibles donde aparecerá. Recuerda que al ser Imprescindible no podrás activarlo ni desactivarlo. --- Hola (humano|robot|cosa), Bienvenido a WordPress SysAdmin, el sitio con información sobre Administración de Sistemas para WordPress. En este sitio vas a encontrar, en diferentes secciones, información sobre los requisitos de WordPress para su instalación, algunas formas de instalarlo según el sistema operativo, mantenimientos, mejoras de rendimiento y seguridad. ¿Buscas información de la WordPress Vulnerability Database API? Este sitio está planteado lo más parecido a una serie de cursos para que puedas seguir paso a paso lo que necesites en cada momento. Requisitos Instalación Rendimiento Seguridad Mantenimiento Desarrolladores Empresas Hosting Extra Últimas entradas ¿Por qué este sitio? En todo Internet podemos encontrar decenas de manuales sobre WordPress, pero algunas veces se limitan sólo a lo básico, a una simple instalación, sin tener en cuenta todo lo que hay alrededor de los sistemas que acompañan al software, o ciertas mejoras que se pueden aplicar para tunear WordPress. Este sitio es la recopilación de varios proyectos que han ido evolucionando a lo largo del tipo y que han acabado fusionándose para poder centralizar toda la información en vez de estar dispersa. ¿Quién hay detrás de esto? Hola, soy Javier Casares, administrador de sistemas y parte del Hosting Team de WordPress. Utilizo WordPress desde marzo de 2005; mis conocimientos de administración de sistemas, SEO y WPO me han llevado a lanzar este sitio en el que recopilo información sobre WordPress desde un punto de vista de sistemas, teniendo en cuenta siempre que WordPress es código. ¿Dudas o sugerencias? Si hay algún texto o tutorial que no te queda claro, por favor ponte en contacto conmigo. Además, si consideras que falta algo en el sitio, pídemelo e intentaré crear un tutorial para ello. Si quieres un servicio profesional de Administración de Sistemas para WordPress, tampoco dudes en enviarme un mensaje. INCIBE: Empresas y Soluciones de Ciberseguridad WordPress Five for the Future --- Propiedad del Sitio Mi nombre es Javier Casares con documento de identificación europeo ES53081177Y. Domicilio fiscal en Carrer de Wagner 28, 08923 Santa Coloma de Gramenet, Barcelona (Spain). Puedes contactar conmigo en wordpress@wpsysadmin. com o en el teléfono +34 644 26 16 26. Registrado en el grupo IAE 762-2 Profesional informático. Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y de Comercio Electrónico (LSSI-CE). Tratamiento de datos y privacidad Este sitio no almacena ningún dato tuyo. Cookies Este sitio no usa cookies de terceros. Tampoco utiliza cookies para el funcionamiento propio del sitio. Reglamento General de Protección de Datos (RGPD) UE 2016/679 del Parlamento y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE, la Ley Orgánica 3/2018 de Protección de Datos Personales y Garantía de los Derechos Digitales, aprobada el 5 de diciembre de 2018 (LOPDyGDD) y demás normativa nacional que sea de aplicación. --- --- ## Entradas Una de las decisiones que va por modas es el uso de un dominio con sitio web asociado y el uso del www o sin-www. Una de las decisiones, que va por modas, es el uso de un dominio con sitio web asociado y el uso del www o sin-www. Seguramente, habrá gente que te diga que por no-sé-qué razones hay que usar sin-www y otros que www... y aunque en principio no debería afectar, ya que a cualquier nivel hemos de hablar de "hostname" (es decir, toda la dirección completa) sí que hay algunos elementos a tener en cuenta. La primera de ellas es que cuando se inventó la web los dominios de por sí ya existían, y, para diferenciar el servicio de correo, de FTP o de la web, se planteó el uso del www delante del dominio. Así que sí, las webs, en teoría, deberían llevar los www según su invención. De todas formas, aunque esto es un "da igual", sí que hay algunos elementos técnicos a tener en cuenta, como por ejemplo el de las redirecciones. La situación es cuando hemos de migrar, por ejemplo, de sin-www a www, teniendo en cuenta el HTTP y HTTPS; no, no puedes migrar directamente todo a la URL definitiva. Y es que hay sistemas actuales de seguridad, por ejemplo el HSTS, que indican claramente cómo hemos de hacer esta mejora en la seguridad de las comunicaciones. Incluso, hay navegadores que, si no los haces en el orden correctos, podrían darte un mensaje de atención. Vamos a partir de la base de todas estas combinaciones: http://example. com/http://www. example. com/https://example. com/https://www. example. com/: esta es a la que queremos llegar siempre. Si comenzamos por la primera de ellas, tenemos que dar los siguientes pasos a la hora de hacer la redirección: http://example. com/http://www. example. com/https://www. example. com/ Hay que partir de la base de que no se debería pasar de HTTP a HTTPS si el hostname no coincide, por lo que primero hemos de mantenernos en el mismo protocolo HTTP, y cambiar el hostname, en este caso del sin-www al www. Ahora que el hostname ya es el mismo, podemos subir de HTTP a HTTPS sin recibir ningún tipo de aviso. En el segundo caso, el recorrido es algo más sencillo: http://www. example. com/https://www. example. com/ En este caso, como el hostname ya es el mismo, simplemente tenemos que subir del HTTP al HTTPS. El tercer caso también es bastante sencillo. https://example. com/https://www. example. com/ En este caso el protocolo HTTPS ya lo tenemos, por lo que no hay ningún problema en modificar simplemente el hostname y pasarlo de sin-www a www. Con esto conseguiremos que las modificaciones de protocolos y hostname se hagan de forma correcta y ordenada sin que afecten a ninguna incompatibilidad. --- WordPress sirve para muchas cosas, y una de ellas es todo lo relacionado con los LMS (Learning Management Systems), los sistemas de gestión de aprendizaje o, en resumen, montar una plataforma de cursos online. La mayor problemática de este tipo de plataformas es la del alojamiento de los vídeos. La solución más simple suele ser ir a Vimeo. Suele ser la respuesta a varias problemáticas. Una de ellas, que subes un vídeo en un tamaño y formato, y te genera todos los tamaños, pesos y demás para los distintos dispositivos. La siguiente es la protección que se hace para bloquear solicitudes desde un dominio, algo que se podría saltar con algo de trabajo. El problema llega cuando la cosa toma camino y creces más de la cuenta. Los planes normales ya no sirven y has de irte a niveles superiores, ya que el límite en el caso de Vimeo sobre todo está en el volumen de reproducciones. ¿Cuál es la solución para estos casos? Hay varias opciones dependiendo de la complicación técnica y editorial. Si quieres simplificar la técnica, la editorial crece, y si quieres simplificar la editorial, la técnica crece. La solución más sencilla es encontrar una plataforma que permita alojar los vídeos de forma barata, que el coste de retransmisión sea proporcional al consumo, y que se encarguen de toda la composición de los vídeos y la seguridad. Existen varias plataformas que lo hacen, y que normalmente llevan detrás una CDN. Solución fácil técnica (pero no editorial) Normalmente, estos sistemas que alojan los vídeos disponen de su propio reproductor, por lo que si utilizas el suyo, toda la problemática se soluciona con respecto a seguridad e incluso técnica. Te dan un código HTML, lo incluyes en donde quieres que se vea el vídeo y ¡ya está! . ¿Cuál es la contra? Que la subida de vídeos la has de hacer en su plataforma, y que te han de dar el código y copiarlo en el WordPress. Es decir, la gestión, muy simple, se hace fuera de WordPress. Solución fácil editorial (pero no técnica) Las plataformas de reproducción de vídeo suelen permitir la subida y gestión de los contenidos mediante una API. Esto ayuda a que desde el propio WordPress puedas subir un vídeo, como si lo subieras al Media, y desde allí incrustarlo en el contenido. Sí, suena muy bonito, pero... En este caso se complica algo más, ya que la reproducción del vídeo queda en manos de WordPress y de sus plugins, lo que hace que el reproductor suela tener que ser uno que de soporte a HLS. El HTTP Live Streaming es, como su nombre indica, un sistema que hace que un vídeo se emita como si fuera en directo. Básicamente, lo que se hace es que un vídeo se divide en miles de pequeñas partes y se van leyendo esas pequeñas partes una tras otra, de forma que no te puedas descargar el vídeo por sí mismo. Un ejemplo que seguro que os ha pasado, y que el HLS permite, es el ajuste del bitrate según tu conexión, por lo que si de pronto tu conexión a internet va peor, el sistema ajustará el vídeo a peor calidad, y en el momento en el que vuelva a una conexión correcta, volverá a una mayor calidad, al menos, si lo configuras en automático. ¿Qué solución es mejor? Depende. Sobre todo de lo que quieras gastarte en preparar la infraestructura, en licencias de plugins o en el nivel de personalización que necesites en cada caso. Si el vídeo es simplemente un commodity, la mejor opción (y la que yo creo que usaría) es la primera, la de facilidad técnica. Al final, tener que subir un vídeo a una plataforma, que me dé un código y pegarlo es algo "fácil", aunque siempre me quede ese código de reproductor externo. La segunda opción, la de gestión editorial, básicamente es que WordPress se haga cargo de absolutamente todo, excepto que la URL del vídeo está fuera. Sí, quizá queda todo mucho más integrado en el sistema, e incluso puedes personalizar con mucho más detalle el reproductor, pero no deja de ser un sistema en el que dependes de ese plugin y que tiene lock-in. Esto debe ser caro, ¿verdad? La respuesta es: depende. Pero en principio no. Lo interesante de estas plataformas es que sueles pagar por el uso que hagas. Si tienes muchos vídeos, pagarás más. Si tus usuarios están en muchos lugares del mundo, pagarás más. Si los vídeos se reproducen mucho, pagarás más. Si borras vídeos, o emites menos, pues pagarás menos. ¿De qué precios estamos hablando? Lo primero que hemos de analizar es dónde alojar los vídeos. La gracia de las DNS es que los vídeos se pueden alojar en más de un sitio a la vez, lo que hace que si estás cerca de esa zona te salga más barato. El coste base suele ser de 1 cts / GB. Si por ejemplo tienes usuarios en Norteamérica, Europa y Sudamérica, quizá te interese elegir esas 3 zonas, por lo que te podría salir por 3 cts / GB. Pongamos esas 3 zonas, que tenemos 100 vídeos de unos 1 GB cada uno, en alojamiento pagaríamos: 0. 03 €/GB X 1 GB X 100 vídeos= 3. 00 € / mes Ahora quedaría ver el coste por la retransmisión de esos vídeos. El precio de media suele ser de 5 €/TB (o sea, 0. 005 €/GB). Pongamos que tenemos 10 cursos de 25 alumnos que tienen 8 asignaturas y cada asignatura tiene 10 clases con su vídeo correspondiente (de 1 GB). 10 cursos X 25 alumnos X 8 asignaturas X 10 clases X 1 GB X 5 €/TB = 100,00 € / mes Hay que tener en cuenta que, como no siempre todo el mundo ve todos los meses la misma cantidad, sería variable. Lo interesante de esto en realidad es que se puede calcular cuál puede ser el coste de cada uno de los cursos según... --- Cuando tienes alojado un dominio en Plesk en el que quieres correo, pero el alojamiento va a ser una redirección, Let's Encrypt no está disponible. Cuando tienes alojado un dominio en Plesk en el que quieres correo, pero el alojamiento va a ser una redirección, Let's Encrypt no está disponible. Plesk te da tres opciones de alojamiento: ninguno, redirección, y sitio web. En los casos de ninguno y redirección, no puedes crear un certificado Let's Encrypt, por lo que el correo, si lo quieres, no podrá ser leído de forma segura. Funcionará en los puertos sin certificados, pero no en los seguros. La opción alternativa si no quieres web, pero sí correo, en este caso, es la de comprar un certificado TLS wildcard, ya que tendrás que proteger también el subdominio de webmail. ¿Qué hacer, entonces, si quiero tener correo seguro, y un certificado Let's Encrypt? Deberás crear un sitio web, aunque, por ejemplo, luego hagas una redirección a otro dominio. En este caso vamos a crear el dominio example. com. Le crearemos un sitio web y el correo, por ahora todo sin certificado. Una vez lo tengamos, seguiremos los siguientes pasos. En las opciones de Configuración de Apache y nginx, añadiremos a las Directivas adicionales de nginx lo siguiente: location ^~ /. well-known/acme-challenge/ { allow all; default_type "text/plain"; try_files $uri $uri/ /dev/null =404; } Con este código tendremos la excepción para cuando se llama a la validación de los certificados. A continuación, deberemos ir al Administrador de archivos y eliminar todo lo que haya en la carpeta del httpdocs. Una vez esté vacío, crearemos un fichero . htaccess con el siguiente contenido. Options -Indexes RewriteEngine On RewriteBase / RewriteCond %{HTTP_HOST} ^example. com RewriteRule ^(. *)$ http://www. example. com/$1 RewriteCond %{HTTPS} off RewriteCond %{HTTP_HOST} ^www. example. com RewriteRule ^(. *)$ https://www. example. com/$1 RewriteCond %{HTTPS} on RewriteRule (. *) https://www. dominio. es/$1 Las redirecciones son 3 bloques distintos. Esto, se hace así por el sistema del HSTS que, en caso de estar activado, hará que el navegador no devuelva un mensaje de error informando de una posible inseguridad. El primero hace que el dominio sin-www mande el tráfico al mismo dominio sin-https. RewriteCond %{HTTP_HOST} ^example. com RewriteRule ^(. *)$ http://www. example. com/$1 El segundo bloque valida que si el dominio tiene las www, pero está sin-https lo subamos a https. RewriteCond %{HTTPS} off RewriteCond %{HTTP_HOST} ^www. example. com RewriteRule ^(. *)$ https://www. example. com/$1 Y, una vez el dominio tenga el https, lo mandaremos a la nueva dirección segura. RewriteCond %{HTTPS} on RewriteRule (. *) https://www. dominio. es/$1 La última línea es donde indicaremos el dominio al que, cuando se visite el dominio, se mandará el tráfico. Con este sistema conseguiremos poder crear el certificado de Let's Encrypt para el dominio, el wildcard (*. example. com) y los certificados para el correo. --- Hacer copias de seguridad de sitios grandes con WordPress puede complicarse. Si este es tu caso, quizá te interese hacer alguna copia con restic. Hacer copias de seguridad de sitios grandes con WordPress puede complicarse. Si este es tu caso, quizá te interese hacer alguna copia con restic. Objetivos y requisitos El objetivo de usar este sistema es el de crear copias de seguridad con un acceso rápido, pero desde consola (CLI). Hay que tener en cuenta que esta herramienta usa un sistema de snapshots, por lo que no se podrá acceder a cada fichero en el lugar del alojamiento de datos. En casos de tener un sitio WordPress grande, a veces es problemático usar un plugin, o las copias de seguridad de un panel tipo Plesk o cPanel, por lo que tendremos que hacer las copias de forma más manual. Además, este sistema también puede servidor como una copia secundaria a un sistema que ya esté establecido. Este tutorial se va a probar en: Ubuntu 22WordPressWasabi (almacenamiento externo) Instalando restic Lo primero que hemos de hacer es instalar la propia herramienta, restic. apt-get -y install restic Podemos, añadirle, además, el sistema de auto-completado. restic generate --bash-completion /etc/bash_completion. d/restic Configurando un almacenamiento Existen distintos tipos de almacenamiento externo para restic. En este caso vamos a hacer la prueba con Wasabi, un sistema de almacenamiento compatible-S3. Como en cualquier sistema de este tipo, necesitaremos 4 datos: Access Key (ejemplo: 3Q7WB7Y98VHMWN4XEVEB)Secret Key (ejemplo: ySXTLpQnqanfHLHM9RA6VXb3SjRaFG22ryuhRvGc)Repositorio (ejemplo: eu-west-2)Nombre del bucket (ejemplo: vps-1-2-3-4) Además, cada instalación de restic tiene una contraseña con la que cifra los datos en el sitio remoto, y que deberás guardar si quieres restaurar en otra máquina. Con esto, podemos crear un fichero en el que incluir todos estos datos: cat > /root/. restic-env /backups-db/example-com-db-$(date +\%F-\%T). sql restic backup /backups-db/ rm -rf /backups-db/ restic backup /webs/example. com/ Cargando la configuración El primero de los bloques es la validación y carga de la configuración. if then source /root/. restic-env echo $RESTIC_REPOSITORY restic init fi Aquí, básicamente lo que validamos es si la configuración está cargada. Si lo está, sigue adelante. Si no lo está, la carga y conecta con el sistema de almacenamiento remoto. Copia de las configuraciones La primera copia que haremos es la de las configuraciones generales de la máquina. restic backup /etc/ Copia de la base de datos El segundo elemento al que vamos a hacer la copia es a la base de datos. En este caso haremos primero un MySQLdump y ese fichero generado será el que usemos. mkdir -p /backups-db/ mysqldump --quick --skip-lock-tables --single-transaction --quick --verbose example-com-db | zip > /backups-db/example-com-db-$(date +\%F-\%T). sql restic backup /backups-db/ rm -rf /backups-db/ Copia de los ficheros Por último copiaremos los ficheros del propio WordPress. restic backup /webs/example. com/ Listar los snapshots Ahora que tenemos ya varias copias hechas, podemos ver el listado de qué se podría recuperar. restic snapshots Algo que nos devolverá algo como: repository cgms3tqn opened successfully, password is correct ID Time Host Tags Paths -------------------------------------------------------------------- af9qtv5m 2022-06-13 18:24:04 example. com /etc 26kkqczj 2022-06-13 18:24:18 example. com /backups-db 44z2cta5 2022-06-13 18:24:29 example. com /webs/example. com 4tdrn8zx 2022-06-13 18:53:42 example. com /etc v3y8d9ee 2022-06-13 18:53:46 example. com /backups-db 4j9qs4m2 2022-06-13 18:53:50 example. com /webs/example. com Recuperar un snapshot Si queremos recuperar una de las copias, podemos hacerlo sobre los ficheros existentes, o podemos recuperarlo en una carpeta temporal para buscar los ficheros que necesitamos. restic restore 26kkqczj --target /tmp/restore Si accedemos a la carpeta /tmp/restore, podremos encontrar la restauración del snapshot. --- Tener varios WordPress en subdominios, carpetas, y sin usar WordPress MultiSite, puede ser una necesidad que por alguna situación del proyecto es necesaria. Y para conseguirlo, necesitamos HAProxy. Tener varios WordPress en subdominios, carpetas, y sin usar WordPress MultiSite, puede ser una necesidad que por alguna situación del proyecto es necesaria. Y para conseguirlo, necesitamos HAProxy. Objetivo a conseguir Planteemos una situación que, se podría dar, ya sea con varios WordPress o con varias tecnologías diferentes. Por un lado, tenemos en //example. com/ un sitio web; por ejemplo, una web corporativa. Por otro lado, tenemos en //example. com/tienda/ una tienda. Y, por otro, tenemos en //example. com/educacion/ con un sistema de cursos. Sí, lo más sencillo sería crear un WordPress MultiSite con todo, pero, por la razón que sea, no es posible, por lo que hay que montar 3 WordPress simples, distintos, en 3 servidores diferentes. Si el sistema estuviera en 3 subdominios, sería muy fácil, ya que apuntaríamos las entradas A de las DNS a las 3 IPs distintas. Pero en este caso no es así. Y aquí es donde entra HAProxy, la herramienta que estará por delante de nuestros sitios y que se encargará de mandar el tráfico. Qué vamos a crear Para este experimento vamos a crear lo siguiente: Un HAProxy que gestione todo el tráfico, por delante. Un WordPress en la carpeta raíz (//example. com/). Un WordPress en una carpeta (//example. com/tienda/). Cada una de estas partes la vamos a montar en un VPS distinto, aunque en realidad los WordPress podrían estar, en principio, en un alojamiento compartido si se quisiera, por ejemplo, de varias agencias que los gestionan. Instalando los WordPress Lo primero que prepararemos son los dos WordPress. Hay que tener en cuenta que el dominio para instalarlo no estará apuntando en las DNS (ya que apuntará a la máquina del proxy), así que tendremos que instalar los 2 WordPress, uno en la raíz y otro en la carpeta, sin acceso web. Por otro lado, aunque se pueden montar certificados Let's Encrypt, es probable que algunas validaciones den error. En cualquier caso, puedes seguir los manuales de instalación de WordPress para ambos casos. Instalando HAProxy En este ejemplo vamos a utilizar: Ubuntu 22HAProxy 2. 6 Instalación de HAProxy No en todos los sistemas operativos está la versión más actual de HAProxy disponible, por lo que la cargaremos desde un repositorio alternativo. add-apt-repository -y -s ppa:vbernat/haproxy-2. 6 Y haremos la instalación. apt-get -y install haproxy Podemos validar que está la versión 2. 6. x instalada. haproxy -v Vamos a tratarlo como un servicio, para que al iniciar la máquina siempre se encienda y esté disponible. Para ello necesitamos activar el demonio. cat > /etc/default/haproxy /etc/rsyslog. d/haproxy. conf /etc/ssl/private/temporal. pem Configurando HAProxy Antes de nada, haremos una copia de seguridad del fichero base de configuración. cd /etc/haproxy cp haproxy. cfg haproxy. cfg-original Y haremos una primera configuración para controlar el HTTP y poder crear los certificados con Let's Encrypt. cat > /etc/haproxy/haproxy. cfg --- Cuando se comienza un proyecto con WordPress una de los primeros momentos es el de elegir los plugins que vamos a utilizar, y muy especialmente los de seguridad y antispam. Cuando se comienza un proyecto con WordPress una de los primeros momentos es el de elegir los plugins que vamos a utilizar, y muy especialmente los de seguridad y antispam. Otra regla básica es la de tener los menos plugins posibles, aunque, personalmente, prefiero ajustarlo a tener los mínimos plugins específicos necesarios. No es lo mismo un mega plugin que hace 10 cosas y que puede pisarse con otros plugins, que varios plugins pequeñitos muy específicos. Además, otro elemento importante es el de seguir las reglas de privacidad, por lo que intentaremos que sean plugins que no manden información a terceros. En este caso vamos a ir a buscar algunos plugins imprescindibles. NOTA: Estos plugins han sido probados con WordPress 5. 9, por lo que deberían funcionar en un rango de WordPress 5. 7 a WordPress 6. 1 En cuanto a seguridad vamos a buscar plugins que cubran distintos puntos. Cortafuegos Un cortafuegos, o firewall, bloquea peticiones a nuestros WordPress indebidas o que buscan algún tipo de agujero de seguridad. Un plugin sencillo y ligero es BBQ Firewall, un plugin de "instalar y listo". También dispone de una versión Pro. https://es. wordpress. org/plugins/block-bad-queries/ Otro punto a tener en cuenta es la pantalla de acceso. Esta parte es seguramente la más débil de todo WordPress por lo que deberemos protegerla por partida doble. Por un lado, instalaremos un sistema que impida ataques masivos. Para ello usaremos un plugin al estilo Login LockDown. https://es. wordpress. org/plugins/login-lockdown/ En otra línea de trabajo, deberemos proteger las fugas de contraseñas o la posibilidad de que los usuarios usen contraseñas débiles o que estén disponibles de forma pública. En estos casos activaremos un plugin de segundo factor de autenticación al estilo de Two Factor. https://es. wordpress. org/plugins/two-factor/ Antispam Aunque WordPress viene con bloatware de serie como es Akismet, pero este plugin manda a servidores centrales toda la información y datos privados. Como un sistema alternativo usaremos algunas funciones de WordPress y un plugin que nos ayude a mejorar el potencial interno. El primero de los elementos a usar es Block List Updater. Este plugin se trae una lista de palabras clave consideradas spam, y la incluye de forma automática a la sección de flltrado nativo de WordPress (en la sección de Comentarios). https://es. wordpress. org/plugins/blacklist-updater/ Para ampliar con un plugin que intente detectar patrones y otros elementos, y que es compatible con el anterior, podemos usar Antispam Bee. https://es. wordpress. org/plugins/antispam-bee/ Copias de Seguridad Otro elemento a tener siempre presente en cuanto a seguridad son las copias o backups. Lo ideal sería, al menos, tener copias en 2 o 3 sitios. Habitualmente el proveedor de hosting nos proporcionará una disponible con sus propias herramientas y sistemas de restauración. Por otro lado, nosotros podemos utilizar un plugin que nos ayude a ello. Existen muchos y hay que probarlos para encontrar el sistema que nos funcione y donde nos sintamos cómodos. Yo suelo utilizar Duplicator (y su versión Pro), y BackWPUp. https://es. wordpress. org/plugins/duplicator/ https://es. wordpress. org/plugins/backwpup/ --- Este procedimiento es una propuesta para proyectos grandes en los que hay muchas personas implicadas, y en los que se requiere cierto control de las actualizaciones. Este procedimiento es una propuesta para proyectos grandes en los que hay muchas personas implicadas, y en los que se requiere cierto control de las actualizaciones. En la propuesta intervienen distintos equipos, aunque se van a resumir en 2 o 3, como son tecnología, seguridad y el equipo editorial. En cualquier caso, podemos separarlo en dos, el equipo técnico y el editorial. Como digo, es una propuesta, basada en un proyecto específico, por lo que debería adaptarse a cada caso concreto. Entornos Vamos a disponer de 3 entornos a la hora de trabajar con WordPress. Entorno de desarrollo (devel) El entorno de desarrollo será un entorno obsoleto en cuanto a contenidos (por defecto) pero alineado en cuanto a configuraciones. Este entorno tendrá, siempre que sea posible, las últimas versiones aplicadas de cualquier parte de WordPress, ya sea infraestructura, WordPress o complementos. Aquí podremos encontrar versiones superiores a las que se vayan a aplicar en producción, por lo que, aunque sea una versión pública, no se ha de tomar de referencia para los pases a producción. Entorno de preproducción (staging) Este entorno se plantea como una versión previa al pase a producción. Se generará con una copia lo más actual posible del sitio de producción, para poder comparar contenidos. En esta versión se aplicarán los cambios que se documenten en el Changelog de versiones de pase a producción. En una línea de tiempo tendríamos: A –3 días, con la recogida de todos los cambios y la presentación del Changelog. A –2 días creación del entorno de staging y una URL pública para analizar los cambios. Entorno de producción (pro) El entorno de producción es el entorno al que los usuarios finales acceden. El sistema tiene copias automáticas en varios lugares y formatos. Previo a las actualizaciones se realizará una copia de seguridad en local y remoto para una recuperación rápida. Las actualizaciones se aplicarán según lo diseñado en el Changelog y, por tanto, aprobado según el entorno de preproducción. Actualización de infraestructura Vamos a definir la infraestructura como la parte que puede hacer referencia a todo lo que afecta a los WordPress, pero no es WordPress. Esto afectaría principalmente a las máquinas y configuraciones de las máquinas virtuales, o entornos en la nube, donde encontramos las configuraciones de MariaDB, nginx, PHP, Redis y otros elementos que conforman los WordPress. Las actualizaciones de la infraestructura se plantean de la siguiente manera. Actualizaciones de seguridad del Sistema Operativo El sistema operativo Linux (en este caso Ubuntu) está configurado para que las actualizaciones críticas de seguridad se apliquen de manera automática. Actualizaciones de seguridad de servicios En caso de que haya alguna actualización de seguridad que pueda afectar a alguno de los componentes de WordPress, como puede ser nginx, PHP o Redis, se dará un aviso y en el plazo de 24 horas se plantea el procedimiento de actualización. Será un procedimiento de silencio administrativo, por lo que, si nadie dice nada en contra, se aplicarán los parches. Actualizaciones normales El primer lunes de cada mes se planificará la actualización de la infraestructura de forma normal. Actualización del núcleo de WordPress Este apartado hace referencia en exclusiva a las actualizaciones del propio WordPress, es decir, su núcleo. WordPress funciona por un sistema de versiones mayores y menores (o parches). Las versiones mayores son aquellas que vienen identificadas por las dos primeras cifras (por ejemplo, 5. 8, 5. 9 o 6. 0). Las versiones menores (o parches) vienen definidas por una tercera cifra (5. 9. 1, 5. 9. 2, 5. 9. 3). Las versiones mayores, entre sus cambios, pueden incluir funcionalidades nuevas, añadir o eliminar ficheros o hacer cambios en la estructura de la base de datos. Las versiones menores se limitan a hacer cambios y mejoras en las funcionalidades existentes, además de la aplicación de parches de seguridad. Actualizaciones menores Por defecto WordPress aplica actualizaciones automáticas en las versiones menores, ya que conllevan un riesgo mínimo, y suelen implicar correcciones de errores o parches de seguridad. La configuración por defecto será la aplicación de estos parches de forma automática por el propio WordPress de forma automática. Actualizaciones mayores Las actualizaciones mayores de WordPress suelen tener un calendario previsto unos 3 meses antes de su lanzamiento. Además, por norma general, se incluyen al menos una versión beta, y una versión candidata, previas al lanzamiento. Las actualizaciones mayores se aplicarán en una versión candidata en el entorno de desarrollo en el momento en el que estén disponibles y, por tanto, se podrán observar las posibles incompatibilidades o mejoras que haya pendientes. El objetivo es que, el día en el que aparezca la versión mayor de forma oficial, se pueda aplicar la actualización de forma planificada y ya con una revisión de compatibilidad de los complementos. Actualización de complementos de WordPress WordPress tiene dos tipos de complementos: plugins y temas. La forma de gestionar ambos es similar, ya que se pueden actualizar desde el repositorio oficial de WordPress y, por tanto, con un clic desde el panel. También se pueden actualizar desde sitios externos que permiten actualización desde el panel, normalmente bajo licencia, o se pueden actualizar de manera manual subiendo un ZIP con el complemento desde la zona de Subir plugin, o Subir tema, del propio panel de administración. Aunque los complementos suelen seguir la misma forma semántica de versiones que WordPress, cada desarrollador aplica sus propios métodos. Temas Los temas hacen referencia a los elementos que se muestran a los usuarios, el frontend del sitio. Una característica de los temas es que no han de incluir funcionalidades que puedan servir en otros temas. Para estos casos, se debe incluir un plugin complementario a determinadas funcionalidades, ya que, si se cambia de tema, estas deben seguir funcionando. Actualizaciones menores Se considera una actualización menor de un tema aquella que hace referencia a la mejora, corrección o cambio de algún elemento del frontal, pero sin incluir funcionalidades nuevas. Esto hace de por sí que solo haya pequeños cambios en el código, correcciones, pero que no se añadan... --- Muchos medios de comunicación medianos quizá no tengan un acceso sencillo a Google News, pero si tienes WordPress puedes adaptar tu negocio de forma sencilla mediante WordPress Newspack. Muchos medios de comunicación medianos quizá no tengan un acceso sencillo a Google News, pero si tienes WordPress puedes adaptar tu negocio de forma sencilla mediante WordPress Newspack. WordPress Newspack es una plataforma todo en uno diseñada para pequeños y medianos medios que simplifica la publicación y genera la audiencia e ingresos necesarios. En un primer momento, Newspack fue un producto gratuito, pero desde hace un tiempo tiene un precio con un mínimo de 500 dólares mensuales. Pero siempre puedes montarte tú el sistema. Newspack también viene con una colección de bloques personalizados, que incluyen las Entradas de la página de inicio, Donar, Carrusel de artículos, Anuncios, Perfil del autor e Iframe, y estilos de bloque únicos para los Bloques principales como los bloques Columnas y Grupo. Newspack mantiene una lista de plugins de terceros aprobados que pueden ser utilizados por cualquier sitio de Newspack. Si alguno de los editores quiere utilizar un plugin que aún no aparece en esta lista, cuentan con un proceso de revisión para garantizar que el plugin es seguro, eficaz y fiable. El asistente de publicidad de Newspack le permite integrar fácilmente los anuncios de WordAds, Google AdSense y Google Ad Manager en su sitio. Newspack Listings es una herramienta que ayuda a los editores a crear listas reutilizables utilizando el editor de bloques de Gutenberg. Se puede emplear para generar listas elaboradas de artículos específicos, o listas que se rellenan con consultas. Las listas se pueden incrustar en el contenido de las publicaciones o de las páginas, o en cualquier lugar en el que se puedan usar los bloques de Gutenberg. Los elementos de la lista existen como piezas discretas y reutilizables de contenido con sus propias páginas independientes, útiles para fines de SEO. Con el plugin Newspack Sponsors, puedes crear patrocinadores y asociarlos a entradas, categorías y etiquetas para dar un tratamiento visual especial a los contenidos patrocinados o suscritos. Newspack Newsletters te permite crear boletines por correo electrónico con el editor Gutenberg, y enviarlos a tus listas de correo de Mailchimp, Constant Contact o Campaign Monitor, todo ello sin salir de tu sitio web. Newspack's Analytics permite mejorar la configuración por defecto de Google Analytics. Actualmente, Newspack ofrece sus funciones relacionadas con la analítica solo cuando el sitio utiliza GA a través de Site Kit. Existe una lista de sitios creados con WordPress Newspack para seguir de ejemplo. Contenidos Requisitos Para utilizar WordPress Newspack para Google News solo es necesario disponer de un WordPress. Lo más recomendable es comenzar con una instalación nueva, y a partir de ahí crear todo el sistema. Hay que tener en cuenta que, teniendo en cuenta que el sistema debe absorber mucho tráfico, lo ideal es tener el WordPress en al menos un VPS (es decir, una infraestructura dedicada y no compartida) y optimizada específicamente para WordPress, incluidas las distintas capas de caché. Mantenimiento Aunque Newspack es un compendio de múltiples plugins y temas, todos ellos de código abierto, no son plugins o temas que estén en el repositorio de WordPress. org, por lo que hay que hacer un trabajo alto en lo que respecta a su mantenimiento, ya que en la mayoría de casos se deberá estar atento a la actualización de forma manual. Instalación La instalación para poner en marcha Newspack es relativamente sencilla, y consta principalmente de 3 partes. La primera de las partes es la instalación de algunos plugins que están en el repositorio de WordPress. org y que facilitan el trabajo de algunos elementos, como AMP, PWA o el SEO. La segunda parte es complementar esos plugins con los propios del sistema de Newspack. Estos plugins no están en el repositorio por lo que habrá que descargarlos del sistema de desarrollo (en Github). Por último, tenemos disponible los temas, tanto el tema principal base, como algunos Temas Hijo que podemos usar como base para nuestro diseño personalizado. Estos temas tampoco están en el repositorio, por lo que también deberemos descargarlos desde el sitio de desarrollo (Github). Plugins del repositorio Para comenzar se recomienda la instalación de 6 plugins. Son plugins de mucho prestigio, bien mantenidos y bastante optimizados, la mayoría soportados por grandes empresas relacionadas con el mundo WordPress. Podemos hacer la instalación desde el buscador interno de WordPress. AMP https://es. wordpress. org/plugins/amp/ Este plugins nos ayudará a la creación y soporte del modo AMP. Co-Authors Plus https://es. wordpress. org/plugins/co-authors-plus/ Permite asignar a un contenido más de un autor. Jetpack https://es. wordpress. org/plugins/jetpack/ Son un conjunto de herramientas para potenciar WordPress. PWA https://es. wordpress. org/plugins/pwa/ Permite la activación del Progressive Web Apps. Site Kit by Google https://es. wordpress. org/plugins/google-site-kit/ El paquete de herramientas de sincronización con Google. Yoast SEO https://es. wordpress. org/plugins/wordpress-seo/ El paquete de herramientas para SEO. Plugins de Newspack Esta lista de plugins deberemos descargarlos directamente desde el sitio de desarrollo. Son más de 10 plugins que deberemos mantener actualizados de forma manual. Tanto la instalación como la actualización se hace desde la zona de plugins, y Subir plugin. Recuerda que, excepto este primer plugin (Newspack) el resto de plugins son opcionales, por lo que es recomendable que mires si realmente te interesa en el proyecto. Otros, son herramientas que facilitan la integración o migración. Newspack (obligatorio) Una avanzada plataforma de publicación y generación de ingresos de código abierto para organizaciones de noticias. Descargar la última versión de Newspack. Newspack Google Ad Manager Integración de servicios publicitarios. Descargar la última versión de Newspack Google Ad Manager. Newspack Blocks Una colección de bloques para editores de noticias. Descargar la última versión de Newspack Blocks. Newspack Campaigns Campañas superpuestas e integradas compatibles con AMP. Descargar la última versión de Newspack Campaigns. Newspack Image Credits Añade información sobre los créditos de las fotos a las imágenes. Descargar la última versión de Newspack Image Credits. Newspack Listings Listados y directorios de sitios de Newspack. Descargar la última versión de Newspack Listings. Newspack Media Partners Añade socios de medios de comunicación y sus logotipos a las publicaciones. Destinado a publicaciones en conjunto con otros medios.... --- WordPress 5.9 va a dar soporte desde la versión de PHP 5.6 hasta PHP 8.1 y en este artículo se presenta un pequeño resumen de pruebas de carga y rendimiento de cómo funciona con cara una de las versiones disponibles. Aunque en estos momentos todavía está solo disponible PHP 8. 1 RC2, sin duda esta nueva versión de PHP va a dar mucho que hablar. Esto también significa que a partir de su lanzamiento, solamente tendremos como versiones soportadas PHP 7. 4 (únicamente con soporte de seguridad), PHP 8. 0 y PHP 8. 1. Como ya es sabido, Matt tomó en agosto de 2020 la decisión de que no se cumpliera lo establecido en el roadmap de que WordPress 5. 6 dejase de dar soporte a PHP 5. 6 y que diera soporte a PHP 8. 0, pero ha pasado un año más y a partir de este WordPress 5. 9 parece que se dará soporte a 8 versiones de PHP diferentes. Así que WordPress 5. 9 va a dar soporte a las siguientes versiones de PHP: PHP 5. 6. 20+PHP 7. 0PHP 7. 1PHP 7. 2PHP 7. 3PHP 7. 4PHP 8. 0PHP 8. 1 Hay que tener en cuenta que, aunque WordPress ya es compatible con PHP 8. 0 y lo será con PHP 8. 1, la versión recomendada en estos momentos sigue siendo una versión que únicamente tiene soporte de seguridad: PHP 7. 4. ¿Funciona mejor WordPress con PHP 8. 1? Una vez más, este estudio que planteo tiene poco de científico, está hecho simplemente por curiosidad, pero sí que he de decir que las cifras, a nivel comparativo, son correctas. Lo que se compara es siempre lo mismo y con la máxima similitud en configuración (en versiones de PHP antiguas hay algunas configuraciones que se han eliminado al no ser compatible). La prueba, esta vez, simplemente es con un contenido de una entrada de Minion Ipsum, por lo que son simplemente 4 bloques de párrafo en Twenty TwentyOne. Se ha utilizado un servidor con 4 CPU y 8 GB de RAM (y 10 GB de disco NVMe). Se han omitido cachés y no se ha configurado JIT. He usado una configuración amplia para que no haya cuellos de botella ni en el servidor web ni en la base de datos y sea capaz de comerse todo el tráfico. El experimento está hecho en un VPS con Ubuntu 20, con las últimas versiones de cada versión de PHP disponibles, y con una configuración de PHP optimizada. También lo están nginx y MariaDB. Todos los resultados se han obtenido con la herramienta "ab", y "wrk" con los siguientes comandos: ab -n 1024 -c 4 https://example. com/ wrk -c128 -d10s -t1 --latency --timeout 5s https://example. com/ Antes de cada análisis se ha reiniciado el servidor para que estuviera completamente limpio y se han ejecutado exactamente los mismos comandos en el mismo orden con tal de que el test sea lo más fiable posible y en las mismas condiciones. Tiempo en conseguir la prueba Tiempo en conseguir 1024 peticiones, separado en 4 hilos. Cuanto menor es el valor, mejor. PHPTiempo (s)PHP 5. 615,131PHP 7. 07,517PHP 7. 17,517PHP 7. 27,190PHP 7. 36,816PHP 7. 46,688PHP 8. 06,713PHP 8. 16,441Los datos son en segundos (con 3 decimales) Peticiones por segundo Peticiones por segundo conseguidas en varias pruebas. Cuanto mayor es el valor, mejor. PHPab (req/s)wrk (req/s)PHP 5. 667,6856,87PHP 7. 0136,23138,32PHP 7. 1136,22137,63PHP 7. 2142,42144,51PHP 7. 3150,24150,10PHP 7. 4153,12156,59PHP 8. 0152,54156,41PHP 8. 1158,98167,30Los datos son en peticiones por segundo (con 2 decimales) Tiempo medio de las peticiones Vendría a ser el TTFB (Time To First Byte). Cuanto menor es el valor, mejor. PHPTiempo (ms)PHP 5. 659,104PHP 7. 029,363PHP 7. 129,365PHP 7. 228,085PHP 7. 326,624PHP 7. 426,123PHP 8. 026,222PHP 8. 125,161Los datos son en milisegundos (con 3 decimales) Petición más rápida Tiempo de la petición (de las 1024 realizadas) que más rápido ha sido creada. Cuanto menor es el valor, mejor. PHPTiempo (ms)PHP 5. 651PHP 7. 026PHP 7. 126PHP 7. 224PHP 7. 323PHP 7. 423PHP 8. 023PHP 8. 122Los datos son en milisegundos (con 3 decimales) Percentil Tiempo de respuesta (ms) El porcentaje de las peticiones realizadas ha tardado menos de ese tiempo (en milisegundos). Cuanto menor es el valor, mejor. PHP90% (ms)95% (ms)99% (ms)PHP 5. 6687887PHP 7. 0323337PHP 7. 1323545PHP 7. 2303341PHP 7. 3293137PHP 7. 4282937PHP 8. 0283040PHP 8. 1272937Los datos son en milisegundos Distribución de latencia Tiempo que ha llevado hacer las peticiones (tiempo máximo, 10 segundos) y peticiones totales hechas en esos 10 segundos. Cuanto menor es el valor, mejor. PHP50% (s)75% (s)90% (s)99% (s)req/10sPHP 5. 64. 114. 254. 344. 46571PHP 7. 01. 791. 811. 831. 861389PHP 7. 11. 771. 811. 831. 871383PHP 7. 21. 691. 711. 731. 761450PHP 7. 31. 661. 691. 711. 751506PHP 7. 41. 561. 601. 631. 671572PHP 8. 01. 561. 631. 681. 741569PHP 8. 11. 491. 511. 531. 561679Los datos son en segundos Conclusiones Como decía al principio, no son datos científicos porque lo he probado en un entorno bastante simple, pero puede dar una pequeña idea de las mejoras que suponen cada una de las versiones. PHP 8. 1 podría aportar una mejora de velocidad del 5-7% con respecto a PHP 8. 0. PHP 8. 1 va 3 veces más rápido que PHP 5. 6Con respecto a PHP 5. 6PHP 7. 3 va 2,63 veces más rápidoPHP 7. 4 va 2,73 veces más rápidoPHP 8. 0 va 2,74 veces más rápidoPHP 8. 1 va 2,94 veces más rápido --- Aunque hoy en día todo está en UTF-8 (incluso en UTF-8 mb4) no siempre ha sido así, y cuando hay migraciones con mysqldump es posible encontrarse que al restaurar aparecen "letras raras". Aunque hoy en día todo está en UTF-8 (incluso en UTF-8 mb4) no siempre ha sido así, y cuando hay migraciones con mysqldump es posible encontrarse que al restaurar aparecen "letras raras". Esas letras raras suelen corresponder con letras "no ascii", es decir, letras como "á" o "ñ" y que se ven de forma extraña. En la mayoría de casos esto viene porque las bases de datos antiguas no están configuradas en UTF-8 por defecto, por lo que al exportar nos aparecerán problemas de codificación que se van arrastrando hasta la restauración. Deberemos seguir 3 pasos a la hora de hacer la copia de seguridad y restaurarla. Copia de Seguridad El primero de los pasos es hacer el mysqldump, pero con unos cambios significativos de lo que es habitual. mysqldump --default-character-set=latin1 basededatos -r copiadeseguridad. sql Por un lado, definiremos el set de caracteres en latin1 (--default-character-set=latin1) que es lo que por defecto viene con las bases de datos antiguas. Por otro lado no haremos el habitual ">" sino un "-r" para guardar el fichero. Eliminando "latin1" El siguiente paso será el de eliminar la línea que ha añadido la descarga. Podemos hacerlo manualmente, simplemente abriendo el fichero y buscando en las primeras líneas el texto, y eliminándolo: /*! 40101 SET NAMES latin1 */; O podemos lanzar un comando para que lo elimine (por ejemplo si el fichero es muy grande). sed -i 's/\/*! 40101 SET NAMES latin1 *\/;/ /' copiadeseguridad. sql Restaurando la copia Para restaurar la copia accederemos al nuevo servidor de base de datos y entraremos en la base de datos forzando el nuevo set de caracteres. mysql --default-character-set=utf8mb4 basededatos Una vez dentro, estableceremos el set: SET names 'utf8'; Y posteriormente cargaremos el nuevo fichero de la base de datos. SOURCE copiadeseguridad. sql; Ahora deberíamos poder acceder a nuestro WordPress y ver correctamente los caracteres del sitio. --- ¿Cuántos WordPress tienes? ¿Lo sabes? Yo a veces no... y esa duda me genera una cuestión: ¿cómo puedo saber cuántos tengo y si están actualizados? ¿Cuántos WordPress tienes? ¿Lo sabes? Yo a veces no... y esa duda me genera una cuestión: ¿cómo puedo saber cuántos tengo y si están actualizados? Para usar esta herramienta deberemos tener WP-CLI previamente instalado, y lo más probable es que necesites acceder al servidor como root, aunque un usuario "normal" también debería poderlo usar. Lo único que deberemos actualizar en el fichero es la ruta principal completa del servidor donde comenzar a buscar, y por eso deberíamos tener todos los sitios restringidos en una carpeta general, tipo /home/wordpress/, /data/ o /webs/, por ejemplo. En este ejemplo vamos a usar la última: /webs/. Primero crearemos nuestro fichero buscador. cd /webs/ touch wordpress-finder. sh chmod +x wordpress-finder. sh vim wordpress-finder. sh E incluiremos este código: #! /bin/bash ##### HOST_PATH="/webs/" ##### # PONIENDO AL DIA WP-CLI echo "" echo "Actualizando WP-CLI a la última versión:" wp cli check-update --quiet --allow-root wp cli update --quiet --allow-root wp cli version --allow-root # INSTALANDO WP-CLI FIND echo "" echo "Revisando el buscador de WP-CLI:" if then echo "Buscador de WP-CLI instalado. " else echo "Instalando buscador de WP-CLI:" wp package install wp-cli/find-command --quiet --allow-root if then echo "Buscador de WP-CLI instalado. " else echo "Se ha producido un error. No se ha podido instalar el buscador de WP-CLI. " echo "Prueba a instalarlo manualmente. " echo "" echo "wp package install wp-cli/find-command" echo "" exit 1 fi fi # BUSCANDO SITIOS echo "" echo "Buscando sitios WordPress:" WP_DATA=`wp find $HOST_PATH --format=csv --fields=wp_path,version --allow-root` WP_TOTAL=`echo "$WP_DATA" | wc -l` if then let WP_TOTAL=WP_TOTAL-1 else WP_TOTAL=0 fi echo "Se ha encontrado un total de ${WP_TOTAL} WordPress". for WP_D in $WP_DATA do echo "" echo "********************************************************************************" echo "" echo "WordPress" echo "" WP_PATH=`echo "$WP_D" | awk -F, 'NR { print $1 }'` echo "- Ruta: ${WP_PATH}" WP_SITE_NAME=`wp option get blogname --path="${WP_PATH}" --allow-root` echo "- Nombre: ${WP_SITE_NAME}" WP_SITE_URL=`wp option get siteurl --path="${WP_PATH}" --allow-root` echo "- URL: ${WP_SITE_URL}" WP_VERSION=`echo "$WP_D" | awk -F, 'NR { print $2 }'` echo "- Versión WP: ${WP_VERSION}" WP_VERSION_UPD=`wp core check-update --path="${WP_PATH}" --format=csv --allow-root | awk FNR-1 | awk -F, 'NR { print $1 }'` if then echo "- Actualización: ${WP_VERSION_UPD}" fi echo "" echo "Themes" echo "" WP_THEMES=`wp theme list --fields=name,update,version,update_version --format=csv --path="${WP_PATH}" --allow-root | awk FNR-1` WP_TOTAL_THEMES=`echo "$WP_THEMES" | wc -l` echo "- Temas: ${WP_TOTAL_THEMES} temas". for WP_T in $WP_THEMES do WP_THEME_UPD=`echo "${WP_T}" | awk -F, 'NR { print $2 }'` if then WP_THEME_NAME=`echo "${WP_T}" | awk -F, 'NR { print $1 }'` WP_THEME_ACT=`echo "${WP_T}" | awk -F, 'NR { print $3 }'` WP_THEME_NEW=`echo "${WP_T}" | awk -F, 'NR { print $4 }'` echo "- Tema actualizable: ${WP_THEME_NAME} ${WP_THEME_ACT} -> ${WP_THEME_NEW}" fi done echo "" echo "Plugins" echo "" WP_PLUGINS=`wp plugin list --fields=name,update,version,update_version --format=csv --path="${WP_PATH}" --allow-root | awk FNR-1` WP_TOTAL_PLUGINS=`echo "$WP_PLUGINS" | wc -l` echo "- Plugins: ${WP_TOTAL_PLUGINS} plugins". for WP_P in $WP_PLUGINS do WP_PLUGIN_UPD=`echo "${WP_P}" | awk -F, 'NR { print $2 }'` if then WP_PLUGIN_NAME=`echo "${WP_P}" | awk -F, 'NR { print $1 }'` WP_PLUGIN_ACT=`echo "${WP_P}" | awk -F, 'NR { print $3 }'` WP_PLUGIN_NEW=`echo "${WP_P}" | awk -F, 'NR { print $4 }'` echo "- Plugin actualizable: ${WP_PLUGIN_NAME} ${WP_PLUGIN_ACT} -> ${WP_PLUGIN_NEW}" fi done echo "" echo "********************************************************************************" done echo "" echo " -- FIN --" echo "" echo "" Una vez lo tengamos, podemos ejecutar el fichero bash wordpress-finder. sh Lo que nos devolverá algo tal que así: Actualizando WP-CLI a la última versión: WP-CLI 2. 5. 0 Revisando el buscador de WP-CLI: Buscador de WP-CLI instalado. Buscando sitios WordPress: Se ha encontrado un total de 2 WordPress. ******************************************************************************** WordPress - Ruta: /webs/example/www. example. com/ - Nombre: Example - URL: https://www. example. com - Versión WP: 5. 7. 2 - Actualización: 5. 8 Themes - Temas: 2 temas. - Tema actualizable: twentytwentyone 1. 3 -> 1. 4 Plugins - Plugins: 10 plugins. - Plugin actualizable: autoptimize 2. 8. 4 -> 2. 9. 0 - Plugin actualizable: gutenberg 11. 0. 0 -> 11. 1. 0 - Plugin actualizable: redis-cache 2. 0. 18 -> 2. 0. 21 - Plugin actualizable: flush-opcache 4. 1. 0 -> 4. 1. 1 - Plugin actualizable: wp-super-cache 1. 7. 3 -> 1. 7. 4 ******************************************************************************** ******************************************************************************** WordPress - Ruta: /webs/example/test. example. com/ - Nombre: Test example - URL: https://test. example. com - Versión WP: 5. 8 Themes - Temas: 1 temas. Plugins - Plugins: 8 plugins. ******************************************************************************** -- FIN -- Y, con este sistema, además de encontrar WordPress que quizá teníamos olvidados, también encontraremos aquellas actualizaciones pendientes. NOTA FINAL: Este es uno de mis primeros scripts bash más complejos que he hecho... así que, por favor, si tienes alguna sugerencia de mejora, por favor, házmela llegar para mejorar el código. --- La seguridad, hoy en día, ya no es suficiente con un usuario y una contraseña, ya sea más o menos segura. Ahora es necesario un segundo factor de autenticación. La seguridad, hoy en día, ya no es suficiente con un usuario y una contraseña, ya sea más o menos segura. Ahora es necesario un segundo factor de autenticación. Si bien es cierto que WordPress por defecto genera claves bastante seguras, nunca puedes saber si posteriormente un usuario realmente acaba poniendo una segura o no segura, así que podemos forzar a determinados usuarios a usar un sistema de 2FA (segundo factor de autenticación) / MFA (multi factor de autenticación). Personalmente soy muy fan de los plugins que la propia Comunidad WordPress hace, a modo de feature plugin, como podría ser este, y es que esta funcionalidad que aporta el plugin quizá debería venir por defecto en el propio núcleo de WordPress. El plugin Two-Factor viene de una propuesta de 2013, que se materializó en 2018 con la creación de un repositorio dentro de WordPress para su desarrollo. El plugin crea una pequeña ficha en el perfil del usuario en el que se pueden configurar 4+1 métodos: Correo electrónico:Si se activa este sistema, tras introducir el usuario y contraseña, te manda un correo electrónico en el que viene un código (numérico) que tendrás que introducir. Contraseña de un solo uso basada en tiempo (TOTP):Deberás configurar una aplicación que genere códigos de tiempo TOPT. Lo más habitual es escanear el código QR que ofrece y usar una aplicación del móvil (tipo FreeOTP -código abierto-). Si se activa este sistema, tras introducir el usuario y contraseña, te pide el código numérico generado por la aplicación, que tendrás que introducir. Claves de seguridad FIDO U2F:Si tienes una llave de seguridad FIDO / U2F, que es un elemento de hardware, podrás incluirla en la lista y cuando accedas a WordPress te pedirá que la utilices. Códigos de verificación de respaldo (de un solo uso):Siempre está bien generar estos 10 códigos únicos y guardarlos. Son códigos de un sólo uso que permiten el acceso si el resto de sistemas falla (por ejemplo, imagina que el correo electrónico no llega, que ya no tienes la App en el móvil o que no tienes a mano el dispositivo. Método simulado:Este es un método de prueba. Sólo debe usarse para hacer pruebas y nunca en producción. Hasta ahora era muy fan de usar, al menos, un código por correo si es que tu correo tiene ya de por sí un método de 2FA, pero como últimamente se están produciendo muchos hackeos en dispositivos móviles (que incluyen los accesos del correo y de las aplicaciones 2FA) he decidido dar un paso más allá y hacer pruebas con un dispositivo físico, que aparentemente es como un pendrive. Como es mi primer dispositivo me he ido a lo fácil y barato, que no tiene validación por huella como tienen otros. HYPERFIDO Pro MINI‎SoloKeys Solo Este dispositivo es un pendrive muy pequeño que incluye un botón/led. Una vez configurado en el sistema operativo, en el fondo es un hardware que lleva una clave interna que es la que valida que eres tú. Otros dispositivos que pueden ser interesantes por calidad/precio: Winkeo FIDO U2FWinkeo FIDO2Yubico Security Key NFC Por norma general lo mejor es configurar varias opciones y dejar una de ellas por defecto. En caso de que no tengas opción de usar esa, siempre podrás utilizar un sistema alternativo. Para registrar una nueva Clave de Seguridad nueva hemos de pulsar en el botón de "Registrar una nueva clave" y nos saltará el sistema operativo para que la pongamos. Una vez puesta, normalmente pide validarla (que en el caso que os comento, es pulsar la bombilla led que parpadea) y una vez esto, podemos cambiarle el nombre al dispositivo. A partir de aquí, cuando accedamos a nuestro WordPress nos pedirá el usuario y contraseña, y posteriormente alguno de los sistemas de seguridad de segundo factor de autenticación disponibles. Sin duda un siguiente paso en la mejora de la seguridad para el acceso a los sitios WordPress. --- Una de las recomendaciones habituales que se hacen para WordPress para una mejor optimización es la de no usar el sistema de WP-Cron nativo, sino que hacer llamadas mediante un programador de tareas. Una de las recomendaciones habituales que se hacen para WordPress para una mejor optimización es la de no usar el sistema de WP-Cron nativo, sino que hacer llamadas mediante un programador de tareas. Y aunque existen múltiples formas de hacer las peticiones para los crones, la óptima es usar WP-CLI. En un WordPress simple podríamos hacer una petición tal que así: */5 * * * * wp cron event run --due-now --path=/home/example. com/ >/dev/null 2>&1 Este código lanzaría todos los hooks pendientes cada 5 minutos. Pero, en un WordPress MultiSite hay que tener presente que cada uno de los subsitios ha de lanzar su propio cron... y, si tienes 3 o 4 controlados, pues podrías añadir esas 3 o 4 líneas en el cron... pero ¿qué pasa si tienes sitios que se van creando o van archivando? En este caso podemos hacer un pequeño script que sea el que se encargue de hacer las peticiones. Por ejemplo podemos guardarlo como cron. sh. #! /bin/bash WP_PATH="/webs/example. com/" SITE_URLS=`php "$(which wp)" site list --fields=url --archived=0 --deleted=0 --format=csv --path="$WP_PATH" | sed 1d` for SITE_URL in $SITE_URLS do php "$(which wp)" cron event run --due-now --url="$SITE_URL" --path="$WP_PATH" --quiet done Con este código básicamente hacemos 2 pasos. El primero de ellos es sacar un listado de todos los sitios web que hay en el WordPress Multisite, pasándole la ruta donde está el wp-config. php. Una vez tenemos la lista, vamos sitio a sitio y lanzamos los crones pendientes que haya para ese sitio. Ahora podremos configurar este cron como: */5 * * * * bash /home/cron. sh >/dev/null 2>&1 Con este sistema podremos programar los crones y dará igual si se añaden o archivan sitios, ya que cada vez que se lanza la tarea sacará la lista de sitios disponibles que no hayan sido archivados o eliminados. --- En muchas ocasiones necesitamos probar un plugin, un tema o alguna funcionalidad concreta de WordPress, pero es muy probable que te dé pereza tener que hacer una instalación completa para probar una funcionalidad. En muchas ocasiones necesitamos probar un plugin, un tema o alguna funcionalidad concreta de WordPress, pero es muy probable que te dé pereza tener que hacer una instalación completa para probar una funcionalidad. Aquí es donde entran los servicios de WordPress Sandbox, unos sitios web que con unos pocos clics te crean un WordPress que dura sólo un tiempo determinado, limitado en cuanto a recursos, pero disponible para ser ese cajón de arena en el que jugar. Hace algún tiempo teníamos el ya desaparecido “poopy. life” que no requería nada para usarse, sólo acceder. Al desaparecer comenzaron, otros sitios, a tener cierta visibilidad. Tabla comparativa SITIORegistroVolumenDestrucción (sin/reg)Destrucción (con/reg)Versiones WordPressWordPress MultiSiteVersiones Beta y/o RCVersiones PHPSubida de MediaContenido InstaladoInstaWPOpcional10 sitios8 horas2 díasMuchasNoSíMúltiples256 MBNativoJurasicOpcional7 díasNingunaNoNoNo512 MBNativoQSandboxObligatorio1 sitio30 díasNingunoNoNoNo12 MBNativoSandbox PageObligatorio1 sitioNingunoNoNoNo128 MBNativoTasteWPOpcional6 sitios2 días7 díasMuchasSíNoMúltiples60 MBNativoTrincheraDEVObligatorio1 sitio30 díasNingunoNoNoNo400 MBNativoWeTopiObligatorio3 sitios5 días15 díasNingunoNoNoMúltiples200 MBNativoWPSandboxNo8 horasAlgunasSíSíNo128 MBDemoWP-SandboxObligatorio1 sitioNingunoNoNoNo3 MBNativo ¿Cuál elegir? Probar versiones no estables / Beta / RC En el caso que se quieran hacer pruebas de plugins y configuraciones de PHP poco estables (como una versión de desarrollo de WordPress, o una versión de PHP que no es la que habitualmente usas, la mejor solución sería InstaWP. Probar un plugin o theme rápido En este caso hay dos opciones. Si la parte más técnica no te preocupa (por ejemplo, poder elegir PHP) WPSandbox es una buena opción, ya que incluye contenido "demo" que para visualizar un tema o probar puede ir bien. Si te interesa hacer pruebas en profundidad, pero es algo rápido (de ponerte, probarlo y olvidarte), seguramente una buena opción sea InstaWP. Probar un WordPress Multisite Si quieres probar rápidamente un WordPress Multisite sin necesidad de tener que hacer tú las configuraciones, la solución más rápida es TasteWP. Algunos detalles InstaWP Tiene una integración con Slack si estás registrado. Desde Slack puedes usar el comando /wp para crear una instancia de forma inmediata. TasteWP Al crear la instalación permite un WP-Config con ciertas configuraciones avanzadas. Sandbox. Page Es un Plesk con el WordPress Toolkit. Permitiría convertir el sitio a MultiSite con Subdominios. ¿Sabes de algún otro proveedor? Si conoces algún otro proveedor que no está en la lista, por favor, dímelo y haré una pequeña revisión para su análisis y comparativa. --- Cuando se accede a un servidor se puede hacer por SSH, y por defecto con un usuario y contraseña. Pero si has de dar acceso a otras personas, lo mejor es darles acceso mediante una clave SSH generada para cada usuario. Cuando se accede a un servidor se puede hacer por SSH, y por defecto con un usuario y contraseña. Pero si has de dar acceso a otras personas, lo mejor es darles acceso mediante una clave SSH generada para cada usuario. Estas claves están formadas por dos ficheros, uno de ellos incluye la llamada "clave pública" y la otra la "clave privada". La privada es tuya y nunca has de dársela a nadie, y la pública es la que puedes usar en los servidores. Generando las claves Linux / Mac Si estás en un servidor Linux o Mac, puedes usar la herramienta ssh-keygen. Esta herramienta te pedirá dónde quieres guardar los ficheros y una vez acabes tendrás los dos allí disponibles. Al final acabará devolviendo algo similar a: Your identification has been saved in /your_home/. ssh/id_rsa Your public key has been saved in /your_home/. ssh/id_rsa. pub The key fingerprint is: SHA256:/hk7MJ5n5a5fsaTVUZr+2Qt+qCiS7BIm5Iv0dxrc3ks user@host The key's randomart image is: +-------+ | . | | + | | + | | . o . | |o S . o | | + o. . oo... . o| |o = oooooEo+ ... o| |. . o *o+=. *+o... . | | =+=ooB=o... . | +---------+ Windows Para generar una clave en Windows lo mejor es usar el programa Puttygen. Pulsaremos en Generate, moveremos el ratón por la pantalla, y al acabar generará una serie de códigos. Pondremos una contraseña segura, por favor, y guardaremos tanto la "public key" como la "private key". Estos dos ficheros los mantendremos a resguardo. Publicando las claves Lo primero de todo es, si estás entrando como root, crear un usuario con los permisos para gestionar todo, a la antigua usanza. Por ejemplo, vamos a crear el usuario wpsysadmin. adduser wpsysadmin Nos pedirá una contraseña y se la pondremos, además de algunos otros datos. Ahora le daremos permisos de "sudo" para poder acceder a todo el sistema. usermod -aG sudo wpsysadmin Ahora le asignaremos una clave SSH, ya que tenemos la clave pública disponible. La abriremos con un editor de texto o la mostraremos por pantalla. El contenido será similar a este: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7457sp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test Entraremos en el servidor donde queremos instalar la clave y crearemos, si no existe, la carpeta correspondiente. mkdir -p ~/. ssh Y lanzaremos un comando tal que así (acortado para hacerlo legible): echo 'ssh-rsa AAAAB3NzaC1yc2EAAA... Q== demo@test' >> ~/. ssh/authorized_keys Y daremos los permisos correspondientes. chmod -R go= ~/. ssh Desactivando las contraseñas Un último paso posible es el de desactivar las contraseñas tradicionales y sólo acceder con claves SSH. Para ello deberíamos hacer lo siguiente. vim /etc/ssh/sshd_config Allí deberemos modificar el parámetro PasswordAuthentication de "yes" a "no". PasswordAuthentication no Una vez lo hagamos, reiniciaremos el servicio SSH. systemctl restart ssh Accediendo con clave SSH En la mayoría de programas de acceso por SSH tendrás la posibilidad de incluir un usuario y contraseña, o un usuario y Clave SSH, que es lo que configuraremos. Y, a partir de este momento, cuando accedas al servidor, lo deberás acceder con tu clave privada y la contraseña que configuraste al generarla. --- Con el RGPD, la LOPD y la ePrivacy la medición se ha vuelto más complicada y, si queremos que todo funcione correctamente y podamos medir de primera mano hemos de usar un sistema en el que las cookies no sean un problema. Con el RGPD, la LOPD-GDD y la ePrivacy la medición se ha vuelto más complicada y, si queremos que todo funcione correctamente y podamos medir de primera mano hemos de usar un sistema en el que las cookies no sean un problema. Y para esto tenemos una opción interesante que es la de SealMetrics, una herramienta compatible con los sistemas de medición de Google Analytics (utm_*) pero que no utiliza ningún sistema de cookies a la hora de realizar la adquisición de datos. Instalación Cuando nos damos de alta, y para facilitar la analítica, nos ofrece la posibilidad de usar un plugin. Tenemos la opción de simplemente usar un sistema que contabilice las páginas (plugin de WordPress) o uno que también contabilice las ventas y conversiones, y la adquisición de tráfico de campañas (plugin de WooCommerce). Si seleccionamos WordPress (o WooCommerce) nos dará las instrucciones para su instalación. De todo, lo importante es el identificador que nos dará para nuestro sitio web, además de la descarga del plugin. Subiremos el plugin a través del panel de "Añadir plugin" de nuestro WordPress, y lo activaremos. Una vez activado, configuraremos el identificador y guardaremos. ¡Y ya tendremos todo configurado y comenzando a sumar! Al cabo de unos minutos ya podremos comenzar a ver algunos datos de nuestro sitio. Usuarios Esta plataforma permite crear múltiples usuarios y múltiples sitios, por lo que con el pago tienes elementos ilimitados. Al crear un usuario puedes asignarle a qué sitios van a tener acceso, de forma que si tienes clientes, puedes darle información sólo a sus cuentas o sitios web. Sitios Podemos crear cuentas nuevas para sitios nuevos. Primero añadiremos el nombre del sitio y su dominio. Después incluiremos la zona horaria en la que queremos que se muestren los datos. Y finalmente podemos dejar el sistema de métricas de Google Analytics o configurar el nuestro propio. El sistema nos dará las instrucciones para configurar cualquier plataforma, además del ID de Cuenta, que podemos usar en los plugins de WordPress / WooCommerce. 1st Party Tracker Code El sistema también te permite la creación de un subdominio propio para el uso de su plataforma. Para ello has de configurar un subdominio. Con este sistema, todas las cookies se tratarán como si de un sistema propio se tratase, por lo que si se generan cookies o cualquier otro elemento, serán propios y no de terceros. --- Seguro que usas la herramienta "top" o incluso "htop" para que se vea más colorido a la hora de analizar el estado de recursos de tu servidor, pero esto sólo analizar los procesos... Seguro que usas la herramienta "top" o incluso "htop" para que se vea más colorido a la hora de analizar el estado de recursos de tu servidor, pero esto sólo analizar los procesos... ¿Y si en la misma pantalla pudiéramos ver los procesos, recursos, tráfico de red y uso de disco? La solución está en la herramienta es Glances. Instalación Hay varias formas de instalarlo. La oficial es: wget -O- https://bit. ly/glances | /bin/bash Aunque, por ejemplo en Ubuntu tienes apt -y install glances Ejecución Una vez instalado puedes ejecutarlo y ver la información: glances Que mostraría algo así: Funcionalidades y trucos Esta herramienta es muy flexible y dispone de mil sistemas para extraer los datos de la máquina. Por ejemplo, podemos mostrar por pantalla en un JSON algunos datos: glances --stdout cpu. user,mem. used,load Y quien dice JSON, dice CSV: glances --stdout-csv now,cpu. user,mem. used,load Usar como servicio Algo interesante es que se puede acceder desde fuera para recoger información de cada máquina, pero para ello deberíamos arrancar la aplicación como un servicio para que siempre esté disponible. Esto lo podemos hacer creando un servicio. Lo primero que haremos es crear el fichero del servicio: vim /etc/systemd/system/glances. service E incluiremos esto: Description=Glances After=network. target ExecStart=/usr/bin/glances -w Restart=on-abort RemainAfterExit=yes WantedBy=multi-user. target Una vez creado, deberemos activar el servicio (para que se active cuando se inicia la máquina). systemctl enable glances. service Y posteriormente lo activaremos. systemctl start glances. service Esto hará que, por defecto, se active un servidor web por el puerto 61208, desde donde podremos recoger los datos. En caso de querer cambiar el puerto o limitar el acceso a determinadas IPs, se puede cambiar esta línea: ExecStart=/usr/bin/glances -w -p 8080 -B 10. 0. 0. 2 Con esto sólo el cliente 10. 0. 0. 2 podría acceder a los datos por el puerto 8080. Configuración Si queremos aplicar alguna configuración lo podemos hacer en la carpeta /etc/glances/. Por defecto ya existe un fichero de configuración en el que viene mucha información predefinida que podemos editar. vim /etc/glances/glances. conf Aunque quizá lo más interesante sea la posibilidad de exportar la información a otros servicios como Elasticsearch, JSON, prometheis o RESTful. La lista es bastante amplia. --- Con la herramienta Logwatch podemos recibir cada día en nuestro buzón de correo un resumen del análisis de los logs del servidor para saber qué ha pasado en la máquina. Con la herramienta Logwatch podemos recibir cada día en nuestro buzón de correo un resumen del análisis de los logs del servidor para saber qué ha pasado en la máquina. Comenzaremos con la instalación de Logwatch apt -y install logwatch Y posteriormente crearemos la carpeta donde va a guardar todos los ficheros que necesita para operar. mkdir /var/cache/logwatch/ Copiaremos la plantilla de configuración para posteriormente configurar a nuestro gusto. cp /usr/share/logwatch/default. conf/logwatch. conf /etc/logwatch/conf/ vim /etc/logwatch/conf/logwatch. conf LogDir = /var/log TmpDir = /var/cache/logwatch Output = mail Format = text Encode = none #CharEncoding = "" MailTo = wordpress@example. com MailFrom = logwatch@example. com #Filename = /tmp/logwatch Archives = yes Range = yesterday Detail = 10 Service = all mailer = "/usr/sbin/sendmail -t" Una vez hayamos acabado podemos ejecutar el comando para ver los resultados por pantalla. logwatch --output=stdout --detail high --format text Si queremos programar el envío diario, podemos configurar un cron para ello, por ejemplo, cada día a las 8 de la mañana. crontab -e 0 1 * * * rm -rf /var/cache/logwatch/* && /sbin/logwatch En el siguiente resultado se puede ver, como ejemplo, un montón de ataques contra el servidor: ################### Logwatch 7. 5. 2 (07/22/19) #################### Processing Initiated: Sun Jul 11 08:34:25 2021 Date Range Processed: yesterday ( 2021-Jul-10 ) Period is day. Detail Level of Output: 10 Type of Output/Format: stdout / text Logfiles for Host: example ################################################################## --------------------- Cron Begin ------------------------ Commands Run: User root: cd / && run-parts --report /etc/cron. hourly: 24 Time(s) test -x /etc/cron. daily/popularity-contest && /etc/cron. daily/popularity-contest --crond: 1 Time(s) test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r: 1 Time(s) test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron. daily ): 1 Time(s) ---------------------- Cron End ------------------------- --------------------- pam_unix Begin ------------------------ cron: Sessions Opened: root: 27 Time(s) sshd: Authentication Failures: root (221. 131. 165. 23): 486 Time(s) www-data (81. 70. 149. 29): 1 Time(s) Invalid Users: Unknown Account: 2002 Time(s) Sessions Opened: root: 2 Time(s) systemd-user: Sessions Opened: root: 2 Time(s) ---------------------- pam_unix End ------------------------- --------------------- SSHD Begin ------------------------ Network Read Write Errors: 17 Negotiation failed: no matching host key type found 143. 137. 166. 137: 3 Times ecdsa-sha2-nistp384: 1 Time ecdsa-sha2-nistp521: 1 Time ssh-dss: 1 Time no matching key exchange method found 105. 203. 195. 68: 2 Times diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1: 2 Times 141. 98. 10. 203: 25 Times diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1: 25 Times Disconnecting after too many authentication failures for user: root : 2 Times Failed logins from: 1. 14. 195. 32: 50 Times root/password: 50 Times 1. 116. 101. 225: 38 Times root/password: 38 Times 1. 116. 237. 80: 70 Times root/password: 70 Times Illegal users from: 1. 116. 101. 225: 1 Time minist123: 1 Time 1. 117. 147. 110: 29 Times postgres: 2 Times user: 2 Times 123456: 1 Time admin: 1 Time argo: 1 Time bot2: 1 Time cent: 1 Time chandra: 1 Time deploy: 1 Time ekp: 1 Time hadoop: 1 Time info: 1 Time jessica: 1 Time joao: 1 Time maria: 1 Time minecraft: 1 Time odoo: 1 Time root123: 1 Time rosa: 1 Time scs: 1 Time sdtdserver: 1 Time starbound: 1 Time test_ftp: 1 Time usuario2: 1 Time webuser: 1 Time wei: 1 Time zhanglei: 1 Time Users logging in through sshd: root: 185. 140. 212. 136: 2 Times Received disconnect: 221. 131. 165. 23 : 162 Time(s) 221. 131. 165. 56 : 83 Time(s) Bye Bye 1. 116. 101. 225 : 39 Time(s) 1. 116. 237. 80 : 70 Time(s) 1. 117. 147. 110 : 31 Time(s) disconnected by user 34. 136. 86. 240 : 14 Time(s) **Unmatched Entries** error: Protocol major versions differ: 2 vs. 1 : 2 Times error: kex protocol error: type 30 seq 1 : 2 Times error: kex_exchange_identification: Connection closed by remote host : 48 Times error: kex_exchange_identification: banner line contains invalid characters : 7 Times error: kex_exchange_identification: client sent invalid protocol identifier "" : 1 Time error: kex_exchange_identification: client sent invalid protocol identifier "\214#" : 1 Time error: kex_exchange_identification: read: Connection reset by peer : 13 Times error: send_error: write: Connection reset by peer : 1 Time message repeated 2 times: : 1 Time message repeated 5 times: : 1 Time ---------------------- SSHD End ------------------------- --------------------- Disk Space Begin ------------------------ Filesystem Size Used Avail Use% Mounted on /dev/sda1 9. 8G 5. 7G 3. 8G 61% / ---------------------- Disk Space End ------------------------- ###################### Logwatch End ######################### --- Cada cierto tiempo tenemos actualizaciones de versiones de MariaDB, y puede ser interesante hacer una actualización entre versiones mayores. ¿Cómo se llevan a cabo? Cada cierto tiempo tenemos actualizaciones de versiones de MariaDB, y puede ser interesante hacer una actualización entre versiones mayores. ¿Cómo se llevan a cabo? NOTA: Este manual está basado específicamente en un Ubuntu 20. 04 y con la versión instalada de MariaDB 10. 5, con el objetivo de actualizar a MariaDB 10. 6. Debería servir en general para cualquier versión Debian / Ubuntu. Antes de empezar, lo ideal sería hacer una copia de seguridad de todos los ficheros de configuración. Puedes hacerlo de varias formas; esta es una de ellas. cd ~ mkdir mariadb-copia/ cp -R /etc/mysql/mariadb. conf. d/* ~/mariadb-copia/ Lo primero que hemos de hacer es actualizar el repositorio. Para ello indicaremos la nueva versión que en este caso va a ser la de MariaDB 10. 6. curl -sS https://downloads. mariadb. com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10. 6" --skip-maxscale Ahora que tenemos establecida la nueva versión, vamos a parar temporalmente la base de datos. service mariadb stop Antes de actualizar o instalar las nuevas versiones, desinstalaremos el servidor de base de datos. No se van a eliminar los datos, sólo el software. apt -y remove mariadb-server mariadb-client mariadb-backup Posteriormente haremos la instalación de la nueva versión, como si fuera un nuevo programa. apt -y install mariadb-server mariadb-client mariadb-backup En caso de tener configuraciones personalizadas, lo más seguro es que sean del fichero del servidor. Puedes recuperar la configuración y adaptarla a la nueva versión recuperando el fcihero. En el caso anterior tendremos el fichero principal en cat ~/mariadb-copia/50-server. cnf Así que haremos los cambios de configuración correspondientes. Una vez acabado, arrancaremos de nuevo MariaDB y validaremos que está funcionando. service mariadb start service mariadb status Para acabar, podemos forzar una actualización y asegurarnos que se ha hecho correctamente. mysql_upgrade --force Una vez acabado el proceso, podemos ir a nuestro WordPress y en Salud del Sitio validar que tenemos la nueva versión instalada. Y con esto tendremos la nueva versión de MariaDB funcionando. --- De la misma forma que queremos saber cuánto tráfico soporta un sitio web y para el que podemos hacer un test de estrés, también podemos aplicar la misma técnica a la base de datos. De la misma forma que queremos saber cuánto tráfico soporta un sitio web y para el que podemos hacer un test de estrés, también podemos aplicar la misma técnica a la base de datos. En este caso vamos a montar una máquina de 4 CPU y 8 GB de RAM exclusivamente para la base de datos, y configurada con MariaDB 10. 5. Configurando el servidor Vamos a aplicar actualizaciones y configuraciones básicas iniciales. Lo primero será establecer la hora del servidor. timedatectl set-timezone 'UTC' timedatectl set-ntp on Y después haremos una actualización completa del sistema. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Instalaremos algunas herramientas habituales. apt -y install ca-certificates software-properties-common curl vim zip unzip apt-transport-https fail2ban build-essential unattended-upgrades Y el idioma español por defecto. locale-gen es_ES. UTF-8 ca_ES. UTF-8 en_US. UTF-8 update-locale LANG=es_ES. UTF-8 LANGUAGE="es_ES:en" LC_ALL=es_ES. UTF-8 Activaremos el swap de memoria. cat /proc/sys/vm/swappiness echo "vm. swappiness=60" | tee -a /etc/sysctl. d/99-swappiness. conf swapoff -a && swapon -a Instalando MariaDB Activaremos el repositorio de MariaDB. curl -sS https://downloads. mariadb. com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10. 5" --skip-maxscale Y posteriormente instalaremos MariaDB. apt -y install mariadb-server mariadb-client mariadb-backup Haremos la configuración y podremos una contraseña al root. mysql_secure_installation Y activaremos el sistema para que funcione tras un reinicio. systemctl stop mysql. service systemctl enable mysql. service systemctl start mysql. service systemctl status mysql. service Prueba de estrés Para hacer la prueba de estrés utilizaremos la herramienta sysbench. apt -y install sysbench Accederemos al MariaDB y crearemos una base de datos vacía. CREATE DATABASE sbtest; A partir de este momento podemos ejecutar los 3 comandos que nos permitirán hacer pruebas. El primero es el de montar las tablas y elementos. sysbench /usr/share/sysbench/oltp_read_write. lua --mysql-host=localhost --mysql-user=root --mysql-password=password --threads=16 --events=0 --time=60 --report-interval=1 --tables=25 --table_size=100000 --range_selects=off --db-ps-mode=disable prepare Una vez acabe, tendremos las tablas con los datos sobre los que se realizarán las pruebas. sysbench /usr/share/sysbench/oltp_read_write. lua --mysql-host=localhost --mysql-user=root --mysql-password=password --threads=16 --events=0 --time=60 --report-interval=1 --tables=25 --table_size=100000 --range_selects=off --db-ps-mode=disable run Este comando es el que nos dará un informe del funcionamiento. Y finalmente, una vez hayamos acabado, podemos limpiar todo. sysbench /usr/share/sysbench/oltp_read_write. lua --mysql-host=localhost --mysql-user=root --mysql-password=password --threads=16 --events=0 --time=60 --report-interval=1 --tables=25 --table-size=100000 --range_selects=off --db-ps-mode=disable cleanup Resultado sin configuración Si no hacemos cambios en la configuración, lo más probable es que no esté nada actualizado ni optimizado, y los resultados pueden ser muy pobres. SQL statistics: queries performed: read: 321740 write: 128696 other: 64348 total: 514784 transactions: 32174 (533. 92 per sec. ) queries: 514784 (8542. 66 per sec. ) ignored errors: 0 (0. 00 per sec. ) reconnects: 0 (0. 00 per sec. ) General statistics: total time: 60. 2571s total number of events: 32174 Latency (ms): min: 1. 61 avg: 29. 96 max: 1289. 31 95th percentile: 84. 47 sum: 963966. 69 Threads fairness: events (avg/stddev): 2010. 8750/18. 69 execution time (avg/stddev): 60. 2479/0. 00 Como datos interesantes: Transacciones por minuto: 32. 174 (533 por segundo)Consultas por minuto: 514. 784 (8. 542 por segundo) Configuración básica Si revisamos la configuración que viene y que en muchos casos encontramos por Internet cuando buscamos cómo optimizar un WordPress, tendremos un server. cnf similar a este: user = mysql pid-file = /run/mysqld/mysqld. pid basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp lc-messages-dir = /usr/share/mysql lc-messages = en_US bind-address = 127. 0. 0. 1 skip-external-locking character-set-server = utf8mb4 collation-server = utf8mb4_general_ci default-storage-engine = InnoDB skip-name-resolve = 1 # Logs log-error = /var/lib/mysql/mysql-error. log expire_logs_days = 14 slow-query-log = 1 slow-query-log-file = /var/lib/mysql/mysql-slow. log # BinLog log-bin = /var/lib/mysql/mysql-bin expire-logs-days = 14 sync-binlog = 1 # MyISAM key-buffer-size = 32M myisam-recover = FORCE,BACKUP # InnoDB innodb-flush-method = O_DIRECT innodb-log-files-in-group = 2 innodb-log-file-size = 1G innodb-flush-log-at-trx-commit = 1 innodb-file-per-table = 1 innodb-buffer-pool-size = 4G innodb-buffer-pool-instances = 3 innodb-large-prefix = true innodb-file-per-table = true # Safety max-allowed-packet = 16M max-connect-errors = 1000000 sql-mode = "" # Cache y Limits tmp-table-size = 128M max-heap-table-size = 128M query-cache-type = 0 query-cache-size = 00 query_cache_limit = 256K query_cache_min_res_unit = 2k max-connections = 800 thread-cache-size = 100 open-files-limit = 65535 table-definition-cache = 32768 table-open-cache = 32768 Una configuración como esta nos devolverá unos datos tales que estos: SQL statistics: queries performed: read: 487580 write: 195032 other: 97516 total: 780128 transactions: 48758 (812. 36 per sec. ) queries: 780128 (12997. 80 per sec. ) ignored errors: 0 (0. 00 per sec. ) reconnects: 0 (0. 00 per sec. ) General statistics: total time: 60. 0190s total number of events: 48758 Latency (ms): min: 5. 55 avg: 19. 69 max: 360. 06 95th percentile: 29. 72 sum: 960016. 16 Threads fairness: events (avg/stddev): 3047. 3750/11. 35 execution time (avg/stddev): 60. 0010/0. 00 Como datos interesantes: Transacciones por minuto: 48. 758 (812 por segundo)Consultas por minuto: 780. 128 (12. 997 por segundo) Configuración específica En el momento en el que configuras el servidor de base de datos para una configuración concreta de CPU y memoria RAM, además de adaptar el sistema (en este caso está pensado para un WordPress MultiSite), tienes una configuración algo más compleja para el server. cnf. # # Global / Idioma # basedir = /usr bind_address = 0. 0. 0. 0 character_set_server = utf8mb4 collation_server = utf8mb4_general_ci connect_timeout = 60 datadir = /var/lib/mysql default_storage_engine = InnoDB default_tmp_storage_engine = InnoDB lc_messages = es_ES lc_messages_dir = /usr/share/mysql lc_time_names = es_ES pid_file = /run/mysqld/mysqld. pid skip_external_locking = 1 skip_name_resolve = 1 tmpdir = /tmp user = mysql # # General # div_precision_increment = 6 host_cache_size = 128 join_buffer_size = 256M lock_wait_timeout = 3600 max_allowed_packet = 128MB max_connections = 400 max_connect_errors = 1024 max_digest_length = 1024 max_error_count = 1024 max_prepared_stmt_count = 16382 max_sort_length = 1M max_user_connections = 0 preload_buffer_size = 32M query_alloc_block_size = 32K range_alloc_block_size = 32K sort_buffer_size = 4M stored_program_cache = 1024 table_open_cache = 1024 table_open_cache_instances = 4 thread_cache_size = 12 # =8+(max_connections/100) thread_stack = 1M transaction_alloc_block_size = 32K transaction_prealloc_size = 16K # # Logs # log_error = /var/lib/mysql/mysql-error. log log_queries_not_using_indexes = 0 long_query_time = 10 slow_query_log = 1 slow_query_log_file = /var/lib/mysql/mysql-slow. log # #... --- Si utilizas MainWP es posible que en alguna ocasión se te haya desconfigurado un sitio tras una migración, cambio de URL o similar. Si utilizas MainWP es posible que en alguna ocasión se te haya desconfigurado un sitio tras una migración, cambio de URL o similar. En estos casos es muy probable que recibas un error como el siguiente a la hora de reconectar: Error detectado: Este sitio ya contiene un enlace. Por favor, desactiva el plugin MainWP y vuelve a activarlo. Sugerencia: ve al sitio hijo, desactiva y reactiva el plugin MainWP Child y vuelve a intentarlo. Aunque el sistema recomienda que desactives o desinstales el plugin, los datos siguen guardados en la base de datos por lo que es muy posible que no puedas volver a reconectarlo. Esta falta de limpieza de los contenidos en la base de datos deberían ser un elemento que integrase el plugin al desinstalarlo, pero al no hacerlo, sólo nos queda una opción: eliminar los datos basura nosotros mismos. Para comenzar desactivaremos el plugin MainWP Child. No es necesario desinstalarlo, pero si desactivarlo. Al reactivarse se regenerará todo lo que vamos a eliminar. Para ello accedemos a la base de datos de nuestro WordPress, por ejemplo con un phpMyAdmin, y ejecutamos la siguiente consulta: DELETE FROM wp_options WHERE option_name LIKE 'mainwp_%'; Recuerda que deberás revisar el prefijo de las tablas y sustituir wp_ en caso de que nos ea el que hay por defecto. Con esto eliminaremos todos los datos previos del plugin. Recuerda que, si tienes alguna caché de base de datos activada (tipo memcached o Redis) deberás vaciarla, ya que estos datos se quedan almacenados ahí temporalmente. Ahora reactivaremos el plugin MainWP Child y podremos comenzar de nuevo el proceso, generando de nuevo el identificador único, y añadiendo el sitio de nuevo en el panel principal de MainWP. El sitio se volverá a crear sin problema y podremos volver a disfrutar de la herramienta que nos avise de las actualizaciones pendientes. --- Informar al navegador del usuario que visita nuestra página para que permita hacer algunas tareas es algo habitual, y también deberíamos informarle de qué puede o no hacer en cuanto a seguridad. Informar al navegador del usuario que visita nuestra página para que permita hacer algunas tareas es algo habitual, y también deberíamos informarle de qué puede o no hacer en cuanto a seguridad. Y esto lo podemos hacer añadiendo algunas cabeceras de seguridad a nuestro WordPress mediante configuraciones en Apache HTTPD o NGINX (el servidor web) o con algunos plugins. Aquí vamos a ver algunas de esas cabeceras para saber para qué sirven y cómo se utilizan. Strict-Transport-Security (HSTS) Definido en el RFC 6797, el HSTS es una cabecera que indica que el navegador ha de utilizar HTTPS sí o sí en el sitio, y que no puede usar HTTP para nada. En este caso las peticiones HTTP se ignorarían. Hay que indicarle el tiempo que queremos que el navegador se acuerde de que ese sitio ha de visitarse de forma segura. También podemos indicarle si los subdominios de ese sitio también ha de cumplir esta regla. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload; Con esto le diríamos que durante un año ha de cumplir la regla del HTTPS y que los subdominios también han de cumplirlo. Puedes validar si se está haciendo la carga del HSTS de forma correcta con la herramienta hstspreload. org. X-Frame-Options (XFO) Definido en el RFC 7034, el XFO define si una página ha de incluir otra página en las etiquetas , , u . Básicamente permite informar de dos opciones: deny o sameorigin. En el primer caso no se cargaría nada, en el segundo sólo se permitirían contenidos que vengan del mismo sitio. Si nos e indica la cabecera se puede cargar contenido de cualquier lugar. X-Frame-Options: sameorigin; X-Content-Type-Options Con esta cabecera impedimos que el navegador interprete un tipo de fichero como otro. Por ejemplo, si mandamos un , se deberá leer como text/css, o un script como tal. También ayuda a que los textos se procesen como tal (HTML, TXT, XML, JSON, incluso SVG). X-Content-Type-Options: nosniff Content-Security-Policy (CSP) Seguramente esta es la cabecera más compleja de configurar, tanto por lo que supone como por la cantidad de opciones que incluye. Con esta cabecera podemos indicar a qué recursos se puede acceder por parte del navegador para un sitio web y que permiten bloquear la carga de elementos externos o de sitios no controlados. Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'; La lista de directivas es bastante extensa y permiten decidir sobre la carga de scripts, fuentes, media, estilos e incluso workers. Antes de comenzar a usarla es muy recomendable configurar el sistema como Content-Security-Policy-Report-Only, ya que te permitirá ver en la Consola del Navegador los errores o malas configuraciones, pero sin que afecte al usuario, sólo a modo informativo. Una vez se encuentren todas las llamadas externas, este sistema puede ayudar a convertir esa cabecera a la normal. X-XSS-Protection En el caso de que aún no uses CSP, esta cabecera todavía puede ser útil. Con esta cabecera, si el navegador detecta un ataque XSS, se realizarán las acciones correspondientes. X-XSS-Protection: 1; mode=block; X-Permitted-Cross-Domain-Policies Esta cabecera es prácticamente sólo para indicar si Adobe Flash Player puede o no acceder a determinados elementos del usuario. Teniendo en cuenta que este software ya no está disponible, esta cabecera se debería indicar sobre todo si tu sitio tiene acceso alto desde navegadores muy antiguos que aún le dan soporte o si aún utilizas Flash para algo. X-Permitted-Cross-Domain-Policies: none; Referrer-Policy Con esta cabecera indicamos qué información enviar de referrer. Un caso muy habitual es el de la adquisición de tráfico de Google Analytics, en la que podemos ver desde qué páginas nos llega tráfico a nuestra web. Hay varias opciones para esta política y dependerá mucho de la información que quieras dar a otras herramientas y por seguridad. Referrer-Policy: strict-origin-when-cross-origin, origin-when-cross-origin; PolíticaMismo sitioHTTPS → HTTPSHTTPS → HTTPno-referrernada nada nada no-referrer-when-downgradecompletocompletonadaorigindominiodominiodominioorigin-when-cross-origincompletodominiodominiosame-origincompletonadanadastrict-origindominiodominionadastrict-origin-when-cross-origincompletodominionadaunsafe-urlcompletocompletocompleto Cross-Origin-Resource-Policy (CORP) Esta cabecera permite indicar el origen de un recurso y es un sistema sencillo para defenderse de determinados ataques. Además, va acompañada de la contraparte Access-Control-Allow-Origin que decide si un elemento de un sitio está permitido ser llamado desde otro. Cross-Origin-Resource-Policy: same-origin; Si tu sitio devuelve esta cabecera no permitirá el acceso a recursos externos. Access-Control-Allow-Origin Con esta cabecera podemos indicar qué sitios tienen la posibilidad de descargar nuestros contenidos. Con este sistema podemos bloquear la carga de una imagen de nuestro sitio en un sitio de terceros. Access-Control-Allow-Origin: https://www. wpsysadmin. com; Cross-Origin-Opener-Policy (COOP) Este sistema previene la apertura de elementos externos desde otro dominio que no sea el que indicas. Un caso podría ser la apertura de un PDF desde un popup fuera de tu sitio. Cross-Origin-Opener-Policy: same-origin; Cross-Origin-Embedder-Policy: require-corp; Cross-Origin-Embedder-Policy (COEP) Esta cabecera está pensada para permitir o bloquear la carga de contenidos externos y que cumpla el CORP. Un ejemplo habitual es la carga de una imagen desde otro dominio que no es el tuyo. Cross-Origin-Embedder-Policy: require-corp; Cross-Origin-Opener-Policy: same-origin; Permissions-Policy Aunque todavía no lo cubren todos los navegadores, con estas cabeceras podemos indicar al navegador si permitir el acceso o no a determinados elementos de hardware de nuestro dispositivo, por ejemplo, si poder acceder a la cámara o a la información de la batería. Permissions-Policy: geolocation 'self' https://example. com; camera *; microphone 'none'; X-Download-Options Aunque esta cabecera se creó específicamente para Internet Explorer 8, puede ser bastante útil en la descarga de un fichero. Si en tu sitio tienes algún sistema de descargas, es posible que quieras impedir que esa descarga se abra directamente y forzar a que se tenga que guardar en el disco (y así, por ejemplo, que el antivirus haga una revisión completa del mismo). X-Download-Options: noopen; Content-Disposition: attachment; filename=inseguro. html; --- Cada vez se usa menos el acceso FTP y más el de SFTP por simples razones de seguridad. Pero los usuarios del sistema por defecto tienen acceso a ver todo. Cada vez se usa menos el acceso FTP y más el de SFTP por simples razones de seguridad. Pero los usuarios del sistema por defecto tienen acceso a ver todo. Es por esto que puede ser interesante tener usuarios que estén limitados sólo a determinadas carpetas. Por ejemplo, si tienes varios sitios web de varios usuarios y no quieres que un usuario sea capaz de ver los datos de los demás. Limitar el acceso SSH Lo primero que haremos será limitar el acceso de los usuarios a las carpetas correspondientes. Los vamos a juntar todo en el grupo sftp. addgroup sftp Una vez creado el grupo, haremos cambios en el servidor de SSH. Editaremos el fichero de configuración: vim /etc/ssh/sshd_config Buscaremos el código siguiente: Subsystem sftp /usr/lib/openssh/sftp-server Y lo sustituiremos por: Subsystem sftp internal-sftp Posteriormente añadiremos una serie de reglas para los usuarios de este grupo: Match Group sftp ChrootDirectory %h ForceCommand internal-sftp AllowTCPForwarding no PasswordAuthentication yes Una vez acabemos, reiniciaremos el servicio y validaremos que funciona. systemctl restart sshd systemctl status sshd Copiando el sistema Como sólo vamos a dejar que los usuarios accedan a una serie limitada de carpetas, también necesitamos que algunos programas funcionen. Es por esto que deberemos crear una estructura copiada del sistema. En este ejemplo vamos a crear una carpeta para alojar todo en /webs/. mkdir -p /webs/ Validaremos que existen una serie de carpetas reales (no las simbólicas). ls -l /dev/{null,zero,stdin,stdout,stderr,random,tty} que devolverá algo similar a esto: crw-rw-rw- 1 root root 1, 3 jun 25 14:47 /dev/null crw-rw-rw- 1 root root 1, 8 jun 25 14:47 /dev/random lrwxrwxrwx 1 root root 15 jun 25 14:47 /dev/stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 jun 25 14:47 /dev/stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 jun 25 14:47 /dev/stdout -> /proc/self/fd/1 crw-rw-rw- 1 root tty 5, 0 jun 25 14:47 /dev/tty crw-rw-rw- 1 root root 1, 5 jun 25 14:47 /dev/zero Copiaremos algunas de las carpetas a nuestro nuevo lugar raíz. mkdir -p /webs/dev/ mknod -m 666 /webs/dev/null c 1 3 mknod -m 666 /webs/dev/random c 1 8 mknod -m 666 /webs/dev/tty c 5 0 mknod -m 666 /webs/dev/zero c 1 5 Limitaremos el acceso a eta carpeta sólo a root y lo validaremos. Es importante que los permisos completos sean sólo al propietario y no al grupo, por lo que usaremos 0755. chown root: /webs chmod 0755 /webs ls -ld /webs Copiaremos el Bash. mkdir -p /webs/bin cp -v /bin/bash /webs/bin Deberemos copiar algunas bibliotecas. Primero crearemos la estructura de carpetas. mkdir -p /webs/lib/ mkdir -p /webs/lib64/ mkdir -p /webs/lib/x86_64-linux-gnu/ Y validaremos que existen una serie de ficheros. ll /lib/x86_64-linux-gnu/{libtinfo. so. *,libdl. so. *,libc. so. *,ld-linux-x86-64. so. *} ldd /bin/bash Copiaremos los ficheros correspondientes. cp -v /lib/x86_64-linux-gnu/{libtinfo. so. *,libdl. so. *,libc. so. *} /webs/lib/ cp -v /lib64/ld-linux-x86-64. so. * /webs/lib64/ cp -va /lib/x86_64-linux-gnu/libnss_files* /webs/lib/x86_64-linux-gnu/ Finalmente, haremos una copia de los permisos de usuario. mkdir -p /webs/etc/ cp -vf /etc/{passwd,group} /webs/etc/ Con esto tendremos todo lo necesario para que los usuarios puedan conectarse por SFTP e interactuar con la subida y bajada de ficheros. Creando un usuario Los usuarios los crearemos para que sólo tengan acceso a esta carpeta /webs/ que hemos creado y que pertenezcan al grupo sftp. useradd usuarioejemplo -m -d /webs/usuarioejemplo -G sftp Podemos validar que está en su grupo y en el del sftp. groups usuarioejemplo Que nos devolverá algo como: usuarioejemplo : usuarioejemplo sftp Lo siguiente será quitarle los permisos de acceso por SSH, ya que si acceden por SSH tendrían la posibilidad de ejecutar o acceder a cualquier parte, usermod -s /bin/false usuarioejemplo Y finalmente le daremos una contraseña al usuario. passwd usuarioejemplo Ahora nos aseguraremos que la carpeta propietaria de ese usuario es de root y que él no puede acceder. chown root: /webs/usuarioejemplo chmod 0755 /webs/usuarioejemplo Y, como hemos cambiado los permisos, grupos y demás, haremos una nueva copia de los accesos. cp -vf /etc/{passwd,group} /webs/etc/ Accediendo por SFTP En este momento los usuarios podrán acceder por SFTP al servidor, de la misma forma que lo harían por FTP. Por defecto el puerto del FTP es el 21, y el del SFTP es el 22. Creando un sitio web A partir de este momento podríamos crear carpetas para distintos sitios web. Si eres el responsable del sistema, puedes crearle un sitio al usuario. Primero crearíamos la carpeta mkdir /webs/usuarioejemplo/www. dominio. es/ Y finalmente nos aseguramos que tenga sus permisos. chown usuarioejemplo: /webs/usuarioejemplo/www. dominio. es/ En este momento el usuario ya podría gestionar por SFTP todos sus contenidos. --- Es muy probable que tengas plugins o themes para clientes que no son públicos, o código que usas para alguno de tus sitios, que está en Github, y que quieres que se haga un deploy de forma automática. Es muy probable que tengas plugins o themes para clientes que no son públicos, o código que usas para alguno de tus sitios, que está en Github, y que quieres que se haga un deploy de forma automática. Lo primero que necesitamos es un repositorio en Github (o Gitlab). Esta plataforma, en su sección de Settings incluye una subsección llamada Deploy keys. Para añadir una nueva clave necesitaremos ponerle un nombre e incluir su clave. Así que lo primero que hemos de hacer es ir al servidor donde vamos a publicar el contenido de repositorio y crear una. Entraremos por SSH en el servidor de la web y crearemos una clave. Por favor, revisa la cuenta de correo y pon la tuya (es recomendable que sea la misma de Github). ssh-keygen -t rsa -b 4096 -C wordpress@example. com Primero te preguntará dónde quieres dejar tu clave (puedes dejarla en la carpeta que te recomiende) o crear una clave para tu plugin en concreto (vamos a usar /root/. ssh/mi-plugin. id_rsa) Generating public/private rsa key pair. Enter file in which to save the key (/root/. ssh/id_rsa): Posteriormente te pedirá una contraseña. En este caso no pondremos ninguna. El propio servidor será la contraseña. Enter passphrase (empty for no passphrase): Enter same passphrase again: Esto creará tu clave y la guardará, generando dos ficheros, la clave privada (id_rsa) y la clave pública (id_rsa. pub). Your identification has been saved in /root/. ssh/mi-plugin. id_rsa Your public key has been saved in /root/. ssh/mi-plugin. id_rsa. pub Finalmente se generará un identificador único: The key fingerprint is: SHA256:0c7GNvve9cXvzZ0uCcyXncAVNHZXCmumyWLGbXbUuHg wordpress@example. com Puedes revisar que se han creado las dos. Primero veremos la clave privada. cat /root/. ssh/mi-plugin. id_rsa Y posteriormente la clave pública. cat /root/. ssh/mi-plugin. id_rsa. pub Este último código que aparece por pantalla es el que deberemos incluir en Github. Para ello, en el Add new Deploy key, pondremos un nombre (por ejemplo, Plugin mi-plugin en servidor1). ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDMCNTqCtJEAQGnIgFlzeATKvAyezbbSOO0Di7NlRIpVsqm2zGoygnGlLIvLXzIs5IzAGwWLHJkdK8Pm5KvbgrToH2eq1BI8pfpFcI4HwiyjV871QzGcpJbtXnj6tRkmp2eJeFBVdZn8gFfIhlKW8n94yQLQb8OTEm57yiBxPpx97tsT/AAOM/q2KC+KACb1cve31dVAA6vkzOA47curc008iRslWLRdM7ybT/1gUWMmI/10329kYZscd0ZDFtdpfz99Z+Jz0BN/3O6OrUtYmMQKXOGoGTL10n/W9E8KjPzXB4u7tHzzCOIF1tqUD/vhn7CksT25/Pi82jX3aFJh55WuUObtBCd9oRwcF8Th1VZLaV3WEpzroZu1b883rdMDo1+O96lK17zz2oEGZ7OOmm03bnpSdY1/5js/WmdQ7LYnh9tSroSFGVighcrgwPmiJbLXAYWBB79eVqSjt0pX50igl3BnToQy0d5o2ZgrpnPP77RrTlwmCqQxw5H+uR2FH0nKvP8IWTcYHmAeWiajzPo0rhvy8HV2Hvi4seXmpDWax90KB1QdzsHNWIu0gH1OExY2ibcrlRFuaSsfAh0JH6UJSvFfjRt9LYFAb92gwJ/V/82x1GOVNjxLjgrTfxFL3k2trgwFxzioRf7mQveaRChR8IpO7tyc3/kH5mfv/ECRw== wordpress@example. com Es importante que no marquemos la opción de Modo escritura, ya que no es el objetivo de esta clave, que es sólo lectura. Lo siguiente que haremos es añadir una configuración en el servidor. vim ~/. ssh/config E incluiremos algo tal que así. Host mi-plugin Hostname github. com User git IdentityFile /root/. ssh/mi-plugin. id_rsa IdentitiesOnly yes Iremos a la carpeta del sitio web en el que queremos hacer el deploy. cd /webs/www. example. com/wp-content/plugins/ Y lanzaremos la primera sincronización. git clone git@mi-plugin:wpsysadmin/mi-plugin. git carpeta-plugin Deberemos aceptar la primera conexión para que se guarde la confianza entre los servidores. Una vez acabado, veremos que hay una carpeta creada, tal y como la hemos llamado previamente. cd carpeta-plugin/ Allí tendremos ya la primera descarga del repositorio. A partir de aquí, podemos actualizar ejecutando, en esa carpeta, la siguiente llamada. git pull origin main A partir de aquí se puede plantear automatizar la descarga y sincronización según se necesite. --- Ahora que ya tenemos ImageMagick 7 y la extensión para imagick de PHP (mediante PECL), podemos utilizar toda la potencia para WordPress 5.8 que da soporte a algunos formatos nuevos. Si utilizas WordPress sabrás que es mucho más recomendable usar ImageMagick que GD para la gestión de ficheros media, sobre todo por la cantidad de cosas que se pueden hacer. Ahora que ya tenemos ImageMagick 7 y la extensión para imagick de PHP (mediante PECL), podemos utilizar toda la potencia para WordPress 5. 8 que da soporte a algunos formatos nuevos. Comenzamos con la instalación de las herramientas necesarias para instalar y compilar los elementos que nos harán falta. apt -y install software-properties-common apt-transport-https build-essential pkg-config Descargamos los paquetes de ImageMagick 7. Para ello usaremos IMEI - ImageMagick Easy Install que compila la última versión de ImageMagick y añade soporte a HEIF, HEIX, AVIF y JPEG XL. Por cierto, depende de los recursos de la máquina, puede tardar entre 15 y 30 minutos. cd git clone https://github. com/SoftCreatR/imei cd imei . /imei. sh Y en este momento tendremos ya instalado ImageMagick 7. magick -version Version: ImageMagick 7. 1. 0-1 Q32 x86_64 2021-06-12 https://imagemagick. org Copyright: (C) 1999-2021 ImageMagick Studio LLC License: https://imagemagick. org/script/license. php Features: Cipher DPC HDRI Modules OpenMP(4. 5) Delegates (built-in): bzlib cairo djvu fftw fontconfig freetype gslib gvc heic jbig jng jp2 jpeg jxl lcms lqr ltdl lzma openexr pangocairo png ps raqm raw rsvg tiff webp wmf x xml zip zlib Instalamos PHP 8. 0. cd add-apt-repository -y -s ppa:ondrej/php apt -y install php8. 0 php8. 0-fpm php8. 0-common php8. 0-dev php8. 0-cli php8. 0-bcmath php8. 0-curl php8. 0-gd php8. 0-intl php8. 0-imap php8. 0-mbstring php8. 0-mysql php8. 0-opcache php8. 0-readline php8. 0-soap php8. 0-xml php8. 0-zip Vamos a instalar la extensión 3. 5. 0 que es compatible con PHP 8 e ImageMagick 7, así que descargamos los paquetes de imagick 3. 5. 0. cd pecl channel-update pecl. php. net pecl install imagick-beta echo "extension=imagick. so" >> /etc/php/8. 0/mods-available/imagick. ini ln -s /etc/php/8. 0/mods-available/imagick. ini /etc/php/8. 0/cli/conf. d/50-imagick. ini Si usas PHP-FPM, tendrás que reiniciar el servicio. ln -s /etc/php/8. 0/mods-available/imagick. ini /etc/php/8. 0/fpm/conf. d/50-imagick. ini systemctl restart php8. 0-fpm. service systemctl status php8. 0-fpm. service Y si revisamos en la configuración de PHP, encontraremos lo siguiente: imagick imagick module => enabled imagick module version => 3. 5. 0 imagick classes => Imagick, ImagickDraw, ImagickPixel, ImagickPixelIterator, ImagickKernel Imagick compiled with ImageMagick version => ImageMagick 7. 1. 0-1 Q32 x86_64 2021-06-12 https://imagemagick. org Imagick using ImageMagick library version => ImageMagick 7. 1. 0-1 Q32 x86_64 2021-06-12 https://imagemagick. org ImageMagick copyright => (C) 1999-2021 ImageMagick Studio LLC ImageMagick release date => 2021-06-12 ImageMagick number of supported formats: => 260 ImageMagick supported formats => 3FR, 3G2, 3GP, AAI, AI, APNG, ART, ARW, ASHLAR, AVI, AVIF, AVS, BGR, BGRA, BGRO, BIE, BMP, BMP2, BMP3, BRF, CAL, CALS, CANVAS, CAPTION, CIN, CIP, CLIP, CMYK, CMYKA, CR2, CR3, CRW, CUBE, CUR, CUT, DATA, DCM, DCR, DCRAW, DCX, DDS, DFONT, DJVU, DNG, DOT, DPX, DXT1, DXT5, EPDF, EPI, EPS, EPS2, EPS3, EPSF, EPSI, EPT, EPT2, EPT3, ERF, EXR, FARBFELD, FAX, FF, FILE, FITS, FL32, FLV, FRACTAL, FTP, FTS, G3, G4, GIF, GIF87, GRADIENT, GRAY, GRAYA, GROUP4, GV, HALD, HDR, HEIC, HEIF, HISTOGRAM, HRZ, HTM, HTML, HTTP, HTTPS, ICB, ICO, ICON, IIQ, INFO, INLINE, IPL, ISOBRL, ISOBRL6, J2C, J2K, JBG, JBIG, JNG, JNX, JP2, JPC, JPE, JPEG, JPG, JPM, JPS, JPT, JSON, JXL, K25, KDC, KERNEL, LABEL, M2V, M4V, MAC, MAP, MASK, MAT, MATTE, MEF, MIFF, MKV, MNG, MONO, MOV, MP4, MPC, MPEG, MPG, MRW, MSL, MSVG, MTV, MVG, NEF, NRW, NULL, ORA, ORF, OTB, OTF, PAL, PALM, PAM, PANGO, PATTERN, PBM, PCD, PCDS, PCL, PCT, PCX, PDB, PDF, PDFA, PEF, PES, PFA, PFB, PFM, PGM, PGX, PHM, PICON, PICT, PIX, PJPEG, PLASMA, PNG, PNG00, PNG24, PNG32, PNG48, PNG64, PNG8, PNM, POCKETMOD, PPM, PS, PS2, PS3, PSB, PSD, PTIF, PWP, RADIAL-GRADIENT, RAF, RAS, RAW, RGB, RGB565, RGBA, RGBO, RGF, RLA, RLE, RMF, RSVG, RW2, SCR, SCT, SFW, SGI, SHTML, SIX, SIXEL, SPARSE-COLOR, SR2, SRF, STEGANO, SUN, SVG, SVGZ, TEXT, TGA, THUMBNAIL, TIFF, TIFF64, TILE, TIM, TM2, TTC, TTF, TXT, UBRL, UBRL6, UIL, UYVY, VDA, VICAR, VID, VIFF, VIPS, VST, WBMP, WEBM, WEBP, WMF, WMV, WMZ, WPG, X, X3F, XBM, XC, XCF, XPM, XPS, XV, XWD, YAML, YCbCr, YCbCrA, YUV Directive => Local Value => Master Value imagick. allow_zero_dimension_images => 0 => 0 imagick. locale_fix => 0 => 0 imagick. progress_monitor => 0 => 0 imagick. set_single_thread => 1 => 1 imagick. shutdown_sleep_count => 10 => 10 imagick. skip_version_check => 0 => 0 Y, dentro de tu WordPress, ya podrás disponer de todo lo necesario para su uso. Puedes validarlo yendo a la sección de Salud del Sitio → Información → Gestión de medios. --- Los permisos de ficheros son siempre elemento de discordia en cuanto a funcionamiento, seguridad y todo lo que hay alrededor de WordPress. Pero ¿cuáles son los permisos que WordPress necesita para funcionar? Los permisos de ficheros son siempre elemento de discordia en cuanto a funcionamiento, seguridad y todo lo que hay alrededor de WordPress. Pero ¿cuáles son los permisos que WordPress necesita para funcionar? La respuesta, como suele ser habitual, es "depende". Y ¿de qué depende? De tu hosting y de cómo se gestionan sus usuarios. Pero antes, vamos a ver ligeramente qué significan los distintos permisos. En este caso sólo vamos a ver los permisos en Linux, aunque en Windows funcionan de forma similar. Qué significan los números de los permisos Por resumir, cuando subimos nuestro WordPress al servidor tenemos 2 tipos: archivos y carpetas. Un archivo es un contenedor de contenido (texto, imagen, etc... ) y una carpeta es un lugar donde agrupar archivos. Tanto unos como otros han de tener ciertos permisos, que son 3: lectura, escritura y ejecución. Y por otro lado, tenemos números de 3 cifras. La primera hace referencia al propietario del archivo, el segundo al grupo al que pertenece ese usuario y el tercero al resto de usuarios. Con esta mezcla, por norma general tendremos 2 tipos de numeración. Permisos para carpetas En el caso de las carpetas, para poder acceder a ellas, necesitamos que sean de "ejecución". La diferencia pues, estará en si son de sólo lectura o lectura y escritura. Escritura: W (Write)Lectura: R (Read)Ejecución: X (eXecute) De esta forma, las carpetas, en un principio, podrían ser así: PropietarioGrupoOtrosWXRWXRW-R Como en un hosting puede entrar el propietario u otros usuarios del mismo grupo (otros desarrolladores) dejaríamos permisos para que ellos también puedan hacer lo mismo que el propietario. Sí que está claro que si algún otro usuario intenta hacer algo, podría ejecutar y mirar una carpeta, pero no modificarla. Permisos para archivos En el caso de los archivos, no necesitamos que sean de ejecución en ningún momento, ya que no vamos a ejecutar ningún programa. En este caso los ficheros serán sólo de lectura y escritura según sea necesario. Escritura: W (Write)Lectura: R (Read)Ejecución: X (eXecute) De esta forma, los archivos, en un principio, podrían ser así: PropietarioGrupoOtrosW-RW-R--R Como en un hosting puede entrar el propietario u otros usuarios del mismo grupo (otros desarrolladores) dejaríamos permisos para que ellos también puedan hacer lo mismo que el propietario. Sí que está claro que si algún otro usuario intenta hacer algo, podría ejecutar y mirar una carpeta, pero no modificarla. Los números Lo más habitual es que veamos códigos del tipo 644, o 775. ¿Qué significan estos números? Esta es la combinación de los WXR en numeración. SímbolosNumeraciónExplicación---0No hay permisos de ningún tipo. --x1Hay permisos de ejecución. -w-2Hay permisos de escritura. -wx3Hay permisos de escritura y ejecución. r--4Hay permisos de lectura. r-x5Hay permisos de lectura y ejecución. rw-6Hay permisos de lectura y escritura. rwx7Todos los permisos. Permisos en un hosting compartido Cuando estamos en un hosting compartido, lo habitual es que el sistema pueda tener varios usuarios de FTP, y que todos ellos compartan el mismo grupo. De esa forma, hay un usuario que es el propietario, y hay otros que son los que están en el mismo grupo. En este caso, tendríamos que el propietario y el grupo han de tener siempre los mismos permisos, y el resto, los mínimos necesarios para funcionar. Si lo hacemos así, los permisos para todos los ficheros de un WordPress serían: Carpetas: rwxrwxr-x / 775Con esto se podrá entrar en las carpetas y leer sus contenidos. Los que tengan usuario podrán escribir en ellas. Archivos: rw-rw-r-- / 664En este caso siempre se podrá leer el contenido de los archivos. Los que tengan usuario, podrán escribir en ellos. En el caso de WordPress, todos los ficheros deberían tener estos permisos. En ningún caso hay que darle permisos de ejecución a un archivo, y tampoco tiene sentido darle permisos de escritura al resto de usuarios. Si alguien te recomienda poner a las carpetas 777 o 666, ten cuidado, porque es probable que el problema no sea de permisos, sino de algo que está mal en alguna otra configuración. Permisos en un VPS / dedicado Cuando hablamos de un hosting dedicado, un VPS o de un sistema en el que el control del sistema se tiene por parte de un administrador de sistemas, la cosa cambia. En estos casos se puede ser extremadamente restrictivos, ya que depende mucho de quién es el propietario de los archivos y carpetas. En estos casos, podemos reducir la casuística sobre todo con respecto a seguridad. En la mayoría de casos, los servicios que hay en el servidor (por ejemplo el Apache o nginx) se pueden encontrar en el mismo grupo de los usuarios, y si este es el caso "no hay más usuarios". Con esto tendríamos como 3 niveles: tú / webmaster (propietario), el propio WordPress (grupo) y otros usuarios. Si lo hacemos así, los permisos para todos los ficheros de un WordPress serían: Carpetas: rwxr-x--- / 750Con esto se podrá entrar en las carpetas y leer sus contenidos. Los usuarios podrán escribir en ellas. Otros usuarios no tendrían acceso. Archivos: rw-r----- / 640En este caso siempre se podrá leer el contenido de los archivos. Los usuarios podrán escribir en ellos. Otros usuarios no tendrían acceso. Este sería el caso extremo, que en general tampoco es necesario. lo más habitual será ser más liviano con los permisos y dejar una configuración más laxa. Carpetas: rwxr-xr-x / 755Archivos: rw-r--r-- / 644 Por tu seguridad En cualquiera de los casos, como habrás podido comprobar, nunca se da permisos de escritura al último de los 3 bloques, y sólo se da permisos de ejecución a las carpetas, nunca a los archivos. --- Todos los dominios, para funcionar, necesitas las DNS (Domain Name Server) que permiten informar de a qué dirección IP corresponde cada uno de los servicios que puede ofrecer un dominio. Todos los dominios, para funcionar, necesitas las DNS (Domain Name Server) que permiten informar de a qué dirección IP corresponde cada uno de los servicios que puede ofrecer un dominio. Si utilizas las DNS de tu proveedor de alojamiento web (que habitualmente tiene su propio panel de control o usa cPanel, Plesk o similar) ya se encargará de crearlo todo... pero no está de más entender qué hacen. Elegir el proveedor Al igual que tenemos la empresa donde registramos un dominio, la empresa que nos gestiona las DNS puede ser la misma o distinta. Existen algunos proveedores gratuitos que pueden ser útiles si no dispones de este servicio. 1984: Aunque se centran en dar alojamiento, tienen su servicio de Free DNS para cualquier usuario. BuddyNS: Aunque sólo ofrecen 300K peticiones/mes, es más que suficiente y tienen una buena infraestructura distribuida. ClouDNS: Aunque la versión gratuita no es muy amplia, no deja de ser otra opción distribuida importante y conocida. Cloudflare: Ofrecen varios servicios y parece que ahora mismo tienen cerca del 40% de la gestión de DNS del mundo. FreeDNS: Es de estos servicios que la comunidad pone a disposición de todo el mundo, siempre actualizado y a la última. Geoscaling: Lo interesante de este servicio es que permite distribuir las entradas dependiendo del punto de origen del usuario. Si un usuario está en América, lo mandas a un servidor en US, si está en Europa, a uno en DE... Hurricane Electric Free DNS: Personalmente el que más me gusta y uno de los que utilizo. Es visualmente feo, pero funcional y si sabes de DNS te deja hacer prácticamente de todo. Además acaban de añadir soporte a las CAA y tienen servicio dinámico. Ofrecen 50 entradas gratuitas. Namecheap FreeDNS: Aunque se centran en registrar dominios, puedes usar sus servicios de DNS de forma gratuita aunque el dominio no esté con ellos. NS1: Tiene buena pinta, y su servicio de pago parece muy interesante. Ofrecen 50 entradas gratuitas con 500K consultas gratuitas. Rackspace: Tienen el servicio simplemente gratis por darte de alta con ellos. Usan el estándar de BIND9 en modo Anycast. Configurando el dominio Cuando te das de alta en cualquier proveedor (ya sea tu hosting, o cualquier proveedor como los anteriores) te tendrán que dar, al menos, dos servidores de nombres NS. Son los famosos ns1. example. com y ns2. example. com, que en realidad pueden ser cualquier hostname. Te pueden llegar a dar hasta 5 de ellos. Estos NS son los que has de configurar en tu dominio (o subdominio delegado). A partir de ese momento, cuando alguien haga una llamada a tu dominio, se resolverán las peticiones según estén configurados en el proveedor. En este momento, el fichero de DNS será parecido a esto: example. com. SOA 86400 ns1. example. net. dnsmaster. example. net. 2019073102 86400 7200 3600000 86400 example. com. NS 86400 ns1. example. net example. com. NS 86400 ns2. example. net Las entradas SOA las genera el sistema, y las entradas NS serán las mismas que tendrás que poner en tu dominio. ¿Qué necesita mi WordPress? Vamos a plantear que usaremos nuestro WordPress en el sitio www. example. com. También queremos que el example. com redirija al sitio. Esto sería lo mínimo necesario para hacer que nuestro sitio web funcione, por lo que deberemos crear entradas de tipo A (y AAAA). example. com. A 3600 198. 51. 100. 20 www. example. com. A 3600 198. 51. 100. 20 En caso de que tu proveedor también te ofrezca IPv6, podrías añadir una dirección con AAAA: example. com. AAAA 3600 2001:db8::20 www. example. com. AAAA 3600 2001:db8::20 Mi proveedor pone CNAME en el www El CNAME es un sistema de alias. Esto significa que si haces algo como esto: example. com. A 3600 198. 51. 100. 20 www. example. com. CNAME 3600 example. com Lo que estás haciendo es que, cuando se haga una llamada al www, el sistema devuelva que la IP es un alias del example. com; posteriormente, se deberá hacer una llamada al example. com para conseguir la dirección IP. Esto significa que para saber la IP del www tendrás que hacer dos peticiones DNS en vez de una, y eso significa tiempo, y eso significa que Core Web Vitals dará peores resultados. Tu dominio siempre debería tener una entrada A Otra de las reglas de oro, aunque ha evolucionado, pero en el que muchos servicios de validación se basan, por ejemplo, los servicios de correo, es que el dominio (sin subdominios) tenga una entrada A que resuelva a una dirección IP. Esto, indirectamente, indica que el dominio es funcional. También, por otro lado, un dominio sólo puede tener entradas A y no CNAME. ¿Por qué? Cosas de los estándares de Internet. ¿Puedo necesitar más DNS para WordPress? En principio con esto tendrías suficiente. Eso sí, a partir de aquí se abre un mundo de posibilidades. Validación en herramientas de Webmasters Una de las mejores formas de validar Google Search Console, Bing Webmasters o Yandex Webmasters. En estos casos suelen darte dos opciones de validación. Una es mediante un TXT, y otra es mediante un CNAME. Por ejemplo, Google te pedirá que crees una entrada similar a esto: example. com. TXT 86400 google-site-verification=VACXsfhn2ZMUB9QS2BpPtNqHYLN9qrAUaxyW En el caso de Bing, te pedirá un CNAME de un subdominio. xnqzj8ky2j2xnf2nxxmn29a5. example. com. CNAME 86400 verify. bing. com Y Yandex te pedirá algo similar al de Google: example. com. TXT 86400 yandex-verification: 4g7ye3mxtqyfrf62 Las entradas CNAME de Bing lo que hará es que si haces una llamada a ese subdominio que te dan, resuelva una IP de Bing. Las entradas de tipo TXT, como se puede intuir, son entradas de texto. Son campos libres de entre 1 y 255 caracteres que, habitualmente comienzan con una palabra clave tipo google-site-verification o yandex-verification, y que después indican un contenido único. Quiero correo electrónico Las entradas DNS sobre el correo electrónico te las tendrá que dar tu proveedor de correo. Si usas hosting compartido suelen venir ya configuradas. Si usas un... --- El correo es de esos servicios en los que habitualmente tienes una cuenta principal y el resto de dominios acaba reenviando todo a tu cuenta. Y si esa es tu situación habitual, aquí tienes una forma óptima de hacerlo. El correo es de esos servicios en los que habitualmente tienes una cuenta principal y el resto de dominios acaba reenviando todo a tu cuenta. Y si esa es tu situación habitual, aquí tienes una forma óptima de hacerlo. Y es que aunque tengas que redirigir el correo, puede ser que tu proveedor de correo o de hosting requiera algunas configuraciones o tenga un coste extra. ¿Cómo conseguir esto de forma sencilla y gratuita? Existen varios servicios como el que voy a explicar, pero este es simple, tiene una versión gratuita ilimitada que te permite el objetivo principal, y es fácil de configurar. Además, si montas una web en un sitio que no tiene correo, es la solución ideal. Registro y Alta Vamos a usar la herramienta de Forward Email para esto. Así que lo primero es entrar en Forward Email y registrarte gratis. Una vez dentro, te pedirá que añadas el dominio al que quieres que recoja todo el correo. Por defecto, puedes desactivar la opción premium (en principio no es necesaria), aunque es una opción interesante, sobre todo por privacidad. Configuración básica Una vez añadido deberemos añadir algunas configuraciones en las DNS del dominio para validar que somos nosotros. La primera es incluir dos entradas MX que son las querán que permita llegar el correo: example. com 86400 MX 10 mx1. forwardemail. net example. com 86400 MX 10 mx2. forwardemail. net El tiempo de caché puede ser el que quieras. Si es algo que no piensas cambiar, lo óptimo sería poner 86400 (un día), o puedes reducirlo a 3600 (una hora). Cuando más alto, mejor (pero sin pasarse de un día). Este servicio, por defecto, lo que permite es que cualquier correo enviado a lo_que_sea@example. com te lo reenvíe a una dirección que tú decidas. Para esto, incluiremos una entrada TXT como esta: example. com 300 TXT forward-email=micorreo@dominio. es En este caso, si queremos hacer cambios (que los haremos) lo mejor será reducir el tiempo a 300 segundos (5 minutos) por si queremos modificar los correos. Aunque en la documentación inicial no lo indica, si queremos evitar problemas en la recepción del correo, deberíamos incluir la entrada SPF. Con esto daremos que la lista de IP del proveedor están en la lista blanca para poder reenviar el correo. example. com 3600 TXT v=spf1 a mx include:spf. forwardemail. net -all Una vez hayamos añadido estas entradas a las DNS, deberemos pulsar el botón y verificar. Y si has hecho bien los deberes... Funcionamiento En este momento, si enviamos un correo a prueba1@example. com, el correo nos llegará, en pocos segundos, a la dirección de correo principal. Por defecto el sistema es un "catch-all", lo que significa que cualquier correo que se mande a ese dominio, te llegará a la cuenta principal. Otras opciones gratuitas Existen varias combinaciones que se pueden configurar a nivel dominio y que pueden ser muy interesantes. Catch-All Esta es la opción que hemos configurado. Todo el correo de lo_que_sea@dominio. com nos llegará a una única cuenta de correo. example. com 300 TXT forward-email=micorreo@dominio. es En caso de querer que la recepción completa del correo vaya a varias cuentas, también se puede. example. com 300 TXT forward-email=micorreo1@dominio. es,micorreo2@dominio. es Sólo una cuenta Es posible que no quizás que todo el correo llegue a la misma cuenta, y que en realidad sólo necesitas una única cuenta. Por ejemplo, que la cuenta wordpress@example. com sea la única que existe. example. com 300 TXT forward-email=wordpress:micorreo@dominio. es Varias cuentas Si tienes unas pocas cuentas, puedes usar una configuración similar, separando por comas las cuentas. example. com 300 TXT forward-email=wordpress:micorreo@dominio. es,soporte:misoporte@dominio. es Los campos de texto TXT en las DNS en principio no deben contener más de 255 caracteres, por lo que si quieres crear cuentas de correo infinitas, puedes hacerlo añadiendo varias entradas DNS. example. com 300 TXT forward-email=wordpress:micorreo@dominio. es,soporte:misoporte@dominio. es example. com 300 TXT forward-email=ayuda:miayuda@dominio. es,tecnixo:mitecnico@dominio. es Múltiples destinatarios Otra posibilidad habitual es la de tener un usuario al que reenviar a múltiples destinatarios. Esto también lo podemos hacer. Aún así, en principio hay un límite máximo de 10 destinatarios. example. com 300 TXT forward-email=wordpress:micorreo1@dominio. es,wordpress:micorreo2@dominio. es Alias global Probablemente esta sea la entrada que más sentido tenga a la hora de configurar, y es que el sistema, ya por defecto, haya una relación 1:1 de las cuentas de correo. De esta forma cada cuenta se enviará a la misma cuenta del dominio de destino. En este caso el dominio de example. com se reenviará, cuenta a cuenta, a dominio. es. example. com 300 TXT forward-email=dominio. es Bloquear un usuario Si queremos bloquear un usuario, podemos hacerlo diciéndole qué usuario bloquear. example. com 300 TXT forward-email=! usuario Servicio premium Existe una versión de pago de este servicio en el que, pagando 3 dólares mensuales, puedes gestionar todos estos cambios, alias y configuraciones mediante su propio panel de control. --- Aunque los certificados de Let's Encrypt son gratuitos, podemos usarlos, pero debemos hacer que den el máximo rendimiento de seguridad a nuestro WordPress. Aunque los certificados de Let's Encrypt son gratuitos, podemos usarlos, pero debemos hacer que den el máximo rendimiento de seguridad a nuestro WordPress. Si queremos sacarle el máximo partido no deberemos usar el certificado que se genera por defecto, sino que deberemos hacer y activar algunas configuraciones extra. Recuerda que los certificados no son compatibles con navegadores muy antiguos, pero que si tienes usuarios que usan dispositivos modernos no debe darte problema. Instalación Para esta prueba en Ubuntu 20, vamos a instalar simplemente un nginx y el certbot (la herramienta de la EFF para la gestión de certificados Let's Encrypt). snap install core && snap install --classic certbot ln -s /snap/bin/certbot /usr/bin/certbot Antes de que se nos olvide, y para que el sistema actualice y renueve los certificados cuando toque, podemos configurar un cron que lo haga. crontab -e Al que le diremos, por ejemplo, que actualice los certificados cada día a las 06:45. 45 6 * * * certbot renew Configuración de nginx Obviando la configuración de nginx, vamos a centrarnos en la configuración concreta del sitio por defecto. cd /etc/nginx/sites-available/ vim default Allí dejaremos algo tan sencillo como esto: server { listen 80; listen :80; server_name www. example. com example. com; root /var/www/html; index index. html; location / { try_files $uri $uri/ =404; } } En esta configuración indicaremos el dominio a utilizar, que es lo principal que necesitaremos. Con esto, nuestra web debería funcionar y verse correctamente (aunque sea un simple HTML). Comprobaremos, reiniciaremos y validaremos que nginx funciona. nginx -t systemctl restart nginx. service systemctl status nginx. service Creando el certificado Para poder utilizar un certificado de Let's Encrypt primero deberemos registrarnos o actualizar nuestra cuenta. certbot register --email my_email@example. com --agree-tos --no-eff-email Y si ya has utilizado esto previamente, puedes actualizar los datos. certbot update_account --email my_email@example. com --agree-tos --no-eff-email Una vez tengamos la cuenta creada, podremos crear nuestro certificado. El sistema que vamos a usar es el de la validación por DNS, que, de entre todas las posibles, es la más difícil que se vea comprometida. certbot certonly --manual --preferred-challenges dns -d example. com -d www. example. com --cert-name example. com En el proceso, nos pedirá que añadamos (por primera y única vez) una entrada en las DNS, de forma que sea capaz de validar que somos los propietarios del dominio. Please deploy a DNS TXT record under the name: _acme-challenge. example. com. with the following value: 77cm8TbWavyWrTp2cB9zSbHL5q8x5nFqufEpS9ykQsKNwrGc Añadiremos la entrada en las DNS y pulsaremos en continuar. Una vez hecho esto nos dará la ruta del sistema en el que se encuentra nuestro certificado. /etc/letsencrypt/live/example. com/fullchain. pem Instalando el certificado Ahora que tenemos el certificado creado ya podemos instalarlo y ponerlo en funcionamiento. Volveremos a cargar el fichero de configuración de nginx y añadiremos la parte que haga que funcione el HTTPS y que tenga activado el certificado. cd /etc/nginx/sites-available/ vim default Separaremos la parte sin certificado (que hará redirección del HTTP al HTTPS) y activaremos el resto. #Mandamos todo el tráfico de HTTP a HTTP server { listen 80; listen :80; server_name www. example. com example. com; return 301 https://www. example. com$request_uri; access_log off; } #Activamos el sitio con HTTPS server { listen 443 ssl; listen :443 ssl ipv6only=on; server_name www. example. com example. com; ssl_certificate /etc/letsencrypt/live/example. com/fullchain. pem; ssl_certificate_key /etc/letsencrypt/live/example. com/privkey. pem; ssl_trusted_certificate /etc/letsencrypt/live/example. com/chain. pem; include /etc/letsencrypt/options-ssl-nginx. conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams. pem; root /var/www/html; index index. html; location / { try_files $uri $uri/ =404; } } Por defecto Let's Encrypt sólo usa TLSv1. 2 y TLSv1. 3, que son las dos versiones correctas. En cualquier caso, deberemos asegurarnos de que eso sea así. vim /etc/letsencrypt/options-ssl-nginx. conf Y validaremos que en la línea correspondiente sólo está esa configuración. ssl_protocols TLSv1. 2 TLSv1. 3; Una vez esto esté configurado, validaremos y reiniciaremos nginx. nginx -t systemctl restart nginx. service systemctl status nginx. service Para validar que el certificado TLS está instalado y funcionando, podemos usar la herramienta de SSLLabs. Esto está bien... pero ¿podemos conseguir mejor puntuación? Validando las DNS Si queremos que un certificado tenga cierta importancia, podemos bloquear qué proveedor lo va a emitir, algo que aumentaría la seguridad, ya que no cualquiera podría generarlo. En este caso, podemos limitarlo por DNS (todos los proveedores tienen su configuración, y se pueden indicar varias, por prioridad). letsencrypt. wpdanger. systems. CAA 0 issue "letsencrypt. org" letsencrypt. wpdanger. systems. CAA 0 iodef "mailto:my_email@example. com" Con esto conseguiremos un paso más. Ampliando la seguridad Hasta este momento tenemos un certificado seguro, pero podemos seguir aumentando ciertos parámetros. El primero de ellos va a ser disponer de un certificado de 4096 bits en vez de uno de 2048 bits, que es el que se genera por defecto. certbot certonly --manual --preferred-challenges dns --key-type rsa --rsa-key-size 4096 -d example. com -d www. example. com --cert-name example. com --force-renew Y lo siguiente va a ser mejorar la configuración de nginx para activar dos elementos: el OCSP y las cabeceras de seguridad. cd /etc/nginx/sites-available/ vim default En el que sustituiremos la configuración. #Mandamos todo el tráfico de HTTP a HTTP server { listen 80; listen :80; server_name www. example. com example. com; return 301 https://www. example. com$request_uri; access_log off; } #Activamos el sitio con HTTPS server { listen 443 ssl; listen :443 ssl ipv6only=on; server_name www. example. com example. com; # TLS CERT ssl_certificate /etc/letsencrypt/live/example. com/fullchain. pem; ssl_certificate_key /etc/letsencrypt/live/example. com/privkey. pem; ssl_trusted_certificate /etc/letsencrypt/live/example. com/chain. pem; include /etc/letsencrypt/options-ssl-nginx. conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams. pem; # TLS OCSP Stapling ssl_stapling on; ssl_stapling_verify on; resolver 208. 67. 222. 222 8. 8. 8. 8 valid=300s; resolver_timeout 2s; # Security headers add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; add_header X-Frame-Options SAMEORIGIN; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; # SITE root /var/www/html; index index. html; location / { try_files $uri $uri/ =404; } } Ahora que tenemos el nuevo certificado y la configuración, reiniciaremos el servicio. nginx -t systemctl restart nginx. service systemctl status nginx. service Y conseguiremos una puntuación y seguridad mayor. --- Plesk incorpora sus propias versiones de PHP que suelen ser las actuales y soportadas por el propio PHP. Pero ¿qué pasa si queremos usar el PHP del propio sistema operativo u otras versiones? Plesk incorpora sus propias versiones de PHP que suelen ser las actuales y soportadas por el propio PHP. Pero ¿qué pasa si queremos usar el PHP del propio sistema operativo u otras versiones? En este caso, por ejemplo si necesitas por alguna razón un PHP 5. 6, podemos activar y configurar nuestras propias configuraciones de PHP. Para hacer todo este proceso usaremos parcialmente un acceso SSH y el panel de Plesk. Estableciendo la base Lo primero que haremos es actualizar el sistema operativo y validar que todo está al día. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Una vez lo hagamos podemos validar que todas las versiones de PHP del propio Plesk están al día desde el Plesk Installer. ¿Necesitamos activar el PHP from OS vendor? En principio no, porque vamos a instalar nuestras propias versiones y no propiamente la del sistema operativo. Para validar lo que hay instalado, podemos hacer un listado. plesk bin php_handler --list Que nos devuelve una lista tal que esta. id: display name: full version: version: type: cgi-bin: php-cli: php. ini: custom: status: plesk-php73-cgi 7. 3. 28 7. 3. 28 7. 3 cgi /opt/plesk/php/7. 3/bin/php-cgi /opt/plesk/php/7. 3/bin/php /opt/plesk/php/7. 3/etc/php. ini true disabled plesk-php73-fastcgi 7. 3. 28 7. 3. 28 7. 3 fastcgi /opt/plesk/php/7. 3/bin/php-cgi /opt/plesk/php/7. 3/bin/php /opt/plesk/php/7. 3/etc/php. ini true disabled plesk-php73-fpm 7. 3. 28 7. 3. 28 7. 3 fpm /opt/plesk/php/7. 3/sbin/php-fpm /opt/plesk/php/7. 3/bin/php /opt/plesk/php/7. 3/etc/php. ini true enabled plesk-php74-cgi 7. 4. 18 7. 4. 18 7. 4 cgi /opt/plesk/php/7. 4/bin/php-cgi /opt/plesk/php/7. 4/bin/php /opt/plesk/php/7. 4/etc/php. ini true disabled plesk-php74-fastcgi 7. 4. 18 7. 4. 18 7. 4 fastcgi /opt/plesk/php/7. 4/bin/php-cgi /opt/plesk/php/7. 4/bin/php /opt/plesk/php/7. 4/etc/php. ini true disabled plesk-php74-fpm 7. 4. 18 7. 4. 18 7. 4 fpm /opt/plesk/php/7. 4/sbin/php-fpm /opt/plesk/php/7. 4/bin/php /opt/plesk/php/7. 4/etc/php. ini true enabled plesk-php80-cgi 8. 0. 5 8. 0. 5 8. 0 cgi /opt/plesk/php/8. 0/bin/php-cgi /opt/plesk/php/8. 0/bin/php /opt/plesk/php/8. 0/etc/php. ini true disabled plesk-php80-fastcgi 8. 0. 5 8. 0. 5 8. 0 fastcgi /opt/plesk/php/8. 0/bin/php-cgi /opt/plesk/php/8. 0/bin/php /opt/plesk/php/8. 0/etc/php. ini true disabled plesk-php80-fpm 8. 0. 5 8. 0. 5 8. 0 fpm /opt/plesk/php/8. 0/sbin/php-fpm /opt/plesk/php/8. 0/bin/php /opt/plesk/php/8. 0/etc/php. ini true enabled Lo que queremos es incluir nuestras propias versiones a esta lista. Instalando el PHP de Ubuntu Activaremos el repositorio más conocido para dar soporte a PHP. add-apt-repository -y -s ppa:ondrej/php E instalaremos las siguientes versiones. La primera de ellas, PHP 5. 6. apt -y install php5. 6 php5. 6-apcu php5. 6-bcmath php5. 6-cgi php5. 6-cli php5. 6-common php5. 6-curl php5. 6-dba php5. 6-dev php5. 6-fpm php5. 6-gd php5. 6-gmp php5. 6-http php5. 6-igbinary php5. 6-imagick php5. 6-imap php5. 6-intl php5. 6-json php5. 6-mbstring php5. 6-mcrypt php5. 6-msgpack php5. 6-mysql php5. 6-mysqlnd-ms php5. 6-opcache php5. 6-redis php5. 6-soap php5. 6-ssh2 php5. 6-tidy php5. 6-uploadprogress php5. 6-xml php5. 6-xmlrpc php5. 6-xsl php5. 6-zip También PHP 7. 3. apt -y install php7. 3 php7. 3-fpm php7. 3-cgi php7. 3-common php7. 3-dev php7. 3-cli php7. 3-bcmath php7. 3-curl php7. 3-gd php7. 3-imap php7. 3-json php7. 3-mbstring php7. 3-mysql php7. 3-opcache php7. 3-soap php7. 3-xml php7. 3-xmlrpc php7. 3-zip php-imagick php-pear php-ssh2 php-xdebug libgeoip-dev También PHP 7. 4. apt -y install php7. 4 php7. 4-fpm php7. 4-cgi php7. 4-common php7. 4-dev php7. 4-cli php7. 4-bcmath php7. 4-curl php7. 4-gd php7. 4-imap php7. 4-json php7. 4-mbstring php7. 4-mysql php7. 4-opcache php7. 4-soap php7. 4-xml php7. 4-xmlrpc php7. 4-zip php-imagick php-pear php-ssh2 php-xdebug libgeoip-dev Y, finalmente, PHP 8. 0. apt -y install php8. 0 php8. 0-fpm php8. 0-cgi php8. 0-common php8. 0-dev php8. 0-cli php8. 0-bcmath php8. 0-curl php8. 0-gd php8. 0-imap php8. 0-mbstring php8. 0-mysql php8. 0-opcache php8. 0-soap php8. 0-xml php8. 0-zip php8. 0-xdebug php8. 0-imagick Ahora que tenemos nuestras versiones, vamos a activar (sólo las versiones FPM, pero se podrían activar también las CGI) para que Plesk las pueda utilizar. Activaremos según necesitemos. La primera será la del PHP 5. 6. plesk bin php_handler --add -displayname '5. 6-FPM (Ubuntu)' -path /usr/sbin/php-fpm5. 6 -phpini /etc/php/5. 6/fpm/php. ini -type fpm -id fpm56 -clipath /usr/sbin/php-fpm5. 6 -service php5. 6-fpm -poold /etc/php/5. 6/fpm/pool. d También PHP 7. 3. plesk bin php_handler --add -displayname '7. 3-FPM (Ubuntu)' -path /usr/sbin/php-fpm7. 3 -phpini /etc/php/7. 3/fpm/php. ini -type fpm -id fpm73 -clipath /usr/sbin/php-fpm7. 3 -service php7. 3-fpm -poold /etc/php/7. 3/fpm/pool. d Continuamos con PHP 7. 4. plesk bin php_handler --add -displayname '7. 4-FPM (Ubuntu)' -path /usr/sbin/php-fpm7. 4 -phpini /etc/php/7. 4/fpm/php. ini -type fpm -id fpm74 -clipath /usr/sbin/php-fpm7. 4 -service php7. 4-fpm -poold /etc/php/7. 4/fpm/pool. d Y acabamos con PHP 8. 0. plesk bin php_handler --add -displayname '8. 0-FPM (Ubuntu)' -path /usr/sbin/php-fpm8. 0 -phpini /etc/php/8. 0/fpm/php. ini -type fpm -id fpm80 -clipath /usr/sbin/php-fpm8. 0 -service php8. 0-fpm -poold /etc/php/8. 0/fpm/pool. d Validaremos de nuevo la lista. plesk bin php_handler --list Donde nos deberán aparecer los nuevos identificadores que hemos añadido. id: display name: full version: version: type: cgi-bin: php-cli: php. ini: custom: status: fpm56 5. 6-FPM (Ubuntu) 5. 6. 40 5. 6 fpm /usr/sbin/php-fpm5. 6 /usr/sbin/php-fpm5. 6 /etc/php/5. 6/fpm/php. ini true enabled fpm73 7. 3-FPM (Ubuntu) 7. 3. 28 7. 3 fpm /usr/sbin/php-fpm7. 3 /usr/sbin/php-fpm7. 3 /etc/php/7. 3/fpm/php. ini true enabled fpm74 7. 4-FPM (Ubuntu) 7. 4. 18 7. 4 fpm /usr/sbin/php-fpm7. 4 /usr/sbin/php-fpm7. 4 /etc/php/7. 4/fpm/php. ini true enabled fpm80 8. 0-FPM (Ubuntu) 8. 0. 5 8. 0 fpm /usr/sbin/php-fpm8. 0 /usr/sbin/php-fpm8. 0 /etc/php/8. 0/fpm/php. ini true enabled plesk-php73-cgi 7. 3. 28 7. 3. 28 7. 3 cgi /opt/plesk/php/7. 3/bin/php-cgi /opt/plesk/php/7. 3/bin/php /opt/plesk/php/7. 3/etc/php. ini true disabled plesk-php80-fpm 8. 0. 5 8. 0. 5 8. 0 fpm /opt/plesk/php/8. 0/sbin/php-fpm /opt/plesk/php/8. 0/bin/php /opt/plesk/php/8. 0/etc/php. ini true enabled plesk-php80-cgi 8. 0. 5 8. 0. 5 8. 0 cgi /opt/plesk/php/8. 0/bin/php-cgi /opt/plesk/php/8. 0/bin/php /opt/plesk/php/8. 0/etc/php. ini true disabled plesk-php74-cgi 7. 4. 18 7. 4. 18 7. 4 cgi /opt/plesk/php/7. 4/bin/php-cgi /opt/plesk/php/7. 4/bin/php /opt/plesk/php/7. 4/etc/php. ini true disabled plesk-php73-fpm 7. 3. 28 7. 3. 28 7. 3 fpm /opt/plesk/php/7. 3/sbin/php-fpm /opt/plesk/php/7. 3/bin/php /opt/plesk/php/7. 3/etc/php. ini true enabled plesk-php80-fastcgi 8. 0. 5 8. 0. 5 8. 0 fastcgi /opt/plesk/php/8. 0/bin/php-cgi /opt/plesk/php/8. 0/bin/php /opt/plesk/php/8. 0/etc/php. ini true disabled plesk-php74-fpm 7. 4.... --- WordPress tiene muchas capas de caché disponibles y algo que de forma nativa no se cachea son las frases de traducción de un WordPress que no está en Inglés de Estados Unidos. WordPress tiene muchas capas de caché disponibles, y algo que de forma nativa no se cachea, sino que se carga en cada petición, son las frases de traducción de un WordPress que no está en Inglés de Estados Unidos (el texto que viene de forma nativa sin fichero extra). Teniendo en cuenta que una gran parte de los WordPress está en un idioma que no es el nativo del software, y si tienes algún tipo de capa de caché ya instalada en tu WordPress (ya sea de PHP Opcaché o de objetos como Redis o memcached) una buena opción es cargar los ficheros de traducción en caché para que estén disponibles y se procesen en memoria de forma casi inmediata. Para ello podremos usar el plugin WordPress Translation Cache. Hay que decir que no es un plugin al uso, sino que hay que instalarlo como Plugin Must-Use (en la carpeta /wp-content/mu-plugins/). Sólo hay que descargar el fichero pomodoro. php y subirlo al servidor. A partir de ese momento, los ficheros . PO/. MO de las traducciones tanto de WordPress como de themes y plugins comenzarán a ser cacheados, lo que implicará una mejora en el rendimiento de tu sitio WordPress. --- Una de las claves en Web Performance es la optimización de imágenes, algo que en WordPress se puede hacer mediante algunos plugins, pero también en el propio servidor. Una de las claves en Web Performance es la optimización de imágenes, algo que en WordPress se puede hacer mediante algunos plugins, pero también en el propio servidor. Cuando subes una imagen, la original se mantiene y se generan las imágenes más pequeñas. Pero esas imágenes por defecto no están optimizadas y que las genera el propio PHP, heredando el ruido que puede incluir la imagen original. Y como queremos poder optimizar las imágenes en nuestro propio servidor, vamos a ver cómo conseguirlo. Requisitos Necesitamos tener instalado WP-CLI y un sistema operativo tipo Ubuntu o CentOS. En la actualidad requiere PHP 7 para funcionar. Además, instalaremos una serie de aplicaciones que nos permitirán optimizar cada uno de los tipos de imágenes: Jpegoptim: para la optimización de JPEG. OptiPNG: para la optimización de PNG. pngquant: para la optimización de PNG. Gifsicle: para la optimizaciónd e GIF. SVGO: para la optimización de SVG. cwebp: para la optimización de WebP. Podemos instalarlos en Ubuntu apt -y install jpegoptim optipng pngquant gifsicle webp npm install -g svgo@1. 3. 2 O podemos instalarlos en CentOS dnf -y install jpegoptim optipng pngquant gifsicle libwebp-tools npm install -g svgo@1. 3. 2 Instalación Para instalarlo y hacer que funcione revisaremos primero si tenemos por defecto PHP 7 u otra versión. SI tenemos ya un PHP 7. 2+ el sistema funcionará directamente. Si tenemos PHP 8. 0 deberemos hacer un pequeño truco. wp cli info Una vez sepamos si tenemos PHP 7 u 8, usaremos los comandos de una manera u otra. Como en general PHP 8 ya es un por defecto en los sistemas, voy a aplicar el comando con "el truco". Para empezar instalaremos el paquete que permite la optimización. /usr/bin/php7. 4 "$(which wp)" package install typisttech/image-optimize-command:@stable --allow-root O directamente wp package install typisttech/image-optimize-command:@stable Funcionamiento Una vez lo tengamos, podemos ver la ayuda del comando. wp help image-optimize Y podemos lanzar una actualización masiva de todas las imágenes que tenemos en el Media de nuestro WordPress. /usr/bin/php7. 4 "$(which wp)" media regenerate --allow-root /usr/bin/php7. 4 "$(which wp)" image-optimize batch --limit=9999999 --allow-root O directamente wp media regenerate wp image-optimize batch --limit=9999999 A partir de este momento tendremos nuestras imágenes optimizadas para que nos den una muy buena nota en las herramientas que analizan el Web Performance. --- Aproximadamente la mitad de las instalaciones están en un idioma que no es el predeterminado (el inglés) y esto nos lleva a pensar en los localismos, la transliteración, las conversiones de codificación, las operaciones de calendario, la colación… Aunque hay muchos tipos de alojamiento, la mayoría de los usuarios de WordPress utilizan un alojamiento compartido y algunos utilizan un alojamiento VPS o Cloud. Los que utilizan VPS o Cloud suelen gestionar sus propios servidores y por tanto deciden qué extensiones de PHP instalar, pero los que utilizan hosting compartido no suelen tener esa opción. Hace unas semanas llegó al equipo de Hosting una petición para que se analizara la idoneidad de utilizar la extensión PHP Internationalization porque, aunque el Core de WordPress no la necesita ahora mismo (porque en ningún momento ni el equipo de Core ni el de Hosting la recomienda ni exige), los equipos de desarrollo no la utilizan porque no está, y los hosters no la instalan porque WordPress no la utiliza. Es el pez que se muerde la cola. Decidir qué módulos de Apache, qué extensiones de PHP, qué configuración de base de datos o la elección de la caché no es algo que deba tomarse a la ligera. ¿Por qué es importante la extensión PHP Intl? WordPress es un software global e internacional, con soporte para multitud de idiomas y con infinitas combinaciones. Aproximadamente la mitad de las instalaciones están en un idioma que no es el predeterminado (el inglés) y esto nos lleva a pensar en los localismos, la transliteración, las conversiones de codificación, las operaciones de calendario, la colación... en definitiva, todo lo que tiene que ver con los diferentes idiomas y formatos que hay en el planeta. Y esto es lo que proporciona la extensión PHP Intl. ¿Qué ganamos como Comunidad WordPress con esta extensión? Sobre todo, ganamos la posibilidad de utilizar un montón de funciones que pueden facilitarnos la vida como desarrolladores y que mejorarían la forma de desarrollar para mejorar WordPress. Funciones como collator_compare nos permitirán comparar cadenas de texto Unicode; con numfmt_format podremos formatear un número según la localización seleccionada; la normalización de caracteres; el formateo de mensajes; saber cuál es el primer día de la semana según la localización, sin necesidad de pedírselo al usuario. Y no sólo en funcionalidad o facilidad, también para mejorar la seguridad, con funciones como Spoofchecker que te puede decir si 'google. com', 'goog1e. com' puede confundir al usuario, o funciones relacionadas con los dominios de Internet, tanto para convertir un dominio IDN a texto como texto a IDN. Sí, es posible que pienses que WordPress ya hace muchas de estas cosas, pero en muchos casos las hace utilizando hacks que ahora podrían ser obviados y utilizados de forma nativa. Recomendación del equipo de alojamiento Teniendo en cuenta que WordPress sigue creciendo, el Hosting Team ha considerado una buena recomendación, pero no una obligación, para todos los hostings que trabajan con WordPress la posibilidad de ofrecer esta extensión, por defecto, a todos los usuarios. --- Existen seis cabeceras de caché que se pueden utilizar desde el protocolo HTTP a la hora de decirle al navegador si ese contenido ha de guardarse o no, y durante cuánto tiempo. Existen cabeceras de caché que se pueden utilizar desde el protocolo HTTP a la hora de decirle al navegador si ese contenido ha de guardarse o no, y durante cuánto tiempo. NOTA: En este artículo se hace un repaso de los elemenos más interesantes y aplicables. Si te interesa conocer con más detalle otras posibilidades, por favor, revisa las Cabeceras HTTP en Web Docs. Age La cabecera Age sólo se debería utilizar si tenemos una caché intermedia, ya sea algo del estilo a Cloudflare como un de un web-proxy, tipo Varnish. Esta cabecera está soportada por todos los navegadores. Esta cabecera debería indicar el tiempo que hace que está cacheado ese objeto, es decir, el tiempo desde el momento actual hasta en el que se puso en caché. El número que se indica está en segundos. Un elemento que hace una hora y media que está en caché indicaría tal que así: Age: 5400 Cache-Control La cabecera Cache-Control se manda al navegador desde el servidor para indicar cómo se debe cachear ese objeto en el propio navegador. Esta cabecera está soportada por todos los navegadores, aunque tiene un elemento experimental que sólo soporta Firefox (luego lo detallo). Este elemento dispone de varias posibles partes (no se han de utilizar todas siempre). Almacenamiento Además de la caché propia que define el navegador, se pueden forzar algunas cosas diferentes. Por ejemplo, por defecto, una petición bajo HTTPS no se debe cachear, pero como hoy en día la mayoría del tráfico viaja sobre HTTPS, quizá queramos que sí que se cacheen. Un ejemplo simple pero clarificador es el del logo de la página, que se va a utilizar probablemente en todos sitios... y por tanto deberíamos cachearlo. De la misma forma, quizá haya algún elemento que queramos cachear pero sólo para ese usuario y en esa sesión. Esta petición sería privada. Si queremos que un elemento no se almacene en la caché deberemos decirle que no se almacene específicamente. Un ejemplo podría ser, por ejemplo, una imagen de un captcha, o la de un PDF con datos bancarios. Algunos ejemplos de estos casos serían: Cache-Control: public; Cache-Control: private; Cache-Control: no-store; Es importante tener en cuenta que la opción no-cache no significa que no se vaya a almacenar, sino que si existe una versión cacheada se ha de revalidar con el servidor. En resumen, con estos elementos le decimos al navegador dónde se ha de almacenar la información. Expiración Cuando almacenamos algo en la caché del navegador deberíamos informar cuánto debería durar esa información, o dejar un datos con el que poder calcular cuándo se ha guardado. Por norma general le indicaremos cuánto tiempo debería estar ese elemento en la caché, el tiempo máximo. En este caso indicaremos los segundos que estará. Por norma general este tiempo se define según el tipo de fichero. Por ejemplo, las imágenes suelen poderse guardar meses, pero un fichero que pueda llegar a modificarse, minutos u horas. Cache-Control: max-age=3600; Pero, también por nuestra seguridad, podríamos indicar al navegador qué ocurre si un contenido está obsoleto, y no se puede recuperar del servidor una nueva versión. De la misma forma que el caso anterior, podríamos indicar este elemento dependiendo del tipo de contenido. Cache-Control: max-stale=3600; En la misma línea, podemos también forzar cada cuánto tiempo debería refrescarse este elemento, aunque tengamos los datos previos incluidos. Cache-Control: min-fresh=600; Validación y recarga El tercero de los elementos que podríamos indicar es cómo es este elemento que queremos cachear y qué hacer en determinados casos. Una opción sería la de indicar que un elemento debe volverse a actualizar una vez haya pasado la fecha de caducidad (cumpliendo las otras posibles reglas). En este caso deberemos informar que debe validarse de nuevo. Cache-Control: must-revalidate; En el caso contrario, es posible que tengamos algunos elementos que sabemos que nunca van a cambiar. Sobre todo si cuando subimos un elemento no lo sobrescribimos sino que lo versionamos de alguna manera, por lo que tenemos todos las versiones en ficheros distintos. En este caso esos elementos son inmutables. Cache-Control: immutable; Algunos casos y ejemplos Si queremos que un elemento no se guarde en el navegador del usuario, simplemente lanzaremos esta cabecera: Cache-Control: no-store; Pero si queremos que, por ejemplo, un logo se almacene, y no se va a cambiar ese fichero, podríamos lanzar algo tal que así: Cache-Control: public, max-age=2419200, immutable; Esto por defecto almacenaría ese fichero durante 1 mes y lo utilizaría sin revalidarse. Clear-Site-Data En alguna ocasión necesitamos que la caché del navegador de un usuario se vacíe. ¿Cómo conseguirlo desde nuestro propio sitio web? Pues con esta cabecera podemos indicar ciertos elementos que se pueden enviar para que se eliminen. Esta cabecera permite principalmente eliminar 3 elementos (o todos), que son la caché, las cookies o el almacenamiento (storage). Uno de los elementos es la caché, y si queremos vaciar todo lo que haya podemos mandar la cabecera correspondiente. Clear-Site-Data: "cache"; De la misma forma podemos eliminar todas las cookies del sitio. Clear-Site-Data: "cookies"; Y finalmente lo que se almacena en el sistema de almacenamiento (que no es la propia caché) como el localStorage o el IndexedDB... Clear-Site-Data: "storage"; Aunque también podemos pedirle que elimine combinaciones de varios elementos. Clear-Site-Data: "cache", "cookies"; O podemos decirle directamente que elimine todos los componentes, con un asterisco. Clear-Site-Data: "*"; Por ejemplo, al salir (hacer logout) de una página, podríamos eliminar todo el material cacheado. Para WordPress, al menos hasta WordPress 5. 7 no viene de forma nativa, por lo que se puede usar el plugin Clear Logout. Expires Si sabemos cuándo va a caducar un contenido en vez de informar cuánto tiempo lleva un elemento cacheado, podemos decirle directamente cuándo queremos que ese contenido desaparezca de la caché del navegador. Este elemento, si existe el Cache-Control, queda inutilizado. Expires: Wed, 21 Oct 2015 07:28:00 GMT ETag Aunque de por sí no es un sistema de caché, si que es un elemento complementario a las cachés, ya que vendría a ser un identificador único de un contenido,... --- ¿Cuántos productos son muchos productos para un WooCommerce? La pregunta en sí no es tanto para un WooCommerce sino para cualquier sistema que almacene información en una base de datos. ¿Cuántos productos son muchos productos para un WooCommerce? La pregunta en sí no es tanto para un WooCommerce sino para cualquier sistema que almacene información en una base de datos. https://es. wordpress. org/plugins/woocommerce/ Pero por poner cifras, planteemos que muchos productos son más de 3. 000 productos. Y que, para todo lo que explicaré a continuación, mi cifra de prueba de productos es de 25. 000, pero que, en este sentido, podríamos estar hablando de hasta 250. 000 productos sin problema. Por cierto, si quieres hacer pruebas y añadir miles de productos aleatorios para probar, puedes usar el plugin WooCommerce Product Generator que te generará todos los productos que quieras. https://es. wordpress. org/plugins/woocommerce-product-generator/ Hay muchos factores a la hora de tener en cuenta la optimización de un WooCommerce, ya que no sólo es la de la cantidad de productos sino la cantidad de visitas que tiene el sitio, y la cantidad de veces que se crea un carrito de la compra. El objetivo de este texto es el de explicar una casuística en la que hay "mucho de todo". WooCommerce es un plugin de WordPress, y WordPress funciona sobre distintos servicios, así que vamos a ir por partes, de la parte más baja, hasta llegar a lo que es la propia optimización de WooCommerce. Hosting Para empezar hablemos en general del hosting. Si quieres un WooCommerce óptimo, olvídate de un hosting compartido, necesitas sí o sí un VPS (lo que vendría a ser un hosting sólo para ti, tipo dedicado). Y aquí viene el primer escollo, y es que no todo el mundo tiene conocimientos técnicos para gestionarlo, y por mucho que te digan, ningún hosting te gestiona esto, por muy gestionado que sea. Necesitas a un técnico en tu equipo o alguien que sepa de Administración de Sistemas y de WordPress. Lo segundo es qué tipo de infraestructura queremos. Al hablar de VPS lo que hablamos son de máquinas que tienen sus propios recursos: CPU, RAM y disco. Aunque podemos separar todos los servicios en muchos, si queremos comenzar con buen pie necesitamos al menos 2 servidores VPS. En uno tendremos la base de datos (el MySQL) y en la otra tendremos el resto (el WordPress con su WooCommerce, el PHP, servidor web y caché). Si lo hacemos todo muy bien, con 2 máquinas de 2 CPU y 4 GB de RAM, con los tamaños de disco SSD que sean necesario, deberíamos tener más que suficiente para un WooCommerce que gestione 25. 000 productos y tenga 2. 500 carritos al día y que podrían ser unas 25. 000 visitas al día. Esto sería una base, unos mínimos que iría bien. Y puestos a elegir un sistema operativo, Ubuntu Server es una buena opción ya que mantiene todos los elementos bastante actualizados. Estamos hablando de unas máquinas que pueden costar unos 15,00 € al mes (2 CPU, 4 GB de RAM y 50 GB SSD), por lo que por 30 euros al mes puedes tener un sistema muy óptimo con soporte para 100. 000 carritos al mes sin problemas. Por cierto, no todas las empresas de hosting sirven. Para una instalación normal irte a Google, Amazon o similares puede ser una pérdida de tiempo y de dinero. Y otras empresas pueden tener algunas limitaciones, así que busca una empresa de servidores VPS que de de acceso completo al servidor y, en caso de que sea gestionado, que te detalle exactamente qué van a hacer cuando haya un pico de tráfico y cuáles son sus sistemas para optimizar y corregir momentos de saturación. Si la empresa no te da una respuesta clara, es mejor contratar servidores lo más abiertos posibles y buscarte a alguien que sepa de esto. Base de datos Si comenzamos por la base de datos, no deberíamos tener nada en especial. Podemos instalar la última versión de MariaDB o de MySQL que todo debería funcionar bien. Cuanto más moderna sea la versión de la base de datos, mejor, porque dará mejor rendimiento. Además, deberemos configurar la base de datos específicamente para la cantidad de CPU y RAM que tengamos. Esta configuración del my. cnf dependerá mucho de cada sistema, por lo que lo deberá hacer un profesional si no quieres que poniendo unas cifras incorrectas haya fallos de memoria o errores graves. Servidor web Si queremos un sistema escalable debemos dejar de lado Apache HTTPD, que sí, que funciona bien y es fácil para aquellos que quieren cambiar el . htaccess, pero tiene unos consumos de memoria elevados para alto tráfico. Así que nos pasaremos a nginx que carga su configuración en memoria de forma que tendrá todo precalculado. Obviamente deberemos configurar nginx de forma óptima a nivel de servidor, pero también deberemos configurar correctamente el host de WordPress para él mismo, optimizando los elementos estáticos para que sean cacheados en el servidor del usuario e incluso en el propio servidor web. PHP Si queremos sacar partido al máximo deberemos asegurarnos de usar la versión de PHP adecuada, y para empezar ha de ser PHP-FPM. En este momento, aunque existe PHP 8. 0, la versión recomendada es 7. 4. En cualquier caso debemos asegurarnos siempre de usar una versión que funcione correctamente con todos nuestros plugins. A nivel de PHP deberemos configurar todos las extensiones de WordPress recomendadas (WooCommerce no tiene ninguna en especial) y también activaremos el OpCache. Con esto activaremos la propia caché de PHP que, mientras no hagamos ninguna actualización, dejará precalculado todo el código fuente. La decisión principal de usar PHP-FPM es que, con nginx funciona mejor, y por otro, que se puede optimizar muy fácilmente cuánto consumo queremos tener en este servicio de forma simple mediante la configuración de sus hilos, uso de memoria y cantidad de RAM que tenga el servidor. Caché de Objetos Y como último gran componente deberemos elegir una caché de objetos. De forma nativa WordPress da soporte a Redis y memcached, cada una con sus pros y sus contras. Si bien es cierto que memcached puede ser algo... --- Cuando buscas un sistema de analítica web, pero no quieres ceder los datos a Google Analytics, la opción más interesante es la de Matomo (antiguamente Piwik). Cuando buscas un sistema de analítica web, pero no quieres ceder los datos a Google Analytics, la opción más interesante es la de Matomo (antiguamente Piwik). Existen dos opciones para usar Matomo con WordPress. La primera y más sencilla (pero nada óptima) es la del propio plugin de Matomo. Este plugin incluye todo el sistema y analítica en el propio sitio (por lo que sólo se podrá usar para ese sitio). Además, es una configuración poco optimizada y que si tienes más de 1. 000 visitas / día suele hacer aguas. https://es. wordpress. org/plugins/matomo/ La otra opción, en caso de tener una instalación de Matomo optimizada (que es lo que veremos a continuación) y que puede dar soporte a varios millones de visitas y a múltiples sitios web con el 100% de configuración, es la de usar un plugin que te permite conectar con el sistema y configurar el código JavaScript a tu gusto. https://es. wordpress. org/plugins/wp-piwik/ Instalar Matomo Para tener un sistema muy estable, lo mejor es tener un VPS separado de cualquier instalación actual y que te permita ir ajustando los recursos según las necesidades. Además, quizá es mejor no mezclar el software de WordPress con el de Matomo para disponer de los recursos completamente libres en cada caso. Uno de los objetivos que plantearemos será que esta instalación permita aceptar cualquier tipo de hostname, del estilo a analytics. example. com. Al ser un subdominio del sitio principal, todo el sistema de cookies se considerará de primeros y, aunque en los términos y condiciones de tu sitio debes informar de la retención de datos, no deberás hacer un uso ampliado de las cookies, ya que son propias del sitio. Los recursos recomendados dependerán de las visitas que quieras contabilizar. Aproximadamente estos son los recursos más recomendables: 100. 000 visitas/mes (3. 000 visitas/día) 1 CPU2 GB RAM50 GB SSD 1. 000. 000 visitas/mes (30. 000 visitas/día) 4 CPU8 GB RAM250 GB SSD El tamaño del disco es muy relativo, y quizá dependerá más de cómo se archiven los datos o cuánto tiempo quieras retenerlos, por lo que quizá es mejor comenzar con poco e ir revisando según vayan siendo necesarios. Configurando el VPS Para esta instalación vamos a hacer uso de un servidor Ubuntu 20. Como en cualquier servidor, comenzaremos configurando algunos elementos básicos. El primero de ellos será la hora, un elemento bastante importante en este caso. timedatectl set-timezone 'UTC' timedatectl set-ntp on Posteriormente revisaremos la versión del Ubuntu y actualizaremos todo el sistema operativo. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Instalaremos herramientas básicas. apt -y install software-properties-common curl vim zip unzip apt-transport-https Y dejaremos activadas las actualizaciones automáticas de seguridad o muy importantes. apt -y install unattended-upgrades dpkg-reconfigure -plow unattended-upgrades Instalando MariaDB Para la base de datos usaremos MariaDB 10. 5. curl -sS https://downloads. mariadb. com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10. 5" apt -y install mariadb-server mariadb-client Una vez instalado, configuraremos el propio servicio. Recuerda indicarle una contraseña para el usuario de root. mysql_secure_installation Como configuración especial del MariaDB para Matomo, activaremos el tamaño máximo de paquetes (debido a que la recepción de información de cada visita es mayor de la que viene por defecto). vim /etc/mysql/mariadb. conf. d/50-server. cnf Incluyendo los siguientes datos: max_allowed_packet = 128MB Para acabar, reiniciaremos el servicio y configuraremos que se active al reiniciar la máquina. systemctl stop mysql. service systemctl enable mysql. service systemctl start mysql. service systemctl status mysql. service Instalando nginx Para Matomo siempre es mejor usar un nginx que un Apache, y en este caso es lo que vamos a hacer. Así podremos optimizar qué y cuándo se ejecuta y optimizar los recursos. add-apt-repository -y -s ppa:ondrej/nginx apt -y install nginx nginx-extras Una vez instalado, reiniciaremos el servicio y lo activaremos al reiniciar la máquina. systemctl stop nginx. service systemctl enable nginx. service systemctl start nginx. service systemctl status nginx. service Instalando PHP Aprovechando que Matomo 4 soporta la última versión de PHP, la 8. 0, instalaremos únicamente esta versión. add-apt-repository -y -s ppa:ondrej/php apt -y install php8. 0 php8. 0-fpm php8. 0-common php8. 0-dev php8. 0-cli php8. 0-bcmath php8. 0-curl php8. 0-gd php8. 0-imap php8. 0-mbstring php8. 0-mysql php8. 0-opcache php8. 0-soap php8. 0-xml php8. 0-zip php8. 0-xdebug libgeoip-dev php-pear pkg-config imagemagick libmagickwand-dev php8. 0-imagick Una vez instalado, activaremos el inicio automático y reiniciaremos el servicio. systemctl stop php8. 0-fpm. service systemctl enable php8. 0-fpm. service systemctl start php8. 0-fpm. service systemctl status php8. 0-fpm. service Aprovecharemos en actualizar el PEAR. pecl channel-update pecl. php. net Y validaremos que tenemos PHP 8. 0. php -v Instalando Redis Para evitar la saturación de la base de datos, configuraremos un sistema de cola que sea el que reciba los datos y que, posteriormente, se vayan incorporando en la base de datos. De esta forma, si llega un pico de tráfico, no se saturará el sistema. apt -y update apt -y install redis-server php8. 0-redis Como en los casos anteriores, activaremos Redis y lo reiniciaremos. systemctl stop redis-server. service systemctl enable redis-server. service systemctl start redis-server. service systemctl status redis-server. service Instalando Certbot (Let's Encrypt) Para conseguir que los dominios que alojemos tengan su certificado TLS activo y funcionando, configuraremos Certbot. snap install core && snap install --classic certbot ln -s /snap/bin/certbot /usr/bin/certbot Activaremos el sistema para que una vez al día revise los certificados instalados y, si hay alguno caducado, lo actualice. crontab -e Y añadiremos la revisión a las 06:45 UTC cada día. 45 6 * * * certbot renew Configurando nginx Eliminaremos las páginas por defecto del servidor y añadiremos nuestros propios contenidos. rm /var/www/html/index. * vim /var/www/html/index. html Y dejaremos el contenido: Hello World! Haremos lo mismo para el robots. txt vim /var/www/html/robots. txt E incluiremos el contenido para que no sea indexable. User-Agent: * Disallow: / Eliminaremos la configuración por defecto de nginx. cd /etc/nginx/sites-enabled/ rm default cd /etc/nginx/sites-available/ rm default Y añadiremos la nuestra. cd /etc/nginx/ rm nginx. conf vim nginx. conf... --- Aunque WordPress tiene sus guías de seguridad para plugins y themes, con sus propias funciones, muchas veces entre tanto código puedes perderte. Y ahí entra SonarQube. Aunque WordPress tiene sus guías de seguridad para plugins y themes, con sus propias funciones, muchas veces entre tanto código puedes perderte. Y ahí entra SonarQube. SonarQube es una herramienta que analiza la calidad del código y su seguridad y que puede ser una herramienta muy útil para mejorar ese plugin que quizá has hecho sin mucho control y que, antes de ponerse en producción, puedes mejorar ligeramente. SonarQube como tal es una plataforma en la que poder integrar todos los proyectos que quieras y que tiene unos requisitos bastante diferentes a los de WordPress, por lo que es más que recomendable disponer de un sistema completamente independiente de otros. Ten en cuenta que funciona con Java, PostgreSQL y nginx. Configuración del Servidor Para poder instalar y gestionar correctamente SonarQube montaremos una máquina del al menos 1 CPU y 2 GB de RAM, con al menos 10 GB de disco. En este ejemplo usaremos Ubuntu 20. Comenzaremos con la puesta en hora del servidor. timedatectl set-timezone 'UTC' timedatectl set-ntp on Y haremos una actualización de todo el servidor. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Posteriormente instalaremos algunas herramientas útiles. apt -y install software-properties-common curl vim zip unzip apt-transport-https Y finalmente dejaremos el sistema para que aplique actualizaciones de seguridad automáticamente. apt -y install unattended-upgrades dpkg-reconfigure -plow unattended-upgrades Instalando Java Para que funcione necesitaremos Java 11, así que optaremos por OpenJDK. apt -y install openjdk-11-jdk openjdk-11-jre Podemos comprobar que está instalado para ver su versión. java -version Que nos devolverá un mensaje similar a: openjdk version "11. 0. 10" 2021-01-19 OpenJDK Runtime Environment (build 11. 0. 10+9-Ubuntu-0ubuntu1. 20. 04) OpenJDK 64-Bit Server VM (build 11. 0. 10+9-Ubuntu-0ubuntu1. 20. 04, mixed mode, sharing) Instalando PortgreSQL Descargaremos las claves. cd wget --quiet -O - https://www. postgresql. org/media/keys/ACCC4CF8. asc | apt-key add - echo "deb http://apt. postgresql. org/pub/repos/apt/ `lsb_release -cs`-pgdg main" | tee /etc/apt/sources. list. d/pgdg. list Instalamos PostgreSQL apt -y update apt -y install postgresql-12 postgresql-client-12 Configuraremos el sistema para que active el servidor cuando se inicie la máquina. systemctl enable postgresql. service systemctl restart postgresql. service systemctl status postgresql. service Vamos a configurar la contraseña del servicio como root, y crear una base de datos para su uso posterior. su - postgres psql -c "alter user postgres with password 'contraseña_de_root'" psql Y creamos la base de datos, con su usuario y contraseña. CREATE DATABASE sonarqube; CREATE USER sonarqube WITH ENCRYPTED PASSWORD 'contraseña_de_sonarqube'; GRANT ALL PRIVILEGES ON DATABASE sonarqube TO sonarqube; Instalando fuentes Configuraremos el sistema de fuentes y tipografía para el servicio. apt -y install fontconfig-config libfreetype6 Instalando SonarQube Visitaremos el sitio web con la lista de descargas y buscaremos el enlace a la última versión. En este caso usaremos la versión 8. 8. cd wget https://binaries. sonarsource. com/Distribution/sonarqube/sonarqube-8. 8. 0. 42792. zip Descomprimimos el fichero. unzip sonarqube-8. 8. 0. 42792. zip rm sonarqube-8. 8. 0. 42792. zip Y dejamos el software en la carpeta de uso. mv . /sonarqube-8. 8. 0. 42792/ /opt/sonarqube/ cd /opt/sonarqube/ Allí configuraremos los datos de acceso a la base de datos. vim /opt/sonarqube/conf/sonar. properties Y modificamos las líneas de configuración (por defecto están com,entadas). sonar. jdbc. username=sonarqube sonar. jdbc. password=contraseña_de_sonarqube sonar. jdbc. url=jdbc:postgresql://localhost/sonarqube Para acabar crearemos un usuario de ejecución del software. useradd -M -d /opt/sonarqube/ -r -s /bin/bash sonarqube chown -R sonarqube: /opt/sonarqube Para ejecutarlo, lo crearemos en modo servicio. De esta forma, cuando se arranque la máquina se ejecutará automáticamente. vim /etc/systemd/system/sonarqube. service En el fichero incluiremos el arranque del sistema. Description=SonarQube service After=syslog. target network. target Type=simple User=sonarqube Group=sonarqube PermissionsStartOnly=true ExecStart=/bin/nohup java -Xms32m -Xmx32m -Djava. net. preferIPv4Stack=true -jar /opt/sonarqube/lib/sonar-application-8. 8. 0. 42792. jar StandardOutput=syslog LimitNOFILE=131072 LimitNPROC=8192 TimeoutStartSec=5 Restart=always SuccessExitStatus=143 WantedBy=multi-user. target IMPORTANTE: deberemos ajustar el fichero de la versión correspondiente al sistema que tengamos en la línea de ExecStart. ll /opt/sonarqube/lib/ Ahí debemos encontrar un fichero llamado sonar-application-8. 8. 0. 42792. jar, que habrá que ajustar según la versión descargada. Le diremos al sistema que encuentre esta nueva configuración. systemctl daemon-reload Antes de lanzarlo modificaremos la configuración del sistema. echo 'vm. max_map_count=262144' >> /etc/sysctl. conf Ahora sí, cargaremos el sistema y lo validamos. systemctl enable --now sonarqube systemctl status sonarqube. service Podemos validar que hay ficheros de logs. ll /opt/sonarqube/logs Instalando nginx Instalaremos un nginx. apt -y install nginx Y, para un funcionamiento sencillo, lo lanzaremos sin HTTPS (se puede configurar, pero para este ejemplo no sería necesario). vim /etc/nginx/sites-available/sonarqube Y cargamos la configuración. server { listen 80; server_name sonarqube. example. com; access_log /var/log/nginx/sonarqube. access. log; error_log /var/log/nginx/sonarqube. error. log; proxy_buffers 16 64k; proxy_buffer_size 128k; location / { proxy_pass http://127. 0. 0. 1:9000; proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto http; } } Para evitar problemas, sí que configuraremos de forma algo más óptima el propio nginx. cd /etc/nginx/ rm nginx. conf vim nginx. conf Y le añadiremos nuestra configuración personalizada. user www-data; pid /run/nginx. pid; worker_processes auto; worker_rlimit_nofile 65535; include /etc/nginx/modules-enabled/*. conf; events { multi_accept on; worker_connections 65535; use epoll; } http { charset utf-8; sendfile on; tcp_nopush on; tcp_nodelay on; server_tokens off; more_clear_headers Server; log_not_found off; types_hash_max_size 2048; client_max_body_size 64m; keepalive_timeout 10; server_names_hash_bucket_size 128; server_names_hash_max_size 1024; include /etc/nginx/mime. types; default_type application/octet-stream; # logging access_log /var/log/nginx/access. log; error_log /var/log/nginx/error. log; # TLS ssl_protocols TLSv1. 2 TLSv1. 3; ssl_prefer_server_ciphers on; # gzip gzip on; gzip_vary on; gzip_proxied any; gzip_comp_level 9; gzip_disable "msie6"; gzip_buffers 16 8k; gzip_min_length 1100; gzip_types application/atom+xml application/javascript application/json application/x-javascript application/xml application/xml+rss image/svg+xml text/css text/javascript text/plain text/xml; # more include /etc/nginx/conf. d/*. conf; include /etc/nginx/sites-enabled/*; } Validaremos la configuración y reiniciamos nginx. ln -s /etc/nginx/sites-available/sonarqube /etc/nginx/sites-enabled/ nginx -t systemctl restart nginx Y ya tenemos todo listo para comenzar a funcionar. Visitaremos la URL de nuestro sitio, http://sonarqube. example. com/, y accederemos, la primera vez, con el usuario admin y contraseña admin. Creando un proyecto Aunque no es la intención de este tutorial explicar el funcionamiento de SonarQube y todas sus opciones, sí que haremos un repaso... --- Cuando pensamos en un antivirus para WordPress como plugin, en realidad tenemos un sistema que busca patrones dentro del código, pero muy limitado. En cambio, un antivirus encuentra otro tipo de perfiles. Cuando pensamos en un antivirus para WordPress como plugin, en realidad tenemos un sistema que busca patrones dentro del código, pero muy limitado. En cambio, un antivirus encuentra otro tipo de perfiles. Y es que existen antivirus para Linux que trabajan igual que en cualquier otro sistema operativo, no sólo buscando funciones que pueden ser peligrosas en el código de WordPress, sino también en otros ficheros, como documentos, imágenes o ejecutables. Si tienes un hosting compartido, es muy probable que tu proveedor ya disponga de medidas de seguridad generales, pero si gestionas tu propia infraestructura, disponer de un antivirus siempre es una buena opción. En este caso usaremos un estándar como es ClamAV. Su instalación para Ubuntu es muy simple. apt -y install clamav clamav-daemon Y una vez instalado, podrás lanzar el escaneo de la carpeta que quieras. clamscan --infected --infected --recursive /webs/example. com/ En este caso está configurado para que no te muestre todos los ficheros, sino sólo los que puedan contener algún tipo de infección. Con un poco de suerte, sólo recibirás el resumen del escaneo. ----------- SCAN SUMMARY ----------- Known viruses: 8515047 Engine version: 0. 102. 4 Scanned directories: 352 Scanned files: 2517 Infected files: 0 Data scanned: 107. 12 MB Data read: 49. 50 MB (ratio 2. 16:1) Time: 58. 752 sec (0 m 58 s) En el caso de que apareciese algún problema con algún fichero, aparecería el fichero en concreto y, a partir de ahí, es cuestión de eliminarlo, moverlo o ponerlo en cuarentena según sea necesario. --- Una de las preocupaciones habituales de los que tienen un sitio web con WordPress es saber cuánto tráfico y a qué velocidad les funcionará a los usuarios el sitio web. Una de las preocupaciones habituales de los que tienen un sitio web con WordPress es saber cuánto tráfico y a qué velocidad les funcionará a los usuarios el sitio web. Y la herramienta para ello es la de un test de estrés. Para hacer estas pruebas podemos usar AB (Apache HTTP server benchmarking tool), pero también una herramienta más moderna en llamada wrk (a HTTP benchmarking tool). La herramienta la deberemos tener en una máquina conectada a Internet si queremos hacer llamadas a una web pública. En este caso el ejemplo será sobre Ubuntu. Instalación de la herramienta Lo primero que hemos de hacer es descargar y compilar la herramienta. Una vez acabado estará disponible en el servidor. apt -y install build-essential libssl-dev git unzip cd git clone https://github. com/wg/wrk. git wrk cd wrk make cp wrk /usr/local/bin A partir de este momento, podemos ejecutar la herramienta y ver sus opciones. Usage: wrk Options: -c, --connections Connections to keep open -d, --duration Duration of test -t, --threads Number of threads to use -s, --script Load Lua script file -H, --header Add header to request --latency Print latency statistics --timeout Socket/request timeout -v, --version Print version details Numeric arguments may include a SI unit (1k, 1M, 1G) Time arguments may include a time unit (2s, 2m, 2h) Haciendo una primera prueba Pruebas de estrés puede haber varias, así que haremos una primera prueba, sencilla, que es la de acceder, mucho, a la página principal de nuestro sitio. La configuración dependerá mucho de los recursos de la máquina. En este caso, vamos a hacer una prueba en un VPS que tiene 4 CPU, y haremos una prueba durante 30 segundos. Según la configuración que tengamos, podemos añadir más o menos usuarios simultáneos (por CPU), en este caso 250 usuarios. En total significa que habrá 1. 000 usuarios en 30 segundos. wrk -c250 -d30s -t4 --latency --timeout 5s https://www. example. com/ c: 250 conexiones por hilod: 30 segundost: 4 hilos (CPU) El resultado será similar a este: Running 10s test @ https://www. example. com/ 1 threads and 50 connections Thread Stats Avg Stdev Max +/- Stdev Latency 2. 85s 902. 12ms 3. 56s 83. 67% Req/Sec 15. 08 7. 34 40. 00 85. 71% Latency Distribution 50% 3. 31s 75% 3. 39s 90% 3. 44s 99% 3. 53s 147 requests in 10. 02s, 1. 40MB read Requests/sec: 14. 67 Transfer/sec: 142. 55KB Para ajustar las peticiones deberías tener en cuenta como base las CPU de la máquina, y la cantidad de peticiones (si quieres probar normal, 100 está bien, si tienes montado algo muy bien, una prueba interesante es de 1. 000. El tiempo, el que se considere... entre 30 segundos y 1 minuto está bien. Estresando el login Sin duda probar la página principal está bien, pero como puede haber caché, en realidad nos e prueba mucha cosa, así que quizá podamos estresar el sistema accediendo al panel de administración (puede ser de un usuario sin permisos). En este caso el test va a estar más en la base de datos. Lo primero que deberemos hacer es crear un fichero de configuración especial. Aquí incluiremos la página del login, y el usuario y contraseña de un usuario. vim wplogin. lua Ahí incluiremos los datos de acceso y la prueba. wrk. method = "POST" wrk. body = "log=usuario_de_test&pwd=contrasenya_del_usuario&wp-submit=Acceder&testcookie=1&redirect_to=https://www. example. com/wp-admin/" wrk. headers = "application/x-www-form-urlencoded" En este caso, la prueba no puede ser tan grande como en el caso anterior. Lo que probaremos será cuántos logins/segundo se pueden hacer. Por ejemplo, probemos si se pueden hacer 10 logins por segundos. wrk -c100 -d10s -t1 --latency --timeout 5s -s wplogin. lua https://www. example. com/wp-login. php Haciendo peticiones a múltiples URL Una de las cosas que habitualmente se suele probar es llamar a sólo una única URL, y quizá lo más interesante es elegir y probar distintas URL: la página principal, una categoría, una entrada, una página, un producto... vim wpurl. lua Ahí incluiremos los datos de acceso y la prueba. init = function(args) local r = {} r = wrk. format(nil, "pagina/") r = wrk. format(nil, "post/") r = wrk. format(nil, "tag/etiqueta/") r = wrk. format(nil, "category/categoria/") req = table. concat(r) end request = function return req end Ahora haremos la prueba para que llame, de forma aleatoria, a estas URL... wrk -c1k -d1m -t16 --latency --timeout 5s -s wpurl. lua https://www. example. com/ Y a probar y optimizar. --- Es posible que no tenga una IP fija en casa o en el trabajo, y que quieras filtrar los accesos a tu WordPress a una IP concreta. Y para esto tenemos las VPN. Es posible que no tenga una IP fija en casa o en el trabajo, y que quieras filtrar los accesos a tu WordPress a una IP concreta. Y para esto tenemos las VPN. Si bien es cierto que las VPN comerciales varían las direcciones IP por seguridad, es posible montar tu propia VPN profesional, con tu propio control, y de forma bastante barata. Una VPN puede costarte unos 10 euros mensuales (100 euros anuales) pero un servidor VPN en un VPS puede costarte unos 3 euros/mes, además de que será sólo para ti. Para este ejemplo vamos a disponer de un servidor con Ubuntu 20, y nada más. En principio este sistema permitiría instalarse en cualquier servidor, incluso en uno que ya esté usándose para otros servicios. IMPORTANTE: Algunos proveedores tienen un cortafuegos (firewall), por lo que si proveedor lo tiene, deberás abrir el puerto 51820 (UDP) para la conexión con WireGuard. Configurando el servidor Lo primero que haremos es poner al día el servidor con Ubuntu. Primero consfiguraremos la hora y la zona horaria universal. timedatectl set-timezone UTC timedatectl set-ntp on Posteriormente haremos una actualización de todo el sistema. apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Instalaremos algunas herramientas útiles. apt -y install software-properties-common curl vim zip unzip apt-transport-https Y la instalación de actualizaciones automáticas de seguridad. apt -y install unattended-upgrades dpkg-reconfigure -plow unattended-upgrades Como vamos a usar este servidor para reenviar tráfico, hemos de validar que esto esté permitido. En el fichero buscaremos estas líneas (vienen por defecto desactivadas). Si están, quitaremos la # de delante. vim /etc/sysctl. conf Dejando la configuración activada. net. ipv4. ip_forward=1 net. ipv6. conf. all. forwarding=1 Y activaremos la configuración. sysctl -p Instalando WireGuard Por suerte, esta VPN viene de serie con Ubuntu 20, por lo que simplemente tendremos que instalarla. apt -y install wireguard Como requiere del control del kernel del sistema, validaremos que esté disponible. modprobe wireguard lsmod | grep wireguard Si todo ha ido bien, veremos las siguientes líneas: wireguard 212992 0 ip6_udp_tunnel 16384 1 wireguard udp_tunnel 16384 1 wireguard Configurando WireGuard Antes de comenzar necesitamos conocer algunos datos. Ahora deberemos ver qué interfaz de red tiene nuestro servidor. Por norma general veremos el "lo" (que es el que llama a la propia máquina) y algún otro de tipo broadcast que es el que se conecta de forma pública a internet. En nuestro caso es "eth0". ip link show 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether fa:16:3e:1f:91:a2 brd ff:ff:ff:ff:ff:ff Ahora que sabemos por dónde se ha de conectar, configuraremos WireGuard. Lo primero será acceder a la carpeta de configuración y establecer unos mínimos de seguridad para esos ficheros. cd /etc/wireguard umask 077 Y crearemos las claves de seguridad de este servidor. wg genkey | tee server_private. key | wg pubkey | tee server_public. key Esto generará dos ficheros que podemos ver si los listamos. -rw------- 1 root root 45 Mar 20 11:04 server_private. key -rw------- 1 root root 45 Mar 20 11:04 server_public. key Para saber el : cat server_private. key Que nos devolverá un código parecido a este: cBM+jwqXBH94Fyp5+qILQozfV7lEmnloZPWMdZY5KXQ= Haremos lo mismo para saber el : cat server_public. key Que nos devolverá un código similar a este: B+EXkrZs2xEQLrKskg+wlyWnN60kOnYTnwJTjZKlGjs= Ahora que ya tenemos las claves públicas y privadas, montaremos la configuración del Wireguard. Para ello debemos crear el fichero de configuración. vim /etc/wireguard/wg0. conf E incluiremos el siguiente contenido: Address = 10. 0. 0. 1/24 SaveConfig = true ListenPort = 51820 PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE PrivateKey = cBM+jwqXBH94Fyp5+qILQozfV7lEmnloZPWMdZY5KXQ= # Aquí pondremos la Lo siguiente que hemos de revisar es que el firewall de la máquina permita el tráfico: ufw route allow in on wg0 ufw allow 51820/udp Y ya podremos levantar el WireGuard y establecerlo como un servicio, de forma que aunque se reinicie la máquina, se vuelva a arrancar automáticamente. wg-quick up wg0 systemctl enable wg-quick@wg0 Para saber si todo ha funcionado correctamente, podemos ejecutar un comando y validar que WireGuard está activo. wg show wg0 Que nos mostrará algo parecido a esto: interface: wg0 public key: B+EXkrZs2xEQLrKskg+wlyWnN60kOnYTnwJTjZKlGjs= private key: (hidden) listening port: 51820 Configurando el cliente de WireGuard Ahora que tenemos el servidor VPN funcionando, hemos de configurar los clientes. WindowsMacOSAndroidiOS En este caso voy a usar de ejemplo el de Windows. Una vez instalado, crearemos una nueva conexión en blanco. Esta conexión nos generará una clave pública y una privada. Tenemos de ejemplo las claves generadas, que son: cliente_private. key: IP3QLKKG4R2u/KO0Ek1WvBsUAhe099muBj+e6QviYF8= cliente_public. key: FaEbJJcA0V/6E8Z9uPNsVVT4QanvOREXXLkVkQ2ncgI= Con estos datos, y los datos del servidor, podremos configurar la cuenta: PrivateKey = IP3QLKKG4R2u/KO0Ek1WvBsUAhe099muBj+e6QviYF8= Address = 10. 0. 0. 2/32 DNS = 8. 8. 8. 8, 1. 1. 1. 1 PublicKey = B+EXkrZs2xEQLrKskg+wlyWnN60kOnYTnwJTjZKlGjs= AllowedIPs = 0. 0. 0. 0/0 Endpoint = 185. 253. 153. 43:51820 PersistentKeepalive = 15 En el Address configuraremos la siguiente IP de la lista de las del servidor (en el servidor eran 10. 0. 0. 1/24) y aquí configuraremos exclusivamente 1 IP, que será la siguiente, 10. 0. 0. 2/32. Si creamos otro usuario, aplicaríamos la misma fórmula, por lo que sería 10. 0. 0. 3/32 y así sucesivamente. En la PublicKey configuraremos la clave pública del servidor, y en el Endpoint pondremos la IP pública del servidor y el puerto. Esta dirección IP será con la que una vez estemos conectados navegaremos, y será nuestra IP fija. Guardaremos esta configuración y nos volveremos al servidor a conectar este nuevo usuario. Configurando el cliente en el servidor Iremos de nuevo al servidor y, lo primero, apagaremos el WireGuard. wg-quick down wg0 Abriremos el fichero de configuración para añadir al final los nuevos datos. vim /etc/wireguard/wg0. conf En este caso pondremos la clave... --- El kernel de CentOS 7 está bastante obsoleto por defecto pero se puede actualizar si necesitas una versión superior. En alguna ocasión me he encontrado que el proveedor de VPS mantiene una versión concreta del kernel de CentOS 7 que puede ser muy antiguo, una versión 3. 10 o similar, cuando necesitamos una versión superior, por ejemplo una 5. x. Seguiremos algunos pasos previos... y cuando tengamos toda la información, haremos la actualización. Primero validaremos que CentOS permite la actualización del kernel. vim /etc/yum. repos. d/CentOS-Base. repo Buscaremos si está activado o no, y si no lo está, lo haremos. enabled=1 Con esto, si actualizamos, nos pondrá la versión 3. 10, que es la que el sistema lleva por defecto. Para ello configuraremos, siempre a medida de backup, que esté disponible el sistema propio. yum clean all && yum update yum -y install kernel-devel kernel Con esto, tendremos que CentOS dispondrá de su kernel oficial y sus actualizaciones. El siguiente paso será instalar unas nuevas versiones del kernel... la última disponible, en la medida de lo posible. Para ello instalaremos los repos de ElRepo. yum -y install yum-plugin-fastestmirror rpm --import https://www. elrepo. org/RPM-GPG-KEY-elrepo. org rpm -Uvh https://www. elrepo. org/elrepo-release-7. el7. elrepo. noarch. rpm yum clean all && yum update A partir de aquí, instalaremos la última versión disponible yum --enablerepo=elrepo-kernel install kernel-ml Y una vez instalados, revisaremos qué kernels hay disponibles. sudo awk -F\' '$1=="menuentry " {print i++ " : " $2}' /etc/grub2. cfg En principio, de toda la lista, el primero de ello será el 0, con el nuevo kernel. sudo grub2-set-default 0 Haremos el cambio en la configuración de arranque. sudo grub2-mkconfig -o /boot/grub2/grub. cfg Y finalmente reiniciaremos la máquina. reboot Al reiniciar, podremos ver si se ha aplicado el nuevo kernel. uname -snr Y con esto podremos disponer de un sistema mucho más actualizado y requerido por algún software relacionado con la web, correo o DNS. --- Una forma sencilla es incorporar algunas reglas de cortafuegos directamente en el .htaccess que bloqueen peticiones por parámetro, o algunos métodos de conexión, o determinados robots. Existen muchas formas de tener un Firewall en WordPress... en muchos casos mediante plugins que funcionan con PHP y que sobrecargan el servidor. Una forma sencilla es incorporar algunas reglas de cortafuegos directamente en el . htaccess que bloqueen peticiones por parámetro, o algunos métodos de conexión, o determinados robots. Si es así, estos filtros pueden servirte para mejorar tu seguridad. # QUERY STRINGS RewriteEngine On RewriteCond %{QUERY_STRING} (eval\ RewriteCond %{QUERY_STRING} (127\. 0\. 0\. 1) RewriteCond %{QUERY_STRING} ({2000,}) RewriteCond %{QUERY_STRING} (javascript:)(. *)(;) RewriteCond %{QUERY_STRING} (base64_encode)(. *)(\ RewriteCond %{QUERY_STRING} (GLOBALS|REQUEST)(=|\ RewriteCond %{QUERY_STRING} (|%3) RewriteCond %{QUERY_STRING} (\\|\. \. \. |\. \. /|~|`||\|) RewriteCond %{QUERY_STRING} (boot\. ini|etc/passwd|self/environ) RewriteCond %{QUERY_STRING} (thumbs? (_editor|open)? |tim(thumb)? )\. php RewriteCond %{QUERY_STRING} (\'|\")(. *)(drop|insert|md5|select|union) RewriteRule . * - # REQUEST METHOD RewriteCond %{REQUEST_METHOD} ^(connect|debug|move|trace|track) RewriteRule . * - # REQUEST STRINGS RedirectMatch 403 (? i)({2000,}) RedirectMatch 403 (? i)(https? |ftp|php):/ RedirectMatch 403 (? i)(base64_encode)(. *)(\ RedirectMatch 403 (? i)(=\\\'|=\\%27|/\\\'/? )\. RedirectMatch 403 (? i)/(\$(\&)? |\*|\"|\. |,|&|&? )/? $ RedirectMatch 403 (? i)(\{0\}|\(/\(|\. \. \. |\+\+\+|\\\"\\\") RedirectMatch 403 (? i)(~|`||:|;|,|%|\\|\s|\{|\}|\|\|) RedirectMatch 403 (? i)/(=|\$&|_mm|cgi-|etc/passwd|muieblack) RedirectMatch 403 (? i)(&pws=0|_vti_|\(null\)|\{\$itemURL\}|echo(. *)kae|etc/passwd|eval\(|self/environ) RedirectMatch 403 (? i)\. (aspx? |bash|bak? |cfg|cgi|dll|exe|git|hg|ini|jsp|log|mdb|out|sql|svn|swp|tar|rar|rdf)$ RedirectMatch 403 (? i)/(^$|(wp-)? config|mobiquo|phpinfo|shell|sqlpatch|thumb|thumb_editor|thumbopen|timthumb|webshell)\. php # USER AGENTS SetEnvIfNoCase User-Agent ({2000,}) bad_bot SetEnvIfNoCase User-Agent (binlar|casper|checkpriv|choppy|clshttp|cmsworld|diavol|dotbot|extract|feedfinder|flicky|g00g1e|harvest|heritrix|httrack|kmccrew|loader|miner|nikto|nutch|planetwork|postrank|purebot|pycurl|python|seekerspider|siclab|skygrid|sqlmap|sucker|turnit|vikspider|winhttp|xxxyy|youda|zmeu|zune) bad_bot # Apache < 2. 3 Order Allow,Deny Allow from all Deny from env=bad_bot # Apache >= 2. 3 Require all Granted Require not env bad_bot --- La interfaz del WordPress Toolkit le permite instalar, configurar y administrar fácilmente WordPress. Es una herramienta que viene de Plesk en colaboración con cPanel. La interfaz del WordPress Toolkit le permite instalar, configurar y administrar fácilmente WordPress. Es una herramienta que viene de Plesk en colaboración con cPanel. Hay una versión Lite (gratuita) y una Deluxe (bajo licencia). ¿Cómo instalar WordPress Toolkit en cPanel? Para instalarlo sólo hay en entrar por SSH al servidor, como root y ejecutar el siguiente comando: sh --- La caché de ficheros estáticos es uno de los elementos más importantes a la hora de gestionar una buena caché, sobre todo de aquellos ficheros que se pueden considerar inmutables. La caché de ficheros estáticos es uno de los elementos más importantes a la hora de gestionar una buena caché, sobre todo de aquellos ficheros que se pueden considerar inmutables. En general un fichero inmutable es el que no cambia, y esto no siempre ocurre. Para empezar sí que podríamos plantear que en un WordPress los ficheros Media que subimos al panel son inmutables, ya que al subir un fichero nuevo se generará una URL nueva, y que esa URL no cambiará nunca. Hablo de ficheros de imágenes, PDF y similares. Para estos casos deberíamos configurar la cabecera de caché con el tiempo que definamos, y con una etiqueta concreta: Cache-Control: public, max-age=86400, immutable Hay que tener en cuenta que no todos los navegadores soportan esta cabecera, pero si no la soportan y está, no pasa nada porque es ignorada. Puedes ver una referencia de dónde está soportado. El caso más útil para este tipo de caché, además de los casos anteriores, es el de las URL Fingerprinted, que son aquellas URL que pueden variar, pero que en ese caso concreto, su contenido siempre es el mismo. Un ejemplo son las URL de caché de CSS o JS que generan muchos sistemas de "optimización", creando ficheros del estilo a style. abc123. css Este fichero lleva un sistema de control (la parte de abc123) que hace que ese contenido sea único, y que si el contenido del fichero cambia, el nombre del fichero también lo haga. Esto ayudaría a que sistemas de caché permitan crear URL inmutables. --- En algunas ocasiones necesitamos sacar uno de los sitios de un WordPres MultiSite a un sitio normal, una instalación simple. El proceso no es automático aunque hay algunas herramientas que lo permiten. En algunas ocasiones necesitamos sacar uno de los sitios de un WordPres MultiSite a un sitio normal, una instalación simple. El proceso no es automático aunque hay algunas herramientas que lo permiten. Herramientas como Duplicator Pro permiten hacer una copia de todo el sitio y al recuperarlo, poder elegir sólo uno de ellos para restaurar. Pero en la mayoría de casos no se tienen herramientas externas, por lo que se puede realizar un proceso paso a paso de migración. Preparación Lo primero que hemos de saber es el ID del sitio que vamos a querer separar. Esto lo podemos conseguir en la lista de Sitios del WordPress MultiSite. En este ejemplo vamos a usar el ID número 2. La base de datos Si accedemos a un panel del estilo a phpMyAdmin, deberemos exportar las tablas que comienzan con el prefijo que tengamos, seguido de 2_. Las tablas tendrán una apariencia del estilo a wp_2_comments. Además de estas tablas deberemos seleccionar las tablas que afectan a los usuarios, que son wp_users y wp_usersmeta. Cuando tengamos el fichero . SQL deberemos sustituir todos los nombres de las tablas. La idea es quitar el 2_ de todos los sitios. Como esto puede afectar a muchas cosas, haremos una sustitución de wp_2_ por wp_. Ahora que ya tenemos el fichero SQL deberemos importarlo en el nuevo sitio. Deberemos tener una base de datos creada pero no el sitio o el WordPress instalado, es decir, ha de estar vacía. Los ficheros Para el nuevo sitio podemos descargar la última versión de WordPress y subirla al servidor. Ahora que tenemos los ficheros base, deberemos copiar del sitio de origen algunas cosas del /wp-content/. Por un lado deberemos copiar los plugins activos, por otro los themes que estemos usando y finalmente los ficheros. De los ficheros subidos deberemos buscar la carpeta /wp-content/uploads/sites/2/ (donde 2 sería el ID) y lo copiaremos a /wp-content/uploads/. La configuración Ahora que tenemos la base de datos al punto, y los ficheros donde toca, hemos de hacer algunos cambios en el wp-config. php. Lo mejor es copiar el fichero original de la base de datos y hacer los cambios sobre él. Como es habitual, hemos de cambiar los datos de conexión a la base de datos: DB_NAME, DB_USER y DB_PASSWORD. Como siguiente punto hay que deshacer toda la configuración del WordPress MultiSite. Todo el código, que debe ser similar a este: define( 'WP_ALLOW_MULTISITE', true ); define('MULTISITE', true); define('SUBDOMAIN_INSTALL', false); define('DOMAIN_CURRENT_SITE', 'example. com'); define('PATH_CURRENT_SITE', '/'); define('SITE_ID_CURRENT_SITE', 1); define('BLOG_ID_CURRENT_SITE', 1); Esto lo debemos sustituir por define( 'WP_ALLOW_MULTISITE', false ); Además, para corregir posibles enlaces internos que no sean correctos, estableceremos las direcciones por efecto, añadiendo al WP-Config la URL de nuestro nuevo sitio: define( 'WP_SITEURL', 'https://www. example. com' ); define( 'WP_HOME', 'https://www. example. com' ); También deberemos recuperar la configuración inicial simple del . htaccess (o la configuración del nginx). Por defecto encontraremos algo del estilo a: # BEGIN WordPress RewriteEngine On RewriteBase / RewriteRule ^index\. php$ - # add a trailing slash to /wp-admin RewriteRule ^(+/)? wp-admin$ $1wp-admin/ RewriteCond %{REQUEST_FILENAME} -f RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^ - RewriteRule ^(+/)? (wp-(content|admin|includes). *) $2 RewriteRule ^(+/)? (. *\. php)$ $2 RewriteRule . index. php # END WordPress Y lo sustituiremos por el código inicial: # BEGIN WordPress RewriteEngine On RewriteBase / RewriteRule ^index\. php$ - RewriteCond %{REQUEST_FILENAME} ! -f RewriteCond %{REQUEST_FILENAME} ! -d RewriteRule . /index. php # END WordPress Accediendo En este momento, si todo ha ido bien, el sitio debería funciona correctamente para acceder al panel. Aunque quedan un par de configuraciones. Sustitución de los media Antes de acabar deberemos sustituir las direcciones URL de las imágenes y Media en general por las nuevas direcciones. Para ello podemos usar el sistema de sustitución de WP-CLI, o podemos instalar un plugin de sustitución. La sustitución debe ser de: /uploads/sites/2/ Donde el número 2 será el del ID del sitio original. Lo sustituiremos simplemente por: /uploads/ De la misma forma deberemos hacer la sustitución de todo el sitio. Por ejemplo, sustituyendo la dirección antigua: //old. example. com/es/ Por la nueva dirección. //www. example. com/ Enlaces permanentes Como último paso, iremos a la Configuración de Enlaces Permanentes y pulsaremos en Guardar. Y con esto acabaríamos la migración de un sitio MultiSitio a un sitio Sencillo. --- Desde hace un tiempo que teneos entre nosotros el nuevo formato de imagen AVIF. Entre otros, Netflix ya ha decidido comenzar a hacer pruebas entre sus sistemas. Desde hace un tiempo que teneos entre nosotros el nuevo formato de imagen AVIF. Entre otros, Netflix ya ha decidido comenzar a hacer pruebas entre sus sistemas. El código para usarlo, con posibilidad de alternativas en caso de que el navegador no le de soporte... Imagen en AVIF Comparativa entre distintos formatos PNG (original) JPEG WebP AVIF ¿Puedo usarlo en mi navegador? Para validar la información, puedes visitar Can I use? . En principio a partir de Chrome 85 y Opera 71 ya viene activado por defecto, y en desde Firefox 77 se puede activar cambiando a "true" el valor image. avif. enabled desde el about:config. Más información AVIF: A New Image FormatAVIF - the next-gen image format you need to know aboutAVIF browser test page: AVIF support in Chrome, Firefox, Edge... --- WordPress 5.6 va a dar soporte desde la versión de PHP 5.6 hasta PHP 8.0 y en este artículo se presenta un pequeño resumen de pruebas de carga y rendimiento de cómo funciona con cara una de las versiones disponibles. Hace unos días que ha salido PHP 8. 0 a la luz cumpliendo así 25 años de este lenguaje de programación y en unos días también verá la luz WordPress 5. 6, la próxima versión de WordPress y última de este 2020. La idea inicial en el roadmap es que WordPress 5. 6 dejase de dar soporte a PHP 5. 6 y que diera soporte a PHP 8. 0, pero Matt tomó la decisión de que aún era pronto para dejar de dar soporte a esa versión ya obsoleta. Así que ahora mismo WordPress 5. 6 va a dar soporte a las siguientes versiones de PHP: PHP 5. 6. 20+PHP 7. 0PHP 7. 1PHP 7. 2PHP 7. 3PHP 7. 4PHP 8. 0 Es muy probable que de todos los CMS que hay en el mercado ahora mismo WordPress sea el que más amplitud de uso tiene sobre PHP. Aunque tampoco hay que olvidar que WordPress, ahora mismo, tanto para WordPress 5. 5 como WordPress 5. 6 recomienda el uso de PHP 7. 4. Con respecto al soporte de PHP 8 y WordPress 5. 6 hace unos días se lanzó el comunicado de qué y cómo WordPress va a dar soporte a esta versión, que básicamente se ha centrado en la corrección de posibles incompatibilidades, pero no la reescritura del código para dar soporte a nuevas funcionalidades. La pregunta del millón es ¿funciona mejor WordPress con PHP 8. 0? Y, en este estudio poco científico que he hecho he intentado hacer la misma prueba con un WordPress en el que le he aplicado los contenidos del "test visual" (para que la página principal tuviera bastantes contenidos) y que ocupase bastante (tanto como 80KB de página principal). Así sería una página con algo de contenido y que se parezca más a lo que una página puede contener. La máquina se ha montado siguiendo el siguiente tutorial de instalación con los ajustes correspondientes para las pruebas de caché. El experimento está hecho primero con un VPS con Ubuntu 20, con las últimas versiones de cada versión de PHP disponibles, en 4 entornos: Config 1: 0,5 CPU, 1 GB de RAM, sin cachéConfig 2: 2 CPU, 4 GB de RAM, sin cachéConfig 3: 2 CPU, 4 GB de RAM, con caché Redis + OpcachéConfig 4: 2 CPU, 4 GB de RAM, con caché Redis + Opcaché (con plugins)WP OPcacheRedis Object CacheConfig 5: 2 CPU, 4 GB de RAM, con caché Redis + Opcaché (con plugins) + caché de páginaWP OPcacheRedis Object CacheWP Super Cache La configuración del JIT de PHP 8. 0 se ha hecho con: opcache. jit_buffer_size = 128M opcache. jit = tracing Todos los resultados se han obtenido con la herramienta de ApacheBench y el siguiente comando: ab -n 1000 -c 10 https://example. com/ Time taken for tests Esta cifra no tiene valor de por sí, pero sí que nos da una idea general de si tarda más o menos en hacer la misma prueba en cada una de las configuraciones y versiones... Cuanto menor es el valor, mejor. MáquinaPHP 5. 6PHP 7. 0PHP 7. 1PHP 7. 2PHP 7. 3PHP 7. 4PHP 8. 0PHP 8. 0 JITConfig 1447. 389280. 844328. 814320. 941340. 995286. 553206. 136Config 2168. 853109. 090133. 471131. 392122. 386112. 08177. 171Config 3170. 710109. 046132. 616126. 551116. 518112. 94678. 29874. 392Config 4110. 727Config 51. 302Los datos son en segundos (con 3 decimales) Requests per second En principio esta es la tabla con los datos más importantes, ya que son las peticiones por segundo que se pueden realizar. Cuanto mayor es el valor, mejor. MáquinaPHP 5. 6PHP 7. 0PHP 7. 1PHP 7. 2PHP 7. 3PHP 7. 4PHP 8. 0PHP 8. 0 JITConfig 12. 243. 563. 043. 122. 933. 494. 85Config 25. 929. 177. 497. 618. 178. 9212. 96Config 35. 869. 177. 547. 908. 588. 8512. 7713. 44Config 49. 03Config 5768. 29Los datos son en peticiones por segundo (con 2 decimales) Time per request Los tiempos que se tarda en hacer una petición, de media entre todas las peticiones. Cuanto menor es el valor, mejor. MáquinaPHP 5. 6PHP 7. 0PHP 7. 1PHP 7. 2PHP 7. 3PHP 7. 4PHP 8. 0PHP 8. 0 JITConfig 1447. 389280. 844328. 814320. 941340. 995286. 553206. 136Config 2168. 853109. 090133. 471131. 392122. 386112. 08177. 171Config 3170. 710109. 046132. 616126. 551116. 518112. 94678. 29874. 392Config 4110. 727Config 513. 016Los datos son en milisegundos (con 3 decimales) Minimum Connection Times (ms) Tiempo mínimo de conexión de todas las peticiones realizadas. Cuanto menor es el valor, mejor. MáquinaPHP 5. 6PHP 7. 0PHP 7. 1PHP 7. 2PHP 7. 3PHP 7. 4PHP 8. 0PHP 8. 0 JITConfig 1882617746656711557591Config 2465239271284288238167Config 3474229331259267231158253Config 4232Config 52Los datos son en milisegundos 80% Percentage of the requests served within a certain time (ms) Cuántas peticiones se han servicio en el 80% del tiempo. Cuanto menor es el valor, mejor. MáquinaPHP 5. 6PHP 7. 0PHP 7. 1PHP 7. 2PHP 7. 3PHP 7. 4PHP 8. 0PHP 8. 0 JITConfig 14551288033523288346329252113Config 2173411241373135812671156795Config 3175511271368130311981164812767Config 41156Config 519Los datos son en milisegundos Como decía al principio, no son datos científicos porque lo he probado en un entorno bastante simple, pero puede dar una pequeña idea de las mejoras que suponen cada una de las versiones. Conclusiones PHP 8. 0 funciona un 50% mejor que PHP 5. 6, sin ningún lugar a dudasPHP 8. 0 con y sin JIT, en WordPress, casi es inapreciable. Cuando WordPress se satura y PHP también, debido a que la máquina no da más de sí (lo que se podría considerar un "mal hosting"), se puede perder un 60% del rendimiento. Invertir en hosting es una buena idea. Tunear las configuraciones de base de datos, caché y otros servicios pueden aumentar el rendimiento lo suficiente como para ser sensible al rendimiento. Configurar correctamente los plugins de caché de página pueden aumentar la velocidad hasta un 90%. --- Uno de los hackeos más habituales en WordPress que no se han mantenido correctamente es el de las redirecciones hacia otros sitios. Uno de los hackeos más habituales en WordPress que no se han mantenido correctamente es el de las redirecciones hacia otros sitios. Hace unos días me llegó un WordPress 3. 4. x (actualmente tenemos las versiones 5. 3. x) que, obviamente, estaba desactualizado por completo, tanto el núcleo como plugins. El theme era hecho a medida. Además tenía PHP 5. 6. x. ¿Cómo corregir esta problemática? Para empezar, he de decir que esta corrección que propongo es muy radical, por lo que es posible que el sitio deje de funcionar y haya que hacer cambios importantes, pero el objetivo es que todo acabe puesto al día. Otra cosa importante es que se debe tener una copia de seguridad del sitio por completo y de la base de datos. Para acabar, será necesario tener acceso SSH al servidor donde está el sitio y disponer de WP-CLI para facilitar las tareas. Se puede hacer de forma más manual, pero con WP-CLI se facilita todo el proceso. Los pasos Lo primero a hacer es actualizar todo. A lo bestia, sí. Para ello actualizaremos el core, plugins, themes y translations. Para empezar, ejecutaremos varios comandos. Actualizaremos e propio WP-CLI, y luego el núcleo y el resto de elementos. wp cli update wp core update --force wp core update-db wp plugin update --all wp theme update --all wp language core update wp language plugin update --all wp language theme update --all Con esto tendremos todo al día y muchas probabilidades de que algo no funcione. Lo siguiente que intentaremos hacer es entrar en el WP-Admin desde la dirección como esta: https://example. com/wp-admin/ Si al entrar tenemos problemas de redirección, haremos un primer repaso del fichero WP-Config. Mi recomendación es aplicar una versión un poco agresiva basada en el fichero que genera por defecto WP-Config. Sobre todo es importante configurar el Site URL y Core files URL con la URL correcta para evitar esas redirecciones. Con esto deberíamos poder acceder al propio panel de gestión de WordPress, aunque seguramente si entramos en la página principal seguiremos teniendo las redirecciones. Lo siguiente que podemos hacer es investigar qué tipo de redirección tenemos. Aún así, si vamos al modo rápido, es muy probable que lo que se haya hecho es una redirección vía JavaScript. Por defecto, en las entradas de un sitio con WordPress, no deberían existir códigos con por lo que nos focalizaremos en que estos no se carguen. Para ello, lo que haremos será sustituir los scripts por algo que nos e pueda ejecutar. ¿Cómo? Pues sustituyendo --- Una de las mejores formas de bloquear tráfico indeseado de máquinas y robots o de elementos maliciosos es directamente desde el servidor web. Una de las mejores formas de bloquear tráfico indeseado de máquinas y robots o de elementos maliciosos es directamente desde el servidor web. Por eso, si usas Apache HTTPD o algún otro servidor web que soporte . htaccess, seguro que este sistema te va a interesar. La gente de myip. ms ha lanzado script que puede ayudarte a ampliar tu . htaccess con su lista de IP que tiene en blacklist. Básicamente el software es el siguiente: --- WordPress tiene muchas opciones en cuanto a capas de caché. Caché de navegador, de página, de compilador, de objetos, de fragmentos, transitoria, de base de datos o de disco. WordPress es el gestor de contenidos más utilizado hoy en día y una de esas razones es la de utilizar tecnología al alcance de todo el mundo, principalmente PHP y MySQL o cualquiera de sus derivados). Pero esto hace que el software sea dinámico de serie desde el servidor. Pero partiendo de la dinámica del PHP; también podemos plantear una serie de capas de caché que vienen de serie dentro del propio WordPress, que se pueden extender con plugins o sobrepasar con sistemas. WordPress tiene muchas opciones en cuanto a capas de caché. Caché de navegador, de página, de compilador, de objetos, de fragmentos, transitoria, de base de datos o de disco. La cuestión es ¿cuáles de esas debes activar? Hay que tener presente que depende de cada proyecto se pueden activar o configurar las caché de una forma más o menos agresiva, así que antes de comenzar lo primero que has de hacer es probar las distintas caché y verificar que funcionan correctamente según tus necesidades. Al fin y al cabo la caché se resume en un verbo: reutilizar. Una de las primeras capas de caché a configurar es la caché de navegador. Básicamente lo que vamos a hacer es configurar el servidor web para los elementos más repetitivos y que no suelen cambiar en una misma sesión se lean una vez quedando alojados en el navegador del usuario en su dispositivo y posteriormente, según el usuario va navegando por la web sólo tenga que cargar las partes que cambian pero no las estáticas. Habitualmente se suelen cachear elementos como los CSS, JS, TXT, imágenes, vídeos... vamos, todo aquello que no suele variar con muca frecuencia. Lo que normalmente no se cachea es el HTML, al menos no aquí. Con esto conseguiremos que el usuario tenga que hacer menos llamadas al servidor, reduciendo el consumo de ancho de banda (los GB del móvil). Una capa similar es la llamada CDN (Content Delivery Network) que es una capa de caché entre el navegador del usuario y el servidor. La idea principal es doble: por un lado hacer que algunos elementos estáticos como los CSS, JS, imágenes y demás se sirvan desde un lugar más cercano al usuario según su conexión a Internet, y por otro que el servidor principal no tenga que procesar peticiones menos útiles. En estos casos los datos se almacenan de forma distribuida y si cambias algo en local deberás invalidar el contenido del sitio remoto. Hasta ahora he comentado los elementos más estáticos, pero también se pueden cachear algunos elementos dinámicos. En este caso hablo de la caché de página, que puede hacerse de distintas maneras. La clave es que los sitios web no se actualizan con muchísima frecuencia por norma general, y aunque se hagan con muchísima frecuencia podríamos hablar de que 1 minuto es mucho tiempo (el sitio web de un diario digital, por ejemplo). SI tienes mucho tráfico, un minuto es mucho tiempo y muchas visitas. La idea es que mientras el sitio no cambie, se sirva una versión ya generada de la página en sí. WordPress lleva una serie de hooks de forma que en el momento en el que se producen algunas acciones como por ejemplo publicar o modificar un contenido o se añaden comentarios, de forma que en el momento en el que un editor hace cambios sobre el contenido se puede configurar el sistema para que la próxima visita regenere esa página, y los usuarios que vengan detrás ya verán la información actualizada. La caché de página puede realizarse principalmente en dos niveles de sistemas. Uno de ellos sería el de montar una capa de proxy-caché. La idea es que un servicio externo a WordPress se haga cargo de esta caché. Normalmente suele ser un software que hace de punto intermedio entre el usuario y el servidor web y que almacena una copia de la página. El sistema, mediante unas reglas, decide si tiene el contenido y por tanto lo sirve, o si no lo tiene (o ha de renovarlo) y lo pide a WordPress para que lo genere y se almacene una copia por el tiempo establecido. La otra opción está en que sea el propio WordPress mediante PHP el que gestione esa capa de caché; este caso suele ser el más conocido y que se gestiona con los típicos plugins de caché. Otra capa es la que nos encontramos en el código fuente de PHP. Al fin y al cabo ¿cada cuánto cambia el código PHP de WordPress? Aunque hagamos una actualización al día de todos los plugins, traducciones, themes o el propio núcleo de WordPress ¿cuántas ejecuciones hay de ese código que no cambia? Pues ahí tenemos otra capa de caché, y en el caso de PHP se puede hacer con el sistema de Opcode caché. La idea es que una vez se ejecuta el código una vez, todas las siguientes ejecuciones de PHP que se hagan igual y que van a ejecutar lo mismo estén mínimamente calculadas, de forma que la ejecución sea más rápida. Las siguiente capas de caché afectan principalmente a los objetos. La definición de caché de objeto es poco clara pero uno de los mayores ejemplos puede ser el de cachear las consultas realizadas a la base de datos. AL fin y al cabo, cuando haces una consulta SQL, a menos que un contenido haya variado, la información suele ser siempre la misma. Es por esto que los resultados de esas consultas se pueden almacenar más o menos tiempo (suele ser poco). De esta forma puedes optimizar, por ejemplo, los recursos de la base de datos para que no se sature en momentos de picos de tráfico. En este bloque también podemos incluir la caché de los Transient. Este sistema básicamente permite cambiar el lugar de almacenamiento de la información dejando de estar en la base de datos MySQL a pasar a un lugar de caché que, en principio, será mucho más óptima en cuanto al almacenamiento, acceso de lectura y... --- Cuando tu WordPress consigue tener mucho tráfico o tienes instalado un WooCommerce y necesitas que siempre esté funcionando es muy probable que necesites montar un sistema de Alta Disponibilidad. Cuando tu WordPress consigue tener mucho tráfico o tienes instalado un WooCommerce y necesitas que siempre esté funcionando para evitar problemas con tu hosting es muy probable que necesites montar tu WordPress en un sistema de Alta Disponibilidad (o High Availability). En su día ya expliqué los distintos tipos de Hosting para WordPress que se pueden llegar a conseguir y partiendo de esa ase se pueden construir sistemas de Alta Disponibilidad. Esto significa que tienes tu sitio web en distintos servidores distribuidos en varias partes del planeta (normalmente en 2-3 localizaciones) y que todos ellos son capaces de responder de la misma manera a todas las peticiones. Para esto necesitamos bastantes elementos previos a montar el propio WordPress en sí, que se centran en la infraestructura y su configuración. Lo que voy a explicar es una de tantas opciones posibles, pero es simplemente una idea de lo que se puede montar y cómo. Para comenzar necesitamos al menos un sistema centralizado de control. En este caso usaremos algún sistema tipo Rancher con el que poder gestionar la infraestructura y sus contenedores. Desde este sistema podremos crear y escalar la infraestructura, sus contenidos y parte de la gestión en los momentos críticos. Por otro lado necesitaremos varios VPS distribuidos en varias localizaciones. Por poner un ejemplo podríamos montar un VPS en Barcelona y otro VPS en Madrid, de forma que tendríamos un sistema de Alta Disponibilidad focalizado a España. Se puede montar a nivel internacional, los límites están en donde quieras ponerlos. En principio se puede montar un VPS con cualquier tipo de recursos, aunque teniendo en cuenta lo que se va a montar es muy recomendable que, por ejemplo para una web sencilla tengamos una máquina de 1 CPU, 2 GB de RAM y 20 GB en SSD, o si tenemos un proyecto ya un poco más avanzado al menos 2 CPU, 4 GB de RAM y 40 GB de SDD. De nuevo, los recursos dependen del proyecto (o los proyectos) que se vayan a incluir. Al fin y al cabo la infraestructura hoy en día es bastante barata. Incluso, se puede plantear que una infraestructura principal tenga una serie de recursos y el resto tenga otra. ¿Qué tendrá cada uno de estos VPS? Pues en principio 4 contenedores que se pueden montar, por ejemplo, con Docker. Uno de ellos tendría la base de datos con MariaDB (o MySQL o Percona). Otro de ellos podría tener ProxySQL para la gestión de las consultas. Un tercer elemento sería un Redis para la caché. Para acabar tendríamos lo que sería el servidor web, con un nginx y PHP. Esta es la base, se podrían montar otros sistemas. Otro elemento a tener presente es dónde se almacenan los datos. En este caso las bases de datos almacenarán la información en local, de forma que MariaDB y Redis alojarán los datos en los discos locales de cada VPS. En cambio para los datos del servidor web (o de las webs en sí) podremos aprovechar en montar un sistema distribuido con GlusterFS, que nos permita, por ejemplo, que cuando se suba una imagen al WordPress automáticamente esté disponible en todas las localizaciones. Para los datos del MariaDB plantearemos un sistema master-slave. Depende de la infraestructura y su conectividad se puede montar también un sistema master-master, todo dependerá de la potencia de la infraestructura y del proyecto. Para la gestión plantearemos que el ProxySQL permita ejecutar las consultas SELECT (el 90%-95% habitualmente en WordPress) en cualquiera de las máquinas, y los INSERT o UPDATE en sólo la base de datos principal. Esta parte es bastante variable aunque este sistema es simple y funcional. La caché de objetos en Redis funcionaría en modo local. Se podría montar también en modo cluster, aunque las ventajas de hacerlo tendrían que analizarse, ya que dependería del sistema de distribución del tráfico que se haga. Para la distribución del tráfico podemos plantear las funcionalidades avanzadas de Route53 a nivel de DNS gracias a las cuales el sistema decidiría a qué infraestructura distribuir el tráfico, e incluso detectar si uno de los nodos está sin funcionar y poder desviar el tráfico automáticamente. Otro elemento a tener en cuenta es el de las tareas programadas (crones). Para evitar que se ejecuten en todas las máquinas y se puedan duplicar tareas, desde un nivel superior el sistema decidirá en qué infraestructura ejecutarlos. Lo ideal es que se ejecuten en la máquina principal donde se trabaja con los INSERT en la base de datos para reducir la latencia. Con este sistema conseguiremos que toda la infraestructura sea capaz de responder en todo momento y que en a penas un par de minutos y sólo en caso de que alguno de los nodos falle, el sistema se gestione automáticamente para resolver las incidencias, mantener el servicio y que posteriormente se pueda recuperar por el equipo responsable del mismo, teniendo en cuenta que el sistema está en modo incidencia. En el tiempo que llevamos haciendo pruebas diversas con este sistema la verdad es que la escalabilidad es muy correcta y en los casos en los que ha habido algún tipo de corte en alguno de los centros de datos se ha distribuido el sistema de forma automática en el resto de sistemas, pudiendo recuperar la localización posteriormente gracias a la distribución de los otros puntos. --- En general damos por hecho que PHP viene bien montado en nuestro alojamiento para WordPress y no suele ser así. WordPress necesita 3 elementos para funcionar: un servidor web, una base de datos y el motor que hace que todo funcione, PHP. Y en general damos por hecho que PHP viene bien montado en nuestro alojamiento, y no suele ser así. En la documentación oficial de WordPress sobre hosting se hablan de los requerimientos de PHP. En general estoy de acuerdo pero creo que son bastante restrictivos y que sólo miran en lo que es WordPress en sí mismo, pero no en las ventajas que puede tener incluir unas extensiones extra de PHP al funcionamiento habitual. También es verdad que algunas de las extensiones son complementarias entre sí, por ejemplo la de GD e ImageMagick. Si tienes una de las dos es suficiente, pero es posible que algún plugin utilice la otra por no estar desarrollado el sistema mejorado. Es por esto que me he planteado hacer un poco de investigación sobre WordPress 5. 2. 3 y algunos de los plugin más conocidos y extendidos. ¿Qué he hecho? Lo primero ha sido montar una máquina VPS en la que he montado PHP 7. 4beta4. En realidad no hace falta y sé que esta versión aún no lo soporta, pero es compatible con lo actual. Lo otro que he hecho ha sido meter en una carpeta la versión de WordPress, y configurar PHP CompatInfo, una herramienta que permite analizar el código PHP. Esto no me dirá exactamente qué funciones son alternativas, pero un mínimo conocimiento de WordPress ya te deja intuir por dónde van los tiros. El primer análisis devuelve la siguiente información: ComponentExtensionPHPCore7. 0. 27. 0. 2PDO5. 1. 05. 1. 0Reflection5. 0. 05. 0. 0SimpleXML5. 0. 15. 0. 1Zend OPcache7. 0. 25. 2. 0com_dotnet4. 0. 0ctype4. 0. 44. 0. 4curl5. 0. 05. 0. 0date5. 2. 05. 2. 0dom5. 0. 05. 0. 0exif4. 3. 04. 3. 0fileinfo1. 0. 5-dev5. 3. 0filter0. 11. 05. 0. 0ftp4. 0. 05. 0. 0gd4. 3. 24. 3. 2gettext4. 0. 04. 0. 0hash5. 6. 0beta15. 6. 0beta1iconv5. 0. 05. 0. 0imagick3. 4. 05. 4. 0imap4. 0. 04. 0. 0intl2. 0. 0b15. 4. 0RC3json5. 5. 05. 5. 0libsodium4. 0. 0libxml5. 2. 115. 2. 11mbstring5. 0. 05. 2. 0mcrypt4. 0. 04. 0. 0memcache0. 24. 3. 3mysql5. 2. 35. 2. 3mysqli5. 0. 05. 0. 0mysqlnd4. 0. 0opcache4. 0. 0openssl5. 4. 07. 1. 0alpha2pcre5. 2. 45. 2. 4posix4. 0. 04. 0. 0sockets4. 3. 04. 3. 0sodium4. 0. 0spl5. 3. 05. 3. 0ssh20. 54. 0. 0standard7. 0. 27. 0. 2 (5. 6. 33)suhosin4. 0. 0tokenizer4. 2. 04. 2. 0xdiff4. 0. 0xml4. 0. 54. 0. 5xmlreader5. 0. 05. 0. 0zip1. 6. 05. 2. 0zlib5. 4. 05. 4. 0 Esta fantástica tabla / lista de extensiones es la base sobre la que trabajar con WordPress. Y esta lista y las funciones que se usan vienen a decir que la versión óptima a utilizar es la de PHP 7. 0. 2, pero que se podría funcionar normalmente con PHP 5. 6. 33 (perdiendo algo de funcionalidad y sobre todo seguridad). Hay que recordar que desde 2019 cualquier versión de PHP menor a la rama 7. 1 no está mantenida y puede ser insegura, por lo que, en este punto, lo ideal sería usar, al menos, PHP 7. 1. Instalando PHP En este ejemplo voy a usar Ubuntu 18 como base, con el repositorio de ppa:ondrej/php. Y para empezar simplemente voy a instalar PHP y PHP-FPM (esto último no afecta a las extensiones, simplemente a cómo tengo configurado el nginx). Para ello lanzo lo siguiente: add-apt-repository ppa:ondrej/php apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install php7. 4 php7. 4-fpm Una vez tenemos esto montado, vamos a ver qué extensiones lleva PHP por defecto instaladas y son compatibles con WordPress y cuáles tendrían que montarse de forma extendida. Para ello usamos el tradicional phpinfo. Con el propio PHP vienen, pues, estas extensiones: Core, PDO, Reflection, Zend OPcache, ctype, date, exif, fileinfo, filter, ftp, gettext, hash, iconv, json, libsodium, libxml, opcache, openssl, pcre, posix, sockets, sodium, spl, standard, tokenizer y zlib. Ahora queda qué hacer con las que tenemos pendientes... Extensiones fáciles Hay algunas extensiones que son bastante fáciles de conseguir. Si ejecutamos este comando también tendremos las siguientes de la lista... apt -y install php7. 4-curl php7. 4-gd php7. 4-mbstring php7. 4-xml php7. 4-zip Esto nos ayuda con SimpleXML, curl, dom, gd, imap, intl, mbstring, xml, xmlreader y zip. La base de datos Otras extensiones importantes son las de la conexión a la base de datos, en este caso compatibles con los sistemas de conexión de MySQL (ya sean MySQL, MariaDB o similares). Existen y han existido varias versiones para las conexiones, y aunque se hable de tres de ellas, en realidad se necesitan simplemente dos. apt -y install php7. 4-mysql php7. 4-mysqlnd Con esto damos soporte a mysqli y mysqlnd, suficiente para que el sistema funcione. Las que quedan La lista de las que quedan es com_dotnet, imagick, mcrypt, memcache, ssh2, suhosin y xdiff. La de com_dotnet es básicamente si montas tu sitio sobre Windows, por lo que en un principio no haría falta instalarla. Las extensiones mcrypt tampoco son necesarias en versiones modernas (PHP +7. 2) ya que estas funciones vienen a ser sustituidas por las sodium (ya instaladas). La extensión ssh2 tampoco es necesaria a menos que para actualizar el sistema requieras conexiones no habituales. Por norma general no son necesarias. Si te fallase el sistema de actualizaciones de WordPress o necesitas el uso de claves privadas/públicas, pues adelante. Y suhosin hace años que está un poco en desuso. Aunque se plantea recuperar parte de ello, en principio tampoco serían necesarias. Antes de continuar vamos a preparar PHP para que permita instalar y ejecutar compilaciones de extensiones extra. Para instalar algunas cosas extra necesitaremos montar PHP para que pueda compilar, lo que significa que necesitamos que PHP tenga permisos de desarrollador... y de paso instalamos el sistema PECL, que permite añadir extensiones extra a PHP. apt -y install php7. 4-dev php-pear pkg-config pecl channel-update... --- Cuando hablamos de una CDN, hablamos de una red de entrega de contenidos, principalmente estáticos. Esto significa que vamos a servir contenidos que no cambian. Cuando hablamos de una CDN, hablamos de una red de entrega de contenidos, principalmente estáticos. Esto significa que vamos a servir contenidos que no cambian, como imágenes, vídeos y otros elementos de este estilo. Cuando hablamos de WordPress vendría a ser, principalmente, la sección de Medios. Seguramente cuando alguien te dice que montes una CDN en tu WordPress te dice que montes todo con Cloudflare y te olvides, pero, personalmente no creo que siempre sea la mejor opción por varias razones, la principal es un tema de rendimiento en "lo que no es estático". Para empezar, explicar un poco cómo funciona un sistema de CDN. La idea es poner una capa intermedia entre el usuario y el servidor. Por ejemplo este sitio está físicamente alojado en Barcelona (España). Es posible que alguien desde Argentina lo visite, y si quiere leer la información ha de hacer una petición desde Buenos Aires hasta Barcelona, probablemente pasando por Miami, Nueva York, Londres, París... y volver. Con un CDN esa petición no tendría que dar tantos saltos porque, por ejemplo, es posible que haya una copia en Miami y que ese usuario reciba la información desde allí. Genial, ¿verdad? Sí, pero no. En el caso de un comercio electrónico o de contenidos dinámicos la cosa se complica, ya que no todo se puede cachear, lo que significa que entre todos estos pasos tenemos también que pasar por el CDN para contenidos que realmente no se pueden cachear. Esto puede provocar que se cacheen elementos que no toca a menos que pongamos las reglas muy claras. Voy a poner otro caso más en pequeño y basado en algunas pruebas que hice hace un tiempo. Tienes un sitio en España y que el 95% del tráfico es de España. En España hay varias operadoras, muchas globales, otras locales. En cualquier caso es posible que te interese tener un CDN como Cloudflare que tiene dos puntos, uno en Madrid (Interxion) y otro en Barcelona (Equinix). Esto hace que esté conectado a Espanix y a Catnix. Con esto tenemos conectividad prácticamente con todas las operadoras del país. Teniendo esto en cuenta (y hablamos ya de milisegundos) cuando hacemos una petición a un estático es muy probable que uno de los dos puntos de Cloudflare sea el más cercano a servir el contenido, pero en el caso de una página generada dinámicamente tu trayecto va a ser desde el Dispositivo hasta Cloudflare, y Cloudflare tendrá que aplicar las reglas, ver que no la cumple, por lo que Cloudflare tendrá que llamar a tu sitio web, generar la respuesta, devolverla, Cloudflare la procesará y se la servirá al usuario. ¿Necesario? No porque el 100% de los contenidos dinámicos van a tener esta problemática. Sí, ya sé que hay otras ventajas e inconvenientes, pero quiero centrarme en lo propio de un CDN. Teniendo esto en cuenta ¿cómo hacer que sólo se cacheen los contenidos estáticos en una CDN con WordPress? Para comenzar, por defecto los Medios que se suben a WordPress se alojan en la carpeta /wp-content/uploads/, bajo el mismo dominio. Esto hace que no se pueda cachear concretamente sóloe sta parte... pero hay un truco, algo que hace años WordPress mostraba por defecto y que ahora está oculto. Configurar DNS El primer paso será el de crear un subdominio (u otro dominio) que va a ser el que vamos a cachear y que será el CDN realmente. Para ello iremos a nuestro listado de entradas DNS y crearemos una entrada de este estilo: estaticos. example. com A 123. 456. 789. 123 Se puede hacer con una entrada A, con un CNAME, con un DNAME... consulta con tu proveedor de alojamiento para que te digan la mejor forma de hacerlo. Lo siguiente que hay que es configurar dónde apunta ese subdominio. La idea es que no apunte a la carpeta raíz de WordPress o a una nueva carpeta, sino a /wp-content/uploads/. Igual que antes, consulta con tu proveedor para optimizar este punto. El objetivo es que cuando se llame a https://estaticos. example. com/imagen. jpg en realidad se llamará a la que hay en la ruta https://www. example. com/wp-content/uploads/imagen. jpg. Ambas rutas deberían funcionar correctamente a que ambos hostname apuntan a los mismos sitios. Configurar WordPress Lo importante de este sistema es que intentemos tocar lo menos posible WordPress. Si algún día queremos deshacer este sistema de CDN se podrá hacer fácilmente ejecutando un comando. Esto significa que físicamente los ficheros se van a seguir subiendo y gestionando en el mismo lugar donde WordPress los guarda habitualmente. Lo que si que vamos a hacer es un cambio en la configuración de WordPress. Estas opciones venían anteriormente en la sección de Configuración, pero dejaron de aparecer hace un tiempo. Aún no estando visibles, siguen estando en el núcleo de WordPress y es muy útil su uso. Para acceder a todo el listado de opciones visitaremos desde el Panel de Administración una dirección tal que https://www. example. com/wp-admin/options. php. Esta dirección no está accesible desde el menú de navegación, y básicamente muestra una lista de todos los elementos de la tabla de opciones. Una vez allí, buscaremos la opción upload_url_path que en principio debería estar vacía. Lo que haremos será actualizarla por https://estaticos. example. com guardando la información con el botón al final de la página. A partir de este momento WordPress gestionará los medios con la dirección nueva. Actualizar las rutas anteriores Antes de continuar lo que haremos es actualizar todas las direcciones de imágenes u otros contenidos que tengamos en todo el sitio. Para este caso voy a utilizar WP-CLI que es la opción más rápida y sencilla, aunque se puede usar algún otro plugin de reemplazar contenidos. Podemos hacer primero una prueba en la que se nos informe de los cambios que se van a aplicar. Para ello ejecutaremos el comando: wp search-replace 'https://www. example. com/wp-content/uploads/' 'https://estaticos. example. com/' --dry-run Si vemos que el cambio es correcto, ejecutaremos la consulta por completo y aplicando los cambios en la base de datos.... --- Cuando comienzas un proyecto en Internet una de las primeras preguntas que te haces es el hosting para tu sitio web. Y esto es más complejo de lo que parece. Cuando comienzas un proyecto en Internet una de las primeras preguntas que te haces es el hosting para tu sitio web. En realidad deberíamos hacernos más preguntas, sobre todo si planteamos hasta dónde queremos llegar con nuestro proyecto. Estas primeras decisiones van a ser cruciales para que el resto del proyecto funcione bien. Algunas cuestiones que hemos de plantear es si nuestro sitio simplemente va a tener información, si va a tener transacciones (comerciales, por ejemplo), si va a ser multi-país o multi-idioma, si nuestros usuarios serán principalmente locales (país) o internacionales. Cada una de esas preguntas requiere de una serie de opciones, y todas las opciones te han de dar una respuesta de qué necesitas. Premisas NOTA: Este artículo está actualizado a fecha de agosto de 2019, por lo que se hace referencia a versiones y productos disponibles para esta fecha. Es probable que cuando leas esto haya cosas más actualizadas, así que mantén al día tus sistemas. Una de las frases que más me habrás escuchado decir es que para hacer cosas en Internet hay que saber de Internet. Y partiendo de esta premisa hay que saber una cosa de Internet: cada "cosa" es un servicio distinto. El dominio, las DNS, el correo, la web, la base de datos... cada uno de estos elementos se puede gestionar por separado o en conjunto. Como supongo que quieres tener un proyecto gratificante y que funcione. Si es así y quieres estabilidad, has de invertir algo de dinero. ¿Cuánto? Un buen amigo mío siempre decía que hay que invertir al menos un 3% de la facturación en tecnología (principalmente en infraestructura en el caso de los proyectos de Internet). Y quizá la pregunta principal: ¿sabes o no sabes de sistemas? Doy por hecho de que el 95% de la población no sabe de sistemas, por lo tanto busca algo fácil porque no se quiere complicar. El hosting es como alquilar un local para montar una tienda, o buscar un piso para comprar o alquilar. Es posible que sepas cambiar un enchufe o colgar un cuadro, pero si has de reformar la cocina entera, has de pintar todo o cambiar la fontanería, no lo haces tú. Ahí entran los Administradores de Sistemas. Si vasa montar algo en serio necesitas a alguien en el equipo (o fuera) que se encargue de ello: un panel de control te ayuda, pero no te da soluciones óptimas. Básico No voy a darle muchas vueltas, porque no es de esto en concreto a lo que vengo a hablar. Si no tienes ni idea, el resumen es tenlo todo en un mismo lugar. Es lo peor, pero funcionará. Esto es que el dominio, las DNS, el correo y el hosting esté todo en un mismo lugar. Probablemente ese proveedor te de un hosting compartido con un cPanel desde el que gestionar todo. Con un poco de suerte ese proveedor sólo (y cuando digo sólo es sólo) ofrezca WordPress, de forma que los servicios de PHP, Web y Base de Datos estarán optimizados para WordPress. ¿Alguno que conozca? Ninguno. Todas las empresas de hosting compartido alojan cualquier tipo de proyecto, por lo que aunque se ofrecen alojamientos para WordPress, no suele ser verdad, es un alojamiento en el que puedes poner cualquier cosa. Un poco más en serio Vale, si quieres atreverte a ir un poco más en serio puedes comenzar separando algunos servicios. Comencemos por el principio, el dominio. Para estos casos siempre hay que ir a un registrador oficial. En general no vas a usar ningún servicio añadido, simplemente el de registrar y gestionar el dominio, por lo que lo mejor es algo sencillo y claro. Mi opción principal está en DonDominio. Un dominio te puede costar unos 10-12 euros/año. Para que un dominio funcione lo siguiente que hace falta son las DNS. Para esto hay varias opciones, pero si quieres algo potente has de irte a algo potente. En este caso recomendaría dos opciones, una de ellas inicialmente gratuita y la otra no (pero muy barata). Una opción es Hurricane Electric que tiene su propio servicio de DNS y es muy potente; son una gente que llevan muchos años trabajando con redes o IPv6. Una segunda opción es Amazon Route53 que, aunque es un servicio de pago que suele rondar los 1-5 euros/mes por dominio, tiene algunas características interesantes de cara a su uso futuro (sobre todo si vas a tener sistemas grandes o distribuidos). Para acabar está el tema del correo. En este punto hay que diferenciar los sistemas de envío de los de recepción. Para recibir correo, si vas a hacer algo en modo profesional, es recomendable usar un Google Suite o un Microsoft 365. En estos casos hay que crear cuentas de correo exclusivamente para las personas y nunca cuentas de tipo "info@", "marketing@"... Para este tipo de cuentas a las que tiene que acceder mucha gente necesitas un sistema de tickets, un sistema de atención al cliente. Para ello hay servicios como Zendesk, Freshdesk o similares. Esto significa que más o menos pagarás 5 euros/mes por cuenta de correo, y luego entre 0 y 20 euros/mes por agente para el soporte. Para el envío de correo lo mejor es utilizar un servicio de SMTP profesional. Así no tendrás ningún problema de validación ni de spam, pero tendrás que pagar por cada correo enviado. Algunos servicios te ofrecen un mínimo de correo al mes gratuito. Para estos casos tienes opciones como Elasticemail o Amazon SES. En cualquier caso estos servicios te obligarán a verificar el correo, que es lo que hace que funcione sin problema. Vamos a por la web En WordPress cuando hablamos de la web hablamos de 3 elementos: PHP, Base de Datos y Servidor Web. Estos son los tres elementos que hacen que un WordPress funcione y que hemos de mantener con frecuencia para que no se queden obsoletos. Según evoluciona el software hemos de mantener los servicios. Tal y como evoluciona WordPress lo mejor es mantenerse al día en... --- WordPress incluye desde hace ya unas cuantas versiones una API que, por defecto, viene activa y abierta a todos los usuarios en modo lectura. WordPress incluye desde hace ya unas cuantas versiones una API que, por defecto, viene activa y abierta a todos los usuarios en modo lectura. Aunque en un principio no hay un problema de seguridad explícito en ello, sí que es verdad que a menos que se utilice la API no tiene mucho sentido dejarla abierta ya que se pueden generar una serie de consultas que no tienen ningún sentido en ello. Un ejemplo para verificar de qué se trata es acceder a la página principal de tu sitio WordPress y añadirle a la URL el /wp-json/. Por ejemplo https://example. com/wp-json/. Por defecto verás información de tu sitio en un formato de texto (o si tu navegador le da formato, de forma más o menos comprensible). Para evitar esta fuga de información, puedes activar un plugin como Disable WP REST API, que de forma automática y sencilla sólo dará acceso a los usuarios que hayan accedido como registrados a dicha información, y la cierra a la navegación anónima. --- Por norma general WordPress se suele instalar y hacer funcionar sobre Linux, y en este sistema operativo puede haber instalado y funcionando muchos servicios diferentes. Por norma general WordPress se suele instalar y hacer funcionar sobre Linux, y en este sistema operativo puede haber instalado y funcionando muchos servicios diferentes. Esto, por tanto da pie a pensar en que esa máquina Linux ha de mantenerse segura. Una de las informaciones más habituales es la de mandar la información de qué servidor web utilizamos. Para ello, por ejemplo en Apache HTTPD podemos cambiar algunas configuraciones. ServerTokens Prod ServerSignature Off TraceEnable Off Otro de los lugares habituales de fugas de información es PHP. En este caso en el php. ini podemos hacer algunos cambios para proteger posibles fugas de datos. expose_php = Off display_errors = Off track_errors = Off html_errors = Off Pero no sólo en estos servicios, también en otros como el SSH puede darnos cierta información. Por ejemplo en Debian y Ubuntu podríamos bloquear los datos en el fichero de /etc/ssh/sshd_config. DebianBanner no También puede surgeir en servicios de correo como Postfix, donde se muestra la información y se puede cambiar por otra en el fichero /etc/postfix/main. cf. smtpd_banner = 0 Incluso, se podría revisar también en el servidor de DNS BIND, dentro del fichero de configuración named. conf. options { version "ninguna"; } Existen muchas otras opciones a revisar, pero el foco es revisar que todos los servicios que se instalan en la máquina y que sean accesibles desde el exterior oculten de forma explícita toda información de sus versiones para hacer más difícil un ataque. --- En alguna ocasión seguro que necesitas montar un WordPress muy rápido para desarrollar pero evitando tener que montar todo el sistema por completo. Si este es tu caso, puedes hacerlo fácil y rápido. En alguna ocasión seguro que necesitas montar un WordPress muy rápido para desarrollar pero evitando tener que montar todo el sistema por completo. Si este es tu caso, puedes hacerlo fácil y rápido. Disponemos ya de un manual para montar un WordPress estable sobre Ubuntu 18. Basándonos en esta posibilidad, vamos a ver cómo montar un VPS (o en local) en el que no haya que montar mucho sistema. Lo principal es tener una base de datos montada, y disponer de PHP. Nada más. Partimos de la base de que montamos un VPS barato. En este caso prepararemos todo el proceso desde cero. Una vez esté instalado el sistema operativo, lo primero que configuraremos será la hora del servidor. En este caso configuraremos la zona horaria de Madrid. timedatectl set-timezone 'Europe/Madrid' timedatectl set-ntp on Lo siguiente que haremos es comprobar la versión del sistema operativo y, posteriormente, hacer una actualización completa del mismo. lsb_release -a apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove Una vez esta todo actualizado, instalamos algunas herramientas y software base que puede ser útil tener en el sistema. apt -y install software-properties-common curl vim unzip ufw El siguiente paso será la instalación de la base de datos. En este caso vamos a utilizar MariaDB 10. 3. Lo primero que haremos será configurar la descarga, y posteriormente su instalación. apt-key adv --recv-keys --keyserver hkp://keyserver. ubuntu. com:80 0xF1656F24C74CD1D8 add-apt-repository 'deb http://tedeco. fi. upm. es/mirror/mariadb/repo/10. 3/ubuntu bionic main' apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install mariadb-server mariadb-client Ahora que está instalada, procederemos a la configuración inicial. Para ello usaremos el sistema se instalación segura, que nos hará algunas preguntas. mysql_secure_installation A la pregunta de si queremos cambiar la contraseña, dependiendo de si hemos puesto o no en la instalación, la cambiaremos. En caso de no haber puesto ninguna, es muy recomendable ponerle una contraseña segura. Set root password? : Y Al resto de preguntas, contestaremos lo siguiente: Remove anonymous users? : Y Disallow root login remotely? : Y Remove test database and access to it? : Y Reload privilege tables now? : Y En este momento ya tendremos la base de datos configurada. Ahora haremos que se ejecute en los re inicios del sistema y la iniciaremos. systemctl stop mysql. service systemctl start mysql. service Ahora vamos a instalar y a configurar PHP para que funcione correctamente con la base de datos y para que haga de servidor web. En este caso vamos a instalar la versión PHP 7. 3. Primero haremos la instalación de los paquetes más actualizados (que no son los que vienen con el sistema operativo) y que en caso de necesitarlo, además, nos permitirían tener varias versiones de PHP en paralelo. add-apt-repository ppa:ondrej/php apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove apt -y install php7. 3 php7. 3-fpm php7. 3-common php7. 3-dev php7. 3-cli php7. 3-bcmath php7. 3-curl php7. 3-gd php7. 3-imap php7. 3-json php7. 3-mbstring php7. 3-mysql php7. 3-opcache php7. 3-soap php7. 3-xml php7. 3-xmlrpc php7. 3-zip php-imagick php-libsodium php-ssh2 php-xdebug libgeoip-dev Ahora que tenemos PHP y MariaDB ya podemos comenzar a trabajar puesto que son los dos requisitos indispensables para que WordPress funcione. ¿Cómo es posible? Pues gracias a que PHP desde hace unas cuantas versiones incorpora un servidor web interno, que aunque no es extremadamente estable, lo es suficiente como para mantenerlo en modo desarrollador. Para ello crearemos y entraremos en donde queramos alojar nuestro WordPress. mkdir /home/example. com/ mkdir /home/example. com/public_html/ cd /home/example. com/public_html/ Una vez tengamos la estructura de carpetas creada podemos descargar WordPress y descomprimirlo. wget https://wordpress. org/latest. zip unzip latest. zip cd wordpress/ Ahora que tenemos WordPress descargado y en su carpeta, podemos arrancar el servidor web. El sistema funciona perfectamente poniendo la IP pública, si trabajamos en un VPS y por el puerto HTTP (80) como si trabajamos en local (pon la IP pública o privada de tu máquina: php -S 127. 0. 0. 1:80 Ahora es tan sencillo como entrar en el navegador y acceder a la web con la IP: http://127. 0. 0. 1:80/ Se puede configurar también (si tienes algún servidor web en producción) por ejemplo en otro puerto, cambiando el :80 por :8000 u :8080. --- Uno de los servicios que vemos con mucha frecuencia en todos los sitios con WordPress (y sin) es el de los avatares generados por Gravatar. Este servicio permite asociar un avatar (normalmente una foto que representa a una persona) con una cuenta de correo. Uno de los servicios que vemos con mucha frecuencia en todos los sitios con WordPress (y sin) es el de los avatares generados por Gravatar. Este servicio permite asociar un avatar (normalmente una foto que representa a una persona) con una cuenta de correo. De esta forma, cuando haces un comentario o te registras en un sitio, aparecerá ese avatar asociado a la cuenta de correo que estás usando. Gravatar aloja las imágenes en su propio sitio, lo que hace que se tengan que hacer llamadas a direcciones URL externas, por lo que se han de generar llamadas HTTP, DNS y demás a otros sitios, además de poderse llegar a reducir la privacidad ya que, en este caso, Gravatar siembra cookies por todos los sitios por los que pasas. Teniendo en cuenta estos dos factores, un planteamiento interesante para mejorar el rendimiento de carga del sitio es el de hacer una cache de las imágenes en local, de forma que no se tengan que hacer llamadas externas. Para ello tenemos un par de opciones que funcionan de una manera similar: Optimum Gravatar Cache: Este plugin crea una copia de los avatares y lo hace de forma masiva mediante los crones propios de WordPress, manteniendo al día las imágenes. SI tienes muchos comentarios es una opción interesante. Avatar Privacy: El objetivo es igual que el anterior, aunque en este caso no se hace uso de crones y, además, permite la gestión de la privadidad de los avatares para cada usuario. Una buena opción si estás en Europa y has de cumplir el RGPD. Sin duda dos opciones muy interesantes que mejorarán la carga y rendimiento de tu sitio web. --- Sin duda nginx es uno de los mejores servidores web existentes hoy en día, pero su configuración ha de hacerse mediante un fichero de configuración que, por norma general, no se puede modificar al vuelo. Sin duda nginx es uno de los mejores servidores web existentes hoy en día, pero su configuración ha de hacerse mediante un fichero de configuración que, por norma general, no se puede modificar al vuelo. Esto significa que cuando se instala un plugin de cache los cambios no se pueden aplicar como en Apache HTTPD u otros mediante el fichero . htaccess, de forma que el plugin no puede hacer los cambios correspondientes para aprovechar la cache. Al activar el plugin comenzará a almacenar los ficheros en las carpetas correspondientes, por lo que tenemos que hacer que nginx llame a esa cache previo a ejecutar los comandos normales. Existe un plugin muy simple de cache llamado Simple Cache. Este plugin gestiona la cache y sus cambios y crea una estructura de URL directamente sobre el sistema de ficheros. De esta forma la cache se encuentra en una dirección similar a esta: /wp-content/cache/simple-cache/example. com/hello-world/index. html En este caso, se utiliza la carpeta habitual de cache de WordPress, seguido del nombre del plugin y, a continuación, la estructura de la URL. nginx por defecto ejecuta la siguiente llamada: location / { try_files $uri $uri/ /index. php? $args; } Esto significa que analiza las URL, verifica si el fichero existe realmente (y si existe lo devuelve) y, en caso contrario, siempre acaba llamado al index. php. Este funcionamiento es el mismo que hace el código que por defecto se añade al . htaccess. Para hacer que se intente probar la llamada a la cache primero para ver si ya existe, disponemos de una fórmula sencilla, sumando estos dos elementos previos: location / { try_files "/wp-content/cache/simple-cache/${http_host}{request_uri}index. html" $uri $uri/ /index. php? $args; } Este sistema sólo funcionaría en el caso en el que los enlaces permanentes están configurados de la siguiente forma: /(loquesea)/%postname%/ En la parte inicial se puede configurar lo que se quiera, pero el último parámetro ha de ser el %postname% acabado en barra final. En caso de que los enlaces permanentes no tengan la barra final, se debería utilizar el siguiente código: location / { try_files "/wp-content/cache/simple-cache/${http_host}{request_uri}/index. html" $uri $uri/ /index. php? $args; } Si el plugin, como es el caso, permite activar la opción de Gzip, deberás desactivarlo ya que nginx ya lleva este sistema activado por defecto, por lo que los datos se guardarán planos y nginx ya ejecutará la mejor opción. --- En el caso de WordPress en general lo más habitual es que sólo se utilicen los métodos de solicitud GET y POST, pudiendo extenderse a HEAD y OPTIONS. EL resto de métodos en general no se utilizan y se podrían bloquear. Se pueden hacer solicitudes HTTP de varias formas. Quizá las más conocidas son el GET y el POST, pero los servidores web soportan una lista más larga de opciones. CONNECT: El método CONNECT establece un túnel hacia el servidor identificado por el recurso. DELETE: El método DELETE borra un recurso en específico. GET: El método GET solicita una representación de un recurso específico. Las peticiones que usan el método GET sólo deben recuperar datos. HEAD: El método HEAD pide una respuesta idéntica a la de una petición GET, pero sin el cuerpo de la respuesta. OPTIONS: El método OPTIONS es utilizado para describir las opciones de comunicación para el recurso de destino. PATCH: El método PATCH es utilizado para aplicar modificaciones parciales a un recurso. POST: El método POST se utiliza para enviar una entidad a un recurso en específico, causando a menudo un cambio en el estado o efectos secundarios en el servidor. PUT: El modo PUT reemplaza todas las representaciones actuales del recurso de destino con la carga útil de la petición. TRACE: El método TRACE realiza una prueba de bucle de retorno de mensaje a lo largo de la ruta al recurso de destino. En el caso de WordPress en general lo más habitual es que sólo se utilicen los métodos de solicitud GET y POST, pudiendo extenderse a HEAD y OPTIONS. EL resto de métodos en general no se utilizan y se podrían bloquear. Esto significa que en el fichero . hatccess (o en cualquier configuración de servidor web) se podrían bloquear los métodos con un par de líneas tales cual estas: # Bloquear request method RewriteCond %{REQUEST_METHOD} ^(connect|delete|head|options|patch|put|trace) RewriteRule . * - Obviamente, si tienes algún sistema de API que requiera de los métodos correspondiente se pueden añadir o eliminar al gusto y a las necesidades. --- Una pregunta recurrente que me llega varias veces por semana es cuánto vale montar un WordPress. Y todo viene por eso de que "es que WordPress es gratis". No, WordPress no es gratis, WordPress es libr Una pregunta recurrente que me llega varias veces por semana es cuánto vale montar un WordPress. Y todo viene por eso de que "es que WordPress es gratis". No, WordPress no es gratis, WordPress es libre. Otra de las razones habituales es debido a la confusión que se genera debido al . COM donde está el servicio freemium de Automattic y que es una opción para muchos, pero un problema cuando quieres hacer cosas serias o quieres tener control absoluto. Voy a enfocar esta entrada a personas que no tienen conocimientos técnicos, ya que en caso de tenerlos los costes se reducen (no mucho, pero hay detalles a tener en cuenta). Antes de comenzar en detalle, me gustaría hacer una breve lista de los distintos elementos ya que, al menos, deberías tener controlados y con una cuenta en cada uno de los sitios para pode operar en ellos. Esto significa que deberás tener acceso al registrador del dominio, al servicio de DNS y al alojamiento web / hosting. Personalmente recomiendo usar servicios distintos para cada uno de estos servicios, de forma que si uno falla el resto siguen activos y es más simple generar redundancia. Para empezar a montar un sitio web, cualquiera, es el registro del dominio. La única regla que pongo para esto es registrarlo en un registrador oficial (en general las webs serias tienen logos e información sobre esto). Personalmente, y como ya he comentado alguna vez, me gusta hacerlo en DonDominio ya que tienen buenos precios y el panel de administración es simple, además de dar la libertad y control absoluto de los dominios, que al final es lo importante. Un dominio suele costar entre 8 y 80 euros al año, depende de la extensión. Lo más habitual es que ronde los 12-24 euros/año. Esta es una de las partes más técnicas. Una vez tengas el dominio, el siguiente paso a tener en cuenta es el control de las DNS. Para las DNS me gusta utilizar Hurricane Electric DNS ya que tienen un servicio de DNS gratuito que cubre la mayoría de las necesidades y a todos los niveles, ya sea para un sitio local como para uno internacional. Es muy probable que tu proveedor de hosting también te ofrezca su propio servicio de DNS. Si no tienes ni idea de cómo gestionarlas, lo mejor es que dejes todo en mano de los técnicos, por lo que alojarlas con el proveedor de hosting suele ser una buena idea ya que no tendrás que preocuparte de las IP, los TTL y cosas parecidas (ya sé que uso palabrejas; si no sabes que significan, tu mejor opción es dejarlo en manos del hosting). En general las DNS son un servicio gratuito ya que puedes conseguir ambos servicios (externos o propios) sin problema. Eso sí, también hay servicios de pago si el sitio web se convierte en algo serio y con tráfico. Una vez tenemos el dominio y las DNS, el siguiente y último paso (en la parte tecnológica) es el alojamiento. Aquí hay muchísimas opciones, pero en general, si te quieres basar por precio, un alojamiento mínimo suele costar al menos 120 euros/año, aunque por menos de 180 euros/año no sueles encontrar nada decente. Pagar unos 20 euros/mes es algo muy razonable en un alojamiento correcto y estable, que es el alojamiento web de WordPress que ofrezco yo. El alojamiento web ha de tener unos mínimos que, como van variando, te recomiendo seguir en la página de Requerimientos para WordPress. Básicamente ha de tener una versión actualizada de PHP, de base de datos y capas de seguridad (al menos contra ataques masivos -DDoS- y un firewall / WAF). Además, cuando hablamos de WordPress hemos de hablar de actualizaciones. El secreto de un buen WordPress radica en básicamente que se mantenga actualizado todo. Y cuando digo todo es todo: núcleo, themes, plugins, traducciones... En general los sistemas actuales de hosting solo actualizan el core, que en general es lo más seguro, dejando de lado themes y plugins que ya parten de ser lo más inseguro y es lo que en general la gente despreocupa. Es por esto que deberías plantearte o hacerte una agenda de mantenimiento semanal, y dedicar 15-30 minutos a verificar que todo está al día, o contratar una empresa o alguien que haga los mantenimientos. Por ejemplo, en mi caso, ofrezco un servicio de mantenimiento de WordPress por 10 euros/mes. Para acabar con esta parte técnica y continuando con la seguridad, has de tener presente tener copias de seguridad. En general es muy raro que un sitio desaparezca si está mantenido, pero a veces las máquinas fallan y se puede estropear un disco o una base de datos y el problema está en que no haya copias accesibles fácilmente. Te recomiendo que tengas varios sistemas de seguridad. Por lo general la propia empresa de hosting tiene unas copias mínimas pero en las que sueles depender de ellos por completo para casi todo. Por otro lado, tienes sistemas externos que alojan copias de forma diaria o cuando te apetezca y que son accesibles, aunque en este caso suelen ya tener un poco de coste. Por ejemplo, yo ofrezco copias de seguridad de WordPress desde 9 euros/trimestre. Ahora ya tenemos el dominio, las DNS y el alojamiento web, lo que significa que ya tienes un WordPress montado. ¿Cuánto cuesta WordPress de por sí? Nada. WordPress es gratuito siempre y cuando lo descargues de WordPress. org, su web oficial. Instalarlo es muy fácil y en muchas ocasiones el hosting te ofrece su instalación con un clic para que no tengas ni que hacer la instalación o configuración de la base de datos y demás. Una vez tienes WordPress instalado comienzan una serie de periplos varios. Lo primero es la elección del theme y plugins a utilizar. En mi experiencia personal recomiendo no focalizarse tanto en el theme en un inicio sino en la funcionalidad y en los contenidos, en hacer que la web haga y tenga lo que necesitas.... --- Cada día veo más y más empresas, proyectos, lugares en los que se habla de los WordPress gestionados, pero que en realidad no lo son. Cada día veo más y más empresas, proyectos, lugares en los que se habla de los WordPress gestionados, pero que en realidad no lo son, y me gustaría dar un punto de vista de lo que considero que debería aclararse, sobre todo de cara a los usuarios y propietarios de sitios hechos con WordPress. Para comenzar, veamos un poco los distintos elementos de los que un WordPress está formado: dominio y DNS, alojamiento web, software base y complementos. Estos son los 4 elementos principales que un sitio tiene, y sí, podemos entrar en agregar o desagregar más, pero creo que esto lo resumen. Para comenzar por el principio, hablemos de lo que es un dominio. No voy a explicar en sí, pero lo que representa: el dominio es tu marca tu nombre, tú. Y como "TÚ" que es, es algo que NUNCA debes dejar controlar a nadie. Tú has de tener el control absoluto del dominio. Esto significa que los dominios los has de tener completamente a tu nombre, y en un registrador oficial que te permita gestionar completa y transparentemente su gestión. El dominio es lo principal de un proyecto, porque si lo pierdes, no hay manera de recuperar su control (al menos fácilmente) de nada o te puedes dar por jodido. Así que NUNCA dejes que nadie registre el dominio por ti o lo gestione, o pueda tener el control. El dominio ha de estar a tu nombre, con tu correo, con el de nadie más. Una vez tienes el control del dominio, comienzan las posibilidades. Por ejemplo las DNS. A mi me da un poco igual dónde o quién las gestione, aunque siempre es más sencillo, en mi caso por ejemplo, que las gestione la misma empresa donde está el alojamiento web, y donde puedas tener el correo o similar. Si lo vas a tener distribuido, otra opción interesante es ponerlo ya a unos niveles superiores, tipo Route 53, Hurricane Electric o similares. Esta parte has de tenerla controlada, pero siempre compartiendo su uso con el responsable técnico, ya que requiere de cierto mantenimiento. Aún así, hasta aquí, si tienes unos mínimos conocimientos técnicos, lo puedes gestionar. Sino, es muy recomendable que alguien que sepa del tema le de una ojeada, que por defecto muchas empresas meten mierda que no vale la pena tener y puede generar problemas. Una mala configuración de DNS te puede fastidiar el SEO y generar problemas de seguridad. El alojamiento web es el siguiente punto. Está claro que tomar una decisión sobre el alojamiento web no es sencillo, aunque haya plataformas que por 1 euro al mes te den alojamiento... ¿a qué coste? El alojamiento web es como una vivienda. Hay casas, pisos, áticos, más grandes, más pequeños, con más ruido, con menos, con ascensor, con terraza. A partir de aquí, imagina que vas a montar una festa, y quieres que sea una fiesta de mucho éxito. Por lo tanto, tendrás que saber cuántos invitados vendrán, cuánta comida tendrás que dar, si vas a ser tú el anfitrión, si vas a tener catering... Pues ahora esto lo llevas al hosting, y el espacio en disco, CPU, RAM, ancho de banda... todo eso es lo que te va a permitir el "éxito de la fiesta". Si es algo familiar, personal y solo van a venir una o dos personas a la fiesta, y van y vienen, pues tú solo te lo vas a poder gestionar, pero si quieres que vengan muchas personas, es probable que contrates a una empresa de catering. Vale, pues eso. Cuando hablamos del alojamiento hablamos también de su mantenimiento. Lo mismo que en una casa hay cosas que se desgastan, tuberías que se estropean, grifos que gotean... o simplemente no está estropeado pero "de tanta fiesta la pintura se ensucia" es muy probable que tengas que contratar a un manitas para que te pinte el piso. ¿Lo puedes hacer tú? Sí, claro, pero si no eres pintor, quedará como quedará. Hoy en día hay que estar atentos a que la infraestructura sea la adecuada, te permita la velocidad y capacidad perfecta para la capacidad que necesitas, y también todo lo relacionado con el rendimiento de PHP y sus versiones, lo mismo con la base de datos MySQL o MariaDB, las actualizaciones... hablamos de software y de hardware. Lo mismo que tienes el Windows Update y que cada X tiempo has de mejorar tu portátil "porque empieza a ir mal", pues con las webs pasa lo mismo. La diferencia es que no eres tú el que usa principalmente el sitio, sino tus visitantes. ¿Qué significa que un hosting / alojamiento web sea gestionado? Pues, por un lado, que ellos vayan haciendo los mantenimientos de la parte de infraestructura, que te vayan adecuando o te sugieran y recomienden las mejoras de infraestructura necesarias, que te informen de que necesitas actualizar el PHP o la base de datos... De la misma manera no deberías preocuparte por las copias de seguridad, porque tu alojamiento se debe encargar de ello de forma automática y de forma sencilla te ha de permitir restaurarlas o conseguirlas. Con respecto al software base y los complementos, es decir, el WordPress, la cosa cambia. Una empresa de "hosting" no se va a preocupar del mantenimiento de tu WordPress. Puede preocuparse de actualizar de forma automática el core, porque se puede automatizar, pero ¿quién se preocupa del resto? WordPress es la suma del núcleo, de los themes, plugins, traducciones, copias de seguridad, caché, etcétera. Volviendo al ejemplo de la vivienda, es como si la puerta de la calle comienza a flojear. Primero se cae la tapa de la mirilla, pero no te das cuenta, aunque desde fuera pueden asomarse y de una forma rara, mirar. O como si te mal acostumbras a no echar la llave y alguien intenta pasar una radiografía para ver si se abre el pestillo... Mantener un sitio web es lo mismo que mantener tu vivienda. Estoy seguro de que la llave de tu casa es... --- Cuando hablamos de web performance siempre se analiza la velocidad de carga de los scripts, principalmente con el objetivo de que se carguen mediante un CDN. Cuando hablamos de web performance siempre se analiza la velocidad de carga de los scripts, principalmente con el objetivo de que se carguen mediante un CDN. Pero ¿cómo podríamos hacer que cualquier script de un sitio con WordPress se carguen con un CDN? Pues existe una solución. Existen muchos sistemas de carga de algunos scripts conocidos, tipo jQuery, y hay muchos plugins que permiten cambiar su carga por la de otro CDN como el de Google o similares. Y es que Google tiene su lista de JavaScript alojados, También lo tiene CNDJS con una larga lista, pero en esta ocasión quiero hablaros de jsDelivr. Y es que jsDelivr no solo tiene alojadas decenas de bibliotecas, sino que permite, de forma automática, la carga de cualquier plugin, theme o core de WordPress. ¿Cómo? Pues es bastante simple, la verdad. las direcciones base son las siguientes: https://cdn. jsdelivr. net/wp/plugins/project/tags/version/file https://cdn. jsdelivr. net/wp/themes/project/version/file Voy a poner un par de ejemplo para que sea mucho más sencillo. Si tienes el plugin del Classic Editor, y analizamos un poco el trunk, podemos ver que hay una carpeta "js". Esto permitiría ver que cuando el plugin se carga, seguramente se llame a un fichero del estilo a: /wp-content/classic-editor/trunk/js/block-editor-plugin. js Esto se serviría directamente desde nuestro hostname, lo que puede no hacerlo óptimo... pero podríamos llamarlo desde aquí: https://plugins. trac. wordpress. org/browser/classic-editor/trunk/js/block-editor-plugin. js https://cdn. jsdelivr. net/wp/plugins/classic-editor/trunk/js/block-editor-plugin. js Solo hay que sustituir la URL del trac, por la URL que ellos nos proporcionan. Con esto tenemos que el JavaScript se carga desde el CDN. Esto también funcionaría al hacer llamadas concretas a versiones concretas del plugin: https://plugins. trac. wordpress. org/browser/classic-editor/tags/1. 3/js/block-editor-plugin. js https://cdn. jsdelivr. net/wp/plugins/classic-editor/tags/1. 3/js/block-editor-plugin. js De la misma forma podemos hacer con los ficheros de las plantillas. En este caso voy a tomar de ejemplo el Twenty Nineteen. https://themes. trac. wordpress. org/browser/twentynineteen/1. 1/js/touch-keyboard-navigation. js https://cdn. jsdelivr. net/wp/themes/twentynineteen/1. 1/js/touch-keyboard-navigation. js Vale, sí, todo esto está muy bien pero... ¿Cómo ponerlo en práctica? Pues hay varias maneras... una de ellas es directamente mediante los desarrolladores de los plugins que te podrían dar la opción. Al funcionar de serie con cualquier plugin, el desarrollador del plugin (o theme) podría darte la opción de carga desde local o a través de este CDN. Tú decides. La otra opción tras una búsqueda por el repositorio, es la de usar este plugin llamado NGT jsDelivr CDN que hace el trabajo por ti. Aunque quizá una de las cosas que más puede gustar es que este plugin no solo sustituye el código de plugins y themes, sino también del core. https://core. trac. wordpress. org/browser/tags/5. 0. 2/src/wp-includes/js/admin-bar. js https://cdn. jsdelivr. net/gh/WordPress/WordPress@5. 0. 2/wp-includes/js/admin-bar. js Como se puede ver, se podría lanzar una versión optimizada de todos tus sitios con WordPress mejorando el rendimiento haciendo llamadas a este CDN. Por cierto, acabo de probar y también funciona con los CSS. https://core. trac. wordpress. org/browser/tags/5. 0. 2/src/wp-includes/css/admin-bar. css https://cdn. jsdelivr. net/gh/WordPress/WordPress@5. 0. 2/wp-includes/css/admin-bar. css Ya sabes... ¿quieres optimizar tu WordPress? Ahora puedes hacerlo. --- WordPress necesita poca memoria para funcionar, pero solo si hablamos del núcleo principal. WordPress necesita poca memoria para funcionar, pero solo si hablamos del núcleo principal. En el momento en el que añadimos plugins pesados, la situación cambia. Si tienes configurado correctamente PHP, el sistema incorporará esa configuración de memoria que tengas disponible, pero en caso de no ser así, por defecto solo tendrá como máximo un uso de 40MB de memoria, aunque si es un MultiSite, subirá a 60MB. Obviamente, esta cantidad es baja, pero segura en un alojamiento web mínimo y básico. ¿Cómo ampliar la memoria? La tarea es sencilla, y afecta básicamente a dos constantes del sistema que se pueden modificar desde el fichero wp-config. php, habitualmente situado en la carpeta raíz de tu instalación de WordPress. Para comenzar deberemos indicar cuál es el límite máximo de memoria que se puede consumir. Esto deberías saberlo al contratar tu servicio de alojamiento. Obviamente si pones algo muy grande lo más probable es que en picos de tráfico el servidor se sature, por lo que hay que poner algo razonable. El pico máximo que viene por defecto es 256MB, que es correcto, pero si tienes problemas, aparte de que deberías revisar el porqué los tienes, puedes aumentarlo hasta los 384MB. Personalmente nunca recomendaría pasar de ahí y esto ya es un extremo. Lo ideal es dejarlo en 256MB. define( 'WP_MAX_MEMORY_LIMIT', '256M' ); La pregunta es ¿cuál es la cifra para el uso normal? Como decía antes, el valor habitual si no se le indica es de 40MB, algo que en mi opinión es bajo. El mínimo debería ser 64MB. ¿El máximo? Obviamente como extremo tendríamos el valor de antes, que para eso está, así que en este caso recomiendo algo menos, que podría ser de 128MB. En caso de que tengas problemas y hayas puesto el máximo a 384MB, quizá el normal podría ser de 256MB. define( 'WP_MEMORY_LIMIT', '128M' ); Con esta configuración y un buen servicio de alojamiento web, deberías tener suficiente para un WordPress normal, e incluso para un WooCommerce con algo de tráfico. Eso sí, recuerda siempre tener un buen sistema de caché de ficheros y de objetos, sobre todo este último que permita almacenar y cachear consultas de la base de datos. --- Si te gestionas tu propio servidor, y en este caso es CloudLinux, es muy probable que una de las ventajas que disfrutes es la del sistema de CageFS para enjaular a cada uno de los usuarios y que no se Si te gestionas tu propio servidor, y en este caso es CloudLinux, es muy probable que una de las ventajas que disfrutes es la del sistema de CageFS para enjaular a cada uno de los usuarios y que no se fastidien los sitios entre ellos. Pero si utilizas WordPress en algunos de ellos y, por ejemplo, quieres configurar que los crones los ejecute el servidor, te encontrarás con un pequeño problema: CageFS y WP-CLI no se llevan muy bien. Si quieres instalarlo, deberás seguir algunos pequeños pasos, diferentes de los que habitualmente se ejecutan: cd ~ curl -O https://raw. githubusercontent. com/wp-cli/builds/gh-pages/phar/wp-cli. phar chmod +x wp-cli. phar chown root:nobody wp-cli. phar mv wp-cli. phar /usr/local/bin/wp Hasta aquí la principal diferencia con respecto al "manual" de WP-CLI es que le damos permisos de al grupo del fichero. Con esto, más adelante, se permitirá que cualquier usuario pueda llegar a ejecutar la instalación global de WP-CLI. El siguiente paso a realizar es el de configurar el CageFS para que pueda acceder a ejecutar WP-CLI: vim /etc/cagefs/conf. d/wpcli. cfg Y añadimos el siguiente contenido: comment=Permite ejecutar WP-CLI con CageFS paths=/usr/local/bin/wp Y una vez hayamos guardado, actualizaremos el CageFS para que se pueda ejecutar el WP-CLI. cagefsctl --force-update En principio, con esto, si entras por SSH en cualquier usuario (aunque tenga el jailed activado) podrá ejecutarlo... el problema viene al intentar configurar los crones... aunque para ello (sin ser la mejor opción) podemos llamarlos por ejemplo, así: * * * * * WP_CLI_PHP=/usr/local/bin/php; SHELL=/bin/bash; /usr/local/bin/wp cron event run --due-now --path=/home/usuario/public_html/ >/dev/null 2>&1 Es posible que recibas algún mensaje de error en la ejecución, pero se ejecutan los crones, que es la situación a resolver. --- Hace unos días que rondaba por Twitter un runrún sobre cómo asegurar una instalación de WordPress en la que no puedes actualizar el core, themes, plugins o transations. Hace unos días que rondaba por Twitter un runrún sobre cómo asegurar una instalación de WordPress en la que no puedes actualizar el core, themes, plugins o transations. En estos casos la solución no es sencilla, pero tampoco significa que la instalación sea insegura. En estos casos lo primero que hemos de analizar es si los plugins / themes son seguros o no, además de que la versión de WordPress que haya no tenga agujeros extremadamente graves. Si comenzamos por la parte del core, hay que saber que existen versiones muy antiguas que tienen parches de seguridad... Para ello podemos visitar la página de WordPress releases donde las encontraremos. Por ejemplo, en este momento, julio de 2018, tenemos versiones como: rama 3. 7: versión 3. 7. 27rama 3. 8: versión 3. 8. 27rama 3. 9: versión 3. 9. 25rama 4. 0: versión 4. 0. 24rama 4. 1: versión 4. 1. 24rama 4. 2: versión 4. 2. 21rama 4. 3: versión 4. 3. 17rama 4. 4: versión 4. 4. 16rama 4. 5: versión 4. 5. 15rama 4. 6: versión 4. 6. 12rama 4. 7: versión 4. 7. 11rama 4. 8: versión 4. 8. 7 Normalmente estas ramas aparecen el mismo día o los posteriores a las versiones más actuales de la rama principal. Así que esta es la primera tarea que hay que hacer, intentar actualizar, al menos, el core de WordPress. En caso de que hayan tocado el núcleo, la verdad es que el desastre ya es tan mayúsculo que no sé muy bien qué solución dar. Como segunda ronda, recomiendo enormemente intentar hacer un mantenimiento del sistema operativo del servidor. Obviamente hay que hacer una copia de todo, montar un entorno de desarrollo y probar el sistema con versiones actuales de PHP, MySQL y sistema operativo. Esto no significa que haya que cambiar a Ubuntu 18 si tienes Ubuntu 14, o cambiar de PHP 5. 4 a la 7. 2, sino que de las ramas del propio sistema operativo, del PHP y del MySQL, se haga una actualización. El sistema operativo y la base de datos, por lo general no deberían dar problemas. Sobre el PHP, aunque no hay tanta retro compatibilidad, sí que habría que intentar hacer el esfuerzo de usar las últimas versiones de PHP 5. 6 o de 7. 2. Es raro que un plugin de WordPress utilice funciones extrañas que no sean compatibles con alguna de estas dos versiones. Por ejemplo, en este momento, julio de 2018, tenemos versiones como: rama 5. 6: versión 5. 6. 37rama 7. 0: versión 7. 0. 31rama 7. 1: versión 7. 1. 20 Por supuesto, en estos casos es imprescindible el uso de algún tipo de firewall, lo más probable es que deba ser externo, así que si tu hosting no es capaz de proveerte un sistema de enjaulado de ficheros (para que ese WordPress no se pueda mezclar con otras instalaciones de cualquier otra cosa) y tampoco es capaz de proveerte de una capa externa de bloqueos, deberías plantearte alguien que sí lo haga. Justo en estos momentos, por ejemplo, yo mismo estoy trabajando en una solución para mis clientes que tienen esta problemática, un sistema que separa las cuentas de usuarios y también mantiene distintas versiones de PHP. Siguiente paso: encontrar vulnerabilidades conocidas de determinados plugins... Para ello podemos usar como base el sistema de la WPScan Vulnerability Database que al menos nos indicará si hay agujeros graves en determinadas versiones de lo que usamos. Tienes revisiones de WordPress, plugins o themes. Si encuentras que un plugin tiene vulnerabilidades, la ventaja de que todo es GPL, es que deberías tener a tu disposición el código fuente de las nuevas versiones y podrías parchear el código con lo más grave que haya. A partir de aquí, que es lo más base de todo el sistema, hay que hacer algunos bloqueos del propio WordPress. Estos sistemas seguramente no te protejan por completo de un ataque, pero sí que, al menos, podrían intentar minimizar la detección de versiones antiguas de algunos elementos. Lo primero es la protección de usuarios y contraseñas. Habría que intentar buscar un un plugin de 2FA que sea compatible con la versión de WordPress. Además, puedes obligar al uso de una contraseña fuerte. Otro elemento importante a tener presente, principalmente por la fuga de datos y posibles inyecciones de código es la instalación de un certificado TLS y activar el HTTPS por defecto (esto no debería afectar al sistema), pero quizá más incluir una serie de reglas de CSP (Content Security Policy), al menos el que activa el "upgrade" automático de http a https. Y siguiendo con temas de hosting (tirando mucho de . htaccess): actualizar los permisos de los ficheros y bloquear la ejecución de PHP en determinadas carpetas. Además, para la base de datos deberíamos hacer una revisión de los permisos (incluso me atrevería a decir que si es una instalación "intocable"), solo dejemos permisos de SQL de INSERT, SELECT, UPDATE y DELETE y eliminemos los demás. Otro elemento es el de ir cambiando cada cierto tiempo las Security Keys, intentando sis e puede automatizarlo con el Salt Shaker. Aunque sin duda lo que hay que hacer es ocultar la detección al máximo de las versiones de WordPress y plugins. Hay que recordar que existen muchos métodos de detección y, por tanto, de ocultación. También, por seguridad, ocultemos la posibilidad de petar la base de datos si falla la conexión. Sobre todo, recuerda hacer backups y probarlos, que no se conviertan en Backup Schrödinger, y si tras pasar un análisis por WordPress Danger sigues teniendo detecciones, no dudes en ponerte en contacto conmigo que analizaremos con más detalle la casuística de esa instalación y la protegeremos de la mejor forma posible. --- ---