Connectors

Connectors are used for establishing connections between Kaspersky Unified Monitoring and Analysis Platform services and for receiving events actively and passively.

You can specify connector settings on the Basic settings and Advanced settings tabs. The available settings depend on the selected type of connector.

Connectors can have the following types:

• internal – Used for receiving data from KUMA services using the 'internal' protocol.
• tcp – Used for passively receiving events over TCP when working with Windows and Linux agents.
• udp – Used for passively receiving events over UDP when working with Windows and Linux agents.
• netflow – Used for passively receiving events in the NetFlow format.
• sflow – Used for passively receiving events in the sFlow format. For sFlow, only structures described in sFlow version 5 are supported.
• nats-jetstream – Used for interacting with a NATS message broker when working with Windows and Linux agents.
• kafka – Used for communicating with the Apache Kafka data bus when working with Windows and Linux agents.
• http – Used for receiving events over HTTP when working with Windows and Linux agents.
• sql – Used for querying databases. KUMA supports multiple types of databases. When creating a connector of the sql type, you must specify general connector settings and individual database connection settings.

  The program supports the following types of SQL databases:

  • SQLite.
  • MariaDB 10.5 or later.
  • MSSQL.
  • MySQL 5.7 or later.
  • PostgreSQL.
  • Cockroach.
  • Oracle.
  • Firebird.
• file – Used for getting data from text files when working with Windows and Linux agents. One line of a text file is considered to be one event. \n is used as the newline character.
• 1c-log – Used for getting data from 1C technology logs when working with Linux agents. \n is used as the newline character. The connector accepts only the first line from a multi-line event record.
• 1c-xml – Used for getting data from 1C registration logs when working with Linux agents. When the connector handles multi-line events, it converts them into single-line events.
• diode – Used for unidirectional data transmission in industrial ICS networks using data diodes.
• ftp – Used for getting data over File Transfer Protocol (FTP) when working with Windows and Linux agents.
• nfs – Used for getting data over Network File System (NFS) when working with Windows and Linux agents.
• wmi – Used for getting data using Windows Management Instrumentation when working with Windows agents.
• wec – Used for getting data using Windows Event Forwarding (WEF) and Windows Event Collector (WEC), or local operating system logs of a Windows host when working with Windows agents.
• etw – Used for getting extended logs of DNS servers.
• snmp – Used for getting data over Simple Network Management Protocol (SNMP) when working with Windows and Linux agents. To process events received over SNMP, you must use the json normalizer. Supported SNMP protocol versions:
  • snmpV1
  • snmpV2
  • snmpV3
• snmp-trap – Used for passively receiving events using SNMP traps when working with Windows and Linux agents. The connector receives snmp-trap events and prepares them for normalization by mapping SNMP object IDs to temporary keys. Then the message is passed to the JSON normalizer, where the temporary keys are mapped to the KUMA fields and an event is generated. To process events received over SNMP, you must use the json normalizer. Supported SNMP protocol versions:
  • snmpV1
  • snmpV2
• kata/edr – Used for getting KEDR data via the API.
• vmware – Used for getting VMware vCenter data via the API.
• elastic – Used for getting Elasticsearch data. Elasticsearch version 7.0.0 is supported.
• office365 – Used for receiving Microsoft 365 (Office 365) data via the API.

Some connector types (such as tcp, sql, wmi, wec, and etw) support TLS encryption. KUMA supports TLS 1.2 and 1.3. When TLS mode is enabled for these connectors, the connection is established according to the following algorithm:

• If KUMA is being used as a client:
  1. KUMA sends a connection request to the server with a ClientHello message specifying the maximum supported TLS version (1.3), as well as a list of supported ciphersuites.
  2. The server responds with the preferred TLS version and a ciphersuite.
  3. Depending on the TLS version in the server response:
     • If the server responds to the request with TLS 1.3 or 1.2, KUMA establishes a connection with the server.
     • If the server responds to the request with TLS 1.1, KUMA terminates the connection with the server.
• If KUMA is being used as a server:
  1. The client sends a connection request to KUMA with the maximum supported TLS version, as well as a list of supported ciphersuites.
  2. Depending on the TLS version in the client request:
     • If the ClientHello message of the client request specifies TLS 1.1, KUMA terminates the connection.
     • If the client request specifies TLS 1.2 or 1.3, KUMA responds to the request with the preferred TLS version and a ciphersuite.

In this section Viewing connector settings Adding a connector Connector settings Predefined connectors

Page top