Se usó la API de Cloud Translation para traducir esta página.

Recopila registros de Apache Tomcat

Compatible con:

Google SecOps SIEM

En este documento, se explica cómo transferir registros de Apache Tomcat a Google Security Operations con Bindplane. El analizador extrae campos de los registros con formato JSON y los transforma en el modelo de datos unificado (UDM). Inicializa los valores predeterminados, analiza la carga útil de JSON, controla los posibles errores de análisis de JSON y asigna varios campos del registro sin procesar a los campos de UDM correspondientes, incluidos los metadatos, el principal, el observador y la información del resultado de seguridad, y, al mismo tiempo, agrega etiquetas personalizadas para el contexto del entorno.

Antes de comenzar

Asegúrate de cumplir con los siguientes requisitos previos:

Instancia de Google SecOps
Un host de Windows 2016 o posterior, o un host de Linux con systemd
Si se ejecuta detrás de un proxy, los puertos de firewall están abiertos.
Versión 9.0.70 o posterior de Apache Tomcat
Acceso de escritura a $CATALINA_BASE/conf y $CATALINA_BASE/logs

Obtén el archivo de autenticación de transferencia de Google SecOps

Accede a la consola de Google SecOps.
Ve a SIEM Settings > Collection Agents.
Descarga el archivo de autenticación de transferencia. Guarda el archivo de forma segura en el sistema en el que se instalará BindPlane.

Obtén el ID de cliente de Google SecOps

Accede a la consola de Google SecOps.
Ve a SIEM Settings > Profile.
Copia y guarda el ID de cliente de la sección Detalles de la organización.

Instala el agente de BindPlane en el servidor de Tomcat para recopilar archivos de registro

Instala el agente de Bindplane en tu sistema operativo Windows o Linux según las siguientes instrucciones.

Instalación en Windows

Abre el símbolo del sistema o PowerShell como administrador.

Ejecuta el siguiente comando:

msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

Instalación en Linux

Abre una terminal con privilegios de raíz o sudo.

Ejecuta el siguiente comando:

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

Recursos de instalación adicionales

Para obtener más opciones de instalación, consulta la guía de instalación.

Configura el agente de BindPlane para transferir Syslog y enviarlo a Google SecOps

Accede al archivo de configuración:
- Ubica el archivo config.yaml. Por lo general, se encuentra en el directorio /etc/bindplane-agent/ en Linux o en el directorio de instalación en Windows.
- Abre el archivo con un editor de texto (por ejemplo, nano, vi o Bloc de notas).

Edita el archivo config.yaml de la siguiente manera:

receivers:
    filelog/tomcat:
    include: [ /path/to/tomcat/logs/access-log.*.json ]
    start_at: beginning

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        # Adjust the path to the credentials file you downloaded in Step 1
        creds_file_path: '/path/to/ingestion-authentication-file.json'
        # Replace with your actual customer ID from Step 2
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        # Add optional ingestion labels for better organization
        log_type: 'TOMCAT'
        raw_log_field: body
        ingestion_labels:

service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - filelog/tomcat
            exporters:
                - chronicle/chronicle_w_labels

Reemplaza el /path/to/tomcat/logs.
Reemplaza <customer_id> por el ID de cliente real.
Actualiza /path/to/ingestion-authentication-file.json a la ruta de acceso en la que se guardó el archivo de autenticación en la sección Obtén el archivo de autenticación de la transferencia de Google SecOps.

Reinicia el agente de Bindplane para aplicar los cambios

Para reiniciar el agente de Bindplane en Linux, ejecuta el siguiente comando:
```
sudo systemctl restart bindplane-agent
```
Para reiniciar el agente de Bindplane en Windows, puedes usar la consola de Servicios o ingresar el siguiente comando:
```
net stop BindPlaneAgent && net start BindPlaneAgent
```

Configura registros de acceso en formato JSON en Tomcat

Abre el archivo de Tomcat en $CATALINA_BASE/conf/server.xml.

Busca la etiqueta <Host> y agrega lo siguiente dentro de ella:

<Valve className="org.apache.catalina.valves.JsonAccessLogValve"
      directory="logs"
      prefix="access-log"
      suffix=".json"
      rotatable="true"
      maxDays="7"/>

Reinicia Tomcat para aplicar los cambios:

cd /path/to/tomcat
bin/catalina.sh stop
bin/catalina.sh start

Aparecerá un nuevo archivo de registro JSON todos los días (por ejemplo, logs/access-log.2025-07-02.json).

Tabla de asignación de UDM

