Page Comparison

...

This guide will walk you through the process of updating your configuration from versions <2.0.0 to version versions 2.0x.0x. This version introduces significant improvements and changes to the configuration style to enhance performance, usability, and security.

Version Versions 2.0x.0 is x are incompatible with previous versions . The new version needs (1.x.x). New versions need some adjustments to the configuration file to ensure a smooth migration process. The following sections will guide you through the necessary steps to update your configuration.

...

1. Backup your current configuration: Make sure you have a backup of your existing configuration files to prevent any data loss.

2. Review the new configuration documentation: Familiarize yourself with the new configuration options available in version 2.0x.0x.

Migration steps

Step 1: Update credentials

...

# Old version (<21.0x.0x)
account:
  ikey: 'NQ0XXXABC69XXXXYZI0F'
  skey: 'Kqfd1XXXX1bCX42OXXXLxNukWXXXXgUpXXX6KUaT'
  hostname: 'api-1a2b3c4d.duosecurity.com'

# New version (2.0x.0x)
credentials:
  integration_key: NQ0XXXABC69XXXXYZI0F
  secret_key: Kqfd1XXXX1bCX42OXXXLxNukWXXXXgUpXXX6KUaT
  hostname: api-1a2b3c4d.duosecurity.com

...

The <start_datetime_utc_value> has the format "YYYY-MM-DDTHH:MM:SS.000Z". For example, a valid start_datetime_utc_value would be "2024-07-01T00:00:00.000Z".

Devo collector features

Data source description

This collector extracts data from 3 log services available from Duo:

• Administrator: Returns a list of administrator log events.

• Authentication: Returns a paged list of authentication log events.

• Telephony: Returns a list of telephony log events.

API limits

• Administrator:

  • Only the 1000 earliest events (maximum) will be returned with each page; the collector will be called multiple times to page through the entire log.

  • The recommended limit suggests requesting logs no more than once per minute.

• Authentication:

  • Returns a paged list of authentication log events ranging from the last 180 days up to as recently as two minutes before the API request. There is an intentional two minute delay in availability of new authentications in the API response. Duo operates a large scale distributed system, and this two minute buffer period ensures that calls will return consistent results. Querying for results more recent than two minutes will return as empty.

  • The recommended limit suggests requesting logs no more than once per minute.

• Telephony:

  • Returns a paged list of authentication log events ranging from the last 180 days up to as recently as two minutes before the API request. There is an intentional two minute delay in availability of new telephony events in the API response. Duo operates a large scale distributed system, and this two minute buffer period ensures that calls will return consistent results. Querying for results more recent than two minutes will return as empty.

  • The recommended limit suggests requesting logs no more than once per minute.

...

Accepted authentication methods

Vendor setup

You need the owner role to perform these steps. Learn more here.

Rw ui steps macro

Rw step Sign up for a Duo account. If you use a 30-day free Duo Advantage trial, this includes Admin API access. Rw step Log in to the Duo Admin Panel and navigate to Applications. Rw step Click Protect an Application and locate the entry for Admin API in the applications list. Click Protect on the far right to configure the application and get your integration key, secret key, and API hostname. You'll need this information to complete your setup. See Protecting Applications for more information on protecting applications in Duo and additional application options. Rw step Determine the permissions you want to grant to this Admin API application. Refer to the API endpoint descriptions throughout this document for information about required permissions for operations. For these logs, you will need Grant read log API permissions. Rw step Optionally, specify which IP addresses or ranges are allowed to use this Admin API application in Networks for API Access. If you do not specify any IP addresses or ranges, this Admin API application may be accessed from any network. The Admin API performs the IP check after verifying the authentication signature in a request. If you restrict the allowed networks for API access and see logged events for blocked Admin API requests from unrecognized unrecognised IP addresses, this may indicate a compromise of your Admin API application's secret key.

...

The security of your Duo application is tied to the security of your secret key (skey). Secure it as you would any sensitive credential. Don't share it with unauthorized individuals or email it to anyone under any circumstances!.

Connectivity requirements

