Devo is a data analytics platform that provides centralized management, monitoring, and analysis of logging data. NXLog can be configured to send log data to the Devo Cloud either directly over TLS/SSL or via the Devo In-House Relay which accepts data via TCP.

All events arriving to the Devo Cloud must have an associated tag that is recognized by Devo. Read more about devo tags in the Devo documentation.

Sending Logs Directly to the Devo Cloud

Sending logs directly to the Devo Cloud does not require any special configuration apart from signing up for the service. Once signed in, the following settings and certificates are available for configuring the om_ssl module instance:

  • The address of the central relay of Devo Cloud is available on the Administration > Relays page. This needs to be used as the value for the Host directive in NXLog.

  • The certificates for the CAFile, CertFile, and CertKeyFile directives can be downloaded by browsing to the Administration > Credentials page and selecting X.509 Certificates on the top.

  • The password for the KeyPass directive can be found next to the certificates.

When sending logs directly to the Devo Cloud, the predefined tag can be added either in the input instance or the output instance of the NXLog configuration.

Example 1. Collecting and Sending Windows Event Logs

Using the im_msvistalog module, the configuration below reads Windows Event Log entries and selects only those entries which contain EventIDs 4624 and 4625. The selected logs are then sent to the Devo Cloud using the om_ssl module. It is required that the "box.win_nxlog."+lc($Channel) tag is added to the data in the output. Read more about the box.win_nxlog tag in the Devo documentation.

The box.win_nxlog tag is a special tag that can only be used with NXLog collecting Windows Event Log with the im_msvistalog module.

For the Host directive, the xx string in the hostname should be replaced with the actual Devo Cloud region.

<Extension json>
    Module          xm_json

<Extension syslog>
    Module          xm_syslog

<Input in>
    Module          im_msvistalog
            <Query Id="0">
                <Select Path="Security">
                *[System[Level=0 and (EventID=4624 or EventID=4625)]]

<Output direct_ssl_devo>
    Module          om_ssl
    CAFile          C:\Program Files\nxlog\cert\chain.crt
    CertFile        C:\Program Files\nxlog\cert\nxlog.crt
    CertKeyFile     C:\Program Files\nxlog\cert\nxlog.key
    KeyPass         topsecret
    AllowUntrusted  TRUE
        $Message = to_json(); 

Below is the header line including the corresponding Devo tag that is added to the beginning of the JSON message.

<14>Jul 28 05:49:42 NXLOGTEST[0x238]:

Below is the event sample of a log message in JSON, which is sent to the Devo Cloud.

  "EventTime": "2020-07-28 05:49:42",
  "Hostname": "NXLOGTEST",
  "Keywords": "9232379236109516800",
  "EventType": "AUDIT_SUCCESS",
  "SeverityValue": 2,
  "Severity": "INFO",
  "EventID": 4624,
  "SourceName": "",
  "ProviderGuid": "{54849625-5478-4994-A5BA-3E3B0328C30D}",
  "Version": 2,
  "TaskValue": 12544,
  "OpcodeValue": 0,
  "RecordNumber": 2747,
  "ActivityID": "{D3963786-6526-0000-8939-96D32665D601}",
  "ExecutionProcessID": 576,
  "ExecutionThreadID": 2816,
  "Channel": "Security",
  "Category": "Logon",
  "Opcode": "Info",
  "SubjectUserSid": "S-1-5-18",
  "SubjectUserName": "NXLOGTEST$",
  "SubjectDomainName": "WORKGROUP",
  "SubjectLogonId": "0x3e7",
  "TargetUserSid": "S-1-5-18",
  "TargetUserName": "SYSTEM",
  "TargetDomainName": "NT AUTHORITY",
  "TargetLogonId": "0x3e7",
  "LogonType": "5",
  "LogonProcessName": "Advapi  ",
  "AuthenticationPackageName": "Negotiate",
  "WorkstationName": "-",
  "LogonGuid": "{00000000-0000-0000-0000-000000000000}",
  "TransmittedServices": "-",
  "LmPackageName": "-",
  "KeyLength": "0",
  "ProcessId": "0x238",
  "ProcessName": "C:\\Windows\\System32\\services.exe",
  "IpAddress": "-",
  "IpPort": "-",
  "ImpersonationLevel": "%%1833",
  "RestrictedAdminMode": "-",
  "TargetOutboundUserName": "-",
  "TargetOutboundDomainName": "-",
  "VirtualAccount": "%%1843",
  "TargetLinkedLogonId": "0x0",
  "ElevatedToken": "%%1842",
  "EventReceivedTime": "2020-07-28 05:50:47",
  "SourceModuleName": "in",
  "SourceModuleType": "im_msvistalog"

