Un clásico de los sitios web que usan un CMS de fondo es la falta de actualización de los mismos. Esto hace que si en un par de meses tu sitio está sin actualizar sea objetivo de cualquier ataque, ya que todos los problemas que puedan haber, estarán.
Si a esta preocupación personal le sumamos que en verano suelo hacer “cositas por entretenerme”, salen proyectos como WPdanger, un sitio web en el que pones la dirección de tu sitio en WordPress y te da algunas vulnerabilidades o te puede servir para encontrar problemas que puedas tener y que todos pueden verificar.
Al principio comencé usando WPscan para hacer algunas pruebas, pero aunque en particular funcionaba, a lo grande ya no era tan simple. Así que monté un primer sistema que mostraba los resultados por pantalla web, posteriormente comené a procesarlos y al final ha salido una web en la que analiza más de lo que hacía al principio (que era puramente reactivo) a algo un poco más decente y que da más datos, además de mostrar enlaces a todos aquellos problemas que pueden aparecer.
Pero esto era poco… si cualquiera tiene acceso a este tipo de herramientas ¿cómo evitar que los datos que aparecen sean útiles para prevenir ataques? Obviamente la primera fase era evitar enseñar lo que no se tiene que enseñar, es decir, que la herramienta crea que lo que realmente hay no esté. Así, si un hacker usa estas herramientas, y ve que aparentemente no hay mucho que hacer en el sitio, pase de él. Esto me ha llevado durante algunos días a hacer y hacer análisis hasta poder ir bloqueando aquellos elementos que bloqueasen ataques pero hiciesen que la web siguiera funcionando. Tras varias horas revisando y analizando y probando con mi sitio, llegué a varias conclusiones.
La primera de ellas es que WordPress funciona mejor con nginx que con Apache HTTPD. En principio debería dar igual, pero a la hora de configurar elementos ys eguridad, ya no tanto. Entre uno y otro, me quedo con nginx. Lo segundo es que hay que montar PHP 7, principalmente por temas de rendimiento. A partir de esta combinación, podemos comenzar a trabajar.
La segunda es que hay plugins (muy utilizados) que no piensan en la seguridad, no permiten desactivar determinados elementos y que ponen en riesgo todo t sitio. El principal que me he encontrado es el Yoast SEO. Me gusta, no me importa que tenga código que ponga que lo usas, pero por favor, no indiquemos la versión, o al menos que la versión sea un eleemnto que se pueda desactivar. Como digo, es el plugin más inseguro (desde ese punto de vista) que he encontrado.
La tercera es que el hecho de que WordPress sea tan estándar y tan sencillo, hace que se puedan detectar versiones de plugins y plantillas de forma extremadamente sencilla (y sobre todo, de forma automática). Obviamente hay que encontrar un mix entre funcionalidad y seguridad. Me ha costado, pero he acabado encontrándolo.
El cuarto es que las configuraciones de seguridad que hay por Internet sobre WordPress se quedan extremadamente cortos. Es obvio que hay que informar, siempre lo primero, en que tu WordPress esté actualizado, obvio ye s así, pero por ejemplo, en todos los manuales se habla del famoso “usuario admin” que desde hace muchísimas versiones ya no viene por defecto. Está bien decir que no se use, pero han pasado años de que sea el mayor problema de seguridad de los usuarios. Lo que más me molesta es que no se explique esto, que es un tema histórico y que una instalación nueva no debería preocuparse en exceso por este asunto.
El quinto es que me ha parecido extraño que los grandes proveedores de hosting especializados en WordPress no den soluciones de seguridad sencillas más avanzadas, sobre todo en la parte preventiva.
Obviamente, no hay sitios 100% seguros, ni pretendo que los haya, pero sí que la prevención de la que siempre se habla en seguridad, se aplique. No tiene sentido decir que tienes un Firewall si luego puedo saber la lista de plugins que tienes instalados, o qué plantillas usas, y mucho menos saber qué versiones son y si están al día o no, incluyendo al núcleo.
¿Qué he aprendido con todo esto? A mejorar la ocultaciónd e información de la manera más simple posible que he encontrado, y principalmente poner difícil a los demás saber qué uso o dejo de usar. Un ejemplo, ahora mismo, es que si lanzo un análisis contra mi sitio, hace unos días me decía qué versión de WordPress tenía (exactamente), toda la lista de plugins, con sus versiones y sabiendo sie staban actualizados o no, y lo mismo con las plantillas… Ahora me dice una versión casi exacta de la que tengo en realidad de WordPress, pero ya no me dice qué plugins o plantilla tengo.
Esto no significa que si te miras un poco el código no se pueda saber, pero el hecho de que “de forma automática nos e sepa” me hace sentir un poco mejor, porque mucha gente que quiera hacer maldades lo tendrá ligeramente más difícil o, como mínimo, tendrá que dedicarle tiempo humano (y no tiempo máquina) para hacer maldades (a alguien que, la verdad, dudo que le aporte o vaya a conseguir nada útil).
Para acabar, tengo escrito un ¿folleto? de 15 páginas sobre seguridad de WordPress en el que explico con pelos y señales cómo solventar prácticamente todos estos problemas. La cuestión es si debería publicarlo por completo o parcialmente y plantear como vía de negocio / modelo de vida (y más ahora que no estoy trabajando en ningún proyecto y he vuelto al autonomismo) y de esa forma, ofreciendo uns ervicio barato, ofrecer la posibilidad de montar WordPress de forma segura a quien no sepa qué hacer con su sitio web. Aún así, como siempre, si alguien necesita ayuda con algo, parcialmente como parte de la comunidad, parcialmente como modelo de vida, estoy aquí para ayudar.