This application communicates with Duo's service on SSL TCP port 443. Firewall configurations that restrict outbound access to Duo's service with rules using destination IP addresses or IP address ranges aren't recommended, since these may change over time to maintain our service's high availability. If your organization requires IP-based rules, please review Duo Knowledge Base article 1337. Effective June 30, 2023, Duo no longer supports TLS 1.0 or 1.1 connections or insecure TLS/SSL cipher suites. See Duo Knowledge Base article 7546 for additional guidance.

Run the collector

Once the data source is configured, you can either send us the required information if you want us to host and manage the collector for you (Cloud collector), or deploy and host the collector in your own machine using a Docker image (On-premise collector).

Rw ui tabs macro

Rw tab title Cloud collector We use a piece of software called Collector Server to host and manage all our available collectors. To enable the collector for a customer: In the Collector Server GUI, access the domain in which you want this instance to be created Click Add Collector and find the one you wish to add. In the Version field, select the latest value. In the Collector Name field, set the value you prefer (this name must be unique inside the same Collector Server domain). In the sending method select Direct Send. Direct Send configuration is optional for collectors that create Table events, but mandatory for those that create Lookups. In the Parameters section, establish the Collector Parameters as follows below: Editing the JSON configuration Code Block { "global_overrides": { "debug": false }, "inputs": { "duo": { "id": "<short_unique_id>", "enabled": true, "credentials": { "integration_key": "<integration_key_value>", "secret_key": "<secret_key_value>", "hostname": "<hostname_value>" }, "services": { "administrator": { "start_datetime_utc": "<start_datetime_utc_value>", "override_base_tag": "<override_base_tag_value>" }, "authentication": { "start_datetime_utc": "<start_datetime_utc_value>", "override_tag": "<override_tag_value>" }, "telephony": { "start_datetime_utc": "<start_datetime_utc_value>", "override_tag": "<override_tag_value>" } } } } } Info All defined service entities will be executed by the collector. If you do not want to run any of them, just remove the entity from the services object. Please replace the placeholders with real world values following the description table below: Parameter Data type Requirement Value range / Format Description short_unique_id int Mandatory Min length: 1 Short, unique ID for input service, used in persistence addressing. Avoid duplicates to prevent collisions. integration_key_value str Mandatory Min length: 1 Client ID for Duo authentication. secret_key_value str Mandatory Min length: 1 Client secret for Duo authentication. hostname_value str Mandatory Min length: 1 Host for Duo requests. This is different for each customer. override_base_tag_value str Optional level1.level2 If present, the family of administrator logs will have a level1.level2 different from auth.duo. Use this only with my.app or you won't be able to see the logs in Devo. override_tag_value str Optional level1.level2.level3.level4 If present, the authentication and telephony logs will have a level1.level2.level3.level4 different from auth.duo.authentication.events and auth.duo.telephony.events. Use this only with my.app.level3.level4 or you won't be able to see the logs in Devo. start_datetime_utc_value str Optional "YYYY-MM-DDTHH:MM:SS.mmmZ" If present, it will be the start date and time for pulling events. If not, the current date and time will be used. Example: 2024-07-01T03:00:00.000Z Rw tab title On-premise collector This data collector can be run in any machine that has the Docker service available because it should be executed as a docker container. The following sections explain how to prepare all the required setup for having the data collector running. Structure The following directory structure should be created for being used when running the collector: Code Block <any_directory> └── devo-collectors/ └── <product_name>/ ├── certs/ │ ├── chain.crt │ ├── <your_domain>.key │ └── <your_domain>.crt ├── state/ └── config/ └── config.yaml Note Replace <product_name> with the proper value. Devo credentials In Devo, go to Administration → Credentials → X.509 Certificates, download the Certificate, Private key and Chain CA and save them in <product_name>/certs/. Learn more about security credentials in Devo here. Image Added Note Replace <product_name> with the proper value. Editing the config.yaml file Code Block globals: debug: false id: not used name: duo persistence: type: filesystem config: directory_name: state outputs: devo_1: type: devo_platform config: address: <devo_address> port: 443 type: SSL chain: <chain_filename> cert: <cert_filename> key: <key_filename> inputs: duo: id: <short_unique_id> enabled: true credentials: integration_key: <integration_key_value> secret_key: <secret_key_value> hostname: <hostname_value> services: administrator: start_datetime_utc: <start_datetime_utc_value> override_base_tag: <override_base_tag_value> authentication: start_datetime_utc: <start_datetime_utc_value> override_tag: <override_base_tag_value> telephony: start_datetime_utc: <start_datetime_utc_value> override_tag: <override_base_tag_value> Replace the placeholders with your required values following the description table below: Parameter Data type Requirement Value range / Format Description short_unique_id int Mandatory Min length: 1 Short, unique ID for input service, used in persistence addressing. Avoid duplicates to prevent collisions. integration_key_value str Mandatory Min length: 1 Client ID for Duo authentication. secret_key_value str Mandatory Min length: 1 Client secret for Duo authentication. hostname_value str Mandatory Min length: 1 Host for Duo requests. This is different for each customer. override_base_tag_value str Optional level1.level2 If present, the family of administrator logs will have a level1.level2 different from auth.duo. Use this only with my.app or you won't be able to see the logs in Devo. override_tag_value str Optional level1.level2.level3.level4 If present, the authentication and telephony logs will have a level1.level2.level3.level4 different from auth.duo.authentication.events and auth.duo.telephony.events. Use this only with my.app.level3.level4 or you won't be able to see the logs in Devo. start_datetime_utc_value str Optional "YYYY-MM-DDTHH:MM:SS.mmmZ" If present, it will be the start date and time for pulling events. If not, the current date and time will be used. Example: 2024-07-01T03:00:00.000Z Download the Docker image The collector should be deployed as a Docker container. Download the Docker image of the collector as a .tgz file by clicking the link in the following table: Collector Docker image SHA-256 hash collector-duo_collector-docker-image-2.0.1 51244c2b8c06f3594bba57877690caf9b64977d6e88ee231b3baaeff394ebbdb Use the following command to add the Docker image to the system: Code Block gunzip -c <image_file>-<version>.tgz | docker load Note Once the Docker image is imported, it will show the real name of the Docker image (including version info). Replace <image_file> and <version> with a proper value. The Docker image can be deployed on the following services: Docker Execute the following command on the root directory <any_directory>/devo-collectors/<product_name>/ Code Block docker run --name collector-<product_name> --volume $PWD/certs:/devo-collector/certs --volume $PWD/config:/devo-collector/config --volume $PWD/state:/devo-collector/state --env CONFIG_FILE=config.yaml --rm --interactive --tty <image_name>:<version> Note Replace <product_name>, <image_name> and <version> with the proper values. Docker Compose The following Docker Compose file can be used to execute the Docker container. It must be created in the <any_directory>/devo-collectors/<product_name>/ directory. Code Block version: '3' services: collector-<product_name>: image: <image_name>:${IMAGE_VERSION:-latest} container_name: collector-<product_name> volumes: - ./certs:/devo-collector/certs - ./config:/devo-collector/config - ./credentials:/devo-collector/credentials - ./state:/devo-collector/state environment: - CONFIG_FILE=${CONFIG_FILE:-config.yaml} To run the container using docker-compose, execute the following command from the <any_directory>/devo-collectors/<product_name>/ directory: Code Block IMAGE_VERSION=<version> docker-compose up -d Note Replace <product_name>, <image_name> and <version> with the proper values.

