Seguridad y arquitectura

• El sensor se ejecuta en su alojamiento, desde el programador de tareas, fuera de la carpeta pública. No tiene reglas propias. Recoge huellas y las envía.
• El servidor central tiene las reglas, compara cada informe con el último estado limpio y decide. La lista de archivos vigilados se define aquí, no en el sensor.
• Las copias limpias de sus archivos críticos se guardan en nuestra infraestructura, no en su alojamiento. Quien entre en su cuenta de alojamiento no puede sustituirlas.

• Se ejecuta con su propio usuario de alojamiento. No necesita acceso root ni instala nada en el servidor.
• Lee archivos de código y, de la base de datos, solo los registros de administradores, los ajustes de pago y unos pocos ajustes de la plataforma, como la dirección del sitio y la lista de extensiones.
• Escribe en un único caso: cuando el servidor central ordena restaurar un archivo de pago.
• Nunca borra un archivo. Antes de sustituir uno, guarda la versión sustituida en una carpeta privada.

• Se envían: huellas de archivos, el contenido de los archivos de código críticos que han cambiado, los nombres de usuario de los administradores y las huellas (no los valores) de los correos y contraseñas de los administradores y de los ajustes de pago.
• No se envían nunca: pedidos, clientes, números de tarjeta ni ninguna página que vean sus visitantes.
• Cada mensaje va firmado en ambos sentidos y lleva una marca de tiempo y un número de un solo uso, de modo que no puede alterarse ni repetirse.

La decisión la toman reglas fijas, no una IA. Así, los mismos hechos dan siempre la misma decisión y cada una puede explicarse. Deben cumplirse todas estas condiciones:

• el archivo es un archivo de pago o de checkout,
• el cambio añade un destino de pago que no reconocemos,
• no hay en curso una actualización de la plataforma ni de esa extensión,
• existe una copia limpia verificada.

Cualquier otro cambio se comunica y espera su aprobación. No se deshace.

Antes de escribir, el sensor comprueba que el archivo en disco sigue siendo exactamente el que se analizó, que no es un enlace a otro lugar y que está dentro de su sitio. La escritura se hace en un solo paso, para que no pueda quedar un archivo a medio escribir. Después, el sensor confirma el resultado al servidor central.

La versión modificada se conserva como prueba. Si el cambio era suyo, lo vuelve a colocar desde su panel con un botón. Cada restauración automática va acompañada de un registro de la decisión: la regla, el archivo, el destino, si había una actualización en curso y las huellas de antes y de después.

Pruebas controladas en tiendas de pruebas, versión 1.12:

• Tiempo desde la manipulación hasta la restauración, con revisión cada minuto. Cambiamos la dirección de pago en un archivo de pago 8 veces, en momentos aleatorios dentro del minuto. Las 8 veces se encontró el cambio y se volvió a colocar el archivo limpio en la revisión inmediatamente siguiente: entre 8 y 57 segundos después de la manipulación, 33 de media. Una vez que empieza la revisión, la detección y la restauración tardan menos de un segundo, así que la espera la marca el intervalo de su plan.
• 100 cambios controlados de seis tipos, en tiendas de pruebas OpenCart y WooCommerce. Los 100 se encontraron y se volvió a colocar el archivo limpio. En la misma tanda hicimos 100 cambios normales de desarrollador: ninguno se deshizo y ninguno hizo saltar una alarma.
• El archivo vuelve a cambiar entre el análisis y la restauración. La restauración no se aplicó, la versión más reciente quedó en su sitio y se revisó en la siguiente pasada.
• El archivo se sustituye por un enlace (symlink) antes de la restauración. El sensor se negó a escribir y se envió una alerta crítica.
• El mismo mensaje se envía dos veces, o se altera por el camino. El segundo se rechazó por repetido, el alterado por firma no válida.
• El servidor central no está disponible. El sensor no cambió nada en el sitio. Cuando el servidor volvió, se encontró el cambio hecho entretanto y se restauró el archivo. Mientras el servidor no responde, no hay revisiones.
• Una contraseña del panel robada. Se pudo iniciar sesión, pero no aprobar un cambio: hace falta el código que se envía al correo del propietario. Seis códigos al azar fallaron y se avisó al propietario.
• Anulación de una restauración desde el panel. Con el código recibido por correo, el cambio volvió a colocarse en la siguiente revisión.
• Se modifica el archivo del propio sensor, o de repente informa de muchos menos archivos. Alerta crítica en la siguiente revisión.
• En la página pública aparecen un script de un dominio parecido a uno auténtico y un formulario que envía datos a otro sitio. La revisión externa generó una alerta crítica.
• Son nuestras propias pruebas controladas en tiendas de pruebas, en la misma máquina que el servidor central. No son una auditoría independiente, y una instalación real añade el retardo de la red.

• Los informes y las aprobaciones solo están disponibles tras iniciar sesión. No hay enlaces de informe abiertos.
• Las contraseñas se guardan cifradas con hash. Tras cinco intentos fallidos, la cuenta se bloquea durante quince minutos.
• Aprobar un cambio o deshacer una restauración requiere además un código que se envía en ese momento a su correo. Una contraseña del panel robada no basta.
• Cada aprobación y cada anulación queda registrada con el usuario y la dirección desde la que se hizo, y se envía por correo al propietario y a nuestro equipo.

Cada seis horas nuestro servidor abre además sus páginas públicas como lo haría un visitante y compara los dominios externos que cargan con la vez anterior. Un script nuevo de un dominio parecido a uno auténtico o de un servicio abierto de alojamiento de código, o un formulario que empieza a enviar datos a otro sitio, genera una alerta. Esta revisión no depende del sensor.

• El historial de eventos se conserva 90 días.
• Las copias limpias se conservan mientras la suscripción esté activa y se eliminan cuando termina.

• HachiGuard no sustituye a un cortafuegos, a un antivirus ni a un escaneo PCI. Es la capa que detecta y deshace un cambio después de que alguien haya entrado.
• Un script que su checkout carga desde el servidor de un tercero puede modificarse en ese servidor sin que cambie ningún archivo suyo. Detectamos un dominio externo nuevo, pero no un cambio dentro de un script que ya estaba ahí.
• Si toman el control de toda su cuenta de alojamiento, no se puede confiar plenamente en un sensor que se ejecuta dentro de ella. Por eso las copias limpias, las reglas y las decisiones están fuera, y por eso un sensor callado o alterado hace saltar la alarma.
• Los archivos codificados no pueden leerse. Los seguimos por su huella e informamos de cada cambio, pero no los restauramos automáticamente.
• La primera revisión toma el estado actual como limpio. Revise sus administradores y sus direcciones de pago antes de que se ejecute.
• La detección se produce con el intervalo de su plan. Un cambio hecho justo después de una revisión se ve en la siguiente.