Kaspersky Unified Monitoring and Analysis Platform

Connectors

Connectors are used for establishing connections between KUMA 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' for receiving data from KUMA services using the 'internal' protocol.
• tcp for passively receiving events over TCP when working with Windows and Linux agents.
• udp for passively receiving events over UDP when working with Windows and Linux agents.
• netflow for passively receiving events in the NetFlow format.
• sflow for passively receiving events in the sFlow format. For sFlow, only structures described in sFlow version 5 are supported.
• nats-jetstream for interacting with a NATS message broker when working with Windows and Linux agents.
• kafka for communicating with the Apache Kafka data bus when working with Windows and Linux agents.
• http for receiving events over HTTP when working with Windows and Linux agents.
• sql 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 application supports the following types of SQL databases:

  • SQLite.
  • MariaDB 10.5 or later.
  • MSSQL.
  • MySQL 5.7 or later.
  • PostgreSQL.
  • Cockroach.
  • Oracle.
  • Firebird.
• file 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 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 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 for unidirectional data transmission in industrial ICS networks using data diodes.
• ftp for getting data over File Transfer Protocol (FTP) when working with Windows and Linux agents.
• nfs for getting data over Network File System (NFS) when working with Windows and Linux agents.
• wmi for getting data using Windows Management Instrumentation when working with Windows agents.
• wec 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 for getting extended logs of DNS servers.
• snmp 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 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 for getting KEDR data via the API.
• vmware for getting VMware vCenter data via the API.
• elastic for getting Elasticsearch data. Elasticsearch version 7.0.0 is supported.
• 'office365' 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.