Collector services detail

This section is intended to explain how to proceed with specific actions for services.

For all the services

Devo categorization and destination

Please check the section Data Source Description to learn about the target tables for each service.

Restart the persistence

This collector uses persistent storage to download events in an orderly fashion and avoid duplicates. In case you want to re-ingest historical data or recreate the persistence, you can restart the persistence of this collector by following these steps:

1. Edit the configuration file.

2. Change the value of the start_datetime_utc_value to a different one.

3. Save the changes.

4. Restart the collector.

The collector will detect this change and will restart the persistence using the parameters of the configuration file or the default configuration in case it has not been provided.

Troubleshooting

This collector has different security layers that detect both an invalid configuration and abnormal operation. This table will help you detect and resolve the most common errors.

Configuration errors

Collector operations

Verify collector operations

This is for the standalone mode only. You can check the information in the following sections to verify the correct collector operation.

Initialization

The initialization module validates the given configuration and runs the setup, the input (pulling logic), and output (delivering logic) services. A successful run has the following output messages for the initializer module:

2023-01-10T15:22:57.146 INFO MainProcess::MainThread -> Loading configuration using the following files: {"full_config": "config-test-local.yaml", "job_config_loc": null, "collector_config_loc": null}
2023-01-10T15:22:57.146 INFO MainProcess::MainThread -> Using the default location for "job_config_loc" file: "/etc/devo/job/job_config.json"
2023-01-10T15:22:57.147 INFO MainProcess::MainThread -> "\etc\devo\job" does not exists
2023-01-10T15:22:57.147 INFO MainProcess::MainThread -> Using the default location for "collector_config_loc" file: "/etc/devo/collector/collector_config.json"
2023-01-10T15:22:57.148 INFO MainProcess::MainThread -> "\etc\devo\collector" does not exists
2023-01-10T15:22:57.148 INFO MainProcess::MainThread -> Results of validation of config files parameters: {"config": "C:\git\collectors2\devo-collector-<name>\config\config.yaml", "config_validated": True, "job_config_loc": "/etc/devo/job/job_config.json", "job_config_loc_default": True, "job_config_loc_validated": False, "collector_config_loc": "/etc/devo/collector/collector_config.json", "collector_config_loc_default": True, "collector_config_loc_validated": False}
2023-01-10T15:22:57.171 WARNING MainProcess::MainThread -> [WARNING] Illegal global setting has been ignored -> multiprocessing: False

