Introducción al Problema#
Los atacantes no aparecen y causan daño instantáneamente. En la gran mayoría de los casos, hay un período de reconocimiento silencioso: exploración de la red, intentos de escalada de privilegios, movimiento lateral. El tiempo promedio entre la primera intrusión y la detección en empresas pequeñas y medianas es de más de 200 días.
Durante esos 200 días, el atacante deja rastros. Intentos de login fallidos. Consultas a recursos inusuales. Accesos en horarios extraños. Transferencias de datos masivas. Cambios de configuración. Cada una de esas acciones genera un evento — un log — en algún sistema de la infraestructura.
El problema es que esos logs, en la mayoría de las empresas, o no existen, o nadie los mira, o se borran antes de que alguien tenga oportunidad de analizarlos. Sin monitoreo de logs, el atacante opera en completa oscuridad. Con monitoreo de logs, cada movimiento puede convertirse en una alerta.
Caso Real o Ejemplo Cotidiano#
Una distribuidora con 45 empleados fue víctima de un ataque de ransomware en un martes a las 3 AM. Al llegar el personal el miércoles, encontraron todos los archivos cifrados con extensión .locked y un mensaje de rescate en la pantalla.
El perito forense contratado para la investigación post-incidente se encontró con la misma situación que en el 70% de los casos similares: los logs del servidor de archivos habían sido sobreescritos (la configuración del sistema mantenía solo 3 días), los logs del firewall nunca habían sido activados, y el único sistema con logs era el antivirus, que había registrado la detección del ransomware en el momento del cifrado — demasiado tarde.
Sin logs del período anterior, fue imposible determinar: cómo ingresaron (phishing, RDP expuesto, proveedor comprometido), desde cuándo tenían acceso, qué datos exfiltraron antes de cifrar, si todavía había acceso activo en otros sistemas.
La empresa tuvo que pagar el rescate porque los backups también estaban cifrados — el atacante los había encontrado en los logs del servidor de archivos que todavía existían. Si hubieran tenido centralización de logs en un servidor separado, el atacante no habría sabido dónde estaban los backups.
Riesgos para la Empresa#
| Deficiencia en logs | Consecuencia concreta |
|---|---|
| Sin logs activos en servidores críticos | Sin evidencia forense cuando hay un incidente |
| Retención de logs de solo días o semanas | El atacante que lleva meses adentro no tiene rastros visibles |
| Logs guardados en el mismo servidor que auditan | Si el servidor es comprometido, el atacante puede borrar su rastro |
| Sin centralización de logs | Correlacionar eventos entre múltiples sistemas es imposible manualmente |
| Sin alertas automáticas | El incidente se detecta cuando ya causó daño visible, no antes |
| Logs sin sellos de tiempo verificables | Inadmisibles como evidencia en procesos legales |
Explicación Técnica Sencilla#
Los logs son el diario de actividad de los sistemas. Cada sistema genera eventos en formato de texto que registran lo que pasó, cuándo, y quién lo hizo.
¿Qué logs recolectar?
No todos los logs tienen el mismo valor de seguridad. Una estrategia práctica prioriza:
| Fuente | Qué registrar |
|---|---|
| Controlador de dominio (AD) | Inicios de sesión exitosos y fallidos, cambios de grupos privilegiados, creación de cuentas |
| Servidores de aplicaciones | Errores de autenticación, accesos a funcionalidades sensibles |
| Firewall/router | Conexiones bloqueadas, tráfico saliente inusual, nuevas reglas creadas |
| Base de datos | Autenticaciones, queries a tablas con datos sensibles, DDL (CREATE/DROP) |
| Equipos de trabajo | Ejecución de software inusual, conexiones de red a IPs desconocidas |
| VPN | Conexiones por usuario: IP de origen, horario, duración |
syslog/rsyslog — el protocolo estándar de centralización:
La mayoría de los sistemas Linux y muchos appliances de red soportan syslog: un protocolo simple que envía los eventos a un servidor central en tiempo real. Configurar un servidor rsyslog central es el primer paso de una arquitectura de logs corporativa, y prácticamente no tiene costo.
Equipos → rsyslog → Servidor central de logs
↑ cada evento se envía en tiempo real
↑ el atacante que compromete un equipo
↑ no puede borrar los logs que ya fueron enviadosSIEM — detección automatizada de patrones:
Un SIEM (Security Information and Event Management) es un sistema que centraliza los logs de múltiples fuentes, los correlaciona, y genera alertas automáticas cuando detecta patrones que indican un ataque. La diferencia entre logs centralizados y un SIEM es que el SIEM tiene reglas que dicen "si hay 10 intentos de login fallidos en 2 minutos desde la misma IP, alertar" — sin que nadie tenga que revisar manualmente.
Cómo Prevenirlo#
-
Definir qué eventos son relevantes para la seguridad y activar su logging: No todos los logs de todas las aplicaciones — eso genera ruido inmanejable. Activar logging para: autenticaciones (éxito y fallo), cambios de configuración, acceso a recursos sensibles, ejecución de procesos administrativos, y cambios en permisos.
-
Centralizar los logs en un servidor separado inmediatamente: Los logs del servidor A deben vivir también fuera del servidor A. Configurar rsyslog (Linux) o Windows Event Forwarding (Windows) para enviar eventos a un servidor de logs dedicado. Este servidor debe estar en una VLAN separada con acceso restringido — el atacante que compromete un servidor no debe poder alcanzar el servidor de logs.
-
Establecer retención adecuada según el riesgo y la normativa: El RGPD y la Ley 25.326 argentina no especifican retención de logs, pero las mejores prácticas de seguridad (y el sentido común forense) indican mínimo 90 días activos y 1 año en almacenamiento frío. Para entornos regulados (salud, finanzas), los requerimientos pueden ser mayores.
-
Configurar alertas automáticas para patrones de ataque conocidos: Empezar con los más obvios: N intentos de login fallidos seguidos de uno exitoso (credenciales comprometidas), login en horario nocturno para usuarios que normalmente trabajan de día, acceso desde una IP nunca vista antes, descarga masiva de archivos, creación de nuevos usuarios administradores.
-
Implementar un SIEM liviano para correlación: Wazuh, Graylog, o una instancia básica del ELK Stack (Elasticsearch + Logstash + Kibana) pueden correr en un servidor con 8 GB de RAM y centralizar los logs de una red PyME con correlación básica de eventos. El costo es operativo (configuración), no de licencias.
-
Revisar los logs periódicamente — no solo en incidentes: Asignar una revisión semanal de logs en el equipo de IT, aunque sea de 30 minutos. Revisar: los 10 intentos de autenticación fallida más frecuentes, los usuarios que accedieron fuera de horario habitual, y cualquier alerta generada por el SIEM. El objetivo es familiarizarse con el "ruido normal" para poder detectar lo inusual.
Herramientas Recomendadas#
Wazuh (wazuh.com): El SIEM open source más completo del mercado gratuito. Incluye detección de intrusiones (HIDS), análisis de logs, detección de vulnerabilidades, monitoreo de integridad de archivos, y análisis de cumplimiento normativo (PCI DSS, HIPAA, GDPR). Se instala en un servidor central y los agentes Wazuh en cada equipo envían eventos. Para una PyME con hasta 50 equipos, corre perfectamente en una VM con 8 GB de RAM. Es la primera opción a considerar para un SIEM gratuito.
Graylog Community (graylog.org): Plataforma de centralización y análisis de logs con una interfaz web muy accesible. La versión Community es gratuita para hasta 5 GB/día de logs. Interfaz de búsqueda potente, dashboards configurables, y sistema de alertas basado en condiciones. Más orientado a análisis de logs que a SIEM puro, pero ideal como primer paso hacia la centralización.
ELK Stack — Elasticsearch + Logstash + Kibana (elastic.co): La combinación más potente y flexible para análisis de logs. Elasticsearch almacena y permite búsqueda full-text sobre millones de eventos. Logstash normaliza y transforma los logs de distintas fuentes. Kibana provee dashboards visuales y exploración de datos. Tiene curva de configuración más pronunciada que Wazuh o Graylog, pero es el estándar en organizaciones con volúmenes de logs altos.
Windows Event Viewer + Event Forwarding: Para redes exclusivamente Windows, el sistema nativo de eventos de Windows con Windows Event Forwarding permite centralizar todos los eventos del dominio en un servidor de recolección sin software adicional. No tiene capacidades de correlación automática, pero es el punto de partida para entender qué events IDs son relevantes para la seguridad en entornos Windows (4625 = login fallido, 4720 = creación de usuario, 4672 = privilegios especiales asignados).
Checklist Final#
- Los logs de autenticación están activos en todos los servidores y sistemas críticos
- Los logs se centralizan en un servidor separado en tiempo real (rsyslog/WEF)
- El servidor de logs está en una VLAN separada con acceso restringido
- La retención de logs es de mínimo 90 días activos
- Hay alertas configuradas para intentos de login masivos (brute force)
- Hay alertas para inicios de sesión en horario inusual
- Hay alertas para creación de nuevos usuarios con privilegios elevados
- Los logs del firewall están activos y centralizados
- Los logs de la VPN están activos y centralizados
- Se realiza una revisión periódica de logs (al menos semanal)
- Los backups están en una ubicación no visible/accesible desde los sistemas que protegen
- Hay un procedimiento documentado de respuesta ante una alerta de seguridad
CVE / Vulnerabilidades Relacionadas#
El monitoreo de logs no está directamente asociado a CVEs específicos, sino a CWE-778 — Insufficient Logging y CWE-223 — Omission of Security-relevant Information, debilidades de diseño que la comunidad de seguridad reconoce como causas raíz de incidentes donde los atacantes operan durante meses sin detección.
MITRE ATT&CK T1562.002 — Disable Windows Event Logging: Una técnica documentada de atacantes activos es deshabilitar el logging de Windows como primera acción tras comprometer un sistema — precisamente porque saben que los logs son lo que los va a delatar. Si los logs se centralizan en tiempo real en un servidor externo, esta técnica pierde efectividad: los eventos anteriores al disable ya fueron enviados y están fuera del alcance del atacante.
El patrón es consistente: los incidentes que quedan sin resolver son los que no tienen logs. Los que tienen logs centralizados con retención adecuada pueden reconstruirse, atribuirse, y servir de base para mejoras. Los logs no previenen el ataque — reducen dramáticamente el tiempo de detección y el impacto.
Conclusión y CTA#
El monitoreo de logs no es una herramienta de prevención — es una herramienta de detección temprana y respuesta. Su valor no se mide en ataques bloqueados sino en: ¿cuándo detectamos que algo raro estaba pasando? ¿cuántos días antes del daño real?
La diferencia entre detectar una intrusión en el día 1 y detectarla en el día 200 es la diferencia entre un incidente contenido y un desastre con datos de clientes filtrados y backups cifrados.
Wazuh, centralización de logs con rsyslog, y un conjunto básico de alertas pueden implementarse en una PyME en un fin de semana. No es costoso. No es complejo. Y es exactamente lo que separa las empresas que sobreviven un incidente de las que no.
¿Querés implementar monitoreo de logs en tu infraestructura? Contactanos o revisá nuestra guía completa de Respuesta ante incidentes: qué hacer (y qué no) cuando te hackean.