Configurar el registro del sistema para dispositivos de seguridad

Registros del plano de control y del plano de datos

Junos OS genera mensajes de registro independientes para registrar los eventos que se producen en los planos de control y datos del sistema.

• Los registros del plano de control, también denominados registros del sistema, incluyen eventos que se producen en la plataforma de enrutamiento. El sistema envía eventos del eventd plano de control al proceso en el motor de enrutamiento, que luego maneja los eventos mediante políticas de Junos OS, generando mensajes de registro del sistema o ambos. Puede elegir enviar los registros del plano de control a un archivo, terminal de usuario, consola de plataforma de enrutamiento o máquina remota. Para generar registros del plano de control, utilice la syslog instrucción en el nivel de [system] jerarquía.

• Los registros del plano de datos, también denominados registros de seguridad, incluyen principalmente eventos de seguridad que se controlan dentro del plano de datos. Los registros de seguridad pueden estar en formato de texto o binario, y pueden guardarse localmente (modo de evento) o enviarse a un servidor externo (modo de secuencia). El formato binario es necesario para el modo de transmisión y se recomienda conservar espacio de registro en el modo de evento.

  Tenga en cuenta lo siguiente:

  • Los registros de seguridad se pueden guardar localmente (en caja) o externamente (fuera de la caja), pero no ambos.

  • SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600, SRX5400, SRX5600 y SRX5800 dispositivos utilizan de forma predeterminada el modo de transmisión. Para especificar el formato binario y un servidor externo, consulte Configuración de archivos de registro de seguridad binaria fuera de la caja.

    Nota:

    Es posible que se eliminen los registros si configura el registro en modo de evento en estos dispositivos.

    A partir de Junos OS versión 15.1X49-D100, el modo predeterminado para SRX1500 dispositivo es el modo de transmisión. Antes de Junos OS versión 15.1X49-D100, el modo predeterminado para SRX1500 dispositivo era el modo de evento.

  • Además de las versiones 18.4R1, 18,4R2, 19.1 y 19.2R1 de Junos OS, en todas las demás versiones a partir de Junos OS versión 18.3R3, el modo de registro predeterminado para los dispositivos SRX300, SRX320, SRX340, SRX345, SRX550 y SRX550M es el modo de transmisión. Los eventos del plano de datos se escriben en los archivos de registro del sistema de manera similar a los eventos del plano de control. Para especificar el formato binario de los registros de seguridad, consulte Configuración de archivos de registro de seguridad binarios fuera de la caja.

  A partir de la versión 20.2R1 de Junos OS, admitimos el escape en el reenvío de registros de flujo y la generación de informes en caja para evitar errores de análisis. El modo de transmisión admite el escape y sd-syslogbinary los formatos cuando los registros no se envían a eventd procesar. Para los registros enviados al eventd proceso, recomendamos no habilitar una escape opción, ya que el eventd proceso ha habilitado el escape para el registro de estructura. El modo Evento solo admite escape en binary formato. De forma predeterminada, la escape opción está desactivada. Debe habilitar la escape opción mediante el set security log escape comando.

Servidor de registro del sistema redundante

El tráfico de registro del sistema de seguridad destinado a servidores remotos se envía a través de los puertos de interfaz de red, que admiten dos destinos de registro del sistema simultáneos. Cada destino de registro del sistema debe configurarse por separado. Cuando se configuran dos direcciones de destino de registro del sistema, se envían registros idénticos a ambos destinos. Aunque se pueden configurar dos destinos en cualquier dispositivo que admita la característica, agregar un segundo destino es útil principalmente como copia de seguridad redundante para implementaciones de clústeres de chasis independientes y activas/configuradas para copias de seguridad.

Está disponible la siguiente información de servidor redundante:

• Facilidad: cron

• Descripción: Proceso de programación de cron

• Nivel de gravedad (de mayor a menor gravedad): debug

• Descripción: Mensajes de depuración de software

Descripción general

El registro de tráfico en caja en unidades de estado sólido (SSD) admite ocho servidores de registro o archivos externos.

Se agrega un archivo XML todo en uno que contiene toda la información de los registros de tráfico. El archivo XML también genera todos los archivos de encabezado de registro y los documentos relacionados con el registro de tráfico.

Un nuevo proceso (demonio) denominado demonio de administración de registros locales (llmd) se admite en las tarjetas de procesamiento de servicios 0 (SPCs0) para controlar el registro de tráfico en caja. El tráfico producido por el flujo en SPC se enumera en los registros de tráfico. El llmd guarda estos registros en el SSD local. Los registros de tráfico se guardan en cuatro formatos diferentes. Consulte Tabla 1 para obtener información sobre los formatos de registro.

El mecanismo de informes en caja es una mejora de la funcionalidad de registro existente. La funcionalidad de registro existente se modifica para recopilar registros de tráfico del sistema, analizar los registros y generar informes de estos registros en forma de tablas mediante la CLI. La función de informes en caja está destinada a proporcionar una interfaz simple y fácil de usar para ver los registros de seguridad. Los informes en caja son páginas J-Web fáciles de usar de varios eventos de seguridad en forma de tablas y gráficos. Los informes permiten a la administración de seguridad de TI identificar la información de seguridad de un vistazo y decidir rápidamente las acciones a tomar. Se realiza un análisis exhaustivo de los registros (según los tipos de sesión) para funciones como pantalla, IDP, seguridad de contenido e IPSec.

Puede definir filtros para los datos de registro sobre los que se informa en función de los siguientes criterios:

• top <number>: esta opción le permite generar informes para eventos de seguridad principales como se especifica en el comando. por ejemplo: los 5 principales ataques IPS o las 6 URL principales detectadas a través de Content Security.

• in-detail <number>: esta opción le permite generar contenido de registro detallado.

• in-interval <time-period>: esta opción permite generar los eventos registrados entre determinados intervalos de tiempo.

• summary—Esta opción permite generar el resumen de los eventos. De esta manera, puede ajustar el informe a sus necesidades y mostrar solo los datos que desea usar.

El número máximo en el intervalo que muestra el recuento en intervalos es 30. Si se especifica una gran duración, los contadores se ensamblan para garantizar que el intervalo de entrada máximo sea inferior a 30.

Tanto en detalle como en resumen tienen la opción "todos", ya que diferentes tablas tienen atributos diferentes (como la tabla de sesión no tiene el atributo "motivo" pero Content Security sí), la opción "todos" no tiene ningún filtro excepto el tiempo de inicio y el tiempo de finalización. Si hay algún otro filtro que no sea la hora de inicio y la hora de finalización, se muestra un error.

Por ejemplo: root@host> mostrar el informe del registro de seguridad en detalle todos los motivos de la razón1

 error: "query condition error"

Los registros del firewall de la aplicación para la visibilidad de aplicaciones y usuarios enumerarán las aplicaciones y las aplicaciones anidadas. Cuando los registros de estas características enumeran aplicaciones anidadas, las aplicaciones anidadas se enumeran en J-Web. Cuando los registros enumeran las aplicaciones anidadas como no aplicables o desconocidas, solo las aplicaciones se enumeran en J-Web.

Utilice los siguientes comandos de CLI para ver las aplicaciones y los usuarios de todas las aplicaciones y la lista de aplicaciones anidadas:

• Para las principales aplicaciones anidadas por recuento:show security log report top session-close top-number <number> group-by application order-by count with user

• Para las principales aplicaciones anidadas por volumen:show security log report top session-close top-number <number> group-by application order-by volume with user

• Para el usuario superior por recuento con aplicación anidada:show security log report top session-close top-number <number> group-by user order-by count with application

La función de informes en caja está habilitada de forma predeterminada cuando se cargan las configuraciones predeterminadas de fábrica en el firewall de la serie SRX con Junos OS versión 15.1X49-D100 o posterior.

Si está actualizando el firewall de la serie SRX desde una versión de Junos OS anterior a Junos OS 15.1X49-D100, el firewall de la serie SRX hereda la configuración existente y la función de informes integrados está deshabilitada de forma predeterminada. Debe configurar el comando y el set security log reportset security log mode stream comando para habilitar la función de informes en caja en el dispositivo que se actualiza.

A partir de Junos OS versión 19.3R1 , la configuración predeterminada de fábrica no incluye la configuración de informes en caja para aumentar la vida útil de la unidad de estado sólido (SSD). Puede habilitar la función de informes en caja configurando el comando de la CLI en [edit security log] la set security log report jerarquía.

Consulte la Guía del usuario de J-Web para dispositivos de la serie SRX para realizar esta tarea en la interfaz de usuario de J-Web.

A partir de Junos OS versión 21.3R1, los registros de informes en caja se almacenan en el sistema de archivos de memoria (MFS) si no hay ningún SSD externo. El número máximo de registros que puede guardar en MFS es menor que el que puede guardar en un SSD externo. Esto evita el agotamiento y la falla de la memoria. Los registros guardados en MFS no se conservan después del reinicio del dispositivo o un corte de energía. Consulte Tabla 2 para conocer el número de registros registrados en los informes integrados y externos.

Después de grabar el mensaje de registro, el registro se almacena en un archivo de registro que luego se almacena en la tabla de base de datos del RE para su posterior análisis (en dispositivos SRX300, SRX320, SRX340, SRX345 y SRX550M) o en la tarjeta SSD para su posterior análisis (en dispositivos SRX1500, SRX4100 y SRX4200).

Los beneficios de esta característica son:

• Los informes se almacenan localmente en el firewall de la serie SRX y no se requieren dispositivos o herramientas independientes para el almacenamiento de registros e informes.

• Los informes en caja son páginas J-Web fáciles de usar de varios eventos de seguridad en forma de tablas y gráficos.

• Proporciona una interfaz simple y fácil de usar para ver los registros de seguridad.

• Los informes generados permiten al equipo de gestión de seguridad de TI identificar la información de seguridad de un vistazo y decidir rápidamente las acciones a tomar.

La función de informes en caja admite:

• Generación de informes basados en los requerimientos. Por ejemplo: recuento o volumen de la sesión, tipos de registros para actividades como IDP, seguridad de contenido, VPN IPsec.

• Capturar eventos en tiempo real dentro de un rango de tiempo especificado.

• Captura de todas las actividades de red en un formato lógico, organizado y fácil de entender basado en varias condiciones especificadas por CLI.

Funciones de informes integradas

La función de informes en caja admite:

• Sqlite3 support as a library—sqlite3 no era compatible antes de Junos OS versión 15.1X49-D100. A partir de Junos OS versión 15.1X49-D100, los demonios que se ejecutan en el RE, así como otros módulos potenciales, utilizan una base de datos de registros SQL (SQLite versión 3) para almacenar registros en firewalls de la serie SRX.

  En Junos OS versión 19.4R1, actualizamos la base de datos de registro en caja para mejorar el rendimiento de las consultas.

• Running llmd in both Junos OS and Linux OS: el demonio de reenvío (flowd) decodifica el índice de la base de datos a partir de registros binarios y envía tanto el índice como el registro al demonio de administración de registros local (llmd).

  En los dispositivos SRX300, SRX320, SRX340, SRX345 y SRX550M, llmd se ejecuta en Junos OS. En dispositivos SRX1500, SRX4100 y SRX4200, llmd se ejecuta en Linux. Por lo tanto, para admitir que llmd se ejecute tanto en Junos OS como en Linux OS, el directorio de código llmd se mueve del lado de Linux al lado de Junos OS.

• Storing of logs into specified table of the sqlite3 database by llmd— Se introduce un nuevo demonio syslog para recopilar registros locales en firewalls de la serie SRX y guardarlos en la base de datos.

  A partir de Junos OS versión 19.3R1, Junos OS almacena registros en varias tablas en lugar de una sola tabla en un archivo de base de datos. Cada tabla contiene la marca de tiempo de los registros más antiguos y más recientes. Cuando inicia una consulta basada en la hora de inicio y finalización, llmd busca la tabla más reciente para generar informes.

  Por ejemplo, si hay 5 millones de registros en una tabla de un archivo de base de datos generado en las últimas 10 horas, y si desea tomar un informe, debe dedicar más de media hora. A partir de la versión 19.3R1 de Junos OS, una tabla se divide en varias tablas y cada tabla tiene 0,5 millones de registros. Para generar el mismo informe, basta con una información de tabla.

  Le recomendamos que consulte con un tiempo más corto para un mejor rendimiento.

  • Database table definition—Para los registros de sesión, los tipos de datos son dirección de origen, dirección de destino, aplicación, usuario, etc. Para los registros relacionados con las características de seguridad, los tipos de datos son nombre de ataque, dirección URL, protocolo de perfil, etc. Por lo tanto, diferentes tablas están diseñadas para almacenar diferentes tipos de registros para ayudar a mejorar el rendimiento y ahorrar espacio en disco. El firewall de la serie SRX crea una tabla de base de datos para cada tipo de registro, cuando se registran los datos de registro.

    Cada tipo de tabla de base de datos tiene su número máximo de registro específico del dispositivo. Cuando el número de registro de tabla alcanza la limitación, los registros nuevos reemplazan a los registros más antiguos. Junos OS almacena el inicio de sesión en un firewall de la serie SRX en el que se pasa el tráfico activo.

    A partir de Junos OS versión 19.3R1, puede crear varias tablas en un archivo de base de datos para almacenar registros. Puede definir la capacidad de almacenar registros en una tabla.

    Si el límite del número de registro supera la capacidad de la tabla, Junos OS almacena los registros en la segunda tabla. Por ejemplo, si el límite de registros de la tabla 1 supera la capacidad de la tabla, Junos OS almacena los registros en la tabla 2.

    Si el límite del número de registro supera la última tabla del archivo 1, Junos OS almacena los registros en la tabla 1 del archivo 2. Por ejemplo, la tabla n es la última tabla del archivo 1. Cuando los registros superan la capacidad de la tabla, Junos OS almacena los registros en la tabla 1 del archivo 2.

    Para hacer efecto inmediato después de cambiar el número de tabla, utilice clear security log report el comando operativo.

  • Database table rotation—Cada tipo de tabla de base de datos tiene su número máximo de registro específico del dispositivo. Cuando el número de registro de tabla alcanza la limitación, los registros nuevos reemplazan a los registros más antiguos.

    A continuación Tabla 3 se describe la capacidad del tamaño del archivo de base de datos:

    Tabla 3: Capacidad de tamaño de archivo de base de datos

    Dispositivos	Sesión	Pantalla	DPI	Seguridad de contenido	IPsec-VPN	CIELO
    SRX300, SRX320, SRX340, SRX345 y SRX550M	1.8G	0.18G	0.18G	0.18G	0.06G	0.18G
    SRX1500	12G	2.25G	2.25G	2.25G	0.75G	2.25G
    SRX4100 y SRX4200	15G	2.25G	2.25G	2.25G	0.75G	2.25G
    SRX4600	22,5G	6G	6G	6G	0.75G	2.25G
    Firewall virtual vSRX	1.8G	0.18G	0.18G	0.18G	0.06G	0.18G

