top of page
banner (1845 × 374 px) (6).png

IBM i ENVIAR LOS EVENTOS DE SEGURIDAD VIA SYSLOG A UN SIEM O SERVIDOR SYSLOG!


¿Qué es Syslog?


Syslog es la abreviatura de System Logging Protocol, que significa Protocolo de registro del sistema. Este es un protocolo estándar para enviar mensajes de registro o eventos del sistema a un servidor específico, llamado servidor syslog.


Syslog se usa principalmente para recopilar varios registros de dispositivos para monitorear y analizar desde muchas máquinas diferentes en una ubicación central. La mayoría de los dispositivos de red tienen habilitado este protocolo, como enrutadores, conmutadores, firewalls e incluso algunas impresoras y escáneres. Además, syslog está disponible en sistemas basados ​​en Linux/Unix y muchos servidores web como Apache.


Los sistemas IBM i no tienen Syslog instalado por defecto y utilizan su propio registro de eventos llamado QAUDJRN, aunque es posible reenviarlos a través de herramientas de terceros u otras configuraciones utilizando el protocolo Syslog.


RFC 5424 define el protocolo Syslog, lo que hace que el anterior RFC 3164 quede obsoleto.




COMPONENTES DE SYSLOG

En cualquier dispositivo dado, el sistema genera varios eventos en respuesta a las condiciones cambiantes del sistema. Normalmente, estos eventos se registran localmente para que los administradores puedan verlos y analizarlos. Sin embargo, monitorear grandes volúmenes de registros de una gran cantidad de enrutadores, conmutadores y sistemas sería lento y poco práctico. Syslog le permite resolver este problema reenviando estos eventos a un servidor centralizado.


Los mensajes de syslog normalmente no superan los 1024 bytes de tamaño.


Una supervisión completa de la red requiere del uso de múltiples herramientas. Syslog es un pilar importante en la supervisión de la red porque garantiza que aquellos eventos que no conlleven un resultado dramático no caigan en el olvido. La mejor práctica consiste en utilizar un software que combine todas las herramientas para tener siempre una visión general de lo que sucede en la red ejemplo un SIEM.


QAUDJRN – ¿Pero estás grabando todo en el IBM i?


Recientemente, hemos notado mucho interés en la solución IPSecurity modulo SYSLOG para la plataforma IBM i (AS/400). La solución envía eventos de seguridad desde IBM i a servidores de recopilación de registros y soluciones SIEM en tiempo real.


Podemos comprender lo difícil que es convertir la información de seguridad de IBM i en un formato utilizable para que los eventos puedan recopilarse y monitorearse.


El reto es grande los eventos de seguridad de IBM están en formato interno de IBM en el QAUDJRN y no en formato syslog. Estos están múltiples fuentes ya que los eventos de seguridad se recopilan desde múltiples ubicaciones, a menudo en formatos internos y propietarios de IBM. Ademas la falta de herramientas para recopilar eventos de seguridad en tiempo real aumenta los riesgos de seguridad.


Otro de los puntos a considerar es que no existe una instalación nativa para la comunicación de syslog UDP, TCP o SSL TCP. A lo cual debemos sumar que la integridad de los datos se debe mantener y si bien la información de seguridad se puede imprimir con las herramientas de IBM, falta información crítica en el informe. Este es un buen ejemplo del último punto. Puedo utilizar el mandato Visualizar entrada de diario de auditoría (DSPAUDJRNE) para imprimir un informe de errores de usuario y contraseña y obtendríamos algo como la siguiente pantalla:

¿Puede una solución SIEM o un servidor SYSLOG tratar de obtener información útil de aquí? Estos campos no son fáciles de identificar y extraer, y la mayoría de las herramientas de consulta SIEM tienen dificultades para extraer el significado de este informe.


Y faltaría una de las piezas de información más importantes la cual el QAUDJRN no suministra la dirección IP del autor del error. Una soluciones SIEM puede correlacionar eventos si suministramos en el mensaje enviado en formato SYSLOG de dónde provienen. Las direcciones IP son fundamentales para que esto suceda. El informe puede decirle cuándo fue atacado, pero no la fuente del ataque, y ciertamente no en tiempo real, adicional no se registraran otro tipos de eventos como por ejemplo:

  • Lecturas a sus bases de datos con reglas bien definidas como por ejemplo la consulta a un maestro de cuentas o cliente.

  • Transacciones con Tarjeta de Débito

  • Conexiones via FTP, ODBC, TELNET.

La herramienta IPSecurity de Exsystem para los IBM i convierte y reenvía cualquier tipo de evento en tiempo real a un servidor SYSLOG o SIEM incluido el registro de auditoría del sistema QAUDJRN, cambios en la base de datos DB2, registro de salida/acceso a la red, QHST Registros históricos, colas de mensajes como QSYS, registros de auditoría de sentencias SQL, IFS y registros cifrados de DB2. Los registros de IBM i se convierten y reenvían a su servidor SIEM o SYSLOG en formato de evento común para el análisis automatizado. La instalación y el reenvío se pueden configurar en menos de un minuto, con la opción de enviar todos los registros de eventos o deshabilitar la transferencia de usuarios y tipos de registro específicos a su servidor SIEM o SYSLOG y en todos los eventos se suministra la dirección ip del servidor y autor como puede ver en el siguiente ejemplo.

Integración SIEM



IPSecurity se integra con muchos productos SIEM incluyendo:


IBM QRADAR


HP ArcSight


Splunk


LogLogic


Tripwire


SolarWinds Kiwi


y muchos más



En el siguiente video de nuestro canal técnico en Youtube vea un ejemplo!

"Envió de eventos del QAUDJRN a un servidor SYSLOG."



Entradas destacadas
Entradas recientes
Archivo