Campo de registro	Asignación de UDM	Lógica
`@timestamp`	`metadata.event_timestamp`	El valor de `@timestamp` del registro sin procesar se asigna directamente a este campo de UDM. Representa la hora en que ocurrió el evento.
`agent.ephemeral_id`	`additional.fields[ephemeral_id].value.string_value`	El ID efímero del agente se agrega como un par clave-valor en los campos `additional`.
`agent.hostname`	`observer.hostname`	El nombre de host del agente se usa como el nombre de host del observador.
`agent.id`	`observer.asset_id`	El ID del agente se combina con el tipo de agente para crear el ID del activo del observador (p.ej., `filebeat: <agent_id>`).
`agent.type`	`observer.application`	El tipo de agente se usa como la aplicación observadora.
`agent.version`	`observer.platform_version`	La versión del agente se usa como la versión de la plataforma del observador.
`host.hostname`	`principal.hostname`	El nombre de host del host se usa como el nombre de host principal.
`host.id`	`principal.asset.asset_id`	El ID del host se antepone con `Host Id:` para crear el ID del activo principal.
`host.ip`	`principal.ip`, `observer.ip`	La dirección IP del host se usa para la IP principal y la IP del observador. Si hay varias IPs, se combinan en un array.
`host.mac`	`principal.mac`	La dirección MAC del host se usa como la dirección MAC principal. Si hay varias direcciones MAC, se combinan en un array.
`host.os.family`	`principal.platform`	Si la familia del SO host es `rhel` o `redhat`, la plataforma principal se establece en `LINUX`.
`host.os.kernel`	`principal.platform_patch_level`	La versión del kernel del SO host se usa como el nivel principal de parche de la plataforma.
`host.os.name`	`additional.fields[os_name].value.string_value`	El nombre del SO host se agrega como un par clave-valor en los campos `additional`.
`host.os.version`	`principal.platform_version`	La versión del SO del host se usa como la versión principal de la plataforma.
`log.file.path`	`principal.process.file.full_path`	La ruta de acceso al registro se usa como la ruta de acceso completa del archivo del proceso principal.
`log_level`	`security_result.severity`, `security_result.severity_details`, `security_result.action`	El nivel de registro se usa para determinar la gravedad, los detalles y la acción del resultado de seguridad. DEBUG, INFO y AUDIT se asignan a la gravedad INFORMATIONAL y a la acción ALLOW. ERROR se asigna a la gravedad ERROR y a la acción BLOCK. WARNING y WARN se asignan a la gravedad MEDIA y a la acción BLOCK. El valor sin procesar de log_level también se asigna a severity_details.
`logstash.irm_environment`	`additional.fields[irm_environment].value.string_value`	El entorno de Iron Mountain de Logstash se agrega como un par clave-valor en los campos `additional`.
`logstash.irm_region`	`additional.fields[irm_region].value.string_value`	La región de Iron Mountain de Logstash se agrega como un par clave-valor en los campos `additional`.
`logstash.irm_site`	`additional.fields[irm_site].value.string_value`	El sitio de Iron Mountain de Logstash se agrega como un par clave-valor en los campos `additional`.
`logstash.process.host`	`intermediary.hostname`	El host de procesamiento de Logstash se usa como nombre de host intermedio.
`logstash.process.timestamp`	`metadata.collected_timestamp`	La marca de tiempo de procesamiento de Logstash se usa como la marca de tiempo recopilada.
`logstash.xyz_environment`	`additional.fields[xyz_environment].value.string_value`	El entorno xyz de Logstash se agrega como un par clave-valor en los campos `additional`.
`logstash.xyz_region`	`additional.fields[xyz_region].value.string_value`	La región xyz de Logstash se agrega como un par clave-valor en los campos `additional`.
`logstash.xyz_site`	`additional.fields[xyz_site].value.string_value`	El sitio xyz de Logstash se agrega como un par clave-valor en los campos `additional`.
`message`	`metadata.description`	El campo del mensaje se analiza como JSON y su campo `event_message` se usa como la descripción de los metadatos. La aplicación intermedia está codificada como `logstash`. El tipo de evento de metadatos está codificado como `USER_UNCATEGORIZED`. El tipo de registro de metadatos se establece en `TOMCAT` a partir de batch.type o batch.log_type del registro sin procesar. El nombre del producto de metadatos está codificado como `Tomcat`. El nombre del proveedor de metadatos está codificado como `Tomcat`.
`user`	`principal.user.userid`	El campo de usuario del registro sin procesar se usa como el ID de usuario principal.

¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.