5 formas prácticas (y muy “de la vida real”) de exprimir el Audit Journal (QAUDJRN) en IBM i
- 7 feb
- 4 Min. de lectura
En Exsystem usamos QAUDJRN como “la caja negra” del sistema: no solo para auditorías de cumplimiento, sino para operación, seguridad, hardening y troubleshooting rápido. Si lo tienes bien configurado, te permite responder en minutos cosas que normalmente se vuelven horas de suposiciones.
Antes de empezar: lo mínimo para que QAUDJRN te sea útil (y no te explote el disco)
1) Confirma si la auditoría está activa
Los valores que mandan son QAUDCTL / QAUDLVL / QAUDLVL2. Revisión rápida:
WRKSYSVAL *SEC
Busca (al menos): QAUDCTL, QAUDLVL, QAUDLVL2, QAUDENDACN.
2) Encendido “rápido y sano” con CHGSECAUD
IBM recomienda CHGSECAUD para activar auditoría: asegura que exista QAUDJRN y configura QAUDCTL(*AUDLVL) y QAUDLVL(*DFTSET) (incluye AUTFAIL, CREATE, DELETE, SECURITY, *SAVRST).
Ejemplo base:
CHGSECAUD QAUDCTL(*AUDLVL) QAUDLVL(*DFTSET)
Si quieres reducir ruido en QTEMP, puedes usar NOQTEMP (debe ir junto con AUDLVL u *OBJAUD).
3) Define qué pasa si falla la auditoría (QAUDENDACN)
Si el sistema no puede escribir entradas de auditoría, QAUDENDACN define la acción: notificar y seguir, o incluso apagar el sistema en entornos donde auditar es obligatorio.
Cómo extraer información del audit journal sin SQL (método “comandos básicos”)
Tienes dos caminos “clásicos”:
Opción A (muy práctica): CPYAUDJRNE desde SECTOOLS
IBM incluye CPYAUDJRNE como herramienta para copiar entradas del QAUDJRN a un archivo de salida por tipo de entrada. Luego lo miras con comandos como DSPPFM o con herramientas de consulta (sin escribir SQL).
Opción B: DSPJRN a OUTFILE en formato *TYPE5 (recomendado)
Para análisis, IBM recomienda OUTFILFMT(TYPE5) (TYPE2/TYPE4 ya no se actualizan).Con TYPE5, además quedan disponibles datos útiles como remote address y remote port en el encabezado.
Ejemplo genérico:
DSPJRN JRN(QAUDJRN) JRNCDE(T) ENTTYP(PW) +
OUTPUT(*OUTFILE) OUTFILFMT(*TYPE5) OUTFILE(MILIB/OUTPW)
Tip 1 — Endurecimiento del IFS: detecta escrituras “raras” en rutas sensibles (CO)
Antes de bajar autoridades en directorios críticos (por ejemplo / o zonas operativas), conviene saber quién crea objetos allí.
Qué mirar: entradas CO (Create Object).
Pasos solo con comandos:
Copia entradas CO a un archivo:
CPYAUDJRNE ENTTYP(CO)
Visualiza el archivo generado (normalmente en QTEMP, según tu salida):
DSPPFM FILE(QTEMP/QAUDITCO)
Qué revisar dentro del registro:
Trabajo (job) y usuario que originó el evento (para diferenciar “proceso del sistema” vs. “usuario final”).
Campos de ruta / nombre si la creación fue en IFS (streamfiles/directorios).
Qué decisión tomar (práctico):
Si ves creaciones en rutas que deberían ser “solo lectura” para *PUBLIC, ajustas autoridades con evidencia y sin romper procesos.
Tip 2 — “¿Quién borró esto?”: rastrea eliminaciones (DO)
Cuando desaparece un objeto (perfil, programa, archivo, streamfile, etc.), lo primero es revisar DO (Deletion of Object).
Pasos:
CPYAUDJRNE ENTTYP(DO)
DSPPFM FILE(QTEMP/QAUDITDO)
Qué te llevas de aquí:
Fecha/hora + job + usuario que ejecutó el borrado (evidencia directa).
Ojo importante: si no aparece el evento, muchas veces no es misterio: o no estabas auditando lo que necesitabas, o tu retención de receptores no cubre ese periodo. IBM insiste en planear la gestión de receptores para no perder historial ni saturar disco.
Tip 3 — Contraseñas “débiles” introducidas por administración: cruza reglas (QPWDRULES) y auditoría (CP)
En IBM i, las reglas de composición de contraseña siempre se aplican cuando el cambio se hace con CHGPWD (y opciones equivalentes).Pero si alguien asigna contraseñas vía CRTUSRPRF/CHGUSRPRF, esas reglas solo se fuerzan si QPWDRULES contiene *ALLCRTCHG.
Revisión de valores (sin SQL):
WRKSYSVAL QPWDRULES
WRKSYSVAL QPWDMINLEN
WRKSYSVAL QPWDRQDDGT
(Estos son parte de los valores de control de passwords).
Auditoría del evento: entradas CP (Change Profile)IBM indica que, cuando una contraseña no cumple reglas en ese escenario, el registro CP lo deja indicado.
Pasos:
CPYAUDJRNE ENTTYP(CP)
DSPPFM FILE(QTEMP/QAUDITCP)
Uso típico Exsystem: detectar prácticas de helpdesk (resets rápidos) que “saltan” políticas, y corregir el proceso con *ALLCRTCHG, procedimientos y control.
Tip 4 — Cuentas de servicio en *DISABLED: identifica si fue cambio manual o política
Cuando una cuenta crítica queda deshabilitada, necesitas saber si alguien la cambió manualmente o si se disparó por intentos fallidos.
Revisa el perfil:
WRKUSRPRF USRPRF(SRVACCT)
Saca evidencia de cambios del perfil con CP:
CPYAUDJRNE ENTTYP(CP)
DSPPFM FILE(QTEMP/QAUDITCP)
Ahí buscas campos de estado/cambio y quién lo ejecutó (usuario/job).
Revisa políticas de intentos:
QMAXSIGN (máximo de intentos)
QMAXSGNACN (acción al alcanzarlo)Estos valores están dentro de los valores de seguridad del sistema.
Tip 5 — Intentos de intrusión o scripts con password viejo: usa PW y el “remote address”
Si sospechas fuerza bruta o un servidor olvidado intentando con contraseña antigua, revisa entradas PW: se generan ante fallos de usuario/contraseña en el sign-on. IBM describe este enfoque como ejemplo de uso de QAUDJRN para detectar intentos.
Pasos:
CPYAUDJRNE ENTTYP(PW)
DSPPFM FILE(QTEMP/QAUDITPW)
Qué dato clave buscar: en salidas modernas (formato *TYPE5), el encabezado incluye remote address y remote port, lo que te ayuda a ubicar el origen.
Bonus de seguridad “rápido” para IFS (antimalware): QSCANFS / QSCANFSCTL
IBM i tiene valores para controlar el escaneo del IFS cuando existen exit programs registrados para escaneo. En particular, IBM recomienda QSCANFS(*ROOTOPNUD) para cubrir /, QOpenSys y file systems definidos por el usuario.Revisión:
WRKSYSVAL QSCANFS
WRKSYSVAL QSCANFSCTL
QAUDJRN es tu mejor herramienta diaria
Si quieres que Exsystem lo deje armado en tu ambiente (y con evidencia lista para auditoría y soporte), contáctanos!
Comentarios