Wazuh 4.14 en cámaras: archivos, agentes y evidencia
Mini-caso de cámara empresaria en Cuyo: Wazuh registra cambios de archivos, agentes, vulnerabilidades y alertas con prueba de lectura y salida documental.
Antes, la cámara empresaria guardaba actas y padrones en una carpeta compartida; después, cada cambio sensible dejó usuario, equipo, hora y alerta. El caso es de una entidad de San Martín, Mendoza, con 1.800 matriculados y equipos Windows mezclados con servidores Linux. Wazuh 4.14 permite armar esa evidencia con agentes, monitoreo de archivos y detección de vulnerabilidades. La nota muestra qué probar antes de confiar en el tablero.
Dónde aparece el archivo modificado de noche
El síntoma llegó con un padrón exportado dos veces y dos totales distintos. El antagonista era una carpeta compartida sin rastro de edición. En la sala de reuniones quedaba una impresora láser con tóner bajo; imprimía actas para firmar, pero no decía quién había cambiado el archivo original. La cifra que ordena la decisión viene del proyecto. La API de GitHub marcó Wazuh v4.14.6 como versión publicada el 3 de julio de 2026. El repositorio wazuh/wazuh tenía 16.222 estrellas y 2.383 forks al 20 de julio. La herramienta ya no es una promesa de laboratorio; tiene comunidad, documentación y releases frecuentes. La escala global aparece en la encuesta 2025 de Stack Overflow: entre 34.188 respuestas, las preocupaciones de seguridad o privacidad quedaron primeras como motivo para rechazar una tecnología en proyectos laborales. La cámara no necesitaba más carpetas; necesitaba evidencia legible cuando un archivo cambiaba. Un archivo de padrón tiene valor cuando se puede explicar su última modificación.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, IT instala un agente Wazuh en servidor de archivos, equipos administrativos y servidor de aplicaciones. Segundo, el agente toma configuración del manager y reporta eventos. Tercero, el módulo FIM calcula una línea base de archivos monitoreados, guarda checksum y atributos, y dispara alerta cuando alguien crea, modifica o borra, según la documentación de File Integrity Monitoring. Cuarto, el manager recibe eventos, aplica reglas y los deja disponibles para consulta. Quinto, el tablero muestra agente, ruta, usuario, hora, acción, severidad y detalle. Sexto, una prueba de restauración o salida exporta alertas de un período y reconstruye qué archivo cambió, desde qué equipo y con qué usuario. El agente recibe reglas, monitorea archivos y envía eventos. El manager recibe eventos, reglas y estado de agentes; entrega alertas y métricas. El módulo de vulnerabilidades detecta paquetes o aplicaciones con fallas conocidas, según Vulnerability Detection. PostgreSQL puede guardar inventario complementario si la cámara integra altas, bajas y responsables fuera de Wazuh.
Qué se instala o configura primero
La pila inicial puede ser Wazuh all-in-one para piloto, agentes en cinco equipos, grupos por rol, FIM sobre carpetas críticas, retención de alertas, backup del manager y exportación mensual. La guía Quickstart permite instalar componentes en un servidor. La documentación de Wazuh agent cubre el alta y la administración de endpoints. El costo de infraestructura puede ubicarse entre USD 40 y USD 110 mensuales, entre ARS 60.000 y ARS 165.000 al dólar oficial de venta de ARS 1.500. Ese rango cubre servidor, almacenamiento, monitoreo, backup y margen de retención. Relevamiento de carpetas, limpieza de permisos y política de respuesta quedan como horas de proyecto. El primer entregable verificable es un piloto con tres rutas: padrones, actas y comprobantes. UMSA puede ayudar a configurar agentes, reglas y reporte de salida cuando la cámara necesita responder quién cambió un archivo y qué evidencia queda después de un cierre administrativo. La segunda entrega agrega una regla de revisión semanal. Tesorería recibe un PDF con agentes activos, alertas cerradas, rutas monitoreadas y eventos sin dueño. IT conserva el archivo fuente para repetir la consulta.
Dónde se rompe y cómo probarlo
El primer riesgo aparece por exceso de alertas. La señal es un tablero lleno de temporales, antivirus y archivos de sistema. La prueba es activar FIM en una ruta chica, revisar diez alertas y ajustar exclusiones hasta que cada evento tenga dueño operativo. El segundo riesgo aparece con agentes caídos. La señal es un equipo sin eventos durante días hábiles. La prueba es apagar un agente de ensayo y confirmar que el manager emite alerta de desconexión con hora y equipo. El tercer riesgo aparece cuando la evidencia no sale del sistema. La señal es una alerta visible en pantalla que nadie puede adjuntar a un acta. La prueba es exportar un período, abrir el archivo en otra máquina y cruzarlo con el cambio de padrón simulado. El cuarto riesgo aparece en rutas sensibles sin dueño. La señal es una carpeta monitoreada que nadie revisa. La prueba es asignar responsable por ruta y exigir una firma digital simple en el reporte mensual. El sistema sirve si el tesorero puede responder una pregunta incómoda: qué archivo cambió, quién lo tocó y qué prueba queda cuando termina la reunión.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.