Guía de seguridad para WordPress
WordPress es el CMS más utilizado del mundo, con una cuota de mercado muy superior a sus competidores. Como consecuencia, también es el más atacado y al que más le buscan las “cosquillas” para intentar acceder a los datos.
Desgraciadamente, la mayor parte de los casos de hackeo o intrusión en WordPress no son resultado de ser el CMS más atacado, sino de una mala praxis o mala gestión por parte del administrador del sitio web. No hace falta ser un gran experto para proteger WordPress de hackers y de otro tipo de atacantes: tan solo es necesario aplicar la lógica y prestar atención.
Por otro lado, yo condeno bastante el uso de suites de seguridad para WordPress, es decir, plugins todo en uno como iThemes Security, WordFence Security o All in One Security.
¿La razón? Pues que, en circunstancias normales, el 90% de las funcionalidades que traen no las vas a utilizar y otras (como sistemas de análisis en vivo o firewalls que analizan tráfico en vivo) consumirán excesivos recursos y ralentizarán la carga del sitio web.
Personalmente, prefiero implementar las funcionalidades por separado según las voy necesitando en lugar de instalar alguno de estos gigantes que son los causantes del mal rendimiento de muchas webs por sobrecarga de PHP.
Para entender esto, primero hay que saber que no es lo mismo ejecutar un WAF a nivel WordPress (como WordFence Security) que un WAF a nivel servidor como mod_security con unas buenas reglas. Ni consumen los mismos recursos (consume menos mod_security), ni operan al mismo nivel, ni son igual de efectivos.
En este post hablaremos de seguridad para WordPress, pero vamos a intentar explicar qué frentes que debemos proteger, cuándo y cómo para no dañar la experiencia del usuario y el rendimiento del sitio web.
Para que te hagas una idea del impacto en el rendimiento de los plugins tipo suite de seguridad, son siempre lo primero que desactivo cuando realizo trabajos de WPO en un sitio web.
Un sitio web con un análisis en vivo de WordFence Security (por poner un ejemplo) NUNCA va a poder competir en velocidad de carga con un sitio que no lo use, ya que siempre va a existir un retardo por el análisis de WordFence.
Este es un ejemplo de sobreuso de recursos y saturación de un hosting con 1GB de memoria RAM por el plugin All in One Security:
En la prueba de la captura anterior, con las gráficas de CloudLinux sobre cPanel, podemos ver el impacto de activar este plugin en una web con tráfico que estaba funcionando bien y sin sobresaltos hasta el momento de activar el plugin.
Ahora que ya he comentado mis intenciones de cara a este post, vamos con la introducción de verdad sobre el tema.
- Prevención y lógica: los dos pilares
- Las infecciones y las "recaídas"
- Plugins: ¿Qué debemos tener en cuenta?
- Si el plugin ya no se actualiza
- Si el plugin es nulled o trae malware
- Si aparece un zero day en un plugin
- Gestionar actualizaciones de plugins
- Themes: ¿Qué debemos tener en cuenta?
- Actualizaciones de WordPress
- Accesos y autentificación segura
- Contraseñas y autentificación
- Cambiar la URL de login de WordPress
- Bloquear ataques de fuerza bruta
- WAF o Web Application Firewall
- CloudFlare como firewall
- Proteger WordPress del SPAM
- Proteger los comentarios de WordPress
- Proteger los registros del SPAM
- Proteger comunidades y foros
- Proteger formularios en WordPress
- Otros tweaks para proteger WordPress
- Bloquear el XMLRPC.PHP
- Permiso de archivos y carpetas
- Backups o copias de seguridad
- Desinfección de WordPress
Prevención y lógica: los dos pilares
Como he dicho anteriormente, la lógica juega un papel muy importante en la seguridad de WordPress. La mayoría de los casos de infección no habrían tenido lugar simplemente si se hubiese aplicado la lógica.
Existen dos puntos débiles a través de los cuales se suelen hackear WordPress:
- Plugins sin actualizar, con fallos de seguridad o descargados de orígenes con malware.
- Contraseñas poco seguras o autentificaciones inseguras.
Estas son solo las dos principales razones, pero existen muchos más factores que afectan a la seguridad de un WordPress y también muchas otras cosas que debemos tener en cuenta. No obstante quiero que quede muy claro, que con medidas de seguridad básicas y un poco de lógica y prevención, podemos tener un WordPress seguro y completamente protegido frente a cualquier tipo de amenaza.
Las infecciones y las "recaídas"
¿Sabes cuál es la principal razón por la que es mejor que NUNCA te infecten? Pues porque si te infectan una vez, tendrás que realizar una desinfección completa de tu sitio web si no quieres que te vuelvan a infectar una y otra vez.
Durante una infección, además de borrar archivos el atacante puede modificar muchos archivos de WordPress y los plugins provocando que, aunque borres los archivos que veas a simple vista, pueda existir un caballo de Troya que vuelva a dar acceso al atacante.
Por esta razón existen los procesos de desinfección de WordPress. En Raiola Networks ofrecemos este servicio de forma especializada desde 2014. Lo importante es que sepas que, si te han infectado y no has desinfectado tu WordPress de la forma más exhaustiva posible, lo más probable es que tu instalación siga infectada.
Plugins: ¿Qué debemos tener en cuenta?
Como hemos dicho ya, los plugins de WordPress son uno de los puntos débiles con más posibilidades de hackeo si no tenemos cuidado.
Lo ideal es actualizar los plugins siempre que aparezca una nueva versión. Esto lo dice la teoría, pero en la práctica… pues debemos adaptarnos al desarrollador y a los bugs de funcionamiento. Un ejemplo de esto es Yoast SEO, que sería un suicidio actualizar el mismo día que se publica la actualización, ya que últimamente ha provocado muchas caídas de sitios web por esta razón.
Además de plugins sin actualizar, pueden existir distintas razones por las que nos infectan un WordPress a través de plugins:
- Que los plugins no hayan sido actualizados desde hace mucho tiempo o que su autor haya abandonado el desarrollo.
- Que aparezca un fallo de seguridad o zero day y que las posibilidades de defensa sean bajas debido a la “novedad”.
- Que el plugin sea nulled o descargado desde un origen poco fiable, que traiga malware o una puerta trasera.
Sabiendo esto, podemos tomar ciertas decisiones, aunque en algunos casos cuesta llevar a término estas decisiones debido al trabajo que dan.
Si el plugin ya no se actualiza
Si el plugin en cuestión lleva tiempo sin actualizaciones y su desarrollo se ha parado hace más de 6 meses o si ha aparecido un zero day y el plugin lleva tiempo sin actualizarse, debemos cambiar ese plugin.
Entiendo la dificultad de cambiar un plugin por otro, sobre todo cuando buscamos ciertas funcionalidades específicas, pero es MUY necesario y no debe darnos pereza, por el bien de la seguridad de nuestro WordPress.
Si el plugin es nulled o trae malware
Es muy común que ciertos atacantes tengan webs donde ofrecen plugins Premium con la licencia crackeada con el fin de infectar a los que instalen estos plugins.
Es un gran reclamo para mucha gente que busca plugins Premium de forma gratuita. Esto hace que esta sea una de las principales razones de infección. De hecho, aunque los instalemos solo para probar y los desinstalemos posteriormente, pueden quedar archivos modificados o escondidos para infectarte meses más tarde por una orden del atacante.
Esto que acabo de explicar es algo MUY común y la principal razón de infección.
Si aparece un zero day en un plugin
Algo que no podemos prevenir es un zero day. Aunque en algunos casos podemos llegar a proteger el sitio web con un WAF, depende de la naturaleza del ataque.
Si aparece un zero day en un plugin, lo ideal es reforzar la seguridad con un WAF mientras que el autor no publica una actualización, aunque esto no garantiza nada. Ciertos sistemas de proxy inverso, como CloudFlare o Sucuri, pueden ayudarte a proteger tu sitio web en estos casos.
Como he dicho antes, si el plugin en cuestión no recibe actualizaciones durante hace tiempo, debemos cambiarlo inmediatamente por una alternativa que haga lo mismo y que reciba actualizaciones.
Gestionar actualizaciones de plugins
Como ya he comentado, la teoría dice que debemos actualizar los plugins nada más liberarse las versiones más actuales.
Esto es la teoría, pero en la práctica puede ser complicado gestionar las actualizaciones de un montón de instalaciones WordPress con distintos plugins y distintas configuraciones.
Para esto existen herramientas como InfiniteWP, que nos ofrecen la posibilidad de gestionar las actualizaciones de muchas instalaciones a la vez.
En la versión 5.5 de WordPress, se implementan las autoactualizaciones de plugins instalados desde el repositorio oficial de WordPress.
Esto es bueno pero también malo, ya que las actualizaciones se realizarán justo cuando se liberen y esto puede causar fallos en tu web.
Themes: ¿Qué debemos tener en cuenta?
Los themes y plantillas de WordPress funcionan del mismo modo que los plugins. Debemos tomar las mismas precauciones y realizar las mismas acciones de prevención que en el caso de los complementos.
Los themes también se pueden descargar nulled y con malware desde páginas “pirata”, también reciben actualizaciones constantemente y también debemos cambiarlos si dejan de actualizarse.
El problema de los themes es que, en muchos casos, se realizan modificaciones en el código sin implementar un child-theme. Esto provoca que muchos administradores sean reticentes a actualizar el theme.
Si tenemos un theme sin actualizaciones desde hace tiempo, pueden infectarnos de la misma forma que a través de los plugins. Debemos cambiarlo por otro aunque esto suponga un trabajo extra por “rediseño”.
Actualizaciones de WordPress
El core de WordPress también necesita actualizarse cada cierto tiempo. Este tipo de actualización debe ir en consecuencia con las actualizaciones de los plugins y themes. ¿Qué quiero decir con esto? Pues que, si actualizamos todos los plugins a la última versión disponible, lo ideal es tener WordPress en la última rama estable para evitar problemas de compatibilidad.
Desde hace bastante tiempo, WordPress lleva un sistema de autoactualizaciones que puede actualizar automáticamente versiones menores dentro de la misma rama estable. Sin embargo, necesita intervención manual para cambiar de rama o para actualizaciones mayores.
Actualmente, es muy “raro” que hackeen un WordPress por un fallo de seguridad en el propio WordPress, ya que normalmente los problemas vienen por fallos de seguridad en plugins y themes. Aun así, debemos tener WordPress actualizado a la última versión de la rama en la que nos encontremos, preferiblemente la última.
Recuerda que puedes retroceder a la última versión de WordPress. Si no sabes cómo hacerlo échale un vistazo a este post sobre cómo volver a la versión anterior de WordPress.
Accesos y autentificación segura
Como he dicho antes, la autentificación es uno de los puntos débiles de un WordPress.
En muchos casos el problema puede ser la contraseña de acceso, pero en otros muchos el problema viene por el entorno en el que trabaja uno de los administradores del sitio web.
Lo bueno es que existen métodos para securizar toda esta parte y evitar ataques de fuerza bruta contra los accesos, al mismo tiempo que bloqueamos a todos los posibles atacantes.
Contraseñas y autentificación
Aunque parezca algo insignificante, en muchos casos las intrusiones vienen por las propias contraseñas de los usuarios.
En esta área, encontramos dos puntos débiles que debemos tener en cuenta:
- Contraseñas débiles que debemos reforzar.
- Casos de phishing donde roban las contraseñas del ordenador de un administrador.
En ocasiones, estos dos puntos débiles se combinan con un exceso de permisos o unos roles de usuario mal configurados.
Reforzar una contraseña no tiene ninguna ciencia, es lógica pura: hay que poner una contraseña fuerte y a poder ser generada.
En cuanto al phishing y otras técnicas para robar la contraseña en el ordenador de un administrador del sitio web, no voy a decir mucho ya que no quiero meterme en temas de seguridad para Windows. Lo básico es tener un buen antivirus en el ordenador si se utiliza Windows y tomar ciertas precauciones en entornos Macintosh o Linux. El resto también es cuestión de prevención y lógica, como en el caso de WordPress.
Existe otra forma de proteger los accesos a WordPress, mediante autentificación en dos pasos. Si quieres saber cómo implementar la autentificación en dos pasos o two factor en WordPress, puedes ver el siguiente vídeo:
https://www.youtube.com/watch?v=hGLBPKd_i4c
También se pueden utilizar otros métodos, como el acceso por USB Key.
El objetivo de estos dos métodos es prescindir de las contraseñas y securizar al máximo los accesos a zonas privadas como el dashboard de un WordPress.
Cambiar la URL de login de WordPress
Además de todo lo anterior, podemos proteger las URL de acceso a WordPress cambiándolas.
Esto es algo que otros CMS, como Prestashop, permiten de forma nativa. Sin embargo, en el caso de WordPress debemos utilizar plugins.
Para que te hagas una idea, el 99,9% de los ataques se realizan mediante bots que identifican y siguen patrones. Entre esos patrones está atacar las URL de login predeterminadas si detectan un CMS.
Algunas suites de seguridad, como WordFence Security o iThemes Security, permiten cambiar la URL de wp-admin y wp-login.php, pero no es necesario utilizar plugins tan pesados para hacer esto. Con plugins como Change wp-admin login podemos cambiar la URL fácilmente y de forma gratuita: https://es.wordpress.org/plugins/change-wp-admin-login/
Bloquear ataques de fuerza bruta
Para bloquear los ataques de fuerza bruta podemos utilizar distintos métodos implementados en distintas partes del entorno web.
Se considera que ha tenido lugar un ataque de fuerza bruta cuando el atacante realiza intentos de autentificación con el fin de encontrar la contraseña correcta de acceso. Lo ideal es bloquear a estos usuarios después de X intentos de acceso (por ejemplo, después de 5 intentos fallidos).
Esto también se puede hacer con la mayoría de suites de seguridad para WordPress, pero veo innecesario gastar recursos con plugins complejos cuando existen otros mucho más simples que ya cubren esta funcionalidad.
La forma más fácil de bloquear ataques de fuerza bruta en WordPress es utilizar plugins como Limit Login Attemps: https://es.wordpress.org/plugins/limit-login-attempts-reloaded/
También es posible, como de hecho sucede en los servidores de hosting compartido de Raiola Networks, que el servidor tenga mod_security con fail2ban, que bloquea los intentos de acceso fallidos directamente desde el servidor de una forma mucho más efectiva.
- Prevención y lógica: los dos pilares
- Las infecciones y las "recaídas"
- Plugins: ¿Qué debemos tener en cuenta?
- Si el plugin ya no se actualiza
- Si el plugin es nulled o trae malware
- Si aparece un zero day en un plugin
- Gestionar actualizaciones de plugins
- Themes: ¿Qué debemos tener en cuenta?
- Actualizaciones de WordPress
- Accesos y autentificación segura
- Contraseñas y autentificación
- Cambiar la URL de login de WordPress
- Bloquear ataques de fuerza bruta
- WAF o Web Application Firewall
- CloudFlare como firewall
- Proteger WordPress del SPAM
- Proteger los comentarios de WordPress
- Proteger los registros del SPAM
- Proteger comunidades y foros
- Proteger formularios en WordPress
- Otros tweaks para proteger WordPress
- Bloquear el XMLRPC.PHP
- Permiso de archivos y carpetas
- Backups o copias de seguridad
- Desinfección de WordPress
WAF o Web Application Firewall
Hace tiempo que soy bastante fan de los WAF o Web Application Firewall y de lo que pueden hacer por cualquier web a nivel seguridad.
Un WAF bien implementado puede consumir pocos recursos y al mismo tiempo proteger WordPress incluso de amenazas nunca vistas.
Tenemos tres formas de configurar un WAF en WordPress: mediante un servicio en el servidor, mediante un servicio externo o mediante un plugin.
En el caso de un WAF en el servidor, normalmente se utilizan sistemas como mod_security.
Si buscamos un plugin para implementar un WAF en WordPress, podemos hacerlo con iThemes Security o WordFence Security, pero también existen otras soluciones potentes y que consumen pocos recursos, como por ejemplo Ninja Firewall:
Si quieres ver un poco mejor cómo funciona Ninja Firewall para WordPress, puedes ver este videotutorial:
https://www.youtube.com/watch?v=dMlueSs2OBk
En cuanto a servicios externos para implementar un WAF, CloudFlare es un ejemplo. CloudFlare puede proteger cualquier sitio web si sabemos configurarlo correctamente, pero de esto vamos a hablar en la siguiente sección.
CloudFlare como firewall
Me encanta CloudFlare. Creo que es un CDN excepcional, el DNS anycast más rápido del mundo según DNSPerf y también un excelente firewall o WAF al colocarse como proxy inverso de un sitio web.
CloudFlare nos permite implementar algunos tweaks para proteger el sitio web para el que lo configuramos:
Si queremos ir un poco más allá, podemos establecer reglas en el firewall que nos permiten bloquear dependiendo de lo que necesitemos.
Y, lo más importante, estos bloqueos se realizarán de forma totalmente externa y sin impacto sobre el rendimiento del hosting, es decir, sin consumir recursos del hosting.
Aquí tienes un vídeo sobre el tema:
https://www.youtube.com/watch?v=GfYR81m2kc4
Existen otras opciones distintas a CloudFlare para la seguridad externa, como Incapsula o Sucuri, pero son alternativas centradas en la seguridad y no tienen casi opciones de rendimiento. Por otro lado, al bloquear ataques importantes, CloudFlare (con su gran red mundial) ha demostrado ser la mejor solución y la elegida por muchos sitios web importantes.
Proteger WordPress del SPAM
Actualmente, el SPAM es algo muy común en sitios web sociales donde se le da la posibilidad de interacción al usuario, como los blogs.
El SPAM no es solo molesto sino que, si nos insertan determinados enlaces o determinadas palabras clave, puede considerarse ataque de SEO negativo y hacernos perder posicionamiento.
En WordPress, dependiendo del tipo de sitio web, el SPAM puede ir a distintas partes:
- En tiendas online WooCommerce pueden registrarse usuarios spam.
- En foros y comunidades pueden registrarse spammers y dejar comentarios.
- En blogs pueden dejarnos comentarios de spam.
- En cualquier formulario de contacto puede llegarnos spam.
¿Qué podemos hacer para protegernos del spam? Pues, en función del área que queramos proteger, deberemos realizar una u otra acción.
En Raiola Networks, recomendamos tres técnicas antispam en entornos web:
- Bloqueo mediante listas negras.
- Google Recaptcha V3 (el invisible).
- La técnica honeypot.
Dependiendo del área donde queremos aplicarla, deberemos usar una técnica o la otra.
Proteger los comentarios de WordPress
El sistema de comentarios nativos de WordPress es bastante limitado y, como siempre digo, tiene bastantes carencias porque no se ha actualizado en mucho tiempo.
El problema de los comentarios de WordPress es que son fácilmente detectables por un bot mediante footprint. Esto los convierte en el objetivo de muchos bots spammers.
Podemos proteger los comentarios de muchas formas. Incluso, si sacamos el campo URL de los campos que tienen que rellenar los usuarios, reduciremos el número de spammers porque perderán interés.
La forma más radical de proteger los comentarios de WordPress es implementar un captcha, pero esto puede dañar bastante la experiencia de usuario. El único captcha que no daña la experiencia de usuario es Google Recaptcha V3, porque es invisible.
Por último, podemos usar la técnica honeypot para proteger los comentarios del SPAM. En Raiola Networks tenemos un plugin para WordPress que nos permite aplicar esta técnica anti-spam: https://raiolanetworks.com/blog/anti-spam-wordpress/
Proteger los registros del SPAM
Esta parte es muy fácil de entender y de aplicar.
Si tu sitio web necesita la parte de registro (es decir, tiendas online, redes sociales, foros, etc.) debes proteger los registros con listas negras.
Si tienes un blog normal o una web corporativa donde no necesitas los registros de usuario, debes desactivarlos desde los “Ajustes” de WordPress:
De este modo, nadie podrá registrarse en nuestro sitio web y no tendremos problemas por esto. Sin embargo, los sitios que no tienen registro de usuarios sí suelen tener comentarios y formularios de contacto que sí habrá que proteger del SPAM.
Proteger comunidades y foros
Cuando trabajamos con comunidades BuddyPress o similares y en foros con WordPress como bbPress o wpForo, es necesario cubrir todos los frentes por donde pueda entrar spam.
El problema de los sitios web que permiten registro abierto de usuarios y un lugar donde dejar SPAM, es que son blancos claros para los bots. En base al sistema utilizado, ya identifican patrones para registrarse. Cuando los bots no llegan, empieza el spam manual.
Cuando empieza el SPAM manual, ya no hay nada que hacer con honeypot o captcha. Deberemos recurrir a listas negras y sistemas como CleanTalk.
CleanTalk utiliza bases de datos muy completas para detectar spammers tanto en registros como en contenido. Para webs de contenido actualizado por los usuarios, como foros o comunidades, es de lo más completo que me he encontrado.
Si buscas más información sobre CleanTalk, puedes encontrar el plugin aquí: https://es.wordpress.org/plugins/cleantalk-spam-protect/
Se trata de es un plugin gratuito, pero el servicio es de pago por suscripción, aunque MUY barato.
Proteger formularios en WordPress
Para proteger los formularios de contacto, yo suelo recomendar Honeypot o Google Recaptcha V3 (invisible).
La forma de implementar esto depende totalmente del plugin con el que implementemos el formulario de contacto. Voy a ir por partes dándote algunos casos con los que yo estoy acostumbrado a trabajar.
- Gravity Forms trae su propio módulo para implementar protección honeypot, aunque también se puede complementar con Google Recaptcha V3 utilizando este plugin: https://es.wordpress.org/plugins/cleantalk-spam-protect/
- Contact Form 7 debe ser protegido mediante plugins. Podemos protegerlo con Honeypot (https://wordpress.org/plugins/contact-form-7-honeypot/) o con Google Recaptcha (https://wordpress.org/plugins/advanced-nocaptcha-recaptcha/).
- Los formularios de Elementor Pro traen honeypot desde hace unas cuantas versiones y simplemente debemos activarlo. Lo mismo sucede con Google Recaptcha V3.
En otros plugins de formulario de contacto, la implementación depende del caso.
Otros tweaks para proteger WordPress
Aunque lo que hemos explicado en este post son áreas o puntos débiles de WordPress a los que debemos prestar atención, existen otras partes más específicas del CMS que podemos modificar con tweaks para proteger nuestro sitio web.
Bloquear el XMLRPC.PHP
Ahora este tipo de ataques han bajado bastante, pero hace unos años aparecieron una serie de problemas en WordPress que hicieron que este tipo de ataques se masificaran.
El ataque contra el XMLRPC.PHP era un ataque por fuerza bruta que no era bloqueado por la mayoría de WAF y que causaba un sobreuso de recursos importante en el servidor.
Con plugins como Perfmatters podemos desactivarlo, aunque también existen plugins como Manage XML-RPC que nos permiten modificar su funcionamiento: https://wordpress.org/plugins/manage-xml-rpc/
Permiso de archivos y carpetas
Aunque esto por sí solo no basta para proteger una instalación WordPress, es muy importante tener todo cubierto.
WordPress, en su documentación, especifica unos permisos CHMOD para ponerles a los archivos y carpetas de la instalación. Esta configuración recomendada es la que debemos poner: 755 para las carpetas de la instalación y 644 para los archivos.
Si queremos ir un poco más allá, podemos utilizar en el wp-config.php este parámetro que bloquea la edición de archivos, aunque debemos tener en cuenta que no podremos ni actualizar plugins:
define( 'DISALLOW_FILE_MODS', true );
Esto es útil para blindar la instalación y protegernos de ciertas inyecciones de código, aunque es una técnica bastante molesta para administrar la instalación en el día a día.
Backups o copias de seguridad
Y cuando todo falla… están los backups o copias de seguridad.
Por muchas precauciones que tomemos, existen casos donde la catástrofe está cantada y no podremos hacer nada. Para estos casos, lo que debemos tener son copias de seguridad disponibles.
Actualmente, no existe ninguna excusa para no tener copias de seguridad de un WordPress. Hay muchas maneras de configurarlas de forma automática y con guardado en la nube (Dropbox, Google Drive, Amazon S3, etc.). Podemos hacerlas desde el servidor o desde un plugin para WordPress.
En Raiola Networks, ofrecemos a todos nuestros clientes de plataforma cPanel la herramienta Installatron, que es un autoinstalador de aplicaciones que también permite gestionar configuraciones y backups:
https://www.youtube.com/watch?v=wNJlhLhP-VY
Como ves, con Installatron no solo puedes crear backups programados y subirlos a la nube automáticamente, sino que también puedes restaurarlos con un clic sin tener conocimientos técnicos.
En los servidores de hosting cPanel de Raiola, incluso tenemos otro sistema de backups también potente llamado JetBackup, que crea copias incrementales del contenido y permite restaurar archivos individuales.
En el caso de VestaCP, también dispone de una herramienta de backups para las cuentas que puedes crear y restaurar con un clic (además de las programadas, claro). Sin embargo, este es un sistema mucho menos completo:
Si tu servidor o hosting no dispone de un sistema de backups potente, si directamente no tiene ninguno o si quieres ir por libre y tener tus propias copias de seguridad, puedes usar un plugin para WordPress. Existen muchos complementos para hacer copias de seguridad en WordPress, pero mis favoritos son BackWPup y Updraft Plus.
- BackWPup en su versión gratuita ofrece copias de seguridad programadas a Dropbox.
- Updraft Plus en su versión gratuita ofrece copias de seguridad programadas a Google Drive.
¿Ves la diferencia de ambos plugins en su versión gratuita? Si los comparamos con sus versiones de pago, son plugins más o menos similares y con funcionalidades parecidas.
El problema de este tipo de plugins para WordPress es que no podemos restaurar copias con un clic, sino que para recuperarlas debemos subir los archivos al servidor como si estuviésemos haciendo una migración.
Existen soluciones que permiten la restauración en un clic, pero suelen ser de pago por suscripción o por uso que guardan los archivos del backup en sus propios servidores.
Otro punto es que es recomendable probar de vez en cuando las copias de seguridad guardadas para evitar encontrarnos con copias corruptas si alguna vez las necesitamos para restaurar la web.
Por último hay que recordar que las copias de seguridad, en caso de infección, pueden ser inútiles. Si hace tiempo que te han infectado la web y esto no se ha manifestado, puedes no tener backups tan antiguos o no poder restaurarlos para no perder contenido. Si esto sucede, lo que hay que hacer es desinfectar.
Desinfección de WordPress
Como ya dije al principio del post, en Raiola Networks llevamos varios años desinfectado instalaciones WordPress con una tasa de éxito del 100% siempre y cuando el cliente nos haga caso y tome las medidas oportunas tras la infección.
En nuestro proceso de desinfección, sustituimos TODOS los archivos de WordPress sin excepciones por los originales equivalentes. Cuando digo sin excepciones, es SIN EXCEPCIONES. No puede quedar ningún archivo de la instalación infectada. Si algún archivo no se puede sustituir (por ejemplo, el wp-config.php), tendremos que revisarlo manualmente.
Para revisar la instalación tras la desinfección podemos utilizar plugins como Anti-Malware and Brute Force Firewall o incluso el escáner de WordFence Security.
También es recomendable revisar la base de datos, ya que algunos tipos de infecciones pueden causar inyecciones de malware en la base de datos de WordPress.
Si estás interesado en desinfectar un WordPress, puedes contactar con nosotros desde esta página: https://raiolanetworks.com/contacto/
Deja una respuesta
Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *