> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/es/pam/administration/integrations/syslog-and-siem.md).

# Syslog y SIEM

Reenvíe el registro de auditoría de forma continua a un colector externo (syslog sobre UDP, TCP o TLS, exportación en texto o Elasticsearch) para que los registros sobrevivan con independencia del app

El envío de registros manda los datos que produce la solución a un colector que usted ya opera, a medida que ocurren. La finalidad es la independencia: un registro que además vive en su SIEM sobrevive a la pérdida, el compromiso o la reinstalación del appliance, y puede correlacionarse con todo lo demás que vigila su SOC.

{% hint style="info" %}
**El envío de registros no es la generación de informes.** El envío es continuo, de máquina a máquina, y va a un colector. Los [informes](/es/pam/administration/audit/reports.md) son extracciones periódicas o bajo demanda, formateadas para personas y entregadas por correo electrónico. Ambos leen los mismos registros subyacentes, descritos en [Registro de auditoría](/es/pam/administration/audit/audit-trail.md), y la mayoría de los entornos quieren los dos.
{% endhint %}

## Qué es esto y cuándo usarlo

Existen dos mecanismos, se configuran en sitios distintos y transportan cosas distintas. Confundirlos es la razón habitual por la que un proyecto de SIEM se atasca.

| Mecanismo                                 | Qué transporta                                                                                              | Dónde se configura                                                          |
| ----------------------------------------- | ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| **Reenvío syslog**                        | Los registros de eventos: inicios de sesión, sesiones, cambios de configuración, transferencias de archivos | En el archivo de configuración del appliance                                |
| **Backend de almacenamiento de comandos** | Los comandos escritos en sesiones de terminal, indexados para búsqueda                                      | **Configuración del sistema › Almacenamiento › Almacenamiento de comandos** |

Use el reenvío syslog cuando el requisito sea "nuestro SIEM debe contener el registro de acceso privilegiado". Use un backend Elasticsearch de almacenamiento de comandos cuando el requisito sea "buscar el historial de comandos en la consola es demasiado lento": por defecto los comandos viven en la base de datos de la propia solución, lo cual funciona bien hasta que crece el volumen de sesiones de terminal.

Destinos disponibles para el registro:

| Destino                  | Notas                                                                                              |
| ------------------------ | -------------------------------------------------------------------------------------------------- |
| **Syslog sobre UDP**     | Puerto por defecto 514. Disparar y olvidar: sin garantía de entrega                                |
| **Syslog sobre TCP**     | Puerto por defecto 514. Orientado a conexión                                                       |
| **Syslog sobre TLS**     | Puerto por defecto 6514. Úselo siempre que el colector no esté en un segmento de confianza         |
| **Exportación en texto** | Un archivo de texto plano, para colectores que leen archivos o para una entrega en entorno aislado |
| **Elasticsearch**        | Indexa los registros de comandos para búsqueda, como backend de almacenamiento de comandos         |

## Antes de empezar

* La dirección y el puerto del colector, y una decisión sobre el protocolo. Prefiera **TLS en 6514** salvo que el colector esté en un segmento en el que ya confía.
* El colector debe ser alcanzable **desde todos los nodos**. En un clúster, cada nodo reenvía sus propios registros; una regla de firewall que solo cubra un nodo produce un registro con agujeros.
* La facility syslog que espera su colector, para que los registros caigan en el pipeline correcto y no en el predeterminado.
* Una ventana de mantenimiento. Habilitar el reenvío exige reiniciar los servicios de la solución.

{% hint style="warning" %}
El reenvío syslog **no se configura desde la consola**. Se establece en el archivo de configuración del appliance, y el cambio solo surte efecto después de que los servicios se reinicien. Abra un ticket de soporte para que el cambio se haga y quede registrado. No edite a mano un appliance de producción sin él.
{% endhint %}

## Pasos

1. **Elija el destino y el protocolo** y abra el camino desde todos los nodos hasta el colector en ese puerto.
2. **Fije los parámetros** en el archivo de configuración del appliance, `/opt/datadike/config/config.txt`:

   ```
   SYSLOG_ENABLE=true
   SYSLOG_ADDR=10.1.12.116:514
   SYSLOG_FACILITY=local2
   ```

   `SYSLOG_ADDR` recibe la dirección y el puerto del colector juntos. `SYSLOG_FACILITY` debe coincidir con lo que espera la configuración del colector.
3. **Reinicie los servicios de la solución.** No se reenvía nada hasta que vuelvan.
4. **Repita en todos los nodos** de un clúster. Cada nodo envía sus propios registros.
5. **Añada un backend de almacenamiento de comandos**, si el objetivo es la búsqueda de comandos, en **Configuración del sistema › Almacenamiento › Almacenamiento de comandos**. Dejar la lista vacía mantiene los comandos en la base de datos local.
6. **Construya el lado del colector**: parsers, índices y paneles. Los registros siguen un estándar común, de modo que los colectores habituales los consumen sin un parser a medida.

## Qué debería ver

Los registros llegan como líneas syslog que llevan un tipo de registro y una carga JSON. El tipo de registro indica de qué log procede el evento:

| Evento                         | Tipo de registro | Datos destacados de la carga                                                                                            |
| ------------------------------ | ---------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Inicio de sesión en la consola | `login_log`      | El backend de autenticación, la `ip` de origen, el `username` y un objeto `status` con el resultado                     |
| Subida de archivo              | `ftp_log`        | La `account` usada en el activo, el `filename`, un `value` igual a `upload`, el `remote_addr` y el `user` de la consola |
| Descarga de archivo            | `ftp_log`        | Los mismos campos, con un `value` igual a `download`                                                                    |

Una línea suelta tiene este aspecto, abreviada:

```
Apr 19 15:25:11 10.1.14.125 datadike: login_log - { "backend": "Password",
  "ip": "10.1.10.35", "status": {"label": "successful", "value": true},
  "username": "admin" }
```

La etiqueta `datadike:` es por lo que se filtra en el colector para aislar los registros de la solución.

## Cómo verificar que funcionó

Confirme la llegada al colector, no solo que la configuración se guardó.

1. **Fuerce un evento conocido.** Inicie sesión en la consola, o inicie sesión con una contraseña deliberadamente incorrecta. Ambos producen un registro `login_log` en segundos.
2. **Busque en el colector la etiqueta `datadike:`** en los últimos minutos y localice ese evento exacto. Compare el `username`, la `ip` de origen y el `status` con lo que acaba de hacer: un registro que llega con los campos equivocados es un problema de parser, no de entrega.
3. **Ejercite un segundo tipo de registro.** Suba un archivo pequeño durante una sesión y confirme que llega un registro `ftp_log` con `"value": "upload"`. Que un tipo de registro funcione no demuestra que los demás lo hagan.
4. **Compruebe todos los nodos.** En un clúster, inicie sesión a través de cada nodo y confirme que los registros de cada uno llegan al colector. Este es el fallo que pasa meses inadvertido.
5. **Si añadió un backend de almacenamiento de comandos**, ejecute una sesión de terminal, escriba un comando y después busque ese comando en **Auditoría › Sesiones › Keylogger**. El comando debe aparecer: si el backend está mal configurado, la indexación falla en silencio y la búsqueda en la consola vuelve vacía aunque la sesión sí se grabara.

{% hint style="warning" %}
Pruebe con un inicio de sesión **fallido**, además de uno correcto. Una regla de colector que solo coincide con los aciertos oculta precisamente los eventos para los que se montó el pipeline.
{% endhint %}

## Errores frecuentes

| Síntoma                                                       | Causa                                                                                         | Solución                                                                                                                              |
| ------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| No llega nada al colector                                     | Los servicios no se reiniciaron después de cambiar el archivo                                 | Reinicie los servicios de la solución; la configuración se lee al arrancar                                                            |
| No llega nada, y los servicios sí se reiniciaron              | Protocolo o puerto equivocados, o el colector es inalcanzable desde los nodos                 | Compruebe contra 514/UDP, 514/TCP y 6514/TLS, y pruebe el alcance desde todos los nodos                                               |
| Llegan registros de unas sesiones y de otras no               | Solo un nodo del clúster está reenviando                                                      | Aplique la configuración en todos los nodos                                                                                           |
| Los registros llegan pero caen en el pipeline equivocado      | `SYSLOG_FACILITY` no coincide con la configuración del colector                               | Fije la facility que espera el colector y reinicie                                                                                    |
| Los registros llegan de forma intermitente por UDP bajo carga | UDP no tiene garantía de entrega                                                              | Pase a TCP, o a TLS en 6514                                                                                                           |
| El destino TLS rechaza la conexión                            | El certificado del colector no es de confianza, o el puerto es incorrecto                     | Arregle la cadena de confianza y confirme que el colector escucha en 6514                                                             |
| La búsqueda de comandos en la consola es lenta o vuelve vacía | Los comandos están en la base de datos local, o el backend Elasticsearch está mal configurado | Añada o repare el backend de almacenamiento de comandos y verifíquelo buscando un comando que acabe de escribir                       |
| Los eventos dejan de aparecer para fechas más antiguas        | La retención expiró, con independencia del reenvío                                            | La retención se fija en **Configuración del sistema › Retenciones**; la retención del propio colector es aparte y suele ser más larga |

## Referencia de campos

### Claves de configuración

| Clave             | Significado                                                                                |
| ----------------- | ------------------------------------------------------------------------------------------ |
| `SYSLOG_ENABLE`   | `true` activa el reenvío. Se lee al arrancar el servicio                                   |
| `SYSLOG_ADDR`     | El colector, como `dirección:puerto`, por ejemplo `10.1.12.116:514`                        |
| `SYSLOG_FACILITY` | La facility syslog, por ejemplo `local2`. Debe coincidir con la configuración del colector |

### Puertos por defecto

| Protocolo  | Puerto |
| ---------- | ------ |
| Syslog UDP | 514    |
| Syslog TCP | 514    |
| Syslog TLS | 6514   |

### Colectores que consumen el formato sin parser a medida

| Categoría                      | Productos                                                                                                                  |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------- |
| SIEM                           | Splunk, IBM QRadar, Microsoft Sentinel, Elastic Security, Google Security Operations, Securonix, LogRhythm, Graylog, Wazuh |
| Plataformas de logs y búsqueda | Elastic Stack (ELK), OpenSearch, Loki con Grafana                                                                          |
| Colectores y reenviadores      | rsyslog, syslog-ng, Fluentd, Fluent Bit                                                                                    |
| Suites de monitorización       | SolarWinds, ManageEngine, Paessler PRTG, Nagios                                                                            |

El formato de los registros sigue un estándar común; cualquier cosa que lea syslog estándar o ingiera cargas JSON lo manejará, aparezca o no en la lista anterior.

## Páginas relacionadas

* [Registro de auditoría](/es/pam/administration/audit/audit-trail.md): los registros que se reenvían, y dónde vive cada uno en la consola
* [Informes](/es/pam/administration/audit/reports.md): la otra vía de entrega, extracciones periódicas para personas, no envío continuo
* [Grabaciones de sesión](/es/pam/administration/audit/recordings.md): almacenadas aparte de los registros de eventos
* [Acceso aplicación a aplicación](/es/pam/administration/integrations/application-to-application.md): la otra integración que produce registros de auditoría dignos de vigilar en un SIEM