Forwarding Logs via the In-House Relay

To forward logs via the Devo In-House Relay, the relay needs to be installed and configured. To learn more about its installation and configuration, see the Installing the Devo Relay section in the Devo documentation.

When forwarding logs to Devo Cloud via the relay, it is best to apply the Devo tags at the input module stage, so data can be identified based on their source. When the events are tagged in their input module, it is only necessary to define the Host and Port directives for the Devo relay.

Example 2. Collecting and Sending Linux System Logs

The configuration below reads file-based system logs from a Linux machine using the im_kernel and im_uds modules. The tags are applied at the input stage. The entries are sent to the Devo relay on the local network, which automatically relays them to the Devo Cloud.

<Extension json>
    Module      xm_json

<Extension syslog>
    Module      xm_syslog

<Input kernel>
    Module      im_kernel
        $Message = to_json(); 

<Input journal>
    Module      im_uds
    UDS         /run/systemd/journal/syslog
        $Message = to_json(); 

<Input devlog>
    Module      im_uds
    UDS         /dev/log
    FlowControl FALSE
        $raw_event =~ s/\s+$//;
        $Message = to_json(); 

<Output devo_relay>
    Module      om_tcp
    Port        13000

Below is the header line including the corresponding Devo tag that is added to the beginning of the JSON message.

<86>Jul 28 10:08:59 ubuntu box.unix.nxlog.devlog:

Below is the event sample of a log message which is sent over TCP to the Devo relay.

  "EventReceivedTime": "2020-07-28 10:08:59",
  "SourceModuleName": "devlog",
  "SourceModuleType": "im_uds",
  "SyslogFacilityValue": 10,
  "SyslogFacility": "AUTHPRIV",
  "SyslogSeverityValue": 6,
  "SyslogSeverity": "INFO",
  "SeverityValue": 2,
  "Severity": "INFO",
  "Hostname": "ubuntu",
  "EventTime": "2020-07-28 10:08:59",
  "SourceName": "box.unix.nxlog.devlog",
  "Message": "pam_unix(sudo:session): session opened for user root by root(uid=0)"

Verification of Data Reception

Reception of log data can be verified using the web interface of Devo. One way to do it is to look at the home page where live event statistics are displayed. This page presents the following information: the incoming event rates, event volumes, the number of received events, and the top 10 event sources.

Devo Dahboard Home

In the Devo Cloud platform, the received data is represented in tables. Devo provides various ways for filtering received logs. For example, the predefined tag allows searching for Windows Event Log events from the security channel. These events were sent directly to the Devo Cloud over SSL/TLS. Read more about searching data in the Devo documentation.

Search Result for the `` Tag

The image below demonstrates the events which are forwarded from a Linux machine via the Devo In-House Relay.

Search Result for the `box.unix` Tag

In addition to the above, tables can be downloaded as CSV, TSV, XLSX, JSON Object Array, JSON Matrix, or as Source files.

Below is an event sample of a log message that has been downloaded from the Devo website in JSON format. The message was sent to the Devo Cloud via the In-House Relay.

  "eventdate": "2020-07-28T09:17:43.271Z",
  "machine": "relayinhouse",
  "facility": "authpriv",
  "level": "info",
  "application": "CRON[669]",
  "appName": "CRON",
  "processId": "669",
  "message": " pam_unix(cron:session): session opened for user root by (uid=0)",
  "user": "root",
  "srcUser": null,
  "srcIp": "null",
  "srcPort": null,
  "obj": null,
  "uid": 0,
  "tty": null,
  "pwd": null,
  "cmd": null,
  "attempt": null,
  "device": null

While we endeavor to keep the information in this topic up to date and correct, NXLog makes no representations or warranties of any kind, express or implied about the completeness, accuracy, reliability, suitability, or availability of the content represented here.

Last revision: 28 July 2020