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

Recopila registros de NGINX

Compatible con:

Google SecOps SIEM

Este analizador de NGINX controla los registros con formato JSON y syslog. Extrae campos de varios formatos de registro y los normaliza en el formato del UDM. El analizador enriquece el evento con metadatos para la administración del servidor y la actividad de la red, incluidos los accesos de los usuarios y las solicitudes HTTP. También controla la lógica de los eventos de SSH y completa los campos de UDM según los datos extraídos.

Antes de comenzar

Asegúrate de cumplir con los siguientes requisitos previos:

Instancia de Google SecOps
NGINX se está ejecutando y generando registros
Acceso raíz a la máquina anfitrión de NGINX

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

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 esta guía de instalación.

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

Accede al archivo de configuración:
1. 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.
2. 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:
    udplog:
        # Replace the port and IP address as required
        listen_address: "0.0.0.0:514"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        # Adjust the path to the credentials file you downloaded in Step 1
        creds: '/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
        ingestion_labels:
            log_type: 'NGINX'
            raw_log_field: body

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

Reemplaza el puerto y la dirección IP según sea necesario en tu infraestructura.
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 Cómo obtener el archivo de autenticación de la transferencia de datos 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
```

Identifica la ubicación de los archivos de registro de NGINX

Por lo general, los registros de NGINX se almacenan en la siguiente ubicación:
- Registros de acceso: /var/log/nginx/access.log
- Registros de errores: /var/log/nginx/error.log
Accede al host de NGINX con credenciales administrativas.
Ejecuta el siguiente comando y busca la ruta de acceso a los registros en tu host de NGINX:
```
sudo cat /etc/nginx/nginx.conf | grep log
```

Configura NGINX para que reenvíe registros a BindPlane

Abre el archivo de configuración de NGINX (por ejemplo, /etc/nginx/nginx.conf):
```
sudo vi /etc/nginx/nginx.conf
```

Edita la configuración y reemplaza <BINDPLANE_SERVER> y <BINDPLANE_PORT> por tus valores:

http {
    access_log syslog:server=<BINDPLANE_SERVER>:<BINDPLANE_PORT>,facility=local7,tag=nginx_access;
    error_log syslog:server=<BINDPLANE_SERVER>:<BINDPLANE_PORT>,facility=local7,tag=nginx_error;
}

Reinicia NGINX para aplicar los cambios:
```
sudo systemctl reload nginx
```

Tabla de asignación de UDM

Campo de registro	Asignación de UDM	Lógica
`_Internal_WorkspaceResourceId`	`target.resource.product_object_id`	Asignado directamente
`Computer`	`principal.asset.hostname`	Asignado directamente
`Facility`	`additional.fields[`facility`]`	Asignado directamente
`HostName`	`principal.asset.hostname`	Se asigna directamente si `src_ip` no está presente.
`ProcessName`	`principal.application`	Asignado directamente
`SeverityLevel`	`security_result.severity`	Se asigna a INFORMATIONAL si el valor es `info`.
`SourceSystem`	`principal.asset.platform`	Se asigna a LINUX si el valor coincide con `Linux`.
`SyslogMessage`	Varios campos	Se analizó con Grok para extraer `time`, `method`, `target_path`, `protocol`, `response_code`, `referral_url`, `user_agent`, `target_ip`, `target_host` y `cache`.
`TenantId`	`additional.fields[`TenantId`]`	Asignado directamente
`acct`	`principal.user.user_id`	Se asigna directamente si no está vacío o es `?`.
`addr`	`principal.asset.ip`	Asignado directamente
`audit_epoch`	`metadata.event_timestamp`	Se convirtió a marca de tiempo con el formato `UNIX`. Los nanosegundos se extraen del mensaje de registro original.
`cache`	`additional.fields[`caché`]`	Asignado directamente
`collection_time.nanos`	`metadata.event_timestamp.nanos`	Se usa para los nanosegundos de la marca de tiempo del evento si están disponibles.
`collection_time.seconds`	`metadata.event_timestamp.seconds`	Se usa para los segundos de la marca de tiempo del evento si está disponible.
`data`	Varios campos	Es la principal fuente de datos, que se analiza de manera diferente según el formato de registro (Syslog, JSON o algún otro).
`exe`	`target.process.command_line`	Se asigna directamente después de quitar las barras inversas y las comillas.
`hostname`	`principal.asset.hostname` O `principal.asset.ip`	Si es una dirección IP, se asigna a `principal.asset.ip`. De lo contrario, se asigna a `principal.asset.hostname`.
`msg`	`metadata.description`	Se asigna directamente como la descripción
`node`	`target.asset.hostname`	Asignado directamente
`pid`	`target.process.pid`	Asignado directamente
`protocol`	`network.application_protocol`	Se asigna a HTTP si el valor coincide con `HTTP`.
`referral_url`	`network.http.referral_url`	Se asigna directamente si no está vacío o es `-`.
`res`	`security_result.action_details`	Asignado directamente
`response_code`	`network.http.response_code`	Se asigna y convierte directamente en un número entero
`ses`	`network.session_id`	Asignado directamente
`src_ip`	`principal.asset.ip`	Asignado directamente
`target_host`	`target.asset.hostname`	Asignado directamente
`target_ip`	`target.asset.ip`	Se asigna directamente después de convertir la representación de cadena en un array JSON y, luego, extraer las IPs individuales.
`target_path`	`target.url`	Asignado directamente
`time`	`metadata.event_timestamp`	Se analizó para extraer la marca de tiempo con el formato `dd/MMM/yyyy:HH:mm:ss Z`
`user_agent`	`network.http.user_agent`	Se asigna directamente si no está vacío o es `-`.
	`metadata.event_type`	Se establece en `GENERIC_EVENT` inicialmente y, luego, se puede reemplazar en función de otros campos, como `terminal` y `protocol`. El valor predeterminado es `USER_UNCATEGORIZED` si el patrón de grok principal no coincide. Se establece en `NETWORK_HTTP` si `protocol` es HTTP y `target_ip` está presente, y en `STATUS_UPDATE` si `protocol` es HTTP, pero `target_ip` no está presente.
	`metadata.log_type`	Está establecido en `NGINX`.
	`metadata.product_name`	Está establecido en `NGINX`.
	`metadata.vendor_name`	Está establecido en `NGINX`.
	`network.ip_protocol`	Se establece en `TCP` si `terminal` es `sshd` o `ssh`, o si el patrón de Grok principal no coincide.
	`principal.asset_id`	Se establece en `GCP.GCE:0001` si `terminal` es `sshd` o `ssh`. Se establece en `GCP.GCE:0002` si el patrón de grok principal no coincide.
	`extensions.auth.type`	Se establece en `MACHINE` si `terminal` es `sshd` o `ssh`.

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