FRODO Security Watchdog | Seguridad para Servidores Linux
En Estudio Ideas administramos la infraestructura de hosting de más de 300 sitios WordPress, todos corriendo sobre nuestro propio servidor, Frodo. Con esa escala, una pregunta se volvió inevitable: ¿cómo detectamos una amenaza en un sitio comprometido antes de que se convierta en un problema para el cliente — y cómo lo hacemos sin arriesgarnos a borrar algo que no debíamos?
La respuesta fue desarrollar nuestra propia herramienta interna: FRODO Security Watchdog.
El problema con los escáneres de malware tradicionales
La mayoría de las herramientas de seguridad para WordPress hacen una de dos cosas: alertan y dejan que un humano decida, o actúan automáticamente y —en el peor de los casos— eliminan archivos. La segunda opción es rápida, pero también es la más peligrosa: un falso positivo puede borrar un plugin legítimo, un archivo de configuración crítico, o evidencia que después se necesita para entender qué pasó realmente.
Nosotros elegimos un camino distinto.
La regla de oro: nunca se elimina nada
FRODO Security Watchdog está construido sobre un principio no negociable: ningún archivo se borra jamás, bajo ninguna circunstancia. Cuando el sistema detecta una amenaza crítica —una webshell conocida, código malicioso ofuscado, un backdoor— no la elimina. La mueve a una zona de cuarentena aislada, pero antes:
- Calcula su huella digital (SHA256) para verificar que la copia es idéntica al original.
- Recién con esa copia verificada, retira el archivo del sitio activo.
- Genera un registro completo: fecha, hora, cuenta, dominio, ruta original y motivo de la detección.
Si alguna vez se tratara de un falso positivo, restaurar el archivo es trivial — todo queda trazado y disponible.
Un motor de riesgo, no un interruptor de todo-o-nada
No todos los hallazgos son iguales. Un archivo PHP suelto en una carpeta de subidas no es lo mismo que un eval() con código ofuscado en Base64. FRODO Security Watchdog asigna un puntaje a cada hallazgo y los clasifica:
| Nivel | Rango |
|---|---|
| 🟢 Verde | 0–20 |
| 🟡 Amarillo | 21–50 |
| 🟠 Naranjo | 51–80 |
| 🔴 Rojo (crítico) | 81+ |
Solo los hallazgos individuales que alcanzan el nivel crítico activan una acción automática de cuarentena. Todo lo demás queda documentado para revisión humana — evitando que el sistema «sobrerreaccione» ante señales de bajo riesgo.
Expedientes forenses, no solo un log
Cuando una amenaza real es detectada y puesta en cuarentena, el sistema genera automáticamente un expediente de caso con un ID único (FSW-2026-000124, por ejemplo): hash SHA256 y MD5 del archivo, permisos, propietario, la firma que lo detectó, el nivel de riesgo y una línea de tiempo completa. Ese documento puede adjuntarse directamente a un informe de auditoría o de respuesta a un incidente — la clase de evidencia que un cliente necesita cuando pregunta «¿qué pasó exactamente y cuándo?».
Pensado para escala real, no para una demo
Un detalle que no suele contarse: la primera versión de nuestro motor de detección, al probarla contra un catálogo simulado de 300 cuentas con decenas de miles de archivos, tardaba tanto que ni siquiera terminaba en un tiempo razonable. El cuello de botella era técnico y sutil (miles de procesos externos lanzándose innecesariamente), y lo resolvimos hasta lograr que una corrida completa sobre esa misma escala tome minutos, no horas. Ese tipo de trabajo de optimización no se ve, pero es lo que diferencia una herramienta que funciona en el papel de una que funciona en producción, todos los días, dos veces al día.
Diseñado para convivir con el resto de nuestra seguridad
FRODO Security Watchdog no reemplaza el resto de nuestra infraestructura de seguridad — la complementa. Trabaja junto a Cloudflare, BitNinja y CSF/LFD, respeta una whitelist configurable para no interferir con integraciones legítimas de cada cliente, y corre con prioridad baja de CPU y disco para no afectar el rendimiento de los sitios activos mientras escanea.
Lo que esto significa para nuestros clientes
En la práctica: dos veces al día, cada sitio bajo nuestra administración es revisado en busca de webshells, cambios sospechosos en archivos core de WordPress, usuarios administradores nuevos no autorizados, plugins con vulnerabilidades históricas conocidas, y más de una decena de otras señales de compromiso — todo sin intervención manual, y sin el riesgo de que una automatización agresiva termine causando más daño que la amenaza misma.
Es la clase de trabajo de infraestructura que normalmente no se ve, pero que hace la diferencia cuando algo sí pasa.
¿Quieres saber más sobre cómo protegemos los sitios que administramos, o necesitas ayuda con la seguridad del tuyo? Conversemos.