• Calculating and displaying the reports that are triggered by CLI: los informes de la base de datos se reciben de la CLI como interfaz. Con la CLI, puede calcular y mostrar los detalles de los informes.

Selección de tablas

Cuando desee generar un informe a partir de varias tablas, llmd ordena las tablas según la marca de tiempo y selecciona las tablas según la hora de inicio y la hora de finalización solicitadas.

Por ejemplo, hay tres tablas: la tabla 1 (1 a 3), la tabla 2 (3 a 5) y la tabla 3 (6 a 8). 1 a 3, 3 a 6 y 6 a 8 denota la marca de tiempo de los registros más recientes y antiguos. Si solicita un informe del 4 al 6, Junos OS generará un informe a partir de la tabla 2 y la tabla 3.

Duración de la tabla

Puede decidir la duración de la tabla mediante el comando de configuración set security log report table-lifetime . Junos OS quita la tabla después de que el tiempo de identificación de la tabla supere la duración de la tabla. Por ejemplo, si configura la duración de la tabla como 2 y la fecha actual es 26-julio-2019, significa que el 24-julio-2019 se eliminarán los registros a las 00:00:00.

Si cambia la fecha y la hora manualmente en un dispositivo, la duración de la tabla cambia. Por ejemplo, si la hora de identificación de una tabla es 19 de julio de 2019 y configura la duración de la tabla como 10, Junos OS debería quitar la tabla el 29 de julio de 2019. Si cambia la fecha del dispositivo como 18-julio-2019, entonces la vida útil real de la tabla se convierte en 30-julio-2019.

Modo denso de tabla

En Junos OS versión 19.4R1, actualizamos el mecanismo predeterminado de almacenamiento y búsqueda en la base de datos de registro en caja para administrar los registros. Ahora puede personalizar el almacenamiento de registros y los resultados del mecanismo de búsqueda. Por ejemplo, si espera menos registros de tráfico, puede usar la configuración predeterminada con una hora de inicio y una hora de detención.

Sin embargo, si espera un gran número de registros de tráfico y mayores intervalos de tiempo para los que se generarán los registros, habilite el modo denso. Para habilitar el modo denso, utilice el set security log report table-mode dense comando de configuración.

Escenario de clúster de chasis

Para los informes internos en un clúster de chasis, los registros se almacenan en el disco local en el que el dispositivo está procesando el tráfico activo. Estos registros no se sincronizan con el par del clúster de chasis.

Cada nodo es responsable de almacenar registros cuando cada nodo procesa el tráfico activo. En caso de modo activo/pasivo, solo el nodo activo procesa el tráfico y los registros también se almacenan solo en el nodo activo. En caso de conmutación por error, el nuevo nodo activo procesa el tráfico y almacena los registros en su disco local. En caso de modo activo/activo, cada nodo procesa su propio tráfico y los registros se almacenan en los nodos respectivos.