Seguridad de WordPress sin un plugin

El problema con la seguridad basada en plugins

Un plugin de seguridad de WordPress se ejecuta dentro de WordPress — usando el propio proceso PHP del sitio, su propia conexión de base de datos, su propio acceso a archivos. Eso no es exactamente un defecto, es simplemente cómo funcionan los plugins. Pero significa que la herramienta que vigila tu sitio comparte exactamente la misma superficie de ataque que el sitio mismo. Si WordPress alguna vez se compromete a un nivel lo suficientemente profundo como para importar, el plugin que lo protege queda comprometido junto con él.

Hay un segundo costo, más silencioso: cada plugin es más código que debe mantenerse actualizado, más superficie para una futura vulnerabilidad, y a menudo otra credencial de nivel admin almacenada en algún lugar de la pila. Las herramientas de seguridad se supone que reducen tu riesgo, no que se sumen al montón de cosas que pueden salir mal.

Qué significa realmente la seguridad «de afuera hacia adentro»

Cualquier cosa que un plugin pueda leer — archivos core de WordPress, archivos de tema y plugin, el directorio de subidas, la base de datos — también es accesible de una manera completamente diferente: mediante SSH, usando una clave dedicada limitada a ese propósito. La herramienta nunca toca tu inicio de sesión de administrador de WordPress, nunca se ejecuta como un usuario de WordPress, y nunca se convierte en parte de la aplicación que está revisando.

Concretamente, eso significa:

• Las verificaciones de integridad de archivos core se ejecutan comparando los archivos reales de WordPress con sumas de verificación conocidas como buenas — hecho desde una sesión de shell, no un hook PHP dentro de WordPress.
• El análisis de malware y puertas traseras lee directamente los directorios de tema, plugin y subidas desde el disco, de la misma manera que lo haría un investigador humano mediante SSH.
• Las verificaciones de base de datos se conectan usando credenciales leídas desde wp-config.php, sin involucrar la propia capa de consultas de WordPress ni ninguno de sus hooks de plugins.
• Las correcciones — cuando son seguras y reversibles — se aplican de la misma manera: directamente al sistema de archivos o base de datos, nunca activando código dentro de un proceso de WordPress en ejecución.

Por qué SSH en lugar de un inicio de sesión de WordPress

Una clave SSH puede generarse específicamente para un propósito, importarse al administrador de claves de una cuenta de hosting, y revocarse en cualquier momento sin tocar nada más de la cuenta — mira exactamente cómo en nuestra guía de instalación. Esa es una huella fundamentalmente más pequeña que un plugin que mantiene una sesión de admin permanente dentro de WordPress mismo. También significa que la herramienta de seguridad sigue funcionando incluso si el propio sistema de inicio de sesión de WordPress es lo que está comprometido.

Lo que este enfoque no puede hacer

Siendo honestos sobre la compensación: las herramientas de afuera hacia adentro necesitan acceso SSH, que la mayoría de los hosts proporcionan pero algunos restringen o deshabilitan por defecto. Y no pueden engancharse al propio runtime de WordPress como lo haría un plugin — así que no es el ajuste correcto para cosas como el filtrado de solicitudes en tiempo real, que es para lo que realmente sirve un firewall a nivel DNS. El análisis de afuera hacia adentro y un firewall de borde resuelven problemas diferentes, y muchos sitios se benefician usando ambos.