Esta página se ha traducido con Cloud Translation API.

Recoger registros de Apache Tomcat

Disponible en:

SecOps de Google SIEM

En este documento se explica cómo ingerir registros de Apache Tomcat en Google Security Operations mediante 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, gestiona los posibles errores de análisis de JSON y asigna varios campos del registro sin procesar a los campos de UDM correspondientes, incluida la información de metadatos, principal, observador y resultado de seguridad, al tiempo que añade etiquetas personalizadas para el contexto del entorno.

Antes de empezar

Asegúrate de que cumples los siguientes requisitos previos:

Instancia de Google SecOps
Un host Windows 2016 o posterior, o un host Linux con systemd
Si se ejecuta a través de un proxy, los puertos del cortafuegos están abiertos
Apache Tomcat 9.0.70 o versiones posteriores
Acceso de escritura a $CATALINA_BASE/conf y $CATALINA_BASE/logs

Obtener el archivo de autenticación de ingestión de Google SecOps

Inicia sesión en la consola de Google SecOps.
Ve a Configuración de SIEM > Agentes de recogida.
Descarga el archivo de autenticación de ingestión. Guarda el archivo de forma segura en el sistema en el que se instalará Bindplane.

Obtener el ID de cliente de Google SecOps

Inicia sesión en la consola de Google SecOps.
Ve a Configuración de SIEM > Perfil.
Copia y guarda el ID de cliente de la sección Detalles de la organización.

Instalar el agente de Bindplane en el servidor Tomcat para recoger archivos de registro

Instala el agente de Bindplane en tu sistema operativo Windows o Linux siguiendo las instrucciones que se indican a continuación.

Instalación de ventanas

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 de Linux

Abre un terminal con privilegios de superusuario 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 ver más opciones de instalación, consulta la guía de instalación.

Configurar el agente de BindPlane para ingerir Syslog y enviarlo a Google SecOps

Accede al archivo de configuración:
- Busca el archivo config.yaml. Normalmente, 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

Sustituye el /path/to/tomcat/logs.
Sustituye <customer_id> por el ID de cliente real.
Actualiza /path/to/ingestion-authentication-file.json a la ruta donde se guardó el archivo de autenticación en la sección Obtener el archivo de autenticación de ingestión 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 Servicios o introducir el siguiente comando:
```
net stop BindPlaneAgent && net start BindPlaneAgent
```

Configurar registros de acceso JSON en Tomcat

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

Busca la etiqueta <Host> y añade lo siguiente:

<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

Cada día aparecerá un nuevo archivo de registro JSON (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 la que se produjo el evento.
`agent.ephemeral_id`	`additional.fields[ephemeral_id].value.string_value`	El ID efímero del agente se añade como un par clave-valor en los campos `additional`.
`agent.hostname`	`observer.hostname`	El nombre de host del agente se usa como 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 recurso observador (por ejemplo, `filebeat: <agent_id>`).
`agent.type`	`observer.application`	El tipo de agente se usa como aplicación observadora.
`agent.version`	`observer.platform_version`	La versión del agente se usa como versión de la plataforma del observador.
`host.hostname`	`principal.hostname`	El nombre de host del host se usa como nombre de host principal.
`host.id`	`principal.asset.asset_id`	Se añade el prefijo `Host Id:` al ID de host para crear el ID de recurso principal.
`host.ip`	`principal.ip`, `observer.ip`	La dirección IP del host se usa tanto para la IP principal como para la IP del observador. Si hay varias IPs, se combinan en una matriz.
`host.mac`	`principal.mac`	La dirección MAC del host se usa como dirección MAC principal. Si hay varias MACs, se combinan en una matriz.
`host.os.family`	`principal.platform`	Si la familia del SO del 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 nivel de parche principal de la plataforma.
`host.os.name`	`additional.fields[os_name].value.string_value`	El nombre del SO del host se añade como un par clave-valor en los campos `additional`.
`host.os.version`	`principal.platform_version`	La versión del SO del host se utiliza como versión principal de la plataforma.
`log.file.path`	`principal.process.file.full_path`	La ruta del registro se usa como la ruta 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 de la gravedad y la acción del resultado de seguridad. DEBUG, INFO y AUDIT se corresponden con la gravedad INFORMATIVA y la acción PERMITIR. ERROR se asigna a la gravedad ERROR y a la acción BLOCK. WARNING y WARN se corresponden con la gravedad MEDIA y 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 añade 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 añade 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 añade 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 intermediario.
`logstash.process.timestamp`	`metadata.collected_timestamp`	La marca de tiempo de procesamiento de Logstash se usa como marca de tiempo de recogida.
`logstash.xyz_environment`	`additional.fields[xyz_environment].value.string_value`	El entorno xyz de Logstash se añade 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 añade 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 añade como par clave-valor en los campos `additional`.
`message`	`metadata.description`	El campo de mensaje se analiza como JSON y su campo `event_message` se usa como descripción de los metadatos. La aplicación intermediaria está codificada como `logstash`. El tipo de evento de metadatos está codificado como `USER_UNCATEGORIZED`. El tipo de registro de metadatos se define como `TOMCAT` a partir de batch.type o batch.log_type del registro sin procesar. El nombre del producto de metadatos se ha 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 ID de usuario principal.

¿Necesitas más ayuda? Recibe respuestas de los miembros de la comunidad y de los profesionales de Google SecOps.