Event delivery and Devo ingestion

The event delivery module is in charge of receiving the events from the internal queues where all the events are injected by the pullers and delivering them using the selected compatible delivery method. A successful run has the following output messages for the initializer module:

2023-01-10T15:23:00.788    INFO OutputProcess::MainThread -> DevoSender(standard_senders,devo_sender_0) -> Starting thread
2023-01-10T15:23:00.789    INFO OutputProcess::MainThread -> DevoSenderManagerMonitor(standard_senders,devo_1) -> Starting thread (every 300 seconds)
2023-01-10T15:23:00.790    INFO OutputProcess::MainThread -> DevoSenderManager(standard_senders,manager,devo_1) -> Starting thread
2023-01-10T15:23:00.842    INFO OutputProcess::MainThread -> global_status: {"output_process": {"process_id": 18804, "process_status": "running", "thread_counter": 21, "thread_names": ["MainThread", "pydevd.Writer", "pydevd.Reader", "pydevd.CommandThread", "pydevd.CheckAliveThread", "DevoSender(standard_senders,devo_sender_0)", "DevoSenderManagerMonitor(standard_senders,devo_1)", "DevoSenderManager(standard_senders,manager,devo_1)", "OutputStandardConsumer(standard_senders_consumer_0)",

Sender services

The Integrations Factory Collector SDK has 3 different sender services depending on the event type to deliver (internal, standard, and lookup). This collector uses the following Sender Services:

Sender statistics

Each service displays its performance statistics that allow checking how many events have been delivered to Devo by type:

Check memory usage

To check the memory usage of this collector, look for the following log records in the collector which are displayed every 5 minutes by default, always after running the memory-free process.

• The used memory is displayed by running processes and the sum of both values will give the total used memory for the collector.

• The global pressure of the available memory is displayed in the global value.

• All metrics (Global, RSS, VMS) include the value before freeing and after previous -> after freeing memory

  INFO InputProcess::MainThread -> [GC] global: 20.4% -> 20.4%, process: RSS(34.50MiB -> 34.08MiB), VMS(410.52MiB -> 410.02MiB)
  INFO OutputProcess::MainThread -> [GC] global: 20.4% -> 20.4%, process: RSS(28.41MiB -> 28.41MiB), VMS(705.28MiB -> 705.28MiB